Dunedan

It isn't? Undisplayed mods wouldn't work that way either, unless the player uses a recompiled version of 0ad, which is a much higher hurdle than just installing a mod. So you're arguing that preventing some cheats is pointless, because there are still others? In my opinion the best way to have an even playing field is to contribute useful features directly to 0ad. That way all players have access to them. Also splitting "harmless" features and features which might be considered cheating into separate mods would also solve this issue.

One idea I got to make it harder to cheat is to limit the mods available for multiplayer games to signed mods. This way all mods would be verified not to give unfair advantages, as they are reviewed before being published on mod.io. This still wouldn't prevent cheating, but would require recompiling 0ad to do so. I'm not sure though how testing new mods which with multiple players would work with this.

Can you also please upload the new version to mod.io (https://mod.io/g/0ad/m/autociv), so it's available directly in game?

There are definitely many setups where hosting without STUN works just fine. What I'm interested in is if there is anybody where hosting without STUN works, but doesn't with STUN. Technically that's not related to STUN, but unfortunately toggled by the same option as STUN in 0ad when hosting a game. I wouldn't be opposed to adding an option to toggle the hole punching, which is as you're suspecting what's causing some of the delay. What I'm interested in is removing the non-STUN code path for retrieving a hosts public IP address. btw: a27 will already have a reduced delay thanks to https://code.wildfiregames.com/D5321

We're trying to make hosting multiplayer games less complex. Part of that is the potential removal of the option to host games in the multiplayer lobby without using STUN (https://gitea.wildfiregames.com/0ad/0ad/pulls/7002). Doing so would obviously break hosting for players who currently have to host without STUN, because hosting with STUN doesn't work. From my understanding of the code I believe the situation that hosting only works with STUN disabled doesn't exist though. However, as I might be wrong with that, I'd like to hear if there is anybody who can only successfully host games in the multiplayer lobby with a26 when STUN is disabled. If that's the case, I'd be interested in details about operating system, network setup and so on.

Shameless plug: https://github.com/Dunedan/ghaction-wiki-sync/tree/improvements It's a fork of an existing Github action to sync parts of a Git repository with a Git wiki repository and works on Gitea as well. I looked into that for another purpose, but it'd work for the 0ad wiki repository as well. It'd however require using another repository as its source and doing all changes as pull requests. As there hasn't been any response from the original author to my PR with improvements I'll soon merge my changes to the master branch of my fork and use that as a base for some stuff. That said, personally I'd prefer a solution which would still allow the same low barrier we have for changes to the wiki right now plus the ability to propose changes via pull requests.

@Norse_Harold: Thank you very much for your contributions to 0 A.D. and its community. I, and I'm sure all other members of Wildfire Games as well, are very grateful for your contributions so far and hope you'll come back after your break to continue to contribute. As @Norse_Harold already mentioned, we'll try out some new approaches to moderation going forward with the goal to make the community an even safer and more welcoming place. If you encounter inappropriate behavior by other community members, which violates the Terms of Use, please let me know. We're also looking for additional volunteers, who'd be willing to help out with moderation. If you're interested in contributing to that, please send me a private message.

I'm already on it. Give me a few more days.

Which public XMPP server do you have in mind for that?

When using the lobby XMPP server, developer communication wouldn't be independent of WFG infrastructure anymore. Having the main communication platform available when WFG infrastructure is down is pretty important from my point of view. We just had the need for that a few days ago.

You also need to ensure this new key is being used when interacting with our Gitea instance. Adding the following to your ~/.ssh/config should do the trick: Host gitea.wildfiregames.com IdentityFile ~/.ssh/wfg

Until you clicked them in the video, I didn't even notice that there are buttons. I believe the design would benefit from making them look more like buttons.

You don't have to fetch upstream for every change. Just do it as often as you'd do "svn up". The only situation where you will need to do it is when you want to merge a pull request and there are conflicts between the current status of the upstream main branch and your feature branch. If there are no conflicts and you merge using the Gitea web interface, you don't even have to rebase manually, as Gitea will handle it transparently for you.

At Wildfire Games we try to create a safe and welcoming space for all players. As everywhere on the internet, this can be challenging. While we try our best to do so, we also rely on volunteering moderators from the community to help us to enforce our Terms of Use. While enforcement of rules is always subject to interpretation, there are some principles which guide the work moderators do: Moderators are expected to be role models and follow the Terms of Use. Moderators must not engage in conduct that would be considered harassment, coercion, or intimidation. Moderators must treat all players according to the same standards. There must be no arbitrary preferential or punitive treatment of individual players. In their role as moderators, they must only use official channels for communication, in particular only the official multiplayer lobby server, the official 0 A.D. IRC channels and the official 0 A.D. forums. Moderators must internally document the reasons and details of corrective actions they take. Moderators must not share details about corrective actions with people other than the involved parties, other moderators and members of Wildfire Games. Moderators must not share personal information about players they learned in their role as moderators with anybody who isn't a moderator or member of Wildfire Games. If you feel a moderator violated these principles or if you'd like to support us with moderation, please send a private message in the forums to @Dunedan. Aside from members of Wildfire Games the current community moderators are: @rossenburg @Palaiologos @MarcusAureliu#s

I have a little addition to that: I just noticed that OFTC offers the same +S channel mode as Libera.Chat. So all of the three mentioned IRC networks would support ensuring users are connected via a TLS-encrypted connection. I also verified that the official web clients of Libera.Chat and OFTC internally also use TLS-encryption when connecting to the IRC server to ensure that people using the web clients can join channels with mode +S.

IRC with enforcement of TLS would be fine for me.

Kind of unrelated, but I'd prefer if we'd only list services run or moderated by Wildfire Games there or make it at least clear which ones aren't official services. A more decentralized structure of IRC networks would've reduced the impact of the Freenode fiasco, but wouldn't have prevented the fiasco itself. To prevent it a different organizational structure than the one Freenode had would've been necessary. I believe that's what changed when Libera.Chat got set up and that the people running it learned from Freenode. However, only time will tell if that's really the case. If the solution isn't going to be Matrix, there can still be an unofficial Matrix room, but official communication should then not happen via Matrix. From my perspective it is, especially if we host the service ourselves. As we want to be able to log conversations between moderators and players, end-to-end encryption would only add unnecessary complexity to that. In principle we don't have to use the web clients provided by the networks, but could set up our own. Whether that makes sense is another question though.

IRC channels have the downside that IRC network operators are be able to read that communication, which certainly isn't optimal, but would be fine for me. Instead of password + kicking everybody else, making such channels invite only would probably be easier. Libera.Chat also offers a channel mode (+S) to only allow users connected via a TLS-encryption to join a channel (Freegamedev supports that as well, as they don't allow unencrypted connections at all). Maybe let's start with that, see how it goes and consider a more elaborate solution later on.

