Coding

[Fluffy203]

heck yes thumbs up 

[ElimiNator]

Can I ask, whats a rep system?

[Fluffy203]

yes you can lol , like reputation , if you are a douche you get -1 , but if you are awesome +1 . Usually does with rank and things on forums 

[ElimiNator]

  ok 

[Fluffy203]

I think they should incorporate that , but i guess enough OT lol

[wciow]

Nice work Fluffy 

I'm looking forward to building some gibbed animations for impact hits 

[-Archmage-]

I can't wait to see this in......MegaGlest maybe?

It's going to be fun to make an animation of the swordsman getting thrown into the air by the behemoth's club.

[silnarm]

Ok, I meant to come back to this last night, but got carried away doing other things...

so, break it down.
1. Need multiple die skills. Need to be able to specify an 'attacker' in a die skill, using the unit name alone is not good enough, as there may be a unit with the same name in two different factions. so we need a pair of strings, faction name and unit name.
2. When a unit dies and its die skill is set, we need to know who killed it, and then we can check if there is a special die skill type to use, else use the default.

1: can be done something like:

Code: [Select]

XmlNode *attackerNode = sn->getOptionalChild("attacker");
if (attackerNode) {
string factionName = attackerNode->getAttribute("faction")->getRestrictedValue();
string unitName = attackerNode->getAttribute("unit")->getRestrictedValue();

// validate (note, faction may not have been loaded for this game, in which case skip this skill)
// store pair<string, string>(factionName, unitName) somewhere
}

XmlNode::getOptionalChild() may be a gae thing, if it's not in megaglest it will be soon.

2: This will be a bit tricky, in gae Unit::kill() is called in UnitUpdater::damage(), so this would have been easy, but in regular-glest/megaglest Unit::kill() isn't called until the dead Unit is updated again, moving the call as was done in gae might be the easy way out, but I'll have to investigate any potential problems this may cause and get back to you on that one.

Have to run... will get back to you on point 2 later

[Fluffy203]

I knew it was in the XMLnode i kept seeing sn for parameters. But i was getting stumped when looking it over i couldn't find where to place it or how to start so again thanks silnarm 

[modman]

Ok, I meant to come back to this last night, but got carried away doing other things...

so, break it down.
1. Need multiple die skills. Need to be able to specify an 'attacker' in a die skill, using the unit name alone is not good enough, as there may be a unit with the same name in two different factions. so we need a pair of strings, faction name and unit name.
2. When a unit dies and its die skill is set, we need to know who killed it, and then we can check if there is a special die skill type to use, else use the default.

I really don't understand why simplifying it to simply react to the specific attack type would not be better...I mean your method is a little complex (and also really time consuming to do right) than mine is.

One advantage you have is that it would be more specific to a certain unit, so you can really perfect the animation.  But then again, I foresee a mess...

[Fluffy203]

I have already said i'm making a hybrid , but don't bash on the specific unit idea it is better in my opinion , but less simplistic and not very compatible , but still i'm making it hybrid so don't get so offense about it 

[Zoythrus]

thank you for going with my idea as well (finally, im being heard, that never happens!)

[-Archmage-]

thank you for going with my idea as well (finally, im being heard, that never happens!)

Eh......what?


Is this going into MegaGlest, or GAE, or what?

[Fluffy203]

idk yet , most likely GAE , depends we'll see , its free to use so it might go with mega

[madmanntis]

I like what I see.

While at first I thought it'd be a lot better to have it to react to attack type, I realized that it'd be an issue at times. If a pierce death had a unit keeling over with an arrow in his chest, he'd look pretty silly being killed by a tech Horseman. If an impact death had a unit being crushed or tossed aside, it'd look weird if it was killed by some guy who was slinging stones or throwing rocks.

So yeah. I like your approach fluffy.

[Zoythrus]

hey, i just gave that idea to make the concept more compatible with other mods.

[Fluffy203]

Thank you madmanntis i love your examples of why my way was better , but i have come up with a system that takes both components and uses them.   

[madmanntis]

 

hey, i just gave that idea to make the concept more compatible with other mods.

Thank you madmanntis i love your examples of why my way was better , but i have come up with a system that takes both components and uses them.   

I realize that Fluffy found a sort of middle path. One that favours the unit-type check, but can still allow attack type check. This allows for unique unit-specific deaths as well as mod compatibility. Didn't mean to dump on your opinion Zoythrus. I just realized that issue with the attack-type-only method and wanted to point it out.

[Bruce]

I appreciate that both methods have their pros and cons, and think it is a fantastic idea, but I'm trying to work out if there may be another way to go about it (I'm not saying this is how it SHOULD be done, just offering another suggestion). I'm not 100% familiar with the source yet (I've put it down for a school holiday break - maybe I can incorporate work on GAE/MegaGlest into the advanced IT class where I teach programming), so my suggestion may not even be possible.

Consider the following situation:
Faction Units: Elephant (mounted archer), Horseman (mounted sword), HorseArcher (mounted archer), Pikeman, Swordsman, Archer.

