ffm2

The games where one can make a comeback out of a very dire situation also have sweetest victory. Maybe it could be a announcement when a threshold of score dis-balance is reached in the game in the oddity detector mod if I revive it. Since your leaving (or atm. feel that way), I'd like to shine on a game where diagonalo had the fastest boom in R28, multiplayer that I attended by min. 13 going by the most resources spend. And all with just 2 extra apple trees in your base. The trick was to reach 2 berry spots far out of base with barracks. This game also made me question this metric a bit, because I was maur and going for the hero Chanakya before doing the military techs. This reduces the tech costs by -20%. And this kind of shortcut isn't reflected in this metric at all. But anyway gg commands.txt

Since so many TGs end without all 4 players resigning I made a classifier for my version of the local ratings mod. This could be made to be used as a victory condition. I am getting also annoyed by mates that resign too early. But some games are already decided long ago and if there is a huge dis-balance in the score and population one could already call it a gg: So for a clear victory condition one could set the score factor to 1.2 and population to 1.8 or so. Just as a suggestion for the game or a mod. I don't have time and the desire to code atm.

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.