For the use cases we use Quakenet for right now (general chat (#0ad) and development related chat (#0ad-dev) I believe it's rather import not to self-host it, so it is still available in cases our own infrastructure is down. That has been quite helpful in the past already. I'd prefer to continue to use IRC for that, but wouldn't be opposed to use Matrix either. As much as I'd like to use XMPP, it's probably not a fitting choice, as Matrix seems to have bigger momentum nowadays and if we don't self-host it, we can leverage existing infrastructure anyway. Regarding the IRC network, I believe Libera.Chat would offer the most upsides. Most of the regular IRC users are probably there already anyway. As for the risk that something like the Freenode fiasco happens again, I believe that's rather unlikely, because everybody should've learned from it. I consider the risk that Freegamedev goes away much higher. My preference would be Libera.Chat, followed by OFTC. There is also another use case we'd like to have a solution for and that's a real-time communication channel to provide support for players, where moderators and WFG representatives can talk privately with players. In my opinion that's something we should definitely self-host, as the communication there might contain sensitive data, which would just cause additional hassle when being shared with a third-party service. We also want to log these chats to be able to review them for complaints and appeals. A self-hosted solution just gives us much more control over that. Such a solution doesn't have to be a traditional chat solution though, but could in theory also be an existing help desk solution offering an integrated chat. I'd however appreciate if it'd be a light-weight solution, for example a chat plugin for the forums would be probably already be sufficient for that for now. Leveraging existing infrastructure like our XMPP server for that would make sense as well though, as that'd mean we could integrate support functionality easier into the game and use the existing user database for authentication, if we want to do so in future.

I'd prefer if we don't continue mirroring after the migration. With Gitea we'll have an accessible platform for contributors and I'd argue the disadvantages of mirrors outweigh their benefits.

In case the translations end up in Git, here is a rewrite of check_diff.py which supports Git instead of Subversion: https://code.wildfiregames.com/D5312

The "extractors" module isn't necessary in "0ad/translations". "i18n_helper" on the other hand contains functionality used by scripts in "0ad/0ad" and "0ad/translations". I don't like the idea of duplicating this code, as it makes changes to it much more annoying. That's part of the reservations I have regarding a separate translations repository.

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.

As the PO-files are excluded via .gitignore I think it'd be fine. As you might have already noticed, I'm just a friend of keeping processes lean and simple and such that circular dependency caught my eye. Without pulling the translations into the nightly-build, how'd you make such builds available in multiple languages? While I brought up the idea of a separate git-repository for translations, after thinking about it for a few days, I believe having translations in the 0ad git repository would still the better trade-off. A separate git-repository for translations just adds additional complexity for very little benefit. For example where would all the scripts related to translations life? For some it's obvious: The one to pull translations would fit well into the translations repository. But what about other ones (to credit translators, to lint translations and POT-templates, ...). One additional thought I had was which translations to pull from Transifex and include. Right now we do that for all languages we have set up in Transifex, no matter if we ship them or not. The volume and rate of changes to translations would be significantly lower, if instead only translations meant to be shipped would be fetched and included in the repository. The obvious downside is of course that testing translations not being shipped yet becomes harder. Just to note: This only works if the source libs are in a git-repository. What are the cases where binaries are part of source libs though? That should be an exception, shouldn't it? Yes, the usual problem with binaries. Reproducible builds would help with that, but that's another can of worms. This depends entirely on the definition of justification. I'd argue all of these commits are justified, as they update translations. What's the difference regarding justification from your point of view between updating a translation and a graphical asset? If somebody doesn't care about translation update commits, it's easy enough to add a custom git alias to not show them in the git history, if they're made with a distinct user just for updating the translations. Does it though? Is it really better for morale to not have recent commits? In the end that's no objective measure, but personal preference. I believe though that a complex project structure is more harmful to contributions (especially from new contributors) than whether there are recent commits or not. Where to find that? I'm not sure if I have access to that right now. I do care more about an easy and accessible project/repository structure and history than optimizing just for size. IMO having translations and source libs in the 0ad git repository wouldn't hurt anybody, but would notably simplify the whole setup.

In my opinion having contributors to the wiki credited via the wiki history is fine. As the wiki is just another git repository, extracting and showing them in the credits ingame, would be straight-forward as well. I'd worry though, that it might be difficult to exclude spammers from being credited. In the wiki history it's straight forward to see who is a spammer, as changes are associated with a name, but in the game credits there'd only be a name.