Leaderboard

I'm not concerned about the complexity of the migration. That's a one-time task. What you and I want to achieve is the best outcome for contributing to the project and managing its infrastructure afterwards. It's just that we seem to prefer different trade-offs. What do you mean by "bundled modules" and what issue exactly did you encounter? As we haven't been able to convince each other which approach is the better one, it's just two personal opinions. In that case I'd suggest moving forward with whatever approach you prefer, as that's the approach you already put time into (and I'm none of the main contributors to the 0ad client application anyway). However, I was hoping to get feedback on the different approaches from other developers as well. If we need a git-compatible checkDiff.py I'd be happy to implement that. You did great work so far and all the late discussion is on me, because I didn't read the details of the planned setup earlier and raised my concerns back then. As mentioned earlier already, I'm really sorry about that.

Thanks for giving a hand In other news, I have added SPIR-V generation (still running) to the nightly build, and, through a sprint, I also set up a separate translations repository, to see how it would work in practice. I'd have to document it on the dev environment page if we go with that, but basically: upon each commit to the main repo, pot files are generated and pushed to the translations repo for the future: ideally, after that pot update, we should push templates to Transifex instead of letting them autoupdate daily, the translation repo pulls updates from Transifex. in the future, we should run the check script and also lint po files, and follow translation issues in that repo. we should be able to eliminate issues such as #4250 This system still has some rough edges but here are my comments after developing that: the concerns are nicely separated now. all interaction with Transifex happens in the translations repo. that's a really good thing. this separate repo will be the perfect place to collaborate with translators and fix long-standing issues such as #4250 the base git repo only sends generated pot files using messages.json and updateTemplates.py. I deleted all the other scripts and all the .tx/config files the translation repo holds the majority of i18n python scripts, which do not need to know about the structure of the data/ dir anymore, that should make their maintenance simpler the checkDiff.py script does not work anymore with git, it was developed specifically for SVN! so the translations git repo gets all po/pot updates even if they are irrelevant. it is not a big deal for that auxiliary repo, but this is another dealbreaker against the idea of having translations in the main git repo. this new repo adds some complexity to the migration, as those scripts need to receive changes for that new infrastructure the nightly repo (and the git repo) can fetch the translations without using svn export... but git does not have that "export" feature so the new fetch script relies on creating a temporary shallow clone, that's a bit yucky the Jenkins setup is much more complex now, with two extra jobs (maybe three if we add a push job to Transifex) on top of the nightly-build job. It is impractical to commit and push to git using Jenkins, this is definitely not a standard use case, and my pipelines may break in the future if Jenkins features evolve. (this reinforces my prejudice against letting bots push to git) the Jenkins setup around the translation updates is not covered by Gitea features. it will be impractical to setup post-commit triggers for this. In a nutshell, I think that this alternative way of handling translations is on the pros side: separates issues, addresses some of your concerns, and gives us much more flexibility in our interactions with Transifex, with room for improvement; on the cons side: more complex to maintain for Jenkins, would require extra development work for you and other Python devs around the migration

Alright good news! I tried borderless.fullscreen = false in user.cfg but I also needed to set xres = "3840" and yres = "2160" because otherwise resolution changed to something like 1024x768 (I think boonGUI has something to do with this) and everything turned big and ugly with these 3 variables set this way it looks incredibly beautiful as it should be so the file ended up this way: borderless.fullscreen = "false" xres = "3840" yres = "2160" curiously now i can go fullscreen and typography and graphics has antialiasing I removed and introduced the line a few times to confirm. Thank you so much for your time, Stan!

The popup in the main menu does a good job

No joke, the cinematic models back in 2002 had one 256x256 texture. I believe 256x256 was the engine's texture size limit.

Able to replace some Unicode characters with typical ASCII counterparts on the Main wiki page. Also made a proof-concept entry for the Han civilization, it just needs some additions based on the Trac counterparts. On a side note, @wowgetoffyourcellphone: what are the Chinese characters used in the term "Wu Wei Yin", and any basis for the Sun Wu Trouble Freeing Forces?

ok, today version 10 is out! Be sure to check out the new sparta content and the updated values for naval units.