fatherbushido

For the first point, I would say #4460 is the top of the iceberg. AlexanderMB's job is adressing more than it. If it was only the 3 duplicated vertices groups, we could have done it (for the meshes and the anims). For the second point: yes, all will be fine!

about updating all ("all" = "new" units): In the .dae *animation* files, you will find the same block as in the .dae *mesh* file. And #4460 is one third of the issue. The other main issue is that the old meshes (with 39 (42 with the 3 dupes) vertices groups were used despite we have in the repo the ones with 42 (45 with the 3 dupes) vertices groups): two different sources files were used. It made impossible to script fixes the duplicated vertices issues (ie the *Name_array* list of vertices, the *float_array* matrix, the *v* vertex weights).

Because it won't be more logical. Those things were stacked, where people use things with their own interpretation. We could flatten the whole thing and then decided what is a logical organization. It would be "change many things for little benefit". (And then someone else will think something else is more logical). -- Let's look at the CitizenSoldier class. I permit myself to quote your recent proposal: The argument "all auras and technologies use the CitizenSoldier class when referring to non-Champion non-Hero Soldiers" is not an argument. It proofs that about ten entries using that were wrong (probably committed by me too). Or you move CitizenSoldier to VisibleClasses (then it should be translated) or you use things like "Citizen Soldier" in those techs/auras. -- Then back to my "no", there are as you exactly mentioned the AI to check but also the gui (yes classes are used here) and possibly the lobby! -- (I don't want to be right or criticize or proof anything (sorry by advance if electronic communication let that feeling).)

No!

Your thoughts are interesting and you in fact pointed out some issues. Worker is used in more than 20 technology and auras so it should be visible. Citizen is in fact not so used in things that should be communicated to the player. (we could use it more). Some specific classes like FemaleCitizen, CitizenSoldier are used in the gui but are not visible. They should (or they shouldn't be used). Note that you can also do operation on classes sometimes (like interesection or union). Support seems not so used in things that should be communicated to the play. So for example: The starting cavalry unit is: Citizen, not Worker, not Support. It is not affected by the basket economic technology. It is affected by the female aura. The starting infantry unit is: Citizen, Worker, not Support. It is affected by the basket economic technology. It is affected by the female aura.

If I am not wrong, some data types used in the code fit the number of players. So it would require some careful work. (It's not like if there was just a number to change everywhere.)

If a class is (for example) used by a technology like "All units of the class *Worker* gain 10hp" then it's better to have it visible in the gui.

Classes are used for many purposes. For example, technologies or auras apply to specific classes. There are also non visible classes (which are not displayed in the tooltips) which are used internally (for the AI for example). EDIT: Note that some words are "abstractions" or have an extended meaning. For example a class "Vehicle" could perhaps be attributed to a "cavalry unit" but not to a "car wreckage".

@Alexandermb: Here it is. If you need something, just ask. Red files are the missing ones, green files are the ones who reference the missing ones. art/variants/biped/formations/syntagma_mid.xml <- art/actors/units/macedonians/infantry_pikeman_a.xml art/actors/units/macedonians/infantry_pikeman_b.xml art/animation/biped/rider/camelry/promotion.dae <- art/variants/biped/rider/camelry/promotion.xml art/animation/biped/rider/camerly/archer_attack_right.dae <- art/variants/biped/rider/camelry/attack_ranged_archer_right.xml art/animation/biped/infantry/siege_operators/gastraphetes_attack.dae <- art/variants/biped/attack_ranged_gastraphetes_fire.xml art/animation/biped/rider/camelry/archer_attack_hip.dae <- art/variants/biped/rider/camelry/attack_ranged_archer_hip.xml art/animation/biped/infantry/spearman/attack_melee_hop_a.dae <- art/variants/biped/attack_melee_hoplite.xml art/animation/biped/rider/camelry/attack_slaughter.dae <- art/variants/biped/rider/camelry/attack_slaughter.xml

@AlexandermbWhen trying to merge the github repo and parsing it into fork AD tools, I noticed a few errors. Do you want I report them directly on the github repo or something else? I don't know if you planed to merge all, so perhaps they are not relevant.

Apart from that from a game design point of view, I don't find that kind of bonuses stupid if one wants hard counters. There are mainly two ways to do things: - emergent behaviors with lot of factors (an abstract game physic) - full gameplay control with hard counters My personal preference is the first one but both are ok. Just coherence is needed. If one choose the second part, which is sometimes the cleaner/easiest for balancing, especially for an rts, you just have to have a set of rules. No stats are really actually needed (or a little set). That's what are hard counters. In that context, the civ counters perfectly fit. To be more clear: you need only one stat: health and then you have a set of bonus of units against units (by type or by civ). Doing that way, you have a full control of the balance and the gameplay.

Most of the civ info page content is what was planed at some point (developed or not). The only part which was updated was the team bonuses part iirc.

That one is straightforward (one template entry and one check in Health). Do you need it?

it was in game around 2012.

The good news is that all that will be fixed soon and the 0ad art (which imo *is* 0ad) will not be messed.

I first thought Alexander was looking (he actually was at some time) for biped/new/inf_sarissa_rest (which was done by enrique, no?). That one being used by most of the elephant rider. But he spoke about different elephant rider animations.

Ah yes it seems I made a confusion with the sarissa weapon. Are you sure it's only cav anims in that file?

A bit more history here: Another draft I had about that:

About the elephant is that this one? The file biped/new/inf_sarissa_rest was in the first experimental new anims commit. Then was not included in the final one. That's mostly that big confusion between the two sets of files where errors were stacked which prevent an automatic way (I mean modifying the anims and mesh .dae) to fix it. So the file should be here: https://trac.wildfiregames.com/changeset/19137/?format=zip&new=19137 (That's perhaps not what you are looking for!)

I don't know, not all wine get better with age :-/

"Wise men", I am not one of them. And please don't make me look what I am not. Please.

Wise men know.

I would say that the answer are in our announcement! :-) Stay tuned! ;-)

We are well aware of your long standing wishlist. Perhaps will you find other reasons! Come join the dark side, we have chocolate cookies!

By the way, that mod idea is really cool!