AInur

I know you want diversity and historical accuracy. Giving each faction the very basics won't conflict with history nor decrease diversity! Argue that some Athenian and Spartan cavalrymen were very well trained, hence they are of champion level. Romans most certainly had archers, Spartans most certainly also had archers and slingers. Set Han crossbowmen to have identical stats to skirmishers and fix their farming upgrade bug. History might limit the unit type, but it says nothing about the stats. Mauryas can have a champion cavalry swordsman Persians most certainly had melee units other than spears. Give them a sword unit or an axe unit! Britons most certainly had elite level melee cavalry Every faction in this game is handicapped because some core units were removed in the name of "diversity". Now is the time to add them back! Please take a look at some factions in mods. Horses didn't exist in America, so the Zapotecs have fast "scout runner" units that look like human but has identical stats to a sword cavalry. Both balance, historical accuracy and diversity is achieved. This approach can be used in the main game.

Easy solution: Just let every civ have some kind of champion spear cavalry. Why is it so difficult? Most of your 0 A.D. balancing problems can be solved by allowing each faction a complete, minimal roster of units, then you can add fancy units on top of that for diversity. Crippling factions by removing essential units will only cause more and more problems. Today we have an issue with champion spear cavalry, the next day we will have problems with swords, then archers... there is no end to this.

@Lion.Kanzen After resting for more than 20 years in the depth of the web server, this thread is unearthed by a curious explorer in late 2024 and exposed to the public again. Little did ElfTheHunter know, that someone born a few days after his last post would be laughing at his beloved gaming rig 'Cyberpower' 21 years later. Even if everyone in this thread assembled their machine into a supercluster, they still cannot beat half of my laptop CPU. Such a supercluster would still struggle to run A26 without lag.

Hi, I don't know about previous versions and I am not saying that Spear Cavalry Champions are particularly OP. I am suggesting a general improvement to how champions are trained and used in the game. The status quo is that they are not being treated as cherished elite units but just hardened soldiers to be spammed everywhere. Not sure if this is a good motif. Another issue is they ban the use of any other cavalry in the game, which removes any civ that doesn't have spear champions from late game.

Hi @bigsmit19, these videos from an expert player might help you out: If you follow these pro advice, you will find even the hardest AI too fragile!

We can exclude heroes from the list of tributable units. The tributable units I had in mind were catapults and ranged units. We can also exclude Civilisation-special buildings from the list.

The next step is for allies or spectators to take over units from another player who is considered inactive. We can start with allies being able to take over players who have left the game, so that the game can still continue despite on disconnected player. This is necessary because many games are ruined by one leaving: Due to bad network / OOS / technical faults Due to real life emergencies Ragequit Due to conflict with others If someone needs to get a pizza delivery, their ally can take over their units instead of pausing the game for 5 mins If this feature is here, then nobody can hold a game hostage in incidents described in this thread: Most problems would be solved immediately.

It would be great if we can tribute units and buildings to allies, like sending resources. For example, a Roman player can give a few catapults to a Maurya teammate who needs it to siege enemy forts, then the Maurya player can send a few archers to the Roman. This is often a great-to-have in team games. I would like to work on a mod which can do this, but before I get started, I would like to hear what the community thinks about it so I don't waste my time on something useless. Why this is great to have: Less need for extremely precise balancing across the civs - missing units can be obtained via allies More friendly corporation between allies and less internal fighting New team strategies, for example, one player manages all of the economy and the other manages rushes. Unlocks the potential of a spectator taking the place of a player who left This feature already exists in other RTS games such as https://www.beyondallreason.info/ and would be a great addition to 0 A.D.

You can use my mod as a temporary solution while the developers are fixing it

Good idea. We remove ratings from the username completely when players join a host, so all of this becomes irrelevant. Then, we can migrate the player profile lookup page to the gamesetup_mp page so that if someone needs to look up the ratings, they can do so here easily.

Exactly. But preferably, you set your rating before even joining the lobby to guarantee stability. This solves 99.9% of the bug. The remaining 0.1% is caused by the very unlikely case that your engine fails to read your config file properly, maybe due to a hard drive error. To solve this, please go straight into your gamesetup_mp.js and edit the line like I did.

