ffm2

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

I criticized local ratings here. And proposed the new AOE2 attempt here. Here it is as text again. Would be nice to test it (of course just a suggestion of me and if I really wanted it I should do it myself). But I also think some games are decided fast due to strategic decisions making it seem the game was imbalanced when it wasn't. Lets say you have a 2v2 of equal strong players. 3 make some cav one goes 100% female. The cav-team now goes 2v1 on the female -> fast end, seems imba. Now lets say the cav-team goes 2v1 on the one with cav, he can hold his ground. The 100% female player can boom to cav-champs -> seems imbalanced again (as the power jump to cav-champs is big).

The skirmisher of the gauls get a cape when they promote to rank 2. During the attack animation this cape stays in position while the body moves forward and backward during throwing. See attachment gaul_cape.mp4

For those questions I made these charts. 9% of the sparta players do that research at about min. 16. Apparently I did it 2 times too, but it must have been at a time where I already won and just research techs that I find and can afford because I don't aim for this unit.

under_10_perc.zip 0_perc.zip

over_70_perc.zip over_10_under_70_perc.zip

Visualizing Technology Research Timing Based on Public Opinion For each technology, I created a diagram showing the optimal research timing based on aggregated player data. Key Metrics and Axes X-axis (Progress Score): Reflects the advancement of a civilization, calculated as: score = resourcesUsed['food'] + resourcesUsed['wood'] + resourcesUsed['metal'] + resourcesUsed['stone'] - unitsCapturedValue - unitsLostValue - buildingsLostValue - buildingsCapturedValue + lootCollected - tributesSent + tributesReceived + tradeIncome Y-axis (Progress Score by Minute 13): Indicates how efficiently a player progressed. Higher values denote better development. Expected Trends Faster-developing players tend to research technologies closer to the optimal timing. Slower-developing players show more deviation, ideally forming a Gaussian distribution around the optimum. Natural barriers (e.g., resource constraints) may prevent earlier research, allowing further refinement of the optimal timing. This approach leverages the Wisdom of Crowds principle. Why Progress Score Over Time? Using time as the X-axis would skew comparisons between fast and slow players. Instead, progress score ensures fair benchmarking. E.g. a for a faster developing player it makes more sense to research p3 earlier, so the dots would lean to the left going upwards. However, for practical player reference, iso-lines mark when different player segments (e.g., top 25%, 50%) typically achieve key progress milestones. These lines are smoothed averages from 60-player samples. Visual Enhancements Top Histogram: Shows the distribution of progress scores when players research the tech. Solid black line: Mean research point. Dotted black lines: ±1 standard deviation (68.2% is inbetween). Colored solid line: Your personal mean-helping identify biases for improvement. Right Histogram: Blue bars: Fraction of players who researched the tech at a given progress level at 13 min. Gray bars: Fraction who could have researched it but didn’t. Note: Naval techs (requiring water maps) are currently not accounted for (less than the grey bar actually have the chance to research them). Civilization-Specific Behavior Technologies with differing research patterns across civilizations (e.g., Ptolemaic farming phases) are split and annotated. Data Interpretation Top Players: While highlighting top performers (e.g., Stockfish, Havran) is possible, overemphasizing them may not be useful. Rankings can shift slightly with minor metric adjustments (e.g., using minute 12 instead of 13). How to Run the Analysis Place the folder in your replay directory (e.g.,~/.local/share/0ad/replays). In A_fastest_boom_at_time_eco.py: zeroad_data_folder needs to point to the game. The icons, descriptions and prices are pulled. Set you = "ffm" (your username). Adjust top = 2000 (sample size) and your_top = 49 (minimum personal records included). In B_tech_of_fastest.py: Configure multiprocessing (cores, top-player highlighting). how many cpu cores you player name again Tech Categories: Over_70_perc: Essential techs (good for beginners). Over_10_under_70_perc: Situationally valuable (deeper insights). Under_10_perc: Rarely used 0_perc: Never used Limitations & Feedback The tool lacks robust error handling, so use caution. Exceptions for some edge-case techs are accounted for. I welcome reports of anomalies, I hope I didn't mess up anything big. Enjoy optimizing your boom. top_analysis.zip

This version should account for lag. I can't test it in real games atm. so maybe someone can verify from real games how well this works. This should not trigger when the turn length is over 400 ms (the usual one is 200). Maybe that number needs to be adapted. In a replay set on 0.25x it didn't trigger.

