AInur

Most of the cheats that you discuss exist in the form of a mod. Here is a potential solution: the clients synchronize all mod files from the host during the gamesetup process, regardless of whether the client has the same mods or not. All clients and the host will expose their mods folder to each other for synchronization over network, while players are chatting or waiting for the game to start. The advantages of my solution are: 1. All cheat edits of signed legitimate mods will be overwritten instantly. 2. Players don't need to restart the game or go through the hassle to download mods in order to join a particular host. 3. Less likely for OOS errors.

The solution to this problem is to not play Nomad Mode. The conventional setting for Nomad Mode is 5 minutes of ceasefire at the beginning and medium resources for players to build a Civic Center. In @strat0spheric's game, another player purposefully set his cavalry to stand on Strat0spheric's CC foundation to prevent him from building. Due to the ceasefire, he could not kill that enemy unit nor move it away. He cannot delete his foundation, otherwise he would not be able to afford a new CC. This removed him from the game until the end of the ceasefire. In a normal game, he can just kill in enemy unit easily. The real problem here is not the foundation or a technical bug; it's the Nomad Mode's design flaw. A ceasefire must be imposed in order to prevent players killing each other immediately on spawn, especially considering that some factions have stronger starting military units than others. The starting points are completely random so the game is more influenced by luck than skill or strategy. A potential improvement for Nomad Mode is to allow the instant build of the first CC. This would solve 5 underlying problems: Using units to prevent others from building as described here Unfair advantage of the Mauryas elephant Inexperienced players deleting their CC foundation and not being able to afford a new one No need for a ceasefire as units can be garrisoned inside immediately - enables early rushing strategy. Wastes no time waiting for the handful of units to build a CC. However, with this being said, allowing buildings to build on units is fine; it happens in other games. We should allow units to walk out of the foundation but not walking into it. The construction can continue in the meantime. An even more flawed game mode is Regicide mode, but that's for another topic.

Do you think it's possible to automatically synchronize all replay files between players? Or at least download the replay file content from the host. When I am joining a game, I see a lot of data being downloaded. Perhaps those can be saved?

I think there is a room for improvement here: save the game state to the replay files, so that everything can be reconstructed?

I watched a spectacular game as an observer and I would like to watch it again offline. However, the replay of this match does not show up in the in-game replays page. I found the relevant files in the replay folder and attached them below: commands.txtmetadata.json I joined the game soon after it started. How can I watch this replay again? The commands file seems intact, so theoretically, we should be able to reconstruct the whole replay from turn 32.

I would like to draw your attention to the code on spread mechanism in /public/simulation/components/Attack.js let randNorm = randomNormal2D(); let offsetX = randNorm[0] * distanceModifiedSpread; let offsetZ = randNorm[1] * distanceModifiedSpread; data.position = new Vector3D(predictedPosition.x + offsetX, predictedHeight, predictedPosition.z + offsetZ); The offset for each projectile is calculated by sampling from a random 2D Normal Distribution. If each player computes their own offset, then the values of the offsets would be different, the data.position vector would be different and hence total damage dealt would be different for each player, based on their own random sample. My question is: wouldn't this instantly cause OOS? How is it being handled? I do observe a greater chance of OOS in large battles, could this be the reason? I have tried to change the parameters and that results in instant OOS.

Instead of upscaling, we can replace these small animals with entities that have larger size that have the same behaviour and total food value. For example, replace chicken with sheeps, rabbits with deers

Some experiments conducted in Atlas editor regarding sniping: With no upgrades at all: 18 archers can kill a class_b ranged unit at their maximum firing range in 1 shot 11 slingers can kill a class_b ranged unit at their maximum firing range in 1 shot Between 19 and 21 archers can kill a class_a ranged unit at their maximum firing range in 1 shot 11 slingers can kill a class_a ranged unit at their maximum firing range in 1 shot An indefinite number of archers is required to kill a class_e ranged unit at their maximum firing range in 1 shot. The number required is huge due to the inaccuracy of the archers - in the most lucky case, 23 would be enough. In less fortunate cases, 35 is required. 13 slingers can kill a class_e ranged unit at their maximum firing range in 1 shot. With only archer accuracy upgrade: 18 archers can kill a class_b ranged unit at their maximum firing range in 1 shot with certainty; 17 is sufficient for most instances. 19 archers can kill a class_a ranged unit at their maximum firing range in 1 shot. Between 23 to 25 archers are required to kill a class_e ranged unit at their maximum firing range in 1 shot.

I switched to X11 display protocol and the errors didn't happen again. Even the previously mentioned mod selection page crash did not occur again. I think there is a conflict between 0ad and latest versions of Wayland. Pyrogenesis 0.0.26 27104-release Build 12 Sept 2024

As soon as I press any key, this key error appears. I did press the shift key to cause this particular crash. Steps to reproduce: 1. Run the Atlas editor 2. Place down some random entities and start playing simulation 3. Press any key combination, for example the attack move. Then this error would appear for me. This seems like something related to X11 and lack of keyboard support?

When I tried to play a scenario in the Atlas editor, it crashed suddenly with this message: /usr/src/debug/wxwidgets/wxWidgets/src/unix/utilsx11.cpp(2645): assert ""Assert failure"" failed in wxGetKeyStateGTK(): Unsupported key 314, the only supported ones are: Ctrl, Alt, Shift, Caps Lock, Num Lock and Scroll Lock for GTK 3.18+ /usr/bin/0ad: line 9: 6857 Trace/breakpoint trap (core dumped) "$pyrogenesis" "$@"

I would like to run the A26 version with a Vulkan backend because it quadruples my framerate, but it is not implemented until the A27 engine. I have tried force the A27 engine to run A26 public as a mod, but the idea didn't work due to A26 javascript calling non-existent engine functions. Is it possible at all to make the engine backwards compatible? I can try to debug A26 but I would like to know whether I am going down a dead end. Thanks.

@ffm2 In the counters panel, do you think it is possible to display the count of each unit type? For example, accurate to the number of spearman and the number of archers? If so, how would I be able to retrieve the stats? For multiplayer, yes that is the case. However, the singleplayer games are not written instantly, from what I have seen. Maybe my file manager didn't refresh quickly enough.

I think this is a great idea! I have thought about it as well and I've made a simple script to analyze the replay commands. I think it would be possible to make an in-game service which advises the player what they should do. This would be very helpful for new players (such as myself) to improve their skills! Regarding your cheating concerns, I found that replay files are not fully written to the replay folder until the game has finished. Therefore you can go ahead with your replay analysis mod without worries

Thank you ffm2, I have got it working! With regards to calculating the gathering rate, could we save the total resources on the previous turn, then do a gradient calculation: gathering_rate = (current_count + spending - previous count) * turns per second This allows us to ignore the details of upgrades, unit types and other factors. We need to account for the resources spent between the turns, e.g. the player gathered 20 wood in 200ms but spent 200 wood for a barrack. In your screenshot, what are the Hou, Bar, Fiel and Civ values? What are the average % values?