Further evolving multiple animations

[Mr War]

Nothing urgent, just thinking aloud

The current multiple animations for skills is great. Very good, allows a step-change in presentation I feel.

But one thing is that all of a given unit still have to look the same, else the move skill animations may not reflect the attack skills.

So you can't have infantry with slightly different models, they all have to dress exactly the same. You cannot have some with round shields, some with square etc. But being the same unit type.

If there was a way around this it could make armies look more, realistic.

Maybe one way is to have different units but all produced by a single command, randomly picking. Then allow grouping as per single unit.

[softcoder]

How about a naming convention to support different models per unit type. So swordsman.g3d, maybe the code looks for swordsman1 to x. Then when producing a unit, we randomly pick 1 to x (lets assume we have 5 different models groups for unit A).  Any time A is produced we pick a random group of models from 1 to 5. Then _attackX and _movex etc would be used for the duration of that unit.

Would something like this work.

[Coldfusionstorm]

How about a naming convention to support different models per unit type. So swordsman.g3d, maybe the code looks for swordsman1 to x. Then when producing a unit, we randomly pick 1 to x (lets assume we have 5 different models groups for unit A).  Any time A is produced we pick a random group of models from 1 to 5. Then _attackX and _movex etc would be used for the duration of that unit.

Would something like this work.

The duration?.

i really don't understand what you are saying.

[will]

For g3d this could work, although best if specifed in unit xml by multiple tags or something rather than filename number based, as Mr War and others regularly reuse files or have inconsistant naming.

I would imagine a system using md5 would be superior and differently specified.

[Mr War]

yeah even I don't trust me for naming conventions.

What I'm thinking seems easiest, from a modder's perspective, is allowing production commands to produce randomly from a list of possible units, with the cost held at the producer.  something like:

                 

Code: [Select]

<command>
<type value="produce"/>
<name value="produce_archery_units" />
<image path="images/produce_archers.bmp" />
<unit-requirements />
<upgrade-requirements />
<produce-skill value="produce_skill"/>
                        <resource-override="true">
                                     <resource name="gold" amount="100" />
             <resource name="stone" amount="150" />
             <resource name="wood" amount="50" />
                        <resource-override>
        <unit-list="true">
                <produced-unit name="fire_dragon_archer"/>
                                        <produced-unit name="archer"/>
                                        <produced-unit name="crossbowman"/>
                         </unit-list>
</command>

[Coldfusionstorm]

yeah even I don't trust me for naming conventions.

What I'm thinking seems easiest, from a modder's perspective, is allowing production commands to produce randomly from a list of possible units, with the cost held at the producer.  something like:

                 

Code: [Select]

<command>
<type value="produce"/>
<name value="produce_archery_units" />
<image path="images/produce_archers.bmp" />
<unit-requirements />
<upgrade-requirements />
<produce-skill value="produce_skill"/>
                        <resource-override="true">
                                     <resource name="gold" amount="100" />
             <resource name="stone" amount="150" />
             <resource name="wood" amount="50" />
                        <resource-override>
        <unit-list="true">
                <produced-unit name="fire_dragon_archer"/>
                                        <produced-unit name="archer"/>
                                        <produced-unit name="crossbowman"/>
                         </unit-list>
</command>

Not a bad idea but it can be simplyfied.

this is a very standard Produce code only with a exstra "produce unit"

Code: [Select]


<command>
<type value="produce"/>
<name value="produce_marine" />
<image path="../uef_marine/images/uef_marine.bmp" />
<unit-requirements />
<upgrade-requirements />
<produce-skill value="produce_skill"/>
<produced-unit name="uef_marine"/>
            <produced-unit name="uef_marine_2"/>
</command>
this seems to produce the most clean result to me. it is a single line additon that makes the produce skill able to make different units.

Then you just have to have a exstra unit in your random rotation.

it also still respects the unit costs. i don't know how this is actually implemented, it should either reserve a amount of money for the most expensive unit and then return the rest of the money when a unit is selected or be able to make the mineral cost go into minus(-).

The inherent problem with this is that a player can just cancel the random and then keep cancel the random production untill he gets the unit he want's however for units that have serveral different textures/animations/models this can be usefull, this essentially makes it possible to have different units of the same race, fx Humans of different heights, And or Beasts/orcs of different kind.

