All Activity

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.

Hey guys. Was there any discussion about this recently? I think that's good way to find games, to engage community, to advertise 0AD on Twitch/Youtube with some fun content, to encourage players to practice, etc. My idea would be to organize something like "0AD Summer League" which would be 4 rounds (swiss format or groups) + play-offs, 1 match peer week. And to have 3-4 such tournaments per year. Alternative would be longer league (if we can have like 20 participants and do round robin/league format), but I think this is better b/c I doubt we will get 20 signups in reasonable amount of time. Better to split in smaller tourneys so people can join each, which'd not be case with long league. Additional details: - Stream. It'd be fun if someone can stream/cast games (i'd prefer 1600 MMR or better players who will explain what's going on - I can't do it). Ideally find some popular streamer with many viewers, from AOE or whatever other game so we advertise 0AD more actively. Could be co-casted with some 0AD top player. - Prize pool. If someone is credible in the community and willing to collect money on Patreon, Ko-fi.com or similar platform. And sponsor would be awesome. - Test gameplay/balance changes. These tournaments is good way to test all balance changes. Community-mod used to hold these tourneys iirc. - Share to in-game news. Over there in the lobby. How it works, who has permissions? What do you think guys? If noone else wants, I can take organization which would include: preparation invitations/forum posts, making event on Challonge, collect replays, communication with players, etc. Other parts, I'd need help with.

How do you account for RD increasing over time? do you factor in the replay date?

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.

Firstly, you installed the outdated A26 version. This is because Debian always gives you outdated packages. You should download the latest release A27.0 from another source. However, A27.0 also stutters a bit, in which case, you can help by testing the RC version A27.1 at http://releases.wildfiregames.com/rc/ The build instructions is here https://gitea.wildfiregames.com/0ad/0ad/wiki/BuildInstructions

