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

Regardless, testing of new software should be done in a blank-slate state, without any additional code. This is an established practice in software development, to better detect and isolate buggy code. Doing it any other way is just a waste of time, as you're all finding out now.

@wowgetoffyourcellphone would be great for your Roman Principate civ in DE.

art.zip

There are no counters to Sele/Pers champion cavalry spears (but you having more champ spear cav then your opponent). Even if you had spartiate or any champion infantry polearms. They have extra range (7m) so if your enemy fight with them in formation with some melee infantry, now the champs fight behind the infantry (who have 4m range), therefor your champ spears aren't counters. Tested it against borg in tg recently even him can't do anything.

On: garrison order (button or key), off: click on units or the number on the ship's panel when near shore.