ffm2

What do you mean? Implemented but not shown? I can't see it anywhere in the web page. Is it also a team Glicko-2 version? Edit: Ah! Found it at the player site, when you click on a player

We have the LocalRatings Page already: Which has no minimum required games problem. I have written about my criticism of LocalRatings in the mod thread and provided 2 other rating systems in the LocalRatings Mod. Glicko-2 and OpenSkill (or one variant of them). One can list the players by their rating. Atm. I prefer OpenSkill. The ratings are currently mostly taken by games that are balanced by vibe. For the rating to be more accurate one would need a few more automatic paired games by their ratings. E.g. in this game a team with a total rating of 7000 wins vs. a team with 5000. Yet again Decger stacks up more wins and Havran more losses. For a accurate rating win - loss should be the same. So in this example Decger should get players with low rating until he stacks up some losses. It is a bit hard though to convince the players to just accept the pairing, since there is currently already some drift in my database. This already got a bit better imo but I still need to convince the players to accept these teams.

Every game would be too much, but a option to submit it easy after one considers it a gg would be nice (with a crosscheck against double submissions). Also to download a bulk of games for better results of the local ratings mod would be nice. Maybe with some certain classifications. I am mostly interested in 4vs4 games with somewhat decisive end (at least one player should have resigned) preferably on mainland / mainland-balanced. For my very specific use case best would be to provide some player names where the rating seems off and to get some games to feed my database.

Yeah, that can be changed from a dropdown menu in the options. Theres a lot. If your curious of the rating of a certain player, you can trace indiviual games and the progression of this player in the replay by filtering his name and check out the bottom right.

