ffm2

It should work also in singleplayer replays. Rapid fire alarm could be triggered false in mp replay if the game lags online but not offline since the turn time is not logged. Or did you maybe work around a trigger?

Of course wrong accusations are bad. I heard some that were too wild too. On the other hand this described cheats are cheats and methods we know of. I would not rule out that e.g. players reveal the map. The oddity detector itself is also just a workaround. If we had something better, like mod signing, I'd drop it since it monitors the players. I made a trainer mod based on autociv for a26 once. It was nice for spectating and reviewing build orders but could be abused easy. That's why I dropped it. This can also lead quickly to information overload. Best method for players atm. is just to play with trusted players which is also annoying. The only cheat we can rule out is reading the enemy chat if the host is trusted (as I understand it atm.).

I spectated a few games today and the market exploit was in 50% of them used. The state is quite bad imo. Maybe everyone is eager to try their new trick. I don't see how atm. besides mod signing.

V01: Added detection for market exploit.

LR checks metadata.json, which doesn't store the date. commands.txt does, but would be another step costing time. I appended to my replays also a string so I can mix replays of different pcs but I can change that to cater to LR too.

there's a template for the decay, but not used actually atm. LR gets the time by the replay folder. But downloaded replays from replay-palas don't have the date in their name like the ones from the game. Like with "2025-05-21_0001", another shared replay would have another game 0001 on that day.

I modified the mod so it calculates a glicko-2 rating. Glicko-2 should get a bit faster to a correct rating than elo (which I tried before). The old local rating is preserved and in the graphs still shown. I only display the glicko-2 rating in the lobby and game setup. Glicko-2 starts at 1500. The other number next to it is volatility. Volatility starts at 200 and goes lower to find the accurate rating and stabilize there. Games are only evaluated if the victory state of all players are won or defeated. The result is not satisfying yet for me. I have played/spectated a lot of games this alpha, more than one could demand of another mod-user. I release it anyway for testing or if anyone else want to play around with it. It could be that this works better if: Team pairings are consequently made by this glicko-2 rating. This way if underrated players gets teamed up occasionally they could gain rating. This feedback loop could benefit the rating. On the other hand if e.g. one player is very strong and known for it, he might get paired with many very bad players and lose rating. Maybe it should not be done locally as then the rating pool gets bigger and better connected. Atm. good players only play with good players and the rating of them doesn't get elevated as high. Atm. I'm a bit disappointed and may not follow up on this but wanted to drop it here. But I mean, if you doubt the team game pairing this could be used as a guide and if it is wrong rating got distributed so it should work better next time. But before one trusts the algorithm I wouldn't put in the work to include the graphs. localratings_glicko2.zip

Added warning of idle players after 30 seconds without command. I think this is important as some games are ruined by players suddenly leaving a 4v4 without notice. In lower rated games this gets triggered occasionally. I can't relate to that but I left the older version (the one without v00) without this if this is annoying. The chat command now also sends the version number (now 00), so if this gets a update and a version was known for false positives one can inform the mod user of the update.

I think the starting point don't matter but would only offset the rating. Iirc in the video rating inflation was described. One could always play with the variables still later on.

I'm in favor of unifying them. For a accurate rating one needs a certain amount of recent games. This split could be done for players that play enough 1v1s and tgs. This would be nice, but would only work if the player base where higher. See also: Would it be possible to have a rating system for games outside of 1v1s? LocalRatings mod Where I already wrote my opinions LR is not accurate for a lot of players I'd prefer team elo like AOE2 (or here as video) From time to time I look in to LR to try to implement team elo (or glicko-2 or whatever) but I never can get my foot in the door or have other stuff to do. But it should not be so hard to start each player with 1200 iterate over all games in chronicle order distribute score per elo system Next little caveat would be that a lot of tgs don't end with a certain victory but that 3 of 4 resigns and the host ends the game. That could change if the host is interested in the score distribution.

From 16 to 22 there was a game breaking unit that everyone agreed not to make (after a few month in the alpha). a23 felt "done". Now balancing started over again and when this model is "done" I fear a new model will be introduced (like historical) by new members that won't reach a mature state like a23. I also like the more diverse civs like the old ptols with free houses that took long to build (although they were always a bit OP).

Which mod? Do you mean the oddity detector? That one should work with 0.27.0 and 0.27.1 in my tests. What is the error?

A bit more from olive to yellow for you? [40, 80, 160], [180, 59, 73], [227, 119, 194], [210, 210, 16], [148, 0, 235], [255, 127, 14], [23, 190, 207], [115, 0, 84]

I worked on 8 colors for the players. Background colors are reserved colors from the original game. I took the chart background, the font halo, trees and terrains. To get one color for each I blurred the terrain. To get 8 new player colors I used some approach with CIELAB which should be better than HSV. CIECAM02 should be even better. In this python script a color distance is calculated. One can compare the numerical value from player vs. background and then player vs. player. Since this is also subjective the colors are then plotted. On this plot one can see and compare if this colors look good and are distinguishable next to each other. These are the colors I arrived at: [40, 80, 160], [180, 59, 73], [227, 119, 194], [200, 189, 16], [148, 0, 235], [255, 127, 14], [23, 190, 207], [115, 0, 84] This topic is very important for silhouettes in the forest. But there was also a incident where 2 players captured my cc, the capture bar seemed still over 50% but one of the players had a similar color to mine so I actually missed the 50% mark. I do NOT accept this loss. It was a fault of the game. color_by_distance.py

Here is my OOS log and the one of diagonalo. Also included are the 2 replays of us. I apologize on behalf of diagonalo that he used mods, he was not aware that we were looking for bugs. I was the only player OOS though. I was present from the setup. I was observer. I did not flare, I did not chat. There was a flare during the OOS though from Flammea which could be a hint. Ricci was not present at all. 0ad_OOS-2025-05-25.zip

