Micfild

I agree with the overall sentiment that mobility is the main advantage of cavalry units and, as such, should come at a higher cost than just resources. I can accept them being mobile and having high damage (since a charge mechanic isn't available yet). The cost would be reduced durability. An overall reduction of Hitpoints and low armor values. This would emphasize they role as skirmishers and reduced their value as main combat units. I would also agree with a reduction of their ability to capture buildings, as they should be viewed as raiders, not a domination force (which would be the infantry's role). =================================== Using base melee infantry units as baseline (100HP ; 5 armor) i would suggest that melee cav units have 100HP or less ; 3 armor or less. As for the ranged cavalry, the same HP and armor stats of it's infantry counterparts (since then they would have the double advantage of being mobile and ranged). =================================== It would basically treat mobility as a higher valued attribute, the same way "Range" is treated. -------------------------------- TL;DR : Keep cost, damage and mobility. Reduce durability stats to get in line or below their infantry counterparts.

Thanks Stan.

Hi. Quick question. Is it possible to upscale unit models by altering some property in a .xml file somewhere or only by changing the model itself? I've searched the forum, but haven't been to find an answer to this. And just in case i've asked the wrong question, what i want is to be able to keep the current proportions of a unit, but make it larger, hopefully by just simply altering a multiplier in a .xml file. Thanks in advance!

In my opinion, it's a reasonable bonus. The problem is, as pointed by other people, that some of the team bonuses are comparably much less usefull, making the iberian's seem stronger than it really is.

The civs' files are a bit spread out since it includes auras and other things. But if you take the simulation folder alone (with gaia and all the civs) it has only 4,22 MB of files with 8,24 MB of occupied disk space. Most of the size of the public folder comes from the Art folder (2,53 GB), Audio folder (177 MB) and the Maps folder (341 MB). The rest only weighs 31 MB. Overall, scripts and XML files are really light.

Thanks @Stan`. I think i understand a few points of your reply, but not all of it. If possible, could you clarify a few things: 1 - It seems that the moddable part of 0AD is treated (in some ways) as a mod itself (called empires_ascendant) <-- is this correct? 2 - If 1 is true, then it means that, much like mods, this one could be changed more frequently, and updated on mod.io 3 - Empires_ascendant is a rather large mod (a few gigabytes in fact) and the only way to change parts of it would be to download and replace the entire thing (can't just change a few files) 4 - " We can't maintain the current version and the next one at the same time. " <--> If i'm understanding this corrently, it means that current versions of 0AD in phabricator (A26) have new features (like acceleration) that changes the game and most of it's .xml files. This way, patches for A25 couldn't be easily tested in Phab without messing with A26 stuff. Therefore it would be necessary to have two projects in Phab, one for A26 and one for A25, and that is just not feasible. If that is the case, then can't we test tentative patches as a simple mod and when eveything is set, officialy transmit them to the Empires_Ascendant "mod". It sounds a little vague because i don't have enough knowledge to know what is possible and what isn't, but if we can use a program, like the installer, to officialy replace files in Empires_Ascedant, it would make things simpler. This way, the workflow would be something like this: Tentative patch A25.01 --> as a simple mod (or .pyromod) file, like any other mods. Balance team downloads the mod, tests it and have discussions. - If the changes are insufficient, a new mod (A25.02) is created and the process is repeated) -If the changes are accepted then it can be implemented. After a final version is approved, an official patch (or something) can be downloaded to replace the original files in the Empires_Ascendant mod for the new ones, but only those that were changed (like a copy and replace). ======================================================= I don't know if i got everything right or if this is even realistic, but if possible, it might be close to a good solution to this problem.

That is true, but imbalances are a natural part of the process, so it is unavoidable in some ways. The biggest issue, in my opinion, isn't that the game can become imbalanced, but that once it does, patches and fixes will only roll out 6-8months later. I'm somewhat aware of the hurdles of changing compiled code, but still can't understand why smaller changes (like numerical tweaks in the template .xml files) can't be updated more regularly, especially since theses changes can be easily modded. This way we wouldn't be so afraid of imbalances, since they could be fixed after a few weeks of discussion.

@alre, Further testing revealed that the impact of the Friction aura in avoiding overlaping isn't as significant as i thought. I ran you mod without them and it felt almost the same (units were a bit faster though, as expected). It kind of reached a level of clumping that i'm ok with. It wasn't as eye catching as the base game (I still have to test it with siege though). Thanks

I remember that part of A24. A25 pushing mechanics really smoothed things quite a bit, which was great. Unfortualy it came with a cost, which is not so great. But at least it can be fixed (eventualy). I checked you mod and your pathfinder values are indeed smaller than the base game. But what it seems to make the most difference, for me, is the Friction aura. It seems that slower units have a more difficult time overlaping. If i'm not mistaken, in another post by @nani, there was a discussion about how farm animals seem to overlap much less than other units, even with the push mechanics. Since they have the same "Default" parameters most other units in the game, it might be because of their speed (which is very slow). Yeah, that mod also has a great AI, Catilina. It does 3-4 minute cav rushes and booms to full pop in 13 minutes. I went as far as extracting just the AI (and the pathfinder file + friction aura) just to play against it in the base game.

Cool, I'll try this as well!

Interesting. There is some good discussion on the matter hapenning at your post. Also, good point about the farm animals, i'll test that out as well. Thanks.

Thank you @wraitii. Good to know! Edit1: I tested it out. It doesn't completely removes overlaping, but it does away with 90% of it. It does make unit movement more clunky though, so now i get it why it was added in the first place.

Some context: I've been messing around with the pathfinder.xml file in an attempt to stop units clumping too much when in battle or marching or gathering resources. But it didn't matter which variable i changed, the best result i could get was that units would overlap and then be pushed (rather slowly) away. If i make pushing zones too big, then those units can't hold formations properly. Then it occured to me that i might be going in the wrong way, and a question was formed: Why can units overlap in the first place? They don't overlap with buildings (as far as i know) or with terrain features, so why can they do it to themselves? Is this a feature? An unintended consequense of some obscure code?A bug that has yet to be fixed? Or something else entirely? Thanks and have a nice day!

On personal experience, attack move seems most effective on small skirmishes, while Violent stance and Hold seems to work better for me on large army clashes. As a disclosure, the majority of my game are against the A.I. , so i don't know how much theses strategies would compare vs human players. I've also been trying formations a bit more, having good results with spartan CS hoplite in Phalanx (due to the tight formation). They don't seem to break rank that easily if i use Hold + Violent stance, instead of attack-move.

I have also noted this while playing with camels. Always thought it was a feature, not a bug.