Leaderboard

Oh it's been implemented, it just needs to be merged for the next version.

There is an ELO rating system implemented in the MP Lobby for 1v1's. A notorious problem with it is that it doesn't handle matches where one of the players disconnected before it was over, these matches simply aren't counted. Some players exploit this by leaving or closing matches when they realise they are about to be defeated, in order not to lose any rating points. This obviously goes against the rules, which is why this thread exists for reporting it: However, I think we can all agree that, ideally, bypassing the rating system like this wouldn't even be possible in the first place. This would save players the frustration and moderators the work of checking submitted replays. While talking about it in this thread the following idea came up: There are two cases of players quitting, firstly the one hosting the match, and secondly the one who joined the hosted game (the client). - If the client leaves, currently, the match continues, just without anyone controlling one side. If the host now finishes the match as usual by defeating the opponent (who doesn't defend himself anymore since the client left), it should still count as a win for the host and as a defeat for the client. If the client disconnected for a different, valid reason and planned to return, he should communicate that to the host beforehand. I'd argue it's the clients' responsibility to ensure they have a somewhat stable internet connection, so that they aren't completely disconnected frequently, and when they are, can still rejoin quickly. The downside is that it incentivizes hosts not to wait for the client to come back, since they no longer have to. - If the host leaves, currently, the match is immediately ended, without the client having a chance to continue the match in the same way as proposed for the host. In that case, the game should count as a win for the client. I know this sounds harsh, but as far as I can tell from the code, this only happens if the host manually exits the match or terminates the program. If the host only loses internet connection, all clients (one, if it's a 1v1) are disconnected from the match, but they are able to reconnect as the match itself on the host side persists. So the only way this can happen unintentionally is if the computer crashes, but again, that's probably something the host is responsible to ensure that it doesn't happen. What do you think? Is there anything I'm missing? An issue I can think of is that it enables hosts to exploit the system by starting a match, immediately kicking the client or blocking his connection deliberately in another way, and then being able to easily win the game and still be awarded rating points. Although, that's something that should just be reported as well.

It wasn't included in R28 because we were already way to far into the release process by the time I opened the PR. But, yes, the implementations are done, what's left is reviewing, finalising, and eventually merging it. My goal is to get everything into R29. I'm working on it.

To rate games we currently rely on both players "agreeing" about the outcome of the game. That means whenever a rated game ends, 0ad sends a report about its outcome to a bot which is responsible for handling the ratings. Only if the reports of both players match, the game will get rated. This is necessary to prevent players from sending fake reports to manipulate their ratings. In case one of the players disconnects and doesn't come back later, we won't get a report from that player and therefore can't rate the game automatically. The best solution I've come up with so far is to inform the bot already when a rated game starts and about which players participate. Then if only a single report gets received later on, we can wait a few hours and award that player the points. I've described that in more detail in https://gitea.wildfiregames.com/0ad/0ad/issues/3951#issuecomment-62016 The non-host player loosing the connection and not being able to reconnect afterwards (no matter for what reason) is an interesting edge case I haven't thought about yet.

thank you, i'm just getting used to moderngui's many changes, but it's good to have this as a backup plan

This https://gitea.wildfiregames.com/0ad/0ad/pulls/8758 Dedicated server partially solves this problem. When player leaves rated game without previously sending resign -> it is detected and reported. Can be automated to the rating bot. I also think that some grace period needed: players may connect and realize that their networking conditions are not allowing a good gameplay and disconnect or basically drop the connection. Maybe in first 2 minutes this is ok to tolerate.

out of topic but I realized that y'all wrote it as "nayara" which reflects the Magadhi Prakrit not having that "ga" sound but rather the "ya". I like these little odes to history (In current sanskrit its pronounced Nagara)

Muy bueno!

@sarcoma I've already ported to R28 and updated the links in the first message. But if you are using ModernGUI you have this feature already

@user1 On February 21, 2026, the player goingloko ended a game without resigning just after I conquered his main civic center. My lobby name: King_Kreg Offenders name: goingloko commands.txt is attached. commands.txt

Both of these would solve that, yes. But I personally wouldn't mind too much if the host was treated more harshly than the client, as @guerringuerrinsaid they have more responsibility already and the main thing is that either side can't ruin the game.

I'm really looking forward to this. I hope it all gets fully integrated into the game, as I for one am itching to make Singleplayer maps/experiences, but feel quite limited due to the limited documentation and lack of any sort of tools in ATLAS to intuitively develop solo maps with triggers and such, as well as the very limited options in actually telling a story/narrative. This narrative stuff, combined with ATLAS's editor being improved to actually include it's own Trigger Editor and such, so that modders, artists, etc. can develop stuff with these tools in a way that is intuitive and user friendly, would be an absolute godsend.

hello atrik, thanks for fixing most of problems. but some still persist. When im plying i can only see the stats of 1 ally, the rest of allies stats are shown only when i resigned or im spec. also, i cant close the map when i expand it using hotkeys

moving_clouds.js

I placed them high above the map just to cast shadows on the ground and reflections in the water.

Yes my friend, I made the clouds using a cloud pattern and texture; this image is just a test. I'll send you the script, no problem.

The Persian's only major eco bonus is their team bonus, which makes production buildings cheaper. Having 220 max pop (and p3 trickle sources) doesn't contribute much to economy growth, just the maximum output after you have completed the exponential curve. I like the idea of letting the ice houses double as a food drop-off point, since that would encourage early game usage. It would allow some wood savings while using stone that might otherwise go to barracks/eco techs.

https://docs.wildfiregames.com/templatesanalyzer/

No more issue at all here i.e. Arch Linux with package 0ad-0.28.0-2 (reverting to js115 from js128) as @ffm2 wrote yesterday evening (just not specifying the version). ty @Stan` for clarifying the spidermonkey bug that caused the issue. Now back to my issue as I'm lagging behind the game's new speed (efficiency) even on a light setup

First test with clouds moving on the map =D

Don't underestimate the power of testing Releasing is always when you find the worst bugs Also I can help you with tooling like checkrefs to find broken / missing art files.

Its fixed I think. I let petras play 7 min. because it's late here, but I think it's fixed. Thanks if you read this

I believe you forget ptol don't have pyramids

Then the app would simply be terminated in another way.

Not to mention that the game can barely manage the amount of players it currently has. Imagine the number of "disconnected to cheat the rating system" posts we'd be inundated with? There needs to be several solutions to several problems with multiplayer and we haven't scratched the surface. We still haven't resolved the issue of macro mods. Imagine throwing thousands of more n00b players into the mix.

I've always found this wording to be... unhelpful.

I hope this gets you as excited as me: https://gitea.wildfiregames.com/0ad/0ad/pulls/8614 (please don't judge my sense of humor )