fatherbushido

Is that work linked with that https://github.com/0ADMods/campaign_first_punic_war?

Thanks for reporting (and testing/playing) ;-) My fault when merging two patch touching at the same part of the code. Edit: Fix in https://trac.wildfiregames.com/changeset/19978

@Nescio: <Tooltip>Counters: 2.0× vs. Fortresses, Towers. \n Garrison units for transport and to increase firepower.</Tooltip> (dunno about the spaces)

All that work had already be done many times (and is also done in some mods). IIrc, one of the final version in 2004 was something like that. Uhm. ---------- But around 2014 (I won't quote), people came to the conclusion that the game needs rebalanced and combat refocused on things that make combat interesting. RPS type of combat ignore combat mechanics and just consists in learning a whole graph. ---------- If people really want to go with hard counter, they can imo nuke most of the stats, even civ bonus or things like that. ------- (by the way, I am more annoyed by the fact that graphical equipment doesn't reflect stats...) ------ What I am for is the other option, work on features and mechanics to allow a better gameplay experience. So: instead of <Bonuses> <BonusCavMelee> <Classes>Cavalry</Classes> <Multiplier>3.0</Multiplier> </BonusCavMelee> </Bonuses>

I just felt into the trap with the han civ

Yes, it's a known problem reported in the ticket above.

https://trac.wildfiregames.com/ticket/4688

(or need to recompile?)

Hint: Encouraging people to make war and to kill opponents (all - if you want the conquest victory) is not something which should be encouraged at the start of 21st century, isn't it?

(while at helmets: https://trac.wildfiregames.com/ticket/2524#comment:49)

@LordGood: it will be time to decrease it when decreasing unit moving speed and reducing vision (and and and and and...) ;-)

(I forget: we have currently some amount of code about formation and it seems a waste if we don't reuse it. So we have to be tricky to complete formations feature with reusing that part of code.) When talking to pathfinding for formations you point out what is imo the more decisive thing, as what we call formation has different meaning. One of my favorite design was perhaps the first one nicely summed up by @Wijitmaker

@av93 Matter of consensus, of doing thing in the better way, of choices, of global picture... and also of time and work. (the unit motion proposal is mainly a nuke of formation ) For example, what do you mean by formation?

(Those things disappeared with the simulation rewrite.)

Not so much. If you really want to play with charge, you can also revert, it was implemented many years ago

Yes, that's different in a22 and in a21. Would you expect the converse?

(By the way, - in technologies json files, we have description (currently it's mainly a global description of the tech) and tooltip (which describe effect). - in auras json files, we only have auraDescription which at first only contained effect (as information about the related/source entity could be in the xml), but also in some cases (for example for catafalques) some history description. While at it, one can perhaps fix/precise the design of those things - mainly from the gui point of view.)

If ever you need the patch for deleting them (r19943). history_delete.diff And a rough backup (ack output) history_dump.txt

It seems you used formation, isn't it?

(Until Itms fix, 0 A.D. entity XML documentation.html)

That can be done with removing them from the EjectOnDestroy list, isn't it?

@Grugnas: don't mislead (structure / mechanical) capture and animal conversion (TBD).

There is indeed something which need to be clarified. In https://trac.wildfiregames.com/wiki/Technology_Templates we have the non bracket syntax for specific affects. We have it in the code doc. (so we need to write some tests for that part of the code). EDIT: I checked, indeed the bracket syntax is not handle in specific affects. In that case, you can just use strings (where 'spaces' are 'and'). If you want an 'or' in a specific affects, you can't neither use "+" in the string. I guess the only solution is to split it like that: {"value": "Cost/BuildTime", "multiply": 0.1, "affects": ["Storehouse", "Farmstead"]} should become {"value": "Cost/BuildTime", "multiply": 0.1, "affects": "Storehouse"}, {"value": "Cost/BuildTime", "multiply": 0.1, "affects": "Farmstead"} EDIT: Though I am not sure we could have the same key :/

See the attachement 0 A.D. entity XML documentation.html

It is. (Notice that it takes into account the intrisic elevation bonus of those structures, not only the terrain one).