Feldfeld

Very good idea. I've tried without success to promote other maps or biomes. The culture needs to change but some maps could take some improvement too. I invite you to try to play svn/dev version on the busiest days. Playtesting could be very helpful for the release. But there won't be autociv I think.

Yes I plan to get active again once A27 releases.

I have been lurking the forum for a very long time, and I found it very inorganic how many new accounts, all seemingly well acquainted with the multiplayer "pro" community (who knows who they actually are?) generate discussions about cheats, the only effect of leaving a very bad impression about the project to any other forum lurker, any potential new people to the project. I think this is a very bad thing and it has to stop. I also saw for myself the public disclosure of cheats. I looked a little bit at these, and found the usual suspects, but also a fairly novel cheat method baked in which should be, in my opinion, very easy to detect and prove from replay files. Since @ffm2 has done work about this, I will contact him to see if he can find usages in replays. This could potentially give answers about which lobby accounts Yekaterina has been using, or simply reveal which player would not hesitate using hidden cheats.

I like these ideas, if I find the time maybe I'll make a mod for that. This can open the way for paired (maybe exclusive) technologies, for example whether compensating for low fertility or optimizing high fertility

Indeed 0 A.D. doesn't split computation between different computers, but it does have multiple agents all in relation to each other and providing their own input. I'm not sure if it qualifies as distributed system. If I go by the Wikipedia page they even consider MMOs as distributed despite that they use dedicated servers and many of them are probably not much more technically complex than many games including the already mentioned Valorant. 0 A.D. is peer-to-peer with one peer taking the role of the host. If I go by the wikipedia page I could see an argument for it being the simplest case of a distributed system. As of right now, if any player other than the host drops, he can rejoin and the game can resume. If the host drops, the game is lost. If there was the added functionality that in case the host drops then the remaining players decide on a new host, then it would make a cool distributed system imo, but well it's too complex compared to the alternative of having a reliable dedicated server. Due to being peer-to-peer, 0 A.D. faces the NAT traversal problem. STUN was used for UDP hole punching to solve it in a22 (I found this patch https://code.wildfiregames.com/D364). Before that was the good old time of opening a UDP port. I personally implemented a simplified UDP hole punching algorithm as part of a free extension project in a distributed algorithms class. As for the simulation, the goal is to provide a smooth experience for every player, hopefully hiding issue related to connectivity. Indeed 0 A.D. is not doing that good. Let's compare approaches (to the best of my knowledge) in similar games: - 0 A.D.: the game advances as fast as the slowest computer, and bad ping of any player would slow the game for everyone. But the biggest problem is bad optimization which will be felt in late game, thus slowing the game, especially if a player is running a toaster. - AoE2: Like 0AD, it also runs with deterministic simulation I believe. With Voobly, it was similarly P2P with a peer taking the role of a host. However, if a player had bad ping with the host then only he was slowed and penalized. With DE there is a dedicated server, and a player is still penalized for having a bad connection. - Mario Kart 8 Deluxe: Also P2P with a peer taking the role of a host. It would be unplayable if you had to wait even a little to have the commands of other players, so the game runs with the other player position being only approximate, and synchronization is done as frequently as possible. Thus, unlike the above games, every player has a different state.

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.