Yes, I told you I do it from now on. I just had a OOS with only feldmap on.

I suggest adding left-handedness. 10 - 15 % of the population are left-handed. But the main reason would be to break up the synchronized animations. E.g. when 50 skrims attack in union. If some of them where mirrored it would look a bit more chaotic.

elexis has to add this: ffm was present from the beginning, did not rejoin everyone except ffm had the same hash on turn 1560 ffm had the same issue one match later ffm uses only 4k, feldmap and visibility mod sim state was from 3 turns later: oos_dump.txt oos turn: 1560 net client turn: 1563 sim turn: 1563 binary simstate is identical! textual simstate contains only differences in RangeOverlayManager.enabledRangeTypes local entities but both states are 3 turns too late, and its unlikely the mechanism will ever write simstate dumps from the correct turn, because the turn lengths are so short and because multiple turns are being computed in advance as far as I know. "Currently, the RangeOverlayManager is serialized" False: RangeOverlayManager.prototype.Serialize = null; The textual output showing this is a regression introduced in 9fc6c3c89769a3, pointed out in #7634 and stated to be addressed by c475cc22652528ce7014d "is definitely caused by one of your mods" pure conjecture ffm did not use riccis mods, ricci computed the same hash as everyone else but ffm! riccis hash is also computed without mods "Doing it any other way is just a waste of time, as you're all finding out now." you can be grateful if you get an OOS report at all, players reporting that is rare, you dont get many chances to identify an OOS, so if you want to dismiss an OOS report, you better investigate it first and not disregard it easily. it's possible it's caused by a broken mod but if you dismiss it without investigating it, you might be ignoring a valid report which can cause the bug to go not unnoticed but unreported for months. only difference in commands.txt besides the mods in the first line: --- commands_ffm.txt 2025-05-24 12:17:26.000000000 +0200 +++ commands_ricci.txt 2025-05-24 12:21:51.000000000 +0200 -hash cc1eb515c7554393f2a2dae2ca4770e6 +hash a763d2495ddab5956941ea577d3c6f30 another bug, not only in JS GUI but also the turn manager should not allow this: turn 3433 200 cmd -1 {"type":"stop","entities":[],"queued":false} cmd -1 {"type":"stop","entities":[],"queued":false} when ffm replays his own replay: Executing turn 1560 of 5970 ERROR: Replay out of sync on turn 1560 when I replay ffms replay without mods, also: hash MISMATCH (a763d2495ddab5956941ea577d3c6f30 != cc1eb515c7554393f2a2dae2ca4770e6) Turn 1560 (200)... So ffm did not rejoin, yet he was the only one to compute something different on turn 1560 but on turn 1563 the difference was gone already and he had this phenomenon on multiple matches. I also recommend never to release 0ad with OOS being not fixed, and therefore you should not remove 0a4bfefb1e5f40d93180690e328b11e148dec0cb but include this in the re-release and to bump the mod version in mod.json from "0.27.0" to "0.27.1". You're saying you release "0.27.1" so the mod version showing "0.27.0" seems misleading. Bumping the version should (TM) mean that due to the mod compatibility check in the lobby, 27.1 players can play in the same a27 lobby, but they can only join 27.1 games, while the 27.0 players play in the same lobby and can join only 27.0 games. A reason against doing it this that was brought up by sera was that you find yourselves unable to provide a release for all platforms and thus some players would be stuck to the old version for months (and thus would not be able to find players to play with). but if that problem was real, then you'd have the same problem with releases, not only re-releases and it doesn't stop you from releasing either. if that OOS 0a4bfefb1e5f40d93180690e328b11e148dec0cb was fixed in 27.1 and the version would have been bumped, then now you wouldnt have to investigate if it could be caused by the modifiers cache OOS. Worse: players get used to that OOS occurring and this means they will not report OOS anymore because they think its the same OOS.

Yes, I disabled all mods but feldmap now and will report once it shows up again. However: -RangeOverlayManager is not serielazed (see the Serialize function) -I was in the game from the start (no rejoin) -the binary dumps were identical

When I run my replay (not riccis) again with my (the same) mods I get the hash of ricci (and the others) and I am OOS. I'm sure I didn't flare at that time. I was observer and may toggled team colors. But when I toggle team colors in other replays I don't get OOS. So I think the ranged overlay mod is not causing the OOS.

The speed in combination with the similar strength is in deed the point. They can ignore their counter. Also selecting wounded and pulling them out works good because of their speed. I also thought of having them slowly change the direction and having a fast end speed after a acceleration time or so. Also on the topic of "dancing": I think running back in (small) zigzag is no abuse. Units don't have to run in a line back like Rickon Stark did under arrow fire. But of course this works great on fast units with sudden change of directions. Dancing in itself can be abuse though. But in this case it just makes sense

That's what I thought. The weird thing is I had ffm_4k, ffm_visibility, feldmap, so reliable tested mods. Ricci had ranged overlay. But I was the only one OOS. Maybe everyone else had it too.

Melee will end you. Ok, you'd still need melee units. But wouldn't you agree that britons and athens can be played without champions or siege without being up civs because of the slingers?

In general something should be done against the champ masses. Either this, or make a limit on them, or make them require more pop. The nisean war horse upgrade especially puts every other champs in the shadows. On the other side I don't agree with a lot players claiming everything would be OP, elephants, siege etc.. As the game goes on one should be incentivized not to rely on citizen soldiers only. Although sadly one could rely on mass slingers atm..

I had a OOS again. They are very rare though. Here are my logs+replay and riccis. I was observer, ricci host. Both on self compiled a27.1 versions. I was the only one OOS. ooslog_2025-05-24.zip