Just be carefull developers, we don't want the produce command to be expensive its pretty much the backbone of the game.

But i so like the idea of this it gives me so many ideas to make a beautifull game. 

[Omega]

I strongly agree with Will that the file should be defined in the XML, not based on a naming convention. Especially since it may be possible for some models to share the same model across different "styles". For example, we have two different types of models for our tank, one a desert shade and one a forest shade of camouflage, but when the unit dies, the model is a charred up model where the colour doesn't matter, and both "styles" of that same tank could share the model.

[John.d.h]

Perhaps this could be done by having different "branches" of a unit.  For example, when you recruit a Swordman, it would pick from a few different variations.  The different variations might be merely cosmetic, or you could have one with (for example) stronger armor or a slower attack, etc., but they would all still be selected as a group when you double-click on one.  This would also be useful for specific characters (named units) in campaigns, like Sir Fred the Horseman.  Just a thought.

[Coldfusionstorm]

Perhaps this could be done by having different "branches" of a unit.  For example, when you recruit a Swordman, it would pick from a few different variations.  The different variations might be merely cosmetic, or you could have one with (for example) stronger armor or a slower attack, etc., but they would all still be selected as a group when you double-click on one.  This would also be useful for specific characters (named units) in campaigns, like Sir Fred the Horseman.  Just a thought.

Jhon.D Check my Example what you suggest is easy obatainable with my one line addition.

[John.d.h]

Of course, having any kind of "meta-unit" thing like we're talking about, would require changing a lot of things in the code to point to the meta-unit instead of the specific one, like double-click selection.

[Coldfusionstorm]

Of course, having any kind of "meta-unit" thing like we're talking about, would require changing a lot of things in the code to point to the meta-unit instead of the specific one, like double-click selection.

TL:DR
Not difficult different levels of implementation for this kind of "meta unit" tho

Actual content below

That would be easy solvable by adding a "name" XML tag for units and a "unique id"  for units. however how to implement a unique ID into the XML''s Require some more thinking. adding hundreds of unique ID's to my mod dosnt seem all that fun just to.

this way you could have total identical units while having different ability's. usefull for many different purposes.

Also your train of thougts in that post could be hard for some people to understand.

offtopic stuff below. Jhon D im looking at you.
(Funny i actually had to read your sentence before i understood it,the sentence bother me for some reason,perhaps because i was required to lay a tiny amount of effort into it?)

[Omega]

Uh, if you just want to CHOOSE the different unit, that can already be done, and the next version of Apocalyptic Dawn uses that system (eg, the same infantry base model has three weapon variations; M16A4, AT4, and M2 Browning. They're just regular units produced as normal). The only thing keeping MegaGlest from using this same system is the inability to make produce commands use a submenu^[1].

However, making just different looks for units, which to my understanding, is what this feature request is meant for, at random, is entirely different. It would still be the same unit, just different ways for them to look. You may have an army of swordmen with all the exact same stats, but one might be caucasian, one might be black, etc... Subtle differences entirely in look. In fact, we could use that to even have different models, not just textures, such as having some units female and some male, etc.

[Coldfusionstorm]

Uh, if you just want to CHOOSE the different unit, that can already be done, and the next version of Apocalyptic Dawn uses that system (eg, the same infantry base model has three weapon variations; M16A4, AT4, and M2 Browning. They're just regular units produced as normal). The only thing keeping MegaGlest from using this same system is the inability to make produce commands use a submenu^{https://docs.megaglest.org/XML/Commands#Produce}.

However, making just different looks for units, which to my understanding, is what this feature request is meant for, at random, is entirely different. It would still be the same unit, just different ways for them to look. You may have an army of swordmen with all the exact same stats, but one might be caucasian, one might be black, etc... Subtle differences entirely in look. In fact, we could use that to even have different models, not just textures, such as having some units female and some male, etc.

ACtually, there is a problem with multiple skills and commands and this sort of stuff, but read my post again,, anyways too tirred going to bed

[Mr War]

I've been rereading this thread and pondering. From a modding perspective I still prefer the ability to tie multiple unit types to a single produce command, and allow multi-select via double click to work across multiple associated unit types defined on the XML.