Overriding animations via attached objects - Revision history

Springheel at 12:14, 21 July 2011

2011-07-21T12:14:25Z

← Older revision		Revision as of 12:14, 21 July 2011
Line 3:		Line 3:
	==Basic usage==		==Basic usage==

	''Note: As of 1.06, this key/var can be put directly on the AI entity~~. No~~ attachment ~~is needed~~.''		''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:		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:

Springheel at 12:13, 21 July 2011

2011-07-21T12:13:25Z

← Older revision		Revision as of 12:13, 21 July 2011
Line 2:		Line 2:

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

			''Note: As of 1.06, this key/var can be put directly on the AI entity. No attachment is needed.''

	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:		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:

Crispy: simplified some of the language and removed some unnecessary info to clarify the article

2009-04-05T01:01:55Z

simplified some of the language and removed some unnecessary info to clarify the article

← Older revision		Revision as of 01:01, 5 April 2009
Line 3:		Line 3:
	==Basic usage==		==Basic usage==

	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 ~~keys~~ that start with "replace_anim_". The remainder of the ~~key~~ is the animation to replace on the actor/AI, and the value is the animation to replace it with. For example:		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 14:

	* 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 29:
	"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]]

Crispy: small correction (only works when attaching to actors)

2008-08-31T02:55:44Z

small correction (only works when attaching to actors)

← Older revision		Revision as of 02:55, 31 August 2008
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:		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 keys that start with "replace_anim_". The remainder of the key 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"

Crispy: /* Basic usage */

2007-02-13T04:39:41Z

Basic usage

← Older revision		Revision as of 04:39, 13 February 2007
Line 3:		Line 3:
	==Basic usage==		==Basic usage==

	When an entity (for example, a longsword) is attached to a parent entity (for example, an AI), the ~~SDK looks~~ for spawnargs on the first entity (the longsword) ~~starting~~ 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:		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:

	"replace_anim_throw" "look_around"		"replace_anim_throw" "look_around"

Crispy at 04:38, 13 February 2007

2007-02-13T04:38:40Z

New page

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.

==Basic usage==

When an entity (for example, a longsword) is attached to a parent entity (for example, an AI), the SDK looks for spawnargs on the first entity (the longsword) starting 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:

"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.
* 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.
* 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:
<pre>"replace_anim_melee_attack" "melee_attack_torch"
"replace_anim_hammer_attack" "hammer_attack_torch"</pre>

And in the hammer entityDef, you'd put:
<pre>"replace_anim_melee_attack" "hammer_attack"
"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.)

The console will throw up a warning if you cause an infinite loop of replacements pointing at each other.

[[Category:Animation]]