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.

Hello. My Username: Micfild7 Offender's name: FUBAR He quit without resigning (Host connection ended or something like that) I would like to add that he was fairly nice during the game and did say gg when he lost so it might have been a simple mistake. I'm just reporting to register the ocurrence, in case it happens again. commands.txt

I mean, they don't help a lot during battles, but i find them pretty useful before one, to get my melee troops in the front and archers in the back before i attack-move. Otherwise my ranged troops tend to be in the front, since they are faster.

Ty Wow. Well, in this case i do agree with your previous statement. A decision should be made to either go Hard battalions or no battalions. The current builds seem to favor no battalion, since it would be the easiest to implement, considering the framework already in place. The current formation system seems more useful as a positioning tool rather than a marching or fighting tool. Also eveytime i set a group in formation and send them to collect resources, some of those units just remain idle. This doesn't happen when i take them out of formation (so i tend to set Formation Control to Walk/Patrol only, since this is where it seems more useful). One of the problems with hard battalions is how they would interact with the fact that militiary units can also build and collect resources. One idea might be to make battalions a champion exclusive feature (like they have propper military training and such). This way we can have both systems and they won't mess with each other. In any case, ty for the explanation Wow.

I would like to understant this distinction. What is the general idea behind a "soft" battalion and a "hard" battalion? Is the current formation system considered a form of soft battalion or no battalion?

Found it recently and decided to share.

Yeah, it was a positive remark. I knew about it, but it comes so late that i kind of forgot about it. Thank you, i'll test it out.

It might help early one, but i think it might break the late game, because of the batch mechanic. In Age games you'll only get one unit, but in 0AD you could be pop capped, start Batching 20 something units (which take a long time) and when your army gets killed, its instantly back.

Funny. It's a new mechanic in AoE, but that is how it works in AoM.

Hi @Grapjas. I tested you mod for a few games now and i must say it's a very interesting mod. It took a game or two to get the nuances of ranged combat (with the new ammo system), but nothing too difficult. So far, what i was able to noticed was: Javelins have aren't viable for long term skirmishes (although they have high damage, their 3 ammo limitation turns them into a worse spearman very quickly, unless they are under a fortress) The two weapon system is very helpful against siege engines (since ranged units will use their melee weapons instead of ranged ones) The persian champion chariot is bugged (has no cost besides population, produces very fast, but doesn't attack or do damage) Great clashes seem to be laggier than the base game (which isn't unexpected considering that it has to deal with charge and ammo now) Loved the changes to the priest and the addition of the healing camp. I find it weird, though, that it can't be built on owned territory). It seems that you removed certain techs from the game (the archery tech in the arsenal that reduces spread, hoplite tradition and woots/toledo steel) =========== That's it for now. If i find anything else, i'll let you know. Overall, nice mod!

Makes sense. My bad. I thought that just replacing the .h file would do the trick like javascript.