ffm2

During multiplayer the trick gets displayed while your game loads, then you go in to the game and wait for the other players. One could make it so that you can still display that trick, so one can finish reading it while the others connect. But you should also be able to check your base, where trees are etc. There's a important typo in 0ad/binaries/data/mods/public/gui/reference/tips/texts/select_wounded_units.txt The hotkey is "O" (the letter) not "0" (zero). These are my tricks I'd like to share. Could maybe be phrased better and/or shorter. I made 3 tricks in a series called "Fight, flight or let them ride?". It seems a bit obvious, but it's important and a lot mistakes are made here. I split it up to 3 so one can read it hopefully in one loading screen. (Fight) Fight, flight or let them ride? If there's a fight going on nearby between two equally strong factions and some units are gathering resources they should definitely join the fight. If all units are occupied fighting any additional unit: -receive no damage at all -can deal additional damage It is very crucial to have the higher numbers in a fight. (Flight) Fight, flight or let them ride? Estimating army strength is crucial. If you notice a enemy army gains a slight upper-hand running is often the best choice as your disadvantage will only grow bigger. Only keep fighting if you are willing to sacrifice more units than your enemy for a very good reason. Don't expect that a bad fight turns better on it's own. (Let them ride) Fight, flight or let them ride? Assume a small group of attackers run around your base. Do not overreact and send too many men to chase them! Running units are not productive. If your enemy has a few units running and a few producing while you have all units running your enemy will flourish. In a fight you want to keep the upper hand though. A seasoned commander reacts to these situations in appropriate way. Anticipate supply and demand. When all men go to battle consider moving some woman from the fields to replace male wood gatherers right away. Garrison forts! A battle is going on. Garrisoned units in forts, civic centers and towers can safely deal damage from within the building. Garrisoned units usually deal less damage from within the building. Select wounded units with "O" and garrison them preferably. This way they avoid soon death and can serve you longer. You can repeat this while the fight is going on. Once the fight is over they may be able to heal up and be stronger than new units through their gained ranks. Teleportation: Units can enter and leave buildings from every angle instantly. You can use this behavior to transport units over the distance of the building. Command the units to enter the building, set the destination with the way-point flag of the building, with the building selected hold the U-key. This can be helpful e.g. for ranged units to gain some distance from melee units or vice versa for your melee units to close the distance to ranged units.

If you don't want to install the oddity detector (which warns in-game) you could check quickly the barter efficiency. If that is suspiciously high watch the complete replay. Note: Just a high efficiency alone is not sufficient to claim a market exploit. It is normal game play to use good prices once one takes note of it in the market. But a market exploit causes a high barter efficiency.

V02 is only a bug fix version. It should work now. It works in my one player replay and in the initial replay on which I set it up. Thanks for the report.

Can confirm. Made a short replay just doing it and its not recognized. I tested the mod on a multiplayer replay where it worked. I will check whats different. It is running though and detects 30s afk for example.

Yeah, the other players may also just like to test out the market glitch now (or something else). And that is annoying to the other 7 players. One could still have games where all mods are allowed and games where one can play the game without having to worry the other players are "just testing something".

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.