Feldfeld

I checked the graph and it seems like what is plotted is (1500 + PlayerDeviation) instead of PlayerRating This is why the graph gets closer and closer to 1500 after each match. Maybe after giving a replay to the glicko code it doesn't take the current player rating, but instead the base value of 1500?

What I mean is that the graph indicates I lost every game beside the first, at least that's the understanding I get from this. But since most replays on the website are from the tournament I'd expect it to be mostly victories, and victories would bring the graph up

Now the graph indicates I'm dropping rating for each match, not sure that's accurate

Nice! The glicko data looks inconsistent. It tells me my rating is 1545 while the graph puts me above 1600 Now may be time to invite the 0addicts to dump their replay. Many players should have hundreds of teamgames, though they would all be in now outdated version of community mod. (that would amount to GBs of disk size) Is there a duplicate detection for replays? Ideally it would keep also the longest version available (there could be a somewhat frequent situation where a player spectated a 1v1 then left in the middle of the game, and posted the replay first) Guess this problem would occur only if players post replays by dumps instead of hand picked 1 by 1. I'd recommend posting the link to the website at the top of the opening post of the thread for visibility.

Finally something is done about melee/ranged balance Maybe I'll try it out this weekend

Yes check here

It's better to just delete every folder related to the community mod and then do a manual install. For precise instructions with manual install you'd have to ask someone else though. For which version, I think the last matches of the tournament were played on 26.3 but the early matches were maybe on something earlier like 26.2 To know precisely which version you can also download the replay from here https://replay-pallas.wildfiregames.ovh/ (it contains the same replays as the tournament and tells the version, plus you can easily filter the games from me), you can also inspect the commands.txt file which indicates the version

None, or very casually at best

Not motivated for now

There are the replays from the tournament I hosted: But you'd have to install a prior version of the community mod to watch them (be careful with that...) If you still want to do it, check the "view other versions" section here https://mod.io/g/0ad/m/community-mod

Imo, first of all, for whichever criterion that is used there needs to be a threshold to say that the game is decided. Because it can be that some replays with no winner were truly undecided at that time (e.g. disconnection). So the algorithm would still decide to discard those games in the rating calculation. Then, as for the actual criterion, imo the biggest tell is if there was a population swing close to the end of the game, or a swing a few minutes before that has never been recovered. If a player has noticeably bigger population after that event then he can be considered winner. If there was a big fight at the end of the replay but no one on top in the population statistic then economy and military score can also be taken into consideration.

Considering that experienced players are more likely to share their replays, I suspect that starting at 1500 would actually look more like ingame ratings.

Yeah that's a bigger issue. A mitigation I see to avoid weird looking swings would be to recompute the whole thing at even slower intervals at which replays are scrapped. So there could be replays displayed not yet used in the rating calculation. So the problem would be "hidden" behind the big quantity of replays at each update. However, it happens that the multiplayer community plays much more TGs than they do 1v1s so not sure it would work well.

Imo, no. There are no draws in 0 A.D., and many replays with no winners would just be replays where there is actually a winner in the field but the game was exited without a result. Could be disconnection too, anyway a draw is a definitive result and it would not represent what happened in the match. It would be better to just ignore these games in the calculation. Could consider in the future having a tool analyzing the replay and deciding if there actually was a winner. I know lichess uses glicko and it is updated game by game. Here is what they say about it: https://lichess.org/faq#ratings https://lichess.org/page/rating-systems So the lichess boys are quite confident this is the better rating system. It's still difficult to compare as they also have a lot more games. As for what is written in the glicko2js github page, too bad they didn't get very specific about it, notably if the collection of games should involve the same players. Because when you think about it, provided the replay pallas scrapper runs at intervals, or if players post replays by dumps, then at each update you'd actually have a collection of replays to evaluate. Edit: nvm can't read. They did say 10-15 games per player. But it remains that lichess updates on the fly

No separation I'd say ideally, no

My idea would be for 1v1 only both ranked and unranked, team games would use the Local Ratings. As for the algorithm, I heard some form of Glicko was state of the art but I don't know more. Would need opinions of others to know if it even is a desired feature.

The idea I had in mind was to start an elo ranking from scratch and give it the data from the replays collected only.

