Dunedan

We need videos of this featuring muskoxen.

https://gitea.wildfiregames.com/0ad/0ad/pulls/8318

@lilypoppy Great work. I'm sure if you keep working on it, it'll be an awesome campaign.

Awesome work @victorcrimea! However, everybody please keep in mind, that we don't allow third-party bots in the official multiplayer lobby, so to use this dedicated server, please either use the direct connection option or a separately hosted multiplayer lobby. Ultimately it'd be great to have such functionality integrated into 0ad itself, so players don't have to go through additional hops to use it.

Don't resurrect such old posts, but use the official way for rating disputes instead:

The same is true for other game settings, be it activated cheats, relics win, last survivor or something else. For everybody unsure there is already the game settings page, which can be opened with a single click in the game. In my opinion that's absolutely sufficient (although the information could be provided in a nicer way on that page). There is no place for that with the smaller resolutions we support. Just have it show up when you take a screenshot. Aside from the mentioned problem that players might take screenshots using other tools, there is also a problem when players want to make screenshots documenting visual bugs where dynamically adding something to the taken screenshot might affect the shown bug. It's also potentially confusing or annoying for players who just want to take a screenshot of what is shown on the screen. The panel can be made wider but you cannot take account of the length of usernames You can dynamically (re)size it, based on its content. No matter what, I believe that'd be a nice improvement in terms of UI consistency. This might be over-engineering the screenshot functionality. Mind that 0ad is a game and not a screenshot taking utility. On the other hand I like the possibilities of that. I kind of like the wonder notifications, so right now I'd vote for showing the ceasefire information there as well.

Bots usually behave notably different than humans. Most of them also aren't even designed to hide the fact that they're not a human user. So in most cases it's quite obvious. I believe I have explained that already in my earlier response. Anything I should clarify about that?

