Overriding animations via attached objects: Difference between revisions

From The DarkMod Wiki
Jump to navigationJump to search
Crispy (talk | contribs)
No edit summary
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
TDM has a mechanism for causing AIs (and other entities) to automatically use different sets of animations when certain objects are attached to them. This could be used for weapons, torches, bandages, or anything else you can think of. It works as follows.
TDM has a mechanism for causing AIs (and other actors) to automatically use different sets of animations when certain objects are attached to them. This could be used for weapons, torches, bandages, or anything else you can think of. It works as follows.


==Basic usage==
==Basic usage==


When an entity (for example, a longsword) is attached to a parent entity (for example, an AI), the code will look for spawnargs on the first entity (the longsword) with keys that start with "replace_anim_". The remainder of the key is the animation to replace on the parent entity (the citywatch), and the value is the animation to replace it with. For example:
''Note:  As of 1.06, this key/var can be put directly on the AI entity, allowing mappers to change animations without an attachment.''
 
When an entity (for example, a longsword) is attached to an actor (for example, an AI), the code will look for spawnargs on the first entity (the longsword) with names that start with "replace_anim_". The remainder of the name is the animation to replace on the actor/AI, and the value is the animation to replace it with. For example:


  "replace_anim_throw"  "look_around"
  "replace_anim_throw"  "look_around"
Line 14: Line 16:


* AIs carrying hammers should use two-handed overhead swings to attack instead of one-handed slashes. A dagger needs a stabbing motion. A club is different again. And so on.
* AIs carrying hammers should use two-handed overhead swings to attack instead of one-handed slashes. A dagger needs a stabbing motion. A club is different again. And so on.
* In a "peering around" animation, a non-torch-carrying guard might put his left hand up to shield his eyes. If he was holding a torch, though, this would burn him. To prevent this, you could add <tt>"replace_anim_peering_around" "peering_around_torch"</tt> to the torch entityDef. This would replace the <tt>peering_around</tt> anim with <tt>peering_around_torch</tt> for torch-carrying entities. The replacement animation might have the left hand lifted up in the air (to illuminate the surroundings) instead.
* Suppose guards have a "peering around" animation, in which the guard puts his left hand up to shield his eyes. If he was holding a torch, this would burn him. To prevent this, you could add <tt>"replace_anim_peering_around" "peering_around_torch"</tt> to the torch entityDef. This would replace the <tt>peering_around</tt> anim with <tt>peering_around_torch</tt> for torch-carrying guards. <tt>peering_around_torch</tt> might have the guard's left hand lifted up in the air (to illuminate the surroundings) instead, for example.
* A guard with a bandaged leg (an attached bandage entity) could be made to limp instead of walking normally.
* A guard with a bandaged leg (an attached bandage entity) could be made to limp instead of walking normally.


Line 29: Line 31:
"replace_anim_melee_attack_torch"  "hammer_attack_torch"</pre>
"replace_anim_melee_attack_torch"  "hammer_attack_torch"</pre>


(If this seems a little redundant, it is - there are two ways to get from <tt>melee_attack</tt> to <tt>hammer_attack_torch</tt>. However, there's no reliable way to know whether the torch's replacements or the hammer's replacements take precedence. So you need both, or Bad Things Will Happen. This is perhaps not ideal, but it does keep the feature simple. Hopefully there will never be a need for more than 2-3 replacements at once anyway.)
(''Aside:'' If this seems a little redundant to you, then you're right - <tt>hammer_attack_torch</tt> is mentioned twice. However, this is necessary because there's no reliable way to know whether the torch's replacements or the hammer's replacements will be applied first.)


The console will throw up a warning if you cause an infinite loop of replacements pointing at each other.
You can do as many similar combinations as you like (limping, torch-carrying, hammer-wielding guard anyone?) but it starts to get messy pretty quickly.


[[Category:Animation]]
[[Category:Animation]]

Latest revision as of 12:14, 21 July 2011

TDM has a mechanism for causing AIs (and other actors) to automatically use different sets of animations when certain objects are attached to them. This could be used for weapons, torches, bandages, or anything else you can think of. It works as follows.

Basic usage

Note: As of 1.06, this key/var can be put directly on the AI entity, allowing mappers to change animations without an attachment.

When an entity (for example, a longsword) is attached to an actor (for example, an AI), the code will look for spawnargs on the first entity (the longsword) with names that start with "replace_anim_". The remainder of the name is the animation to replace on the actor/AI, and the value is the animation to replace it with. For example:

"replace_anim_throw"  "look_around"

Placing the above line in the ai_weapon_longsword entityDef would cause AIs carrying longswords to use their "look_around" animation whenever they would normally use their "throw" animation.

Note: The animation names are the ones specified in the model def. They are not filenames.

The practical uses for this include being able to have different animations for guards carrying torches, and/or different weapons. Some examples:

  • AIs carrying hammers should use two-handed overhead swings to attack instead of one-handed slashes. A dagger needs a stabbing motion. A club is different again. And so on.
  • Suppose guards have a "peering around" animation, in which the guard puts his left hand up to shield his eyes. If he was holding a torch, this would burn him. To prevent this, you could add "replace_anim_peering_around" "peering_around_torch" to the torch entityDef. This would replace the peering_around anim with peering_around_torch for torch-carrying guards. peering_around_torch might have the guard's left hand lifted up in the air (to illuminate the surroundings) instead, for example.
  • A guard with a bandaged leg (an attached bandage entity) could be made to limp instead of walking normally.

Combining multiple replacements (advanced)

So far so good, but what if we want to combine several uses? What if a torch-carrying hammer-wielding guard should have a different animation from a non-torch-carrying hammer-wielder, which is different again from a torch-carrying sword-wielder? Well, animations can be replaced multiple times.

Let's assume that the default melee_attack anim is for a sword-wielding guard with no torch. In the torch entityDef, you'd put:

"replace_anim_melee_attack"   "melee_attack_torch"
"replace_anim_hammer_attack"  "hammer_attack_torch"

And in the hammer entityDef, you'd put:

"replace_anim_melee_attack"         "hammer_attack"
"replace_anim_melee_attack_torch"   "hammer_attack_torch"

(Aside: If this seems a little redundant to you, then you're right - hammer_attack_torch is mentioned twice. However, this is necessary because there's no reliable way to know whether the torch's replacements or the hammer's replacements will be applied first.)

You can do as many similar combinations as you like (limping, torch-carrying, hammer-wielding guard anyone?) but it starts to get messy pretty quickly.