On Debian 12 the game has always been stuttering to the point it is hardly playable and decreasing video settings quality not helped. $ apt list 0ad 0ad/stable,now 0.0.26-3 amd64 [installed] 0ad/stable 0.0.26-3 i386 I am running other apps too, CPU use is around 27% without 0AD running. Free memory 8 GiB. $ free -ht total used free shared buff/cache available Mem: 62Gi 53Gi 8.0Gi 17Mi 1.2Gi 8.6Gi Swap: 59Gi 23Gi 35Gi Total: 121Gi 77Gi 43Gi $ zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 zstd 59G 23.5G 7.3G 7.5G 16 [SWAP] $ dstat # 0AD not running $ dstat ---load-avg--- ------memory-usage----- ----swap--- -dsk/total- --io/total- --filesystem- -net/total- --------sockets--------- ----unix-sockets--- ------tcp-sockets------- ---udp--- 1m 5m 15m | used free buff cach| used free| read writ| read writ|files inodes| recv send|tot tcp udp raw frg |dgm str lis act |lis act syn tim clo |lis act 11.1 13.1 12.8|53.2G 7634M 4408k 656M| 23G 36G| 122M 85M|22.0k 21.6k|40480 615k| 0 0 | 4k 1k 29 0 0 | 83 2k 70 2k| 52 1k 69 1k 72 | 35 4 11.1 13.1 12.8|53.2G 7706M 2796k 622M| 23G 36G| 241M 35M|4430 8837 |40512 615k|1278k 7674k| 4k 1k 30 0 0 | 83 2k 70 2k| 52 1k 72 1k 68 | 35 4 11.1 13.1 12.8|53.2G 7738M 2824k 578M| 23G 36G| 285M 23M|5146 5904 |40512 615k|1228k 9508k| 4k 1k 29 0 0 | 83 2k 70 2k| 52 1k 81 1k 65 | 35 3 11.1 13.1 12.8|53.2G 7714M 2836k 591M| 23G 36G| 313M 20M|8372 5096 |40512 615k|1213k 7929k| 4k 1k 30 0 0 | 83 2k 70 2k| 52 1k 74 1k 68 | 35 4 11.1 13.1 12.8|53.2G 7697M 2820k 591M| 23G 36G| 191M 24M|2693 5269 |40512 615k|1241k 7187k| 4k 1k 30 0 0 | 83 2k 70 2k| 52 1k 77 1k 68 | 35 4 11.1 13.1 12.8|53.2G 7686M 2792k 608M| 23G 36G| 272M 26M|7646 6480 |40384 614k|1180k 8799k| 4k 1k 30 0 0 | 83 2k 70 2k| 52 1k 66 1k 66 | 35 4 11.1 13.1 12.8|53.2G 7682M 2776k 609M| 23G 36G| 209M 19M|3833 4904 |40384 614k|1382k 7910k| 4k 1k 30 0 0 | 83 2k 70 2k| 52 1k 74 1k 63 | 35 4 11.1 13.1 12.8|53.2G 7738M 1788k 625M| 23G 36G| 234M 46M|4660 11.7k|40480 615k|1007k 8200k| 4k 1k 31 0 0 | 83 2k 70 2k| 52 1k 69 1k 65 | 35 5 11.1 13.1 12.8|53.2G 7740M 1776k 622M| 23G 36G| 291M 27M|6674 6980 |40352 615k|1187k 8744k| 4k 1k 30 0 0 | 83 2k 70 2k| 52 1k 74 1k 61 | 35 4 11.1 13.1 12.8|53.2G 7745M 1780k 608M| 23G 36G| 247M 33M|7001 7918 |40352 615k|1065k 8868k| 4k 1k 31 0 0 | 83 2k 70 2k| 52 1k 77 1k 62 | 35 4 10.6 12.9 12.8|53.1G 7795M 1796k 612M| 23G 36G| 229M 30M|4438 7550 |40416 614k|1207k 7277k| 4k 1k 32 0 0 | 83 2k 70 2k| 52 1k 73 1k 63 | 35 6 10.6 12.9 12.8|53.1G 7818M 2044k 608M| 23G 36G| 317M 29M|4914 7284 |40416 615k|1238k 8930k| 4k 1k 32 0 0 | 83 2k 70 2k| 52 1k 80 1k 56 | 35 6 10.6 12.9 12.8|53.1G 7838M 2044k 614M| 23G 36G| 274M 22M|4857 5645 |40448 615k|1018k 7513k| 4k 1k 53 0 0 | 83 2k 70 2k| 52 1k 86 1k 63 | 35 29 10.6 12.9 12.8|53.1G 7858M 1788k 603M| 23G 36G| 216M 44M|4098 10.3k|40416 615k|1192k 7951k| 4k 1k 30 0 0 | 83 2k 70 2k| 52 1k 83 1k 58 | 35 4 10.6 12.9 12.8|53.1G 7871M 1792k 599M| 23G 36G| 224M 30M|4238 6255 |40416 616k|1469k 8313k| 4k 1k 41 0 0 | 83 2k 70 2k| 52 1k 100 1k 67 | 35 13 10.2 12.8 12.7|53.1G 7921M 1264k 534M| 23G 36G| 362M 39M|9193 9883 |40416 615k|1170k 8281k| 4k 1k 31 0 0 | 83 2k 70 2k| 52 1k 89 1k 60 | 35 5 10.2 12.8 12.7|53.1G 7904M 1260k 536M| 23G 36G| 304M 15M|3700 3793 |40416 615k|1016k 7316k| 4k 1k 31 0 0 | 83 2k 70 2k| 52 1k 91 1k 58 | 35 5 10.2 12.8 12.7|53.1G 7853M 1256k 560M| 23G 36G| 335M 42M|16.1k 10.6k|40512 616k|1228k 9312k| 4k 1k 33 0 0 | 83 2k 70 2k| 52 1k 86 1k 55 | 35 7 10.2 12.8 12.7|53.1G 7849M 1532k 569M| 23G 36G| 316M 23M|7024 5855 |40352 615k|1006k 7934k| 4k 1k 33 0 0 | 83 2k 70 2k| 52 1k 80 1k 62 | 35 7 $ dstat # 0AD is running and stutter ---load-avg--- ------memory-usage----- ----swap--- -dsk/total- --io/total- --filesystem- -net/total- --------sockets--------- ----unix-sockets--- ------tcp-sockets------- ---udp--- async ----most-expensive---- ----most-expensive---- 1m 5m 15m | used free buff cach| used free| read writ| read writ|files inodes| recv send|tot tcp udp raw frg |dgm str lis act |lis act syn tim clo |lis act | #aio| block i/o process | i/o process 23.0 17.4 15.3|52.8G 8225M 1984k 475M| 24G 35G| 232M 25M|5891 4762 |40416 636k|1442k 8577k| 4k 1k 69 0 0 | 83 2k 70 2k| 52 2k 93 1k 58 | 35 43 | 0 |AppRun.wrap3372k 0 |airdcppd 896k 286k 21.6 17.2 15.2|52.8G 8207M 1996k 499M| 24G 35G| 235M 40M|7593 9483 |40448 617k|1575k 8652k| 4k 1k 51 0 0 | 83 2k 70 2k| 52 2k 85 1k 58 | 35 25 | 0 |session-des 13M 0 |session-des 12M 10M 21.6 17.2 15.2|52.9G 8099M 2620k 554M| 24G 35G| 374M 18M|32.7k 4617 |40416 618k|1397k 9058k| 4k 1k 49 0 0 | 83 2k 70 2k| 52 2k 84 1k 55 | 35 24 | 0 |session-des 18M 0 |session-des 21M 19M 21.6 17.2 15.2|52.9G 8017M 2688k 602M| 24G 35G| 341M 38M|25.1k 9593 |40320 617k|1336k 7331k| 4k 1k 49 0 0 | 83 2k 70 2k| 52 2k 93 1k 61 | 35 23 | 0 |AppRun.wrap4696k 0 |session-des2386k 1992k 21.6 17.2 15.2|52.9G 8062M 3144k 558M| 24G 35G| 371M 112M|20.6k 28.7k|40320 617k|1314k 7532k| 4k 1k 66 0 0 | 83 2k 70 2k| 52 2k 96 1k 59 | 35 31 | 0 |thunderbird 25M 0 |airdcppd 1966k 656k 21.6 17.2 15.2|52.9G 8096M 2924k 548M| 24G 35G| 243M 86M|8739 21.4k|40352 617k|1312k 8534k| 4k 1k 49 0 0 | 83 2k 70 2k| 52 2k 93 1k 63 | 35 23 | 0 |firefox-esr3880k 0 |LosslessCut1425k 1336k 20.5 17.1 15.2|52.8G 8185M 2888k 508M| 24G 35G| 282M 101M|7799 25.8k|40384 618k|1371k 8162k| 4k 1k 65 0 0 | 83 2k 70 2k| 52 2k 88 1k 56 | 35 43 | 0 |LosslessCut5876k 0 |LosslessCut3922k 4029k 20.5 17.1 15.2|52.7G 8282M 2552k 504M| 24G 35G| 324M 89M|23.3k 22.6k|40352 620k|1278k 8127k| 4k 1k 49 0 0 | 83 2k 70 2k| 52 2k 83 1k 61 | 35 23 | 0 |session-des7356k 0 |session-des6831k 4780k 20.5 17.1 15.2|52.8G 8251M 2040k 485M| 24G 35G| 323M 51M|24.5k 13.2k|40352 617k|1348k 9453k| 4k 1k 49 0 0 | 83 2k 70 2k| 52 2k 83 1k 61 | 35 23 | 0 |AppRun.wrap4864k 0 |airdcppd 1540k 405k 20.5 17.1 15.2|52.7G 8317M 2024k 478M| 24G 35G| 326M 107M|12.8k 27.2k|40352 618k|1330k 7938k| 4k 1k 49 0 0 | 83 2k 70 2k| 52 2k 86 1k 53 | 35 23 | 0 |AppRun.wrap3232k 0 |session-des 388k 276k 20.5 17.1 15.2|52.8G 8245M 1960k 465M| 24G 35G| 366M 47M|32.0k 11.7k|40352 618k|1180k 8069k| 4k 1k 49 0 0 | 83 2k 70 2k| 52 2k 81 1k 58 | 35 23 | 0 |AppRun.wrap3840k 0 |airdcppd 833k 348k 21.8 17.4 15.3|53.0G 8077M 2188k 485M| 24G 35G| 460M 38M|49.9k 9574 |40352 621k|1221k 8226k| 4k 1k 49 0 0 | 83 2k 70 2k| 52 2k 91 1k 67 | 35 23 | 0 |thunderbird 26M 0 |LosslessCut2324k 2369k 21.8 17.4 15.3|52.9G 8089M 1624k 489M| 24G 35G| 330M 42M|21.0k 10.6k|40352 616k|1683k 8939k| 4k 1k 49 0 0 | 83 2k 70 2k| 52 1k 86 1k 69 | 35 23 | 0 |session-des 34M 0 |session-des 22M 17M 21.8 17.4 15.3|52.9G 8087M 1656k 519M| 24G 35G| 308M 39M|11.2k 9586 |40320 617k|1334k 8320k| 4k 1k 27 0 0 | 83 2k 70 2k| 52 2k 91 1k 62 | 35 1 | 0 |session-des5812k 0 |session-des3047k 2257k^ Full system details here. The issue has been there always, since my initial installation yesterday.

