Dunedan

Where would something like https://github.com/0ad/lobby-infrastructure/ fit with that?

What I miss in Gitea right now (maybe I haven't just found it yet) is an overview of all (official) public repositories. https://gitea.itms.ovh/ just shows an empty way (aside from the menu and filter options on the right side). The generated ones, which just contain the first letter of the name on top of a colored background are something I wouldn't consider migrating. What I was talking about are the ones uploaded manually by the users. I'm pretty sure that's compliant, because only the underlying software changes, not the context and purpose the data is used for. With your argument migrating the accounts themselves wouldn't be compliant either. btw: Gitea also offers an Oauth2 provider with support for OpenID Connect (https://docs.gitea.com/development/oauth2-provider). That means we could use Gitea as central user management tool for all WFG related developer tools. That'd remove the need for different accounts for different services.

Yes, but in a private repo. Not directly related to the migration, but is code or documentation for the set up of the new infrastructure available somewhere? I find being able to do pull requests for infrastructure as well pretty helpful. I'm in favor of sunsetting Trac and Phab as fast as possible and as long as the links continue to work, by being redirected to Gitea. True. I also disliked the fact you could make the diff private on Phab because that's kind of anti open source to me and moreover it broke the bot as well. If you're gonna have private code maybe don't share it at all... There are valid cases for having stuff with limited visibility at first. I'm thinking about proposed changes and associated discussions which relate to serious security vulnerabilities, where vulnerability details shouldn't be public before a fix is shipped. However, I guess even with everything open on Gitea, we can handle such situation through other channels. Also mind that limiting repositories for users doesn't help much against spam/malicious stuff, if forking existing repositories is still possible, as one can simply replace the content of the forked repository with something else. I'd like to keep trunk for historical/nostalgic reasons, and also because I'd like us to explicitly follow a trunk-based development model. I am open to discussion about that. The vast majority of git repository uses "master" or "main" as their primary branch name. I'd prefer doing so for 0ad as well, as people are used to it. I actually can't remember having ever seen a git repository using a branch named "trunk" as their primary branch. Just recently I was working on a git repository which used a different name for their primary branch and it was such a PITA, as muscle memory (git checkout ma<TAB>) didn't work. What do you mean about surprising? In terms of privacy you mean? (if yes, I tried to be precise in the privacy policy, and people who don't use Gravatar won't have their data sent there, so they are not supposed to complain unless I missed something). For the PoC, getting the profiles from Gravatar allows one to have a sense of the look and feel of the platform and of the community interactions. I wouldn't like to see everyone with generated avatars... For the actual migration, active users will be able to populate their profile, but IMO it would be a bit of a shame to leave all the old members of the community without a face. I'm very happy to see a profile pic associated with janwas or k776 for instance. As Gitea is configured right now, for every request where a profile image is meant to be shown, a request for the user whose image is supposed to be shown is made to Gravatar, unless that user uploaded an own image in Gitea. As these requests happen for every visitor, Gravatar is able to track visitors of our Gitea instance, without them being able to consent to this first. I believe this doesn't comply with GDPR. Upstream Gitea now also ships with OFFLINE_MODE=true by default (https://github.com/go-gitea/gitea/pull/28548), which disables requests to gravatar.com and other external services. Did Phabricator even support Gravatars or were all profile images there uploaded by the users themselves? Maybe it'd be an alternative to migrate the existing profile images from Phabricator to Gitea instead.

Thanks a lot. With OpenGL the GLSL shaders get generated on-the-fly and cached on disk, if they aren't present, aren't they? Would that be possible for Vulkan as well?

I just checked and yes, it's caused by an old save game from 2019. Also no new behavior with Alpha 27/svn, but happens with Alpha 26 already as well.

Are there now instructions how to build the SPIR-V shaders locally somewhere? If not, it'd be great if those could be added.

This is fixed now. If you don't mind, could you please close the PR on Github (or grant me the necessary permissions)?

The "Demo campaign - new maps" campaign doesn't include a single scenario and is therefore unplayable.

When deselecting the "Filter compatible saved games" checkbox in the load game screen a JavaScript error is printed, no matter if saved games exist or not: ERROR: JavaScript error: gui/common/l10n.js line 69 Script value conversion check failed: v.isString() || v.isNumber() || v.isBoolean() (got type undefined) translate@gui/common/l10n.js:69:36 updateSavegameList/list<@gui/loadgame/SavegameList.js:134:35 updateSavegameList@gui/loadgame/SavegameList.js:129:38 SavegameList/this.compatibilityFilter.onPress@gui/loadgame/SavegameList.js:27:51 ERROR: Errors executing script event "Press

The headline "Welcome to the 0 A.D. tutorial." shown at the beginning of the tutorial is broken in Alpha 27 and not being translated. Seems to caused by the introduction of non-breaking white spaces.

I just noticed that there is an additional "Isthmus of Corinth" map in Alpha 27. That means we now have four different ones of these maps: Corinthian Isthmus Corinthian Isthmus (2) Corinthian Isthmus (4) Isthmus of Corinth (2) Can we somehow consolidate or rename them, so we don't have these name collisions? There are surely other Isthmen to name maps after.

I actually would want to improve quite a few strings, however as that wipes out the existing translations on every change, I'm not sure if that's a good idea. That's especially a problem for languages without much translation activity. Yes, the suggested translations also seem to include translations of strings which don't exist anymore. I noticed that only after writing this post. However, that still just a workaround and requires translators to actively check the suggestions, but it's better than nothing of course. I agree with all of that, but getting translations constantly wiped is a pretty big downside in my opinion, so I was wondering if there are alternative solutions which might have less downsides. If there are none, well, that's how it is then.

I recently started to do some translation work for 0 A.D. While I had a high opinion of Transifex before, I quickly realized that it has a major shortcoming: When doing the translations, I noticed that lots of strings which were already translated in the past and do for example show up translated in Alpha 26, wouldn't show up as translated in Transifex. I was quickly able to track that down to https://trac.wildfiregames.com/changeset/27786, which replaced the regular white space in "0 A.D." with a non-breaking one. While a valueable change, that erased hundreds of translations as Transifex doesn't support fuzzy translations (https://help.transifex.com/en/articles/6220794-gettext-po#h_c820bfaa77). That means whenever somebody changes an untranslated string and be it such a tiny change, the whole translation gets wiped out and the translators don't even get the previous translation shown to adapt it. That's really annoying and results in a lot of unnecessary work. So I was wondering if we should look for an alternative to Transifex which does handle that better. Does somebody have experience with other web-based (preferably Open Source) translation tools? Any other idea how we can mitigate this issue?

That just means you're not as good as you think. I suggest you play a few games against other human players using the multiplayer lobby and you'll quickly notice that AI at any level is still quite easy to defeat.

Because of the complexity of modern software, I believe it's utterly important to keep third-party dependencies to a minimum when developing software. One of the worst offenders there is probably the JavaScript eco-system, where you quickly pull in dependencies by the hundreds if not thousands. It's kind of interesting. I'd argue that the vast majority of people are ethical and as corporations consist of people they therefore should be ethical as well. However, once a corporation reaches a certain size, its employees start making unethical decisions (or at least decisions which aren't in the interest of their customers).

I'm really looking forward for the migration to Gitea, as it makes contributing so much easier and as it bundles different functionality (tickets, wiki, code review, ...) it'll significantly reduce the complexity of infrastructure we need. Great work @Itms.

You need an ejabberd server with the proper configuration. Not sure if that'd work on other operating systems than Linux. Setting this up can be cumbersome, but we got https://github.com/0ad/lobby-infrastructure/ which makes it straight-forward to fire up a virtual machine under any operating system to get an environment to test and play around.

The code for the lobby bots, including the rating logic, is available here: https://github.com/0ad/lobby-bots For pull requests which change such fundamentals as how ratings work, I'd like to see a solid and reasonable explanation how it improves the game experience, before accepting them. In any case I'd be happy to see community contributions to the lobby bots and I am there to answer any questions which might arise doing so.

The lobby is online again now. It's not entirely clear what's causing the problems yet. So far we've implemented a workaround, which seems to work for now. We'll monitor the situation and continue to work on figuring out the root case. As it looks right now the problem could be hardware related, but we don't know for sure yet. I'll post a comment here whenever there is something newsworthy.

We're having some issues with the lobby right now, but we're working on it. I'll post an update once it's back up.

Thanks for the heads up, however the forums aren't a good place for such urgent information, as receiving and reading its notifications might come with a significant delay. In fact I just did see this post when I went to the forums to post the post-mortem, you can see below. Pinging me in the lobby (as long as it's still available) or in the 0ad channels on IRC is usually much faster. Today's lobby outage happened between 18:31 UTC and 19:04 UTC. During that outage the ability to host games or join hosted games was limited and the lobby bots rapidly quit and rejoined the lobby, leading to a lot of spam due to the quit and join messages. Here is why that happened: Earlier today I merged some lobby related infrastructure improvements (https://github.com/0ad/lobby-infrastructure/) and deployed the changes to the lobby VM. As part of that I accidentally deployed the productive configuration (lobby-config.yml) to a local instance of the lobby running as a Vagrant VM on my machine as well. This happened, because the hosts file I use for Ansible didn't just contain the VM of the official lobby, but my local instance as well and I wasn't limiting applying the changes to the official lobby (using ansible-playbook --limit …). I had my local lobby instance in the hosts file, because I sometimes test things which are easier to do with ansible-playbook, than with vagrant provision. While I did notice the incorrect deployment of the productive config to my local VM, I didn't recognize the possible impact that might have and instead figured that running vagrant provision later on would cause the correct config to be used for my local instance and would fix everything again. When I ran vagrant provision later to test some unrelated changes locally, the correct config (lobby-config-vagrant.yml) did get used, but instead of fixing things, it resulted in the outage. That's because deploying changes to the lobby bots doesn't remove possibly existing instances of the lobby bots. So if for example a bot named xpartamupp1 is present on a target host, it doesn't get removed when a new deployment happens which doesn't include xpartamupp1 in its config anymore, but rather includes for example xpartamupp2. That alone wouldn't have been an issue, but that deployment also removed the mapping of lobby.wildfiregames.com to 127.0.0.1 in /etc/hosts, as is done for the productive lobby to ensure the lobby bots don't need to do a network round-trip when connecting to the ejabberd which runs on the same host. That then caused the productive lobby bots to connect to the official ejabberd server instead to the one running on localhost. That meant suddenly for all bots two instances with the same XMPP resource were connecting and that caused ejabberd to kick out the one connected first. As each bot then immediately reconnected again, that resulted in a kick-loop which caused the rapid quits and rejoins of the lobby bots. To get out of this situation I simply stopped the bots on my local lobby instance again. That took a bit, as I had to figure out the reason for the problems first. While that whole outage was ultimately my fault, I believe there are some things we can improve to avoid such problems or their impact in future: - Adjust the Ansible code to delete (or at least disable) lobby bots present on the target host, but not in the configuration used to deploy. - Fix the lobby bots so they honor the reconnect delay when getting kicked like in this situation. - Avoid putting hosts which aren't the official lobby host in Ansible's `hosts` file. If somebody wants to step in and contribute to these improvements or would like to see other improvements, pull requests for https://github.com/0ad/lobby-bots/ and https://github.com/0ad/lobby-infrastructure/ are always welcome.