Nice to see it up! Seems like the website enforces a password of length 9 despite claiming it should be 8 characters. On the Local Ratings section, the number of matches column doesn't seem consistent with other data. (also I'd argue that for 1v1 some form of elo system is always going to be better than local ratings)

Feldmap doesn't use compatibility check. Perhaps your issue is caused by another mod? Could you take a screenshot of your ingame mod selection screen?

I think it's bad for gameplay if palisades are built for the sole purpose of hindering pathfinding. To mitigate that, I could suggest to make it so when one section of palisade is broken then nearby sections are destroyed as well so it doesn't make a super tiny opening. Could consider making them weaker to pierce damage as well. On the other hand, they could be quicker to build so it doesn't take too much economy to build them early game.

Look at the bottom of the first post of the thread. You can also find the a25 version here btw.

If you want 0.2.0, look at the "a26 archive" spoiler in the first post of the thread. I think there's also a way to get it off mod.io

Not quite close for me, hotkeys are a very important part of any RTS game, the ProGUI features may not be something 0 A.D. goes for in the future. The only thing i have observed is a player that was on par with me without ProGUI beat me quite convincingly with the mod. I didn't play a lot this alpha so I didn't notice anything else, and it's not like i played a lot of games with that player either, but still what I observed was kinda overwhelming.

I agree with Mentula that ProGUI gives a serious advantage over a player of the same level, if used well. However he didn't say what is in my opinion the biggest reason why this is the case (at my level that is). The biggest advantage is in the case of continuous fights or harrassments, preferably in p1 or p2, where there are 3 or 4 production buildings per player. In that case, the attacking player can focus near all his actions in microing the fights, making threats, forcing his opponent to react accordingly, and he will still have near perfect production at home. Meanwhile, the other player forced to micro his fights as well will not be able to queue units at the right time and will fall behind because of it. The population deficit will grow until the game is definitely over. I think that it is quite a big advantage. For comparison if used correctly by a good player it would be kind of as if a player is with a game speed of 0.7 while his opponent is at 1.0, normal speed. While both players have the same skills and would make a good decision at a good time, having your game slow down allows you to make more actions that are valuable at a critical time of the game. However, if both players are booming, it makes almost no difference as both players will have the time to do all meaningful actions, and the boom will be the same. It may still boost some players' booming ability, so it may also be unfair for that reason, but i don't really know about that personally. I am saying this based on (maybe a bit limited) experience. There's a certain player that has a similar skill level as me. If I recall correctly I have a slightly higher win ratio against him when he is not using ProGUI. However when he used ProGUI I had 0-3, and it was not even close. He simply made what I think is a perfect use of the mod, forcing fights mid-game and getting a pop advantage I could not recover from. I will give a little more intuition on how this can affect competitive games by giving the example on how macros are viewed in Age of Empires 2. Basically, any kind of macro is banned, and you can see in this video how even the simplest macros are problematic: 0 A.D. is not AoE2 of course but still that shows macros can escalate into a huge advantage. So if powerful macros are found with @Mentula's mod then that gives what i think could be an unfair competitive advantage as well. The same can be said with autociv where building hotkeys give a huge advantage (when used properly, of course). The difference for me is that it is a feature that should so obviously be in the game, that it makes it fine. But anything further than that, I am not so sure. AoE2 also had some grey areas with the building range indicator, and some mods like small trees or age of cubes. I hope you see my point. I personally wouldn't mind too much in team games which are less serious and where we try to balance it before game start, however if I expect the game to be competitive when I really want my level to clash with the opponent, that's gonna be a problem for me. Of course I know that neither @Atrik and @Mentula intend to do any wrong and I respect the openness of your programs, but still that can cause a problem when a powerful feature is released. Personally I would like very much for the AI to have an enhanced training algorithm. Personally a long time ago I modified their queuing algorithm to grow population faster, however it is not worth much as I didn't touch the other parts of the AI to go with it. We can see that in the following screenshot where my AI (red) grew population much faster in the early game than Petra (green), where they both had the same gather rate at a medium difficulty each:

Looks good to me. I would also be interested in some form of a guard against sending resources to an enemy, a good number of games is with fixed diplomacy where we only want to send resources to allies