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.

There is one additional parameter regarding ranged units - gravity. 0ad projectile trajectories are parabolic curves that intercept the archer and the target, modelled based on your ballistic arrow in vacuum. The gravity parameter decides the curvature of the trajectory and the developers manipulates the visual shape of the trajectory using this parameter. The issue here is that if your gravity parameter is too high compared to your launch speed, then your projectile might not be able to reach your target before it lands. This page may be helpful: https://en.wikipedia.org/wiki/Projectile_motion

@Emacz Speed is the flying speed of projectile in meters per second. Faster speeds prevent the target unit from escaping, so no dodge or dance moves would be possible - very much like laser weapons.Slower speeds are more cinematic but players can dodge projectile by waltzing units around. It's up to you which one you prefer, but I like high speed projectiles, after seeing absorber dancing troll and scout leaks in another RTS game. If your archer has a projectile speed of 70 m/s then it will reach the target in 1 second after firing. The speed of an infantry unit is about 8m/s. In 1 turn, the infantry can travel 1.6 meters. The 95% likely landing zone of your arrows is a circle with radius approximately 1.5 meters, from the calculation above, so if the other player reacted quickly enough (within 3 turns or 0.6 seconds), then they can always dodge the arrow successfully, theoretically. The average human reaction time is 0.25s, just over 1 turn. If you don't want dodging to happen, you should use a very fast projectile speed, e.g. 1100m/s (similar to a modern sniper rifle). I don't understand what is the point of adding spread mechanism. The random sampling is extra load on the CPU and does almost the same as just lowering the arrow damage, except with more uncertainty and luck. Just simply decrease the arrow damage to an appropriate amount would fix these issues completely.

Of course, I will try to explain. By default, the arrows are aimed perfectly at the target's location and all hits will be 100% precise. In order to introduce spreads and near misses, the developers added random errors to the target coordinates, so that the arrows will always land some distance away from the target location. The units in 0AD have a non-zero but finite sized hit box, so anything which lands within the unit's hitbox is still considered a direct hit. On a 2 Dimensional map, mathematically, we have: Target coordinates: (x, z) The landing coordinates of arrows, after adding errors: (x + offsetX, z + offsetZ) The value of the offsets (random errors) are computed by: offset = (distance from target * spread multiplier / 100) * RandomNumber The random number here is generated by taking computer generated values following a Gaussian (Normal) distribution: In our case, the mean is 0 and the standard deviation is 1. So it is the most likely to return some small value near 0, and our arrow will hit the target unit. But there are also small chances that it gives us a very large value and our arrows will miss. For example, there is a 68% chance that our RandomNumber < 1, a 96% chance that our RandomNumber < 2. Increasing the spread multiplier and the distance target will lower the maximum tolerable RandomNumber that we can take to hit, therefore the probability of a direct hit will decrease and chances of missing will increase. In a sense, greater spread multiplier and distance squeeze your acceptable region from the lighter blue to the only the darker blue. Above was a high level theoretical overview; there are a few computational details to be aware of: The distribution that we are sampling from is not exactly the Gaussian distribution shown above, but a Box-Muller transform of the Gaussian Distribution. This is because taking samples from the real Gaussian distribution is too slow and will result in lag, but the Box-Muller transformed distribution is much faster. The Box-Muller distribution samples from 2 random variables following an Uniform Distribution between 0 and 1, then calculates a result from these 2. Details here: https://en.wikipedia.org/wiki/Box–Muller_transform The random variables are not truly random but pseudorandom, meaning that all 'random' numbers we get are actually taken from a predictable chain. This chain is determined by a seed, which is generated and written to the replay files while the match is loading. Having this key, you can predict all future 'random' values and hence predict where exactly each one of your arrows will land. The developers forgot about the height dimension; the arrows will not miss vertically (will not fly above the target unit's head and miss).

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:

Hello, the spread mechanism has been discussed here: The key takeaway here is that we are sampling 2 random variables following a 2D Gaussian distribution in order to get 2 multipliers X and Y. Then we multiply the Distance from target by the multipliers to get the deviation .. Let me know if you need further explanations of the JavaScript code or the mathematical details

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.