Feldfeld

There can also be the concept of progressive resource cost. The cost of the next building depends on the number of buildings currently in place, it augments with that number. That concept is used in Age of Mythology Egyptian monument to gods, it is also used in Age of Empires Online if my memory is correct. This allows for a bonus from the early game that can scale properly in the late game. The Persian ice house could benefit from this as right now it doesn't feel it has a good place in gameplay. But a distance restriction could also work.

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.

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

Version 1.0.0 has been submitted to mod.io and is awaiting signature. Please do not manually download the update from mod.io with intent to play it in multiplayer as long as it is not signed. This would confuse many players. Please wait for the signature to play it! This update introduces wood balance. As long as there is enough space around the player's base, they will be given 3 forests in p1 territory. The total amount of wood in these forests is equal (in expectation, and with fairly small variance) among players, but there can be variance between individual forests. The shape of the forests remains pretty random so there can be small imbalances here but it shouldn't matter much. I made it so that forests look the same as before. Depending on the situation the new forests may contain more trees than before and I haven't yet harmonized it with the rest of the map, but this should be barely noticeable. I invite you to try different biomes now! They are a lot more playable. I didn't include berry tree balance yet, but I made it so they spawn a little further away from the player, so less chance you get a "one for all" farmstead at the beginning. Note that I mainly tested the map with 1v1 small size and 4v4 medium size settings, though I did some runs with extreme settings as well. This update makes Mainland Balanced incompatible with previous version's Mainland Balanced. Yet I still make the choice to disallow the incompatible mod check, for the same reasons I gave previously in this thread. As a small mitigation I made it so Mainland Balanced gets a new mappreview image, so if players with outdated version join a game with the up to date version, they will see an error related to the mappreview file. If a player reports such an error in the game, please say there is a new feldmap version and players who haven't done so yet should update it! (Please note however that players up-to-date that join an host with outdated version will not notice anything until game starts) Sorry, that's not for this version yet . Unless I make an exception for pizza settings, it would have to wait for at least a 2.x.x zone of control mechanic.

Not really. I believe badosu used the prototype food balancer code I gave him. I don't recall what he did for wood. He did his own mineral balancer, which I do not really like because it was too predictable/not diverse enough (something like "players always get 1 mine at this distance of the CC"). But I intend to make my balancing code fairly generic and applicable to a wide range of possible map shapes. In the ideal case only some parameters would need to be fine tuned for every map. Anyway I don't see a reason why it would not work. But I will only consider integrating more maps after I am satisfied with my 2.x.x release of feldmap. (I recommand perhaps including a screenshot for every different map in the mod.io page for badosu's balanced maps)

I recall that some time ago @wowgetoffyourcellphone introduced new textures but these have been merged in vanilla already. Did he bring new ones since then? If so feel free to link me the relevant content

Textures and models are artists work which is not in my expertise. That being said, the wood rebalance should make every biome perfectly playable. So as result of the mod update you should see more diverse biomes being played which if you're used to only playing temperate would be a big improvement. If even with the update the community keeps playing the same biome I don't know what I can do anymore.