I see little value in automated matchmaking with the current numbers of players playing multiplayer games, as matching with equally ranked players would either take much too long and/or would match with the same opponents over and over again. For making a meaningful difference to just selecting a game as it is right now, match making IMO would have to happen server-side (as it could be easily gamed with modified clients otherwise), such games must not be visible in the existing lobby and 0 A.D. clients must not know the identity of the opponent before a game starts. While one of the players would still need to host the game, its settings shouldn't be set by the host, but based on the preferences of all matched players and should be set by the server logic. Implementing it this way would also offer the ability to centrally punish known smurfs or cheaters, as we could deny them to participate in such automatically matched games (or shadowban them, match them with stronger players, ...). Maybe it'd make sense to introduce automated matchmaking only when WFG-hosted games are an option as well, as that'd remove a whole bunch of problems.

I wanted to share some details about the migration of the lobby we did on Friday and what went problems we encountered while doing so. That'll take a bit to explain so I suggest grab a cup of tea and some cookies before you continue to read. The motivation for migrating the lobby to a new server was to get it into an up-to-date state and to improve its performance. The operating system on the previous server was already getting older and as it got manually updated over the past years, there was lots of stuff on the server, which wasn't really necessary for operating the lobby. Therefore, to start with a clean slate, we decided to set up a new server from scratch. Server in this case means a new virtual machine as part of the infrastructure Wildfire Games has available to host everything related to 0 A.D. Instead of manually configuring the new server, we wrote so called playbooks for a tool called Ansible, which are instructions written as code how to configure such a server. We did so to increase transparency and documentation what's running on the lobby server. Going forward instead of doing manual changes on the live lobby, changes are written in Ansible code and can be reviewed like any other code related to 0.A.D. as well. This also improves the ability to test changes in an isolated environment instead of having to use the live lobby for that, as the written Ansible code makes it easy to configure other computers the same way. With an additional tool called Vagrant, which allows easy creation of virtual machines running on your local computer, it's now easy to get a nearly identical copy of the official lobby running for testing purposes on your own computer. If you're interested in the details regarding that, please check out the git repository where we published all of that: https://github.com/0ad/lobby-infrastructure/. If you're interested in participating and improving the infrastructure behind the lobby, contributions are always welcome there as well. While having the configuration of the lobby available as Ansible playbooks means that configuring a new server is just a matter of running a single command and waiting a few minutes, that's only true for a new lobby without any existing state. State in this context means lobby accounts, ratings and certain logs we wanted to keep. As migrating the state takes additional time and care and because unexpected things might (and in fact did) happen during such a migration, we planned a quite long downtime of 4 hours. However, the actual migration only took roughly one hour and once everything looked good again we made the lobby available for all of you again. Unfortunately, that's when we and some of you started to notice some problems, which took us quite a while to debug and fix. Here is a list of the most critical and interesting problems we encountered: Games becoming invisible Once more and more of you joined the lobby after the migration, eager to play again, we quickly noticed that something wasn't right. Games would become invisible or wouldn't even show up in the first place. After searching for a while, we figured out that this was caused by rate-limiting of messages getting sent through the server. There is rate-limiting in place to avoid spamming of large amounts of messages. That means that each user can only send a certain amount of text per second. During the migration we made a mistake in the configuration and applied the same rate-limiting which applies to all players to the bot managing the games as well. While you don't see many written messages from WFGBot, it's actually a pretty busy bot and sends out a lot of messages which get processed by 0.A.D. to be able to show you the list of games. With WFGBot not being able anymore to send all messages it wanted to send, this meant the list of shown games would be outdated or even completely empty, because your instance of 0.A.D. wouldn't get up-to-date information of the available games. We didn't catch this problem in our testing prior to the migrating, as our test setup had too little volume in terms of online players and hosted games to trigger the rate-limiting. Fortunately the fix for this problem was easy and just required fixing the mistake in the configuration. Lots of stale and outdated games being shown With invisible games not being a problem anymore, the list of games constantly grew and quickly started to show games whose hosts had already left the lobby. That's no new problem, and you've probably seen such stale games in the past already. That happens when WFGBot doesn't get a notification when a player hosting a games leaves the lobby, as WFGBot then doesn't know that that player isn't hosting a games anymore. We don't know why that happens sometimes, but it does and when it does it leaves behind such stale games. To avoid this problem going forward we added a filter to only show hosted games whose host is still online, which fixes this problem. Windows users not able to join anymore with TLS-encrypted connections Another problem which became visible was that Windows users weren't able to join the lobby anymore if they had TLS-encrypted connections enabled in the settings (which is the default and a good idea to have set). To explain why that happened I have to back up a bit. Core of the lobby is a protocol called XMPP. At its core XMPP is an extensible chat protocol. When you connect to the lobby using 0.A.D., it'll establish an XMPP-connection to an XMPP-server running as part of the lobby. Such connections can be unencrypted or encrypted with TLS. TLS is the encryption protocol also used when you visit websites whose protocol is HTTPS, like your beloved https://play0ad.com/. TLS is available in multiple versions. For historical reasons 0.A.D. up to Alpha 26 on Windows only works with TLS v1.0, which is deprecated nowadays and usually already disabled by default. Connecting to the lobby with TLS-encrypted connections didn't work for Windows users right after the migration, because the lobby XMPP-server didn't offer TLS v1.0 anymore, but only more recent TLS versions. However, the configuration of the XMPP-server was fine. What we missed during the migration of the lobby was to enable TLS v1.0 in OpenSSL, the library the XMPP-server uses for all the heavy-duty TLS-related work. Interestingly, even if we hadn't missed that it wouldn't have worked, because the configuration for OpenSSL required slightly different parameters than before thanks to it being a newer OpenSSL version. Nevertheless, this problem should have been surfaced during testing before the migration, but didn't because we simply forgot to test with Windows. The fix was once again straight-forward and just involved setting the correct OpenSSL configuration after we figured out what exactly the culprit was there. Going forward we'd love to disable such old TLS versions, but we'll have to wait with that until all recent 0.A.D. versions support newer TLS versions as well. Some Linux users not able to anymore with TLS-encrypted connections With login for Windows users fixed, we received reports from some Linux users not being able to connect to the lobby with TLS-encrypted connection enabled. Figuring out what was causing this took us a while, as it did work for the majority of Linux users, but not for all of them. The culprit in this case were the TLS-versions supported by the XMPP-server again, but this time not an old version was missing, but a new version causing problems in certain cases. As part of the migration we enabled the most recent TLS version TLS v1.3. This usually works without having to change clients, because only clients supporting such a version will use it. The client which didn't work correctly was gloox, which is the XMPP-client library used by 0.A.D. We don't know yet why it doesn't work, but it apparently doesn't. The interesting piece is why that was so difficult to track down. Contrary to Windows it's common with Linux that application don't contain all of their dependencies, but rely on them being provided by the operating system in one way or the other. The version of gloox adding support for TLS v1.3 got released less than 4 weeks ago and Linux distributions usually don't include software which got just released a few weeks ago. That's why the majority of Linux users had no problem, as the version of gloox they were using didn't support TLS v1.3. The affected users were mainly users which did install 0.A.D. as Flatpak application, as the Flatpak app for 0.A.D. included such a new version of gloox. Our workaround for this problem was to disable support for TLS v1.3 again on the lobby server, as that makes gloox and therefore 0.A.D. happy again. That's of course just a workaround, as we'd like to be able to offer support for TLS v1.3 in future as well, but to enable it again, we have to figure out why it's currently not working with gloox and get that fixed first. Conclusion As you can see preparing and carrying out the migration of the lobby was quite some effort and not without challenges. While most of the problems which appeared during the migration could've been avoided, that's always easy to say in hindsight. I'm personally very satisfied with the result of the migration though, as it's a great base for further improvements and the performance of the lobby is even better than before as well.

Connecting to the lobby from Linux with TLS-encrypted enabled, which didn't work after the migration with certain configurations (e.g. when 0ad got installed via flatpak), should work again now.

Stale games shouldn't be shown anymore now. If you do still encounter stale games or have other issues with the list of shown games in the lobby, please let us know.