Dunedan

How would you ensure the names of the mods shown would be legit? It wouldn't prevent cheats, but would make them less trivial if you need to recompile the game to make them work, instead of dropping a bit of JavaScript in a directory. Please report players cheating by using mods or other means. Without reports there is little we can do.

That's what https://gitea.wildfiregames.com/0ad/0ad/issues/7166 would solve. In my opinion cheating is degrading the user experience way more than giving hosts the option to disable unsigned mods. We're not talking about a single mod here. Such a change would prevent all unreviewed and unsigned mods to be used, if the host of a game decides so. There are for examples instructions on the internet to create mods just meant for blatant cheating. The first post in this thread proves the opposite. You can only enforce something you know about and the use of certain mods is not known to other players.

I created an issue to add an option to only allow signed mods: https://gitea.wildfiregames.com/0ad/0ad/issues/7166

What does that mean?

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: @Norse_Harold @rossenburg @Palaiologos

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