LocalRatings Team Balancer A mod that extends LocalRatings by Mentula with two new buttons on the game-setup screen. One balances teams automatically by rating, the other evaluates the current setup and adds two outcome-based rating systems, Glicko-2 and OpenSkill, alongside the original LocalRatings score. Why outcome-based ratings? The LocalRatings ranking list already shows the problem: even with plenty of replay data, some known-strong players end up rated poorly and some known-weak ones look stronger than they are. Raw in-game statistics don't track skill cleanly. In a 4v4, if three players focus-harass one strong opponent, that player's stats look weak, though they're being targeted because they're strong. A useful comparison: modern chess engines evaluate positions with neural networks far beyond human understanding, yet FIDE still uses Elo, chess.com uses Glicko-1, and lichess uses Glicko-2. Even with perfect game analysis available, the established outcome-based systems remain the standard for tracking player skill over time. Win/loss results across many games carry a signal that in-game metrics miss. 0 A.D. has no chess-engine equivalent, so the case for outcome-based rating is even stronger here. Rating systems Three systems are available, selectable in the LocalRatings settings: Local Ratings (original) - rates players by in-game statistics relative to others in the same match. Works for all game types but inherits the limitations above. Glicko-2 - tracks each player with a rating, a rating deviation (confidence), and a volatility. New players start at 1500 ± 350. The conservative rating used for balancing is rating − 2·deviation, so a fresh player is treated as significantly weaker than someone who has won even one game. OpenSkill - an open-source Bayesian system based on the Bradley-Terry full model. Each player has a mean skill mu and an uncertainty sigma. New players start at mu 1500, sigma 500. The conservative rating is mu - 3·sigma. Glicko-2 and OpenSkill only count locked-teams games with exactly two teams; free-for-all and unlocked-team games are excluded. All other LocalRatings filters (minimum duration, population cap, cheat games, etc.) still apply and can be configured in the LocalRatings settings. Win/loss counts are tracked separately and shown alongside ratings. Balance button When the host presses balance, the mod reads all currently assigned players, looks up their ratings, and finds the partition into two teams that minimizes the difference in conservative rating sums. It then reorders the player slots. The result is posted in chat with rating sums, the rating difference, and a predicted win probability. Note the win probability it calculated with the raw rating and the pairing done with the conservative rating. Non-host players with the mod see a suggest button instead. Pressing it posts the same proposal to chat without changing any settings, so the host can decide whether to apply it. Both buttons have spam protection: pressing them again with the same player constellation does nothing. Slot shuffles or team swaps don't count as a new constellation. Evaluate button Reports on the current team assignment without changing anything: rating sum and conservative sum per team, the rating difference, which team is stronger, predicted win probability, and a full player ranking by rating with win/loss counts. Observers in the lobby appear in the ranking as well. End-of-game rating updates When a game finishes, the rating database updates on every mod user's machine. To avoid multiple mod users posting the same numbers to chat, only one client announces the changes; the others update silently. There's a known chat-line spacing bug that pushes this announcement far below the regular chat area. It can be fixed with this patch Including older replays The engine only exposes replays from the currently installed version, so by default ratings are built from 0.28.0 replays only. To include 0.27.1 replays, copy them into the 0.28.0 folder. They count toward all three rating systems. Linux: copy or move everything from ~/.local/share/0ad/replays/0.27.1/ into ~/.local/share/0ad/replays/0.28.0/ Windows: copy everything from %APPDATA%\0ad\replays\0.27.1\ into %APPDATA%\0ad\replays\0.28.0\ macOS: copy everything from ~/Library/Application Support/0ad/replays/0.27.1/ into ~/Library/Application Support/0ad/replays/0.28.0/ After copying, open the LocalRatings page and press Rebuild list to re-process all replays in date order. This step is needed even when rebuild isn't normally required, because the imported replays are older than your existing ones and the ratings have to be recalculated from the beginning. The imported replays won't be playable as visual replays in 0.28.0, but their metadata is read correctly for rating purposes. Limitations Team rating is inherently harder than 1v1. Individual contribution isn't fully separable from team performance, and the rating systems see each game as a single team win or loss. This is a fundamental constraint of every team rating system, not something specific to this mod. Cold-start: ratings come from the host's local replays only. Since the database is built from whatever the host has played or observed, players who appear in the lobby with no recorded games start unrated, and their conservative rating sits well below average until they accumulate results. A genuinely strong player with only a few recorded losses will likewise look weaker than they are. The automatic team pairing works as a correcting instance: A strong player with low rating will be paired with players with a high rating, resulting in a very strong team and a high likely win. This strong player will then accumulate wins. These unbalanced games might be frustrating. Three things you can do meanwhile: Accept the balance and play. The fastest fix is more games with the automatic pairing. Adjust manually. Use /rate username 1600 to set a player's rating before the match starts. Useful when a rating is obviously off. Seed the database. Download games with known outcomes from replay-pallas and drop them in your replays folder, then rebuild. Pick a balanced selection - similar wins and losses for each player - so you don't accidentally bias the rating in either direction. A player can help to fix their rating by uploading a few decisive games to replay-palas for the hosts to download. Non-decisive games. Most 0 A.D. team games don't end with the entire losing side eliminated, and Glicko-2 / OpenSkill can only update on games where a winner can be determined. The LocalRatings Team Balancer ships with an Auto-Classifier that infers a winner from in-game data (surviving populations, final scores and defeated-count difference) for games that ended without a clean engine verdict. The quality of your ratings therefore depends partly on how well the Auto-Classifier performs on your replay set. Per-game rating changes under your current settings are visible in the replay section. Locked teams. The most sensible option usually would be only evaluate games with locked teams. The problem is when one switches the map e.g. from mainland to balanced-mainland the settings defaults to unlocked teams. In most cases this is harmless as the players just don't change their diplomacy states. Therefore the option Rate unlocked-team games exists. LocalRatings_Team_Balancer.zip

Here is a autociv version with the "Building placement auto-retry at cursor" fixed and made optional. The options page is now slightly too big. Killed, Lost and KDr are still always 0. The problem is in simulation/components/StatisticsTracker~autociv.js KilledEntity and LostEntity aren't incremented. Fixing it in autociv would cause OOS. Needs upstream fix. AlexHerbert Teams are fixed, but who cares about that from the stats overlay? autociv.zip

We had a OOS today with a lot of players and specs OOS. I wasn't OOS so heres my logs. OOS Players: breakfastburrito_007, Atrik, Decger (1623), terry_boucle (1507), erictommy01 (2000) commands.txt metadata.json interestinglog.html mainlog.html oos_dump.dat oos_dump.txt system_info.txt

Problem: The replay folder format YYYY-MM-DD_NNNN uses a per-machine sequence counter. The same multiplayer game has a different folder name on every participant's machine and different games having the same name. This makes it harder for cross-player merging of replay data (rating aggregation, replay sharing, debug traceability) without parsing every commands.txt to extract the matchID. Proposal: Change the new replay folder format to YYYY-MM-DD_<matchID>, using the existing matchID already written into commands.txt. Date prefix preserved for chronological sort; existing replays unchanged. matchID already exists, is generated by the engine for every game (multiplayer and singleplayer), and is identical across all participants of a given match. Use cases: Replay-sharing site https://replay-pallas.wildfiregames.ovh: matches uploaded by different players collapse to the same identifier instead of being renamed. Mods (e.g. local ratings): users can merge rating data from co-players without name-collision workarounds. Bug reports: devs can ask for a specific replay by ID and the user finds it directly in their folder list. Edit: The date should also be unified in UTC-0 or such.