Here is how the attacks might pan out:
Elephant <Crushes> Everyone Else (when Speed > 0 and <Collision> => speed -=1)
Elephant <Pierces> Everyone Else (at Distance X)
Horseman & HorseArcher <Chrushes> Pikeman, Swordsman, Archer (when Speed > 2 and <Collision> => speed -=1)
Horseman <Slashes> Pikeman, Swordsman, Archer (when Speed <= 2 and <Collision>)
HorseArcher <Pierces> Pikeman, Swordsman, Archer (when Speed <= 2 or at Distance X)
Pikeman <Pierces> Everyone Else (highly effective against <mounted> units)
Swordsman <Slashes> Everyone Else
Archer <Pierces> Everyone Else (at Distance X)
Archer <Pierces> Everyone Else (Very ineffective at Distance = 0)

Ok, so that gives us an idea about how the various battles between the types of units play out. Consider the complexities of various types of death animations that could exist here for just a minute...

Now we can't use a simple unit-type check - the Horseman, HorseArcher and Elephant all have different types of attacks depending on how they kill you. We also can't use an attack type - both the Pikeman and the Archer pierce, but one uses a pike and one uses an arrow. You also can't use the hybrid that's been tossed around - at least not without performing additional checks, and that starts to become complicated and very unit specific.

So, there must be a better way. Assuming, that is, that units can have more than one type of attack (which seems logical).

I know you want mods to be pretty flexible, but with flexibility comes overhead - whether it be code processing overhead or logic complexities, it can't be avoided.

The only way it can be done (IMHO) would be to alter the XML tree so that the various conditions can be defined in there somehow. That should also simplify the code, since all that you'd need to do then would be to parse the XML and, depending on the number and order of keys read, execute the appropriate code snippet. That might be beyond the scope of a minor revision, though...

[John.d.h]

Hmm... good point.  The Battle Machine, for example, has an axe attack and an arrow attack, so we wouldn't want a unit getting split in half when it gets killed by a giant arrow.

[Zoythrus]

hmm...i see...i want to say that we could just all combine our ideas (but do you know how confusing the XMLs would be?), but that doesnt seem possible without some form of a catch  . There is no easy way of doing this....

so, how do we do it?

[zombiepirate]

I'm not sure why a condition tree in the XML would be all that complicated...

Code: [Select]

<death animation>

   <attack type = slash>
      <unit type = swordsman>
         <animation path...
      </unit>
      <unit type = horseman>
         <animation path...
      </unit>
      <unit type = default>
         <animation path...
      </unit>
   </attack>

   <attack type = crush>
      <unit type = elephant>
         <animation path...
      </unit>
      <unit type = horseman>
         <animation path...
      </unit>
      <unit type = default>
         <animation path...
      </unit>
   </attack>

   <attack type = default>
      <unit type = default>
         <animation path...
      </unit>
   </attack>

</death animation>

[Fluffy203]

you have a good point , i'll look more into it later , but for now i'm making it hybrid i my implement your idea later on , when i get the coding more friendly to me 

[Zoythrus]

I'm not sure why a condition tree in the XML would be all that complicated...

Code: [Select]

<death animation>

   <attack type = slash>
      <unit type = swordsman>
         <animation path...
      </unit>
      <unit type = horseman>
         <animation path...
      </unit>
      <unit type = default>
         <animation path...
      </unit>
   </attack>

   <attack type = crush>
      <unit type = elephant>
         <animation path...
      </unit>
      <unit type = horseman>
         <animation path...
      </unit>
      <unit type = default>
         <animation path...
      </unit>
   </attack>

   <attack type = default>
      <unit type = default>
         <animation path...
      </unit>
   </attack>

</death animation>

not a bad idea!

[Bruce]

I'm not sure why a condition tree in the XML would be all that complicated...

Code: [Select]

<death animation>

   <attack type = slash>
      <unit type = swordsman>
         <animation path...
      </unit>
      <unit type = horseman>
         <animation path...
      </unit>
      <unit type = default>
         <animation path...
      </unit>
   </attack>

   <attack type = crush>
      <unit type = elephant>
         <animation path...
      </unit>
      <unit type = horseman>
         <animation path...
      </unit>
      <unit type = default>
         <animation path...
      </unit>
   </attack>

   <attack type = default>
      <unit type = default>
         <animation path...
      </unit>
   </attack>

</death animation>

If the existing XML structure works like that, then it should be a trivial change, yes. Looks like the problem is being made much more complicated than it needs to be - glad someone who is very familiar with the way things work was able to clear that up easily.

Still, as I said, compared to a "standard" approach, that does create a rather complex XML tree because you still need to include all unit types. It would be ideal if you could somehow adapt the way it works so that adding a new unit doesn't require the addition of so many lines of XML - but doing THAT, as I said, may require a new approach to the logic used in the code as well.

I think of all of the options I've heard so far, this one is the best and most adaptable.