wraitii

I think lowering the attack of damaged units is possibly more worthwhile. Still allows retreating, but might smooth the snowbally Lanchester effect. Needs thorough testing, and possibly comparisons with other existing games.

The general idea would be to work around Lanchester's square law. Because several units can attack one unit, it's better overall to focus fire on one unit until it's killed (without overkill however), and then move on to the next, rather than distribute damage to the group as a whole. I'm not 100% sure how to fix this elegantly - perhaps to an extent it's not really possible or desired - but in principle it should make the game fight less snowballs, which I think is generally a pretty good thing for an RTS.

Congrats on the release folk

Not seeing anything too weird in the second replay (replaying non-visually). Can't replay the first one unfortunately as it doesn't start on turn 0. If you can reproduce from scratch that'd be great.

This will lead to GCs when the game runs out of memory. I think you're better off implementing my Incremental GC fix (which I merged since A27). Pathfinder is already in C++. I don't think you'll win much by swapping JS math functions to C++ unfortunately, as that's not really the bottleneck.

Overall a 2x faster scripting language wouldn't really "fix" the game - some of it is overhead, but most of the time is spent in C++. WASM is interesting, but unfortunately not actually super easy to use. I'd rather not do assembly script but write in some other compiled language for it tbh.

Been having some fun asking chatgpt to remake 0 A.D. screenshots into more realistic images. Obviously far from perfect but it's fun. The island in particular came out great IMO.

Interestingly these sound like they'd apply pretty equally to AoE2's naval system. People also complain about that one a bit but it's proven hard to improve.

Does this happen even without mods ? If it's a GUI thing it could be tied to a mod maybe?

https://en.wikipedia.org/wiki/Garbage_collection_(computer_science) It's linked to our usage of javascript. As it happens, I also have a diff for this problem: https://gitea.wildfiregames.com/0ad/0ad/pulls/7239

Replaying this - I don't see an obvious point where lag shows up, it's just slowly slower over time. There are big lag-spikes from the full hashes - they take about 150ms on my machine and I have a very powerful computer. The biggest lag spikes are GC slices, which take around 350ms on my machine. Regular sim turns take about 30ms, so on slower computers that's a lot of lag. --- I suspect the phase 3 lag might actually be from the GUI update, which I won't see by just replaying.

Could you upload a commands.txt of a game which shows this behaviour? It's possible that there's some tech thing that leads to issues.

I suspect the report is showing data at the end of the game when things are smoother. You should try clicking "save live report to file" in the middle of the game. But based on that profiling, your render frames take exactly 16ms which is consistent with targeted 60 fps. The "sim" frame every 200 ms take about 50ms, which should be potentially noticeable, but not dramatic. Breaking that down ,the "gui sim update" takes about 10ms, and the sim update is probably variable but 5-15ms is expected. The full state hash check in that replay is 111ms which is definitely noticeable. --- One possibility is that the lag is GUI lag. We've bumped the max selection size to 300 units I believe, that might affect lag?

This video seems to show "regular sim lag" to me - I would expect A26 to behave similarly. If you upload the profile2 JSON file we could look more in-depth.

The hashing happens on the main thread so the CPU literally cannot do anything else. So it's a freeze of everything.