I think it would. The cause of players rejoining as spectators is due to querying the rating method from the attribs object in gamesetup_mp.js: g_UserRating = attribs.rating; Engine.StartNetworkJoinLobby(playername + (g_UserRating ? " (" + g_UserRating + ")" : ""), hostJID, password); If the first line fails to extract the correct user rating (for example, due to slow network connection or server loading), then g_UserRating would be NoneType at the second line. The brackets with ratings would be replaced with an empty string. This changes the username perceived by the host, therefore the host will consider the rejoining player as a different person, hence they will be set as spectator. The host will accept both pure playernames and usernames formatted with " ()" at the end of the playername, that are currently active in the lobby. The exact content inside and after the brackets are not considered by the host. This is why such errors can occur. Using my mod, you can fix the g_UserRating variable to a custom string of your choice. You will not have to attempt to extract your rating from the attributes object and you will always join with the same username and formatting. Failure to execute attribs.rating method will not impact the host's perceived username, so you will always rejoin exactly as who you are. In the demo case, we essentially have: Engine.StartNetworkJoinLobby(playername + " (9999) OP", hostJID, password); There is no point of failure here, so the rejoin bug has been fixed Note that extracting settings from user.cfg is much more reliable than requesting for the user's rating from the WFG server, especially for high ping cases.

I would like to argue that this mod does not impact the lobby statistics nor does it adjust anybody's rating. It is a GUI level mod which changes the visual display of the user's rating and suffix only after they have joined a host. The custom rating only appear in the hosted game's gamesetup page; no change is visible in the lobby at all. The mod cannot alter the statistics stored in WFG servers and does not change any element of the lobby interface. All participants of the lobby and the hosted game can still see the player's true rating in the lobby page. Experiment shows that the lobby calculates the average rating of the room using the players' true rating values instead of the custom rating. So no rating or statistic has been adjusted, only the visual element has been changed. Leaving the custom rating box blank will result in your real rating being displayed. The other examples stated in the Terms of Use are not relevant to this mod.

Hi, I've made a mod that enables you to give yourself a custom rating number and a custom suffix after your name, like this: Your custom rating and suffix can be configured in your options page once the mod is activated: this configuration below will give exactly the effect shown above. The mod is attached as a zip file in the standard 0 A.D mod format. Works out of the box. Have fun! customsuffix.zip

Technical bugs with champion units: - They do not show up on idle units list - Their pathfinder often traps them in forests or between units

Hi, I would like to discuss some potential changes to champion cavalry units and their role in the game. Currently, many players dominate by spamming large amounts of spear champion cavalry in late game. It is becoming the common theme and is getting a bit monotonic. This is fine, however, it causes a few issues: Factions without champion spear cavalry suffer in late game: Athenians, Spartans, Mauryas and Britons have little defense against large numbers of spear cavalry champions. More spam and less strategy: early attacks and other creative plays always loose to one player who decides to spam large quantities of champions Monoculture army Champions should be elite, rare and cherished, not spammed en masse. I am not saying they are too OP at all; each single champion unit is not significantly stronger than an infantry unit. The issue is the numbers. My suggestion is to make champions only producible from certain buildings, for example the Imperial Academy of the Han civ, or only allow them to be porduced from fortresses. With this constraint imposed, we can turbo up their stats to even higher values so that they can be used strategically as true distinct champions and not just spammed upgraded soldiers. The late game is still a game of strategic fights and not spam. It also doesn't make sense that the same stable is training units of different classes. Elites need better environments and need longer time, so they should get their own buildings. Same applies for infantry champions. Let me know what you think

Hi, I totally agree with you. You can discuss Sparta related issues with Leif in the lobby. Meanwhile, he has made a patch:

You can force your units to attack only enemy ranged units by editing unit_actions.js, change the target classes then setting the appropriate hotkey. However, the effect of this is not so persistent and does not save you much effort. FFM you should also be aware that during large fights, each turn may take a few seconds to process and during this lag, some players panic and spam click. As a result, you may see abnormal amounts of commands being sent.

Norse Harold and ffm2 raise valid concerns. I now have a safer and more convenient plan than the hashes: The host exposes the list of mods (must be registered, signed mods) that they are using to the clients. The client sees the list and automatically downloads the specified mods from the trusted mod.io repository. The newly downloaded mods will overwrite the contents of their mod folder and automatically activate themselves. Then they can join the game and will not need to re-download and reboot. Many new players are not able to download and activate the mods correctly themselves. Players who take vacations may come back with an outdated version of the same mod and OOS desync the whole game. Meanwhile, it is inconvenient for players to keep switching between community mods and public, then re-activate Mainland-Twilight or Feldmap; many players loose their slots or crash in this process. This is why I insist on refreshing the mod files automatically during the gamesetup page. I hope you can understand my perspective. If the host is using unsigned mods, then the clients will not be able to find the list in mod.io and the host will not be joinable. If the host edits mods without committing to mod.io as new versions, there might be an OOS issue. To combat this, we can use Norse Harold's suggestion of hashes to guarantee that everyone is running on identical source code. I hope you find my suggestions helpful.

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.