Feldfeld

It was the same filename of that post where you reported that issue and couldn't get the seed so I thought you were still on that issue. And just now I noticed you posted an image and not an actual file. If you want a seed from a replay file it's at the start of the command.txt

From the description you gave of it the problem is probably https://trac.wildfiregames.com/ticket/6605 which is known and somewhat reproducible using extreme map settings. See also some discussions here https://code.wildfiregames.com/D5247

Is this Gitea instance suitable to host mods?

I believe you just have to check for name uniqueness. Both feldmap and badosu maps define their own balancer which they only use in their own new maps (thus unique). So the only way they would be incompatible is if some functions defined share the same name in both mods, then one would override the other which is bad. With a quick check it seems there is no shared name so they should be compatible but tell me if you see otherwise. A way to check for OOS if you are alone is that you can launch a game, generating the map, then exit, change the mod order, and open the replay to that game. If it is incompatible you should see OOS there.

When that change was introduced, it was argued that it wouldn't decrease the performance, and that it would possibly even increase it (maybe even with benchmarks to confirm). Keep in mind that not everything is recalculated every turn. I think calculations use the elapsed time to decide if they trigger, or something like that. So I believe the more expensive calculations do not trigger more often even with a lower turn time. Personally I recall the lag issue was still very important even in a23 and below. But if you feel there is a change, there are so many other things that can also explain it: - Player level get stronger -> fully boomed faster -> huge fights happen sooner and more frequently -> you feel the lag - Economy upgrades are more effective -> all same as above AND you can afford to leave fewer units at home when fully boomed (so more in the expensive fight) - Meta: rush less viable -> people don't do it -> instead of having maybe 6 players simultaneously fully boomed, you have all eight which reach the same situation at almost the same timestamp, and every fight will happen simultaneously.

Also valid as a gameplay argument. I'd like my fortress to damage multiple units at a time and I even find it strange some people don't want that. That may be possible in theory but in practice I didn't really feel that much. In AoE2 even towers can kill multiple units at a time. That could be an interesting thing, but if every arrow goes for that unit then the player probably won't have the time to react before the unit dies. Also, having distinguishable arrow volleys would help with that (not saying that's not the case right now, I didn't play recently enough to remember)

Imo that would be an improvement but I still also would like to see deviation with arrows being able to hurt a different unit than the target, not sure if that's possible without hurting performance

Currently 0 A.D. has quite high scale fights and I find it absurd that all the fortress garrison would focus a single unit to oblivion. All arrows follow the same path, it is ugly and hard to tell what is happening, is the fortress effectiveness reduced because of overkill, or missed arrows? I would also find it not nice having to keep valuable units out of a fight under fortress from fear of having them focused with all arrows by the enemy without drawbacks. Not more than exactly one unit is damaged in a volley. It's weird that all defenders perfectly coordinate and are perfectly accurate (not as in "the unit will be hit", but the arrow follows exactly the intended path). There is no deviation, there is not a single other unit that will be hurt by a missed arrow. Meanwhile, random arrows are spread into the enemy army, for me that is a behavior that makes more sense with a strong fortification in a large scale fight. Arguably, they were spread too perfectly, which is also unnatural in the other direction, but I still prefer it over the alternative. And there are the concerns about rushes mentioned by @chrstgtr already.

Nonrandom arrows simply don't play well with the engine currently imo, and random arrows did introduce a somewhat unique strategical mechanism like mentioned above. That said I think nonrandom arrows would be good for ships.

It's possible to make AI have a tighter control on queues compared to what Petra does (iirc there exists something like a callback after trained units for example). The next question would be how much modifications need to be made to other PETRA components so your new queuing intelligence is well integrated in the overall working of the AI. That I do not know but it would probably be big changes.

I don't have a github repo for it. I could make one if you really need it but otherwise I think you can also work without version control and send me a feldmap with the changes.

If the host has a simulation issue then that would show every other player OOS. Not saying that's necessarily the case here

The fixed feldmap is available for download in mod.io

Indeed, sorry... Probably a modification from like a year ago which I then forgot about, here is the fixed feldmap, which I'll submit to mod.io feldmap.zip

New version is out and can be downloaded from mod.io