I'm reading some strange comments. Of course, cavalry should be faster; that's the principle of the unit. It already has minor penalties, such as reduced capture attack and suffering damage multiplication. The solution isn't to have a common citizen unit with a lance destroy a very expensive champion unit! The champion cavalryman is one of the most expensive units, so it must be one of the strongest units. Furthermore, I believe it's necessary to balance champion units between each civilization. If I'm not mistaken, the Persian and Selucid champion cavalrymen are better suited to long melee combat than other civilizations because they have better range and armor. Their range needs to be nerfed and made sure they can't stack too much in a small space. For example, champion chariots already have this feature. This will allow the infantry to do their job. Additionally, it is absolutely necessary to remove the 20% extra life tech on champions.

The game was balanced for having CS from the start, so they should stay. However, we should still get rid of the Female citizens and replace them with the generic two-gendered citizen unit with slightly altered gather rates. But, I won't get too much into off-topic.

Always great to watch : (https://www.youtube.com/watch?v=1GzQPxblnxg )

This mod allows you to build on the entire map, without restrictions. It also removes the territorial border. If you encounter any bugs, contact me somewhere. Maybe on the Wildfire games forum. What’s New: Fixed Civilian Selection Bug – Resolved issues with unit selection panels. No More Gaia Decay – Structures built on neutral territory are no longer decayed by Gaia. Downloads: GitHub Repository: Download the Latest Version Here ModDb.com: Download the Latest Version Here Feedback Welcome! Found a bug or have suggestions? Open an issue or discussion on the GitHub page. Enjoy the mod!

Aren't you the guy who fights against CS? So Cavs aren't CS so we want to encourage people to use them instead CS, don't we??

CS jav cav was op in A25. But now they are not as OP because of the acceleration mechanic and the buffed spear cav hard countering them. And speed is exactly why we make cavalry in the first place This is a good idea in my opinion

@BeTe, I put it, please remove the quoted spoiler part.

Spoiler?! :p

"QUICK! Nerf the champion spear cavalry!" Meanwhile, CS javelin cavalry: Exists The main reason ALL cavalry is OP is speed. They're simply too fast when compared to spear infantry (which should be their counter). Either increase hoplite armor, or decrease the cavalry speed.

Don't forget this is real-time strategy, not turn-based strategy game.

Soved!

That said, Olympic Champion could be an appropriate tier 3 rank name for Spartans if such was ever introduced.

so maybe there were about two olympic champions in the spartan army who served as elite soldiers, while hippeis were an established elite contingent. name should be changed already.

Well apparently if people claim that Vulkan is faster than any Linux rendering API (which it clearly is) then I'll try switching to that. Also thanks a lot for the info EDIT: It works! I changed from OpenGL to Vulkan and things seem to be great. The game loaded and I got to play with the friend I told you about in the OP. Thanks a lot!

No no, it's a known bug with OpenGL. IIRC the patch has been backported in the flatpak. It will also be in A27.1 which hasn't yet come out.