Flare is turned of for Quick start for now

This mod reports gameplay that should not be possible in 0 A.D. without mods. Currently, in 4v4 matches, new or aspiring players are never informed about which mods are being used or how they affect gameplay. Instead, it’s implicitly assumed that everyone already knows the players and their supporting mods. With these quick in-game messages, players at least receive basic information and can further discuss the implications - whether in the match itself or on the forums. Quick start triggers the chat message: "Units receives automated commands by %(player)s at turn %(turn)s (v01)" Clicking tools like the razor rapid fire triggers the chat message: "Automated clicker makro detected by %(player)s(v01)" If a player does not send a command in 30 seconds triggers the chat message: "%(player)s has not send a command in 30s (v01)" Market Exploit "%(player)s has bought %(buy)s shortly after selling it for %(sell)s (v01)" Elexis set up the mod template for me to fill. Lag is atm. not accounted for, so during heavy lag it could trigger false positives. I tested it in a few games and didn't had false positives. Report if it behaves weird and some thresholds should be changed. Some features that should be added: turning off in game or handle 2 players with the mod to limit spam Current version: 02 oddity_detector.zip oddity_detectorv00.zip oddity_detectorV01.zip oddity_detector V02.zip

I had a Index error. I didn't take the score at minute 12 but at minute 6. The statistics gets taken every 30s. The score itself is spend (food+wood+metal+stone)/10.

There are a lot of players with a low elo that can pull of a extreme good boom. Some have problem with army coordination or understanding how crucial 2v1 situations are. These players also gets left alone more often because a good rushing player wants to hold back a strong player from tactical perspective. I found some strong players surprising low in the total list. There are lots of biases here but there's also some truth to it regarding the booming aspect.

What do you mean? It's the top performance of each civ. Of course Ptol and Celts are listed. Or you expected them worse? Ptol with the food trickle is excellent as teammate. Having same civs in a team is worse as the boni don't stack. So it could also be a bias that a ptol player gets the ptol team boni less frequent.

Not yet, this was just a by-product. Maybe when the other stuff is ready for release or I'd extract it next time I do something like this (wouldn't be hard but I got other stuff atm. going on), sorry. Also a big factor are the team-boni. For better civ performance analysis one should take the mean of top 20 booms per civ or so. Here I just wanted to give players that are interested in the boom of one civ a reference point. E.g. how to handle iber walls, what to do with the maur elephant etc.

Top Eco Scores of Used Resources at 6 Minutes Here are the best games with the most resources spend at minute 6. I don't take the games eco score (of gathered resources) because unused resources are bad and this is better reflected in the eco score of used resources (ecu score) Methodology Excluded: Fortress maps (games starting with Barracks) Conditions: Cheats disabled Starting resources: 300 Full replay available Game duration >12 minutes No quickstart used Dataset Total games evaluated: 763 Total player entries: 3,255 (Note: Same player in multiple games counts as separate entries) Key Findings The top scores typically come from games where players: Produced only women for the first 3 minutes Didn't face early punishment Played as pocket position Note: This only one viable strategy, that can be measured in a benchmark well. Top Performances by Civilization Replay Date Ecu Score Player Civilization 2025-04-20 920.0 stockfish Gaul 2025-02-13 911.5 chrstgtr Brit 2025-02-06 905.0 havran Spart 2025-02-12 890.0 stronglag Athen 2025-03-16 887.5 borg- Sele 2025-03-23 884.5 havran Maur 2025-02-23 884.0 e133 Ptol 2025-02-16 870.0 havran Rome 2025-04-18 872.0 ricci-curvature Pers 2025-04-22 870.0 stevie_wonder Kush 2025-02-16 865.0 chrstgtr Mace 2025-03-29 847.0 borg- Iber 2025-04-26 845.0 blossom Han 2025-03-22 830.0 duck__ Cart All replays available on replay-pallas

Ok, thanks. I'm on the edge of my seat for a27.1 since the improvements apart from the OOS were good. Just as additional info, I compiled on a current arch linux with git clone --single-branch --branch release-a27.1 https://gitea.wildfiregames.com/0ad/0ad.git and attached my replay if someone still want to look more in to it. Then I'll play with a27.0 for now. commands.txt metadata.json