Sorry, my statement was incomplete: bots run by players aren't permitted, the ones run by Wildfire Games are of course permitted (and are actually necessary to run the multiplayer lobby). What we need is a server, which can run headlessly, so without requiring a graphics card. It also has to be resource efficient, easy to isolate (e.g. by running it inside a Firecracker micro VM) and maintainable (so no re-implementation of the required functionality, but reuse of code we already have in pyrogenesis). Additionally it should be integrated into pyrogenesis and XpartaMuPP, so whether or not to use a dedicated server is an option in the game UI rather than sending chat messages. That'd also allow us to use it for rated games, something which isn't possible with an unofficial solution. It's probably also a good idea to get in touch with us developers while developing such functionality, so we can provide guidance where necessary, to avoid work which results in something which doesn't fit our needs and standards (for example a change of the network layer from UDP to QUIC is in the works right now (https://gitea.wildfiregames.com/0ad/0ad/pulls/8925), which would require changes to a dedicated server as well). That said, if we're talking about ways to improve the ability of players to join multiplayer games and improve their performance, proper support for IPv6 (https://gitea.wildfiregames.com/0ad/0ad/projects/9) is something I personally would like to see as a step before adding dedicated server functionality.

You might not be aware, but uff wasn't the first to do that. @victorcrimea is working on this topic as well (https://gitea.wildfiregames.com/victorcrimea/0ad/src/branch/feature/dedicated-server/server) and at one point had a bot, similar to uffs, running in the lobby as well. He registered and used multiple accounts, which violates the terms of use. In addition, as a general rule, we don't allow any kind of bots in the multiplayer lobby. That's primarily to prevent abuse and protect the privacy and security of all users and it's also why @victorcrimea wasn't allowed to run his dedicated hosting stuff in the official lobby any further. That said, I suggested to uff yesterday to get in contact with @victorcrimea to collaborate on dedicated server functionality so we get something we can supported officially. We're an open source project after all, so we expect such contributions to be made using our usual processes and not in a way without us even knowing. I'm sorry that I wasn't able to better explain that to uff.

I'd also suggest adding logging of ingame notifications (like joining players) and chat messages to the same per-match log file, which could be stored together with the replay data.

https://gitea.wildfiregames.com/0ad/0ad/issues/7194

I just edited the initial post and removed the naming of one specific player from the mod name in it and the zip-file with the mod itself (as that contained the mod as well). @Effervescent Feel free to edit the first post and add a zip file again, after renaming it to a name which doesn't bully a single player.

I didn't question this use case, but there are other cases where old hardware is being used with modern kernels. Also for the case of using old hardware with old kernels, it doesn't matter if drivers get removed from the current Linux kernel.

Generally people using the word generally don't know what they're talking about.

It's even more hilarious, as we're talking about drivers, which are apparently not used by anybody anymore.

You should be able to review translations now.

Right now we don't care if strings are approved or not, we take whatever we can get (we obviously filter for vandalism though). The best way would be to get in touch with one of the language coordinators (https://app.transifex.com/wildfire-games/teams/17418/tr/). If they aren't responsive, let me know and we'll find another way.

Updates to the translations get integrated whenever a new version of 0ad gets released. Once we start the release process, we'll publish multiple release candidates, translators like you can use to check if the translations look fine in the game and give you the chance to polish the translations. The start of the release process will be announced via a notification on Transifex, as well as in the "Announcements / News" subforum here. If you're eager to try out the translation before, you can either compile the current development state of the game yourself or, if you're using Windows, use the nightly build: https://gitea.wildfiregames.com/0ad/0ad/wiki/NightlyBuild

These changes are now deployed and I'm hopeful this problem is now fixed. I've closed the associated issues in Gitea. If somebody is still encountering this problem, please don't refrain from re-opening the issues or comment here.

As we know thanks to the debugging work of @Shad_ and others that the problem seems to be related to client certificates, I dug into it a bit deeper. While I have no Windows available, I couldn't figure out the root cause, but I'm confident I found a workaround to get rid of the problem server-side without players having to do anything. As I mentioned, it isn't possible to disable requesting client certificates in ejabberd right now. After a discussion with the ejabberd devs (https://github.com/processone/ejabberd/discussions/4593), this will be added to the next version of ejabberd though (https://github.com/processone/ejabberd/commit/5b03ca51e003bae785d186f183c0cd276fc89e97), so once we update to that version at some point in the future, we should be fine. Until then, the workaround I have is to instruct the clients to only send us certificates signed by a specific CA. That CA is a dummy CA we have created and where clients haven't signed certificates from, which should result in clients not sending certificates at all. I have prepared all changes necessary for that (https://github.com/0ad/lobby-infrastructure/pull/43) and will likely deploy them in the upcoming days. It would be awesome if we'd have somebody who is currently affected by this problem or can reproduce it, so we can test if the changes indeed fix it.

Yes, the client can only send a "Certificate Verify" if it has a client certificate available. So this just indicates whether a client certificate is available or not and isn't directly related to the problem. When using "openssl client" with a client certificate "Certificate Verify" is included as well and the connection succeeds without issues Thanks for checking anyway. Much appreciated.

That theory turned out to be wrong, as I was able to confirm with "openssl client" that providing a self-signed and therefore invalid certificate to the lobby server works just fine. ejabberd in our configuration does just ignore any client certificate provided. Disabling requesting client certificates would be a workaround, but doesn't appear to be possible with ejabberd. Seems like SChannel is doing something weird, as my understanding is that the client code terminates the connection after the TLS connection got established, not ejabberd. The best way forward is probably somebody debugging this who's running Windows.

For reference: https://gitea.wildfiregames.com/0ad/0ad/issues/5396 I believe it's likely that this is caused by the same underlying problem.

That's quite helpful. Here is my current theory what's happening: While we don't use mTLS, there is support for that in ejabberd (the XMPP server we're using for the multiplayer lobby). Part of that is instructing the client (0ad) to optionally send a client certificate if it has one available (SSL_VERIFY_PEER option for SSL_CTX_set_verify of OpenSSL). For most Windows users that's not the case, as they never used client certificates. However, for users which have client certificates installed, SChannel (the TLS-library used by 0ad under Windows) picks an invalid certificate and sends it to the server under certain circumstances. As it's invalid the connection gets terminated, resulting in errors when trying to connect to the lobby. As sending a client certificate to the server is optional and not used by us, that should be an avoidable problem. @Shad_: Could you do me a favor and figure out what's considered a valid client certificate by SChannel in this case? Is it just any client certificate or does it have to have certain properties (like being issued by Let's Encrypt for example). That would help us to find a way to work around the issue in 0ad or the lobby server so users don't have to manually take action.

https://gitea.wildfiregames.com/0ad/0ad/issues/8847