This is a 4v4 that went a long time. The player I_am_groot went OOS. He did not rejoin before the OOS happened. i_am_groot_oos.zip

What do you mean? this new info is only for one player as everything would be too much. The old one is still there, you may need to check your settings again.

New Spectator Features in AutoCiv This version of AutoCiv adds two new features for spectators: gathering rates and gameplay tips. Gathering Rates A new row displays real-time resource gathering rates (food, wood, stone, metal per second) for the selected player. Rates are calculated using a rolling window to smooth out drop-off events and provide stable measurements. Gameplay Tips Context-aware tips appear in a second row, suggesting timely upgrades and buildings. For example: "Ax" suggests researching the axe upgrade "3Fields" suggests building more fields (usually you should have 3 now) Important notes: Tips don't detect queued foundations or in-progress research, so they may appear redundant if you've already started the action Tips are tuned for booming pocket players and based on economic optimization. Take them as suggestions, not strict rules Player strategies vary; tips won't fit every playstyle Multiplayer Behavior Players: Tips and rates are hidden during active multiplayer games (fairness) Observers: Full access to tips and rates for all players Optional: You can completely hide the stats overlay when playing multiplayer, keeping AutoCiv strictly for lobby features and spectating Methodology Tips are derived from two sources: Statistical analysis of high-level replays (field timing, upgrade timing) Economic modeling comparing upgrade costs vs. worker efficiency (capacity upgrades, gather rate upgrades) Development Note Much of the AutoCiv codebase is legacy code. I used it as a foundation because it was easy to modify, but I don't plan ongoing maintenance. I don't typically use this myself. I built it primarily for economic analysis. Hopefully it helps some players improve their gameplay. Future posts may share more insights using the gathering rate data. autociv.zip trainer.patch

The gaul trumpeters should make sound. I was just scrolling reddit on the trumpeters. Some user says it's somewhat altered and provides 3 other examples: https://open.spotify.com/episode/0eABuyDFXAM09jKd7MWPZh?si=vc-gGIsATEij3GbV-p0Ebg&t=1 https://www.bbc.com/news/articles/cgk1p8xk7z7o https://www.instagram.com/reel/DU4spHMAM1H/?utm_source=ig_web_copy_link&igsh=NTc4MTIwNjQ2YQ==

There's a bug: one can't rotate buildings by holding the mouse button pressed and move the pointer on a obstruction. That's necessary to turn a storehouse between trees just right. The bug is in input~!autociv.js. I don't need any input changes, so I removed the file.

The problem is that a lot game relevant "skills" is not covered in the scores though. I think a score for "enemy presence", a bit like the exploration score would help a bit. This is more directed to the main game though. A player should get a score from enemy units near him based on time and distance. E.g. player 1 has 3 units, player 2 has 15 units. Player 1 can just run around and make the 15 units chase him. Player 1 should then receive more "enemy presence" points. Currently all would count as idle, not making eco or military score. This would also favor someone who gets 2v1 attacked. LR doesn't make the scores though, only weights whats there.

When I checked for the unusual high sniping activity I came to the conclusion that its a auto-clicker. There are a lot of games where this is prohibited and reason for bans. It's definitely the case that some players are using such mice and see no harm in it and it's the case that some players would like that such mice/features were not used. I don't like the current balance where one is incentivized to target the ranged units at the back (because they have less armor and deal much damage). Besides that, even if the balance were changed to my liking and melee were a high priority target, I think the feature of the target area could still be beneficial in situations. To take out healers, elephants, heroes or so. I think "sniping upgrade" could be a interesting upgrade. That doesn't upgrade any stat. but how well the army acts together in later games. Upgrade 1: Target the unit which requires the least amount of attacks within your range Upgrade 2: Be aware of where the other soldiers shoot and don't shoot more arrows on a unit than necessary. I know some game that had these as upgrades. Should be priced high though, as they are quite valuable.

I don't know about this part. I haven't played AOE2 in so long that I can't say anything about it. AFAIK borg and Valihrant were also good AOE2 players. I don't think one should change the complexity based on the current skill of the lobby users. I think it would be interesting to see statistics of nr. of players over the time. How a releases draws in players, how it may go down over time. Maybe with elo ranges. For myself I can say that I don't have as much of a competitive drive as before "enhancement mods" were around.

Yes it does. You don't have the final say in the truth. Also: there's never a mind challenging task you add to the eco that you would rather like to solve in your base while you are raiding. You just removed the "boring repetitive" ones. All your "features" go just one way, you remove penalties and make the game easier in a competition with the ones that still have to deal with the penalties.

That is no argument. The whole game is a artificial problem. If you want to relax, there is no problem in setting the starting resources to high. Your production won't turn of. You can also use proGUI which changes 0a.d. more to your liking, just as DOTA changed Warcraft 3 with a shift of the focus to the heros. The Idea of these "artificial problems" is that the player has tasks in his base even while raiding that may get neglected. The key is for the player to prioritize on the more beneficial: Is the raid good or doing more damage to your economy. In depth also discussed here: The community is heavy divided because players automate their game with mods, don't disclaim it and compete with players that like to compete solving these "artificial problems" better than their enemy. See other threads like: It's also not just that the problems just gets removed, they get removed in a way that no human player can. So besides that they have to deal with less, they have a benefit.

Tbh. I didn't fully understand what each is doing here. But as I understand it, the pro of small batch is the units can get faster to work, the pro of higher batch sizes is the total train time decreases. In this simulation a unit with total cost of 100 gets produced, gathers with 0.75 without ways to drop of, at different batch sizes from one cc. To account for the ways one could reduce the gather rate. I wouldn't take any practical advice from this. Just spectate some games with good eco scores. This leaves out the timings of the next barracks which costs again. batch.py

Here is what the LLM ended up with, take it with caution, but to me it seems kind of plausible. Some approximations have been made. One builder just build sequential houses, corrals or fields. Usually its more. The walking distances are neglected. Targeted are ~38.9 f/s. All resources are just pooled together. Realistically its also a big factor that one gathers wood and get food at the fields, while at the corrals you don't have so much food to invest at the start, except if you start out with elephants (or other plenty of fauna) nearby. The one big benefit with the corrals is that you need a lot less pop. Also this pop is way better as it can be used to attack. farms_vs_corrals.py

Why though? It would be 2 developers working against each other. First develops a game mechanic where each farmer has x0.9 of the efficiency of the former. Second just optimize the effect automatically to a minimum making it meaningless for the player. If you like to plan less for your setup, why don't you just suggest to remove the feature that's also not full documented with the numbers? I'd just keep it as it is, but it should be documented with the numbers clearer.

Yeah, if I have some time, I could update it or anyone with the script and a LLM. Just describe the stats in full detail. But to me this seem to be too obvious to put in that effort of typing the stats and debug it. First comes the berrys, then hunt/fish, then transition to fields. Corrals with slaughtering seems not to be the meta atm.. In earlier alphas I liked to have corrals, a temple nearby, wounded cav could work and heal by aura. But it was never a question of either farm + upgrades or corrals. Farms are a must. ... (well one exception was survival of the fittest were there were once no farms, but corrals)

Map: Mainland Players Involved: ffm (Germans), JulioC23 (Macedonian) Description: After capturing an enemy cc (belonging to JulioC23), I trained units and attempted to set the CC waypoint first to ground, then to the cc, so newly trained units would garrison. Despite multiple attempts changing the waypoint to different spots on the ground in front of the CC, on the CC’s corner, and beside it, units spawned outside, did not garrison, and were killed by a nearby enemy tower (still owned by JulioC23). Attempts to reproduce: Replicated the situation in a new game with unassigned players on Mainland, but the issue did not occur. The original game was saved and rehosted, so no working replay is available. Note: If someone is interested, it might be possible to combine the two replays by adjusting turn numbers to investigate further. This is at least a report for awareness; perhaps others can upload if they encounter the same issue commands1.txt commands2.txt

The connection issues I was talking about should happen in the first 4 min. and I'd expect if 2 players recognize this to just abort the game on equal terms. More frustrating its at >8 min. I also like the way lichess handles it. Its server hosted, but apart from that, if one player disconnects, a timer counts down "1:30" and if its run out, the remaining player has the option to claim a victory or draw. He also has the normal resignation option. For 0 A.D. if one player drops, and the remaining player is fair, I'd like some options, like claim victory, resign, abort (draw), spoil scores for a better decision or choose decide by score (blind without knowledge of it).

I set up another game where it was 11 relics: commands.txt