Playing AI Animations - Revision history

Springheel at 12:15, 21 July 2011

2011-07-21T12:15:27Z

← Older revision		Revision as of 12:15, 21 July 2011
Line 1:		Line 1:
	== Animation Channels ==		== Animation Channels ==

			This article is for developers only.

	Each Actor has a set of animation channels (all AIs are deriving from Actors, by the way):		Each Actor has a set of animation channels (all AIs are deriving from Actors, by the way):

Greebo: /* Where to define the Animations */

2008-07-13T09:11:03Z

Where to define the Animations

← Older revision		Revision as of 09:11, 13 July 2008
Line 25:		Line 25:
	testModel tdm_ai_citywatch		testModel tdm_ai_citywatch
	testAnim draw		testAnim draw
	This will place a citywatch torso in front of you and loops the draw animation. You can enter noclip to conveniently inspect the animation.		This will place a citywatch torso in front of you and loops the draw animation. You can enter noclip to conveniently inspect the animation. The head chosen for this testmodel is defined in the CVAR [[g_testModelHead]], which defaults to the citywatch head entityDef ''head_citywatch''.

	== Animation Groups ==		== Animation Groups ==

Greebo: categorised

2008-06-30T07:42:45Z

categorised

← Older revision		Revision as of 07:42, 30 June 2008
Line 102:		Line 102:
	* Be sure to let the WaitState be cleared by the script after the animation is done.}}		* Be sure to let the WaitState be cleared by the script after the animation is done.}}

	{{ai}}		{{ai}} {{sdk}}
	~~[[Category:Coding]]~~

Greebo: /* Animation States */

2007-11-08T10:59:50Z

Animation States

← Older revision		Revision as of 10:59, 8 November 2007
Line 72:		Line 72:
	However, if the programmer intends to do something after the animation is done, things get more involved, that's what WaitStates are for.		However, if the programmer intends to do something after the animation is done, things get more involved, that's what WaitStates are for.

	Note about the above example: As many animation states are using the same ''playanim/loop/finishAction/Idle'' algorithm in their script functions, I introduced a convenience function to make these things shorter and to avoid copy&paste errors:		'''Note about the above example:''' As many animation states are using the same ''playanim/loop/finishAction/Idle'' algorithm in their script functions, I introduced a convenience function to make these things shorter and to avoid copy&paste errors:
	// Call this with the channel, the animation name, the blendframes and the fallback animation state		// Call this with the channel, the animation name, the blendframes and the fallback animation state
	PlayAnimationOnce(ANIMCHANNEL_LEGS, "surprise", 4, "Legs_Idle");		PlayAnimationOnce(ANIMCHANNEL_LEGS, "surprise", 4, "Legs_Idle");

Greebo: /* Animation States */

2007-11-08T10:59:34Z

Animation States

← Older revision		Revision as of 10:59, 8 November 2007
Line 70:		Line 70:
	If the programmer's intention is just to let the "melee_attack" animation play on the torso channel and to fall back into the Idle animation state afterwards, it's enough to call:		If the programmer's intention is just to let the "melee_attack" animation play on the torso channel and to fall back into the Idle animation state afterwards, it's enough to call:
	actor->SetAnimState(ANIMCHANNEL_TORSO, "Torso_QuickMelee", 4);		actor->SetAnimState(ANIMCHANNEL_TORSO, "Torso_QuickMelee", 4);
	However, if the programmer intends to do something after the animation is done, things get more involved, that's what WaitStates are for:		However, if the programmer intends to do something after the animation is done, things get more involved, that's what WaitStates are for.

			Note about the above example: As many animation states are using the same ''playanim/loop/finishAction/Idle'' algorithm in their script functions, I introduced a convenience function to make these things shorter and to avoid copy&paste errors:
			// Call this with the channel, the animation name, the blendframes and the fallback animation state
			PlayAnimationOnce(ANIMCHANNEL_LEGS, "surprise", 4, "Legs_Idle");

	== Animation WaitStates ==		== Animation WaitStates ==

Greebo: /* Animation Groups */

2007-11-08T02:48:30Z

Animation Groups

← Older revision		Revision as of 02:48, 8 November 2007
Line 28:		Line 28:

	== Animation Groups ==		== Animation Groups ==
	For a given animation name (let's say "melee_attack") the game code automatically tries to lookup one of the animations "melee_attack1", "melee_attack2", etc. These animations, sharing the same prefix with a different integer number, form an animation group.		For a given animation name (let's say "'''melee_attack'''") the game code automatically tries to lookup one of the animations "'''melee_attack1'''", "'''melee_attack2'''", etc. These animations, sharing the same prefix with a different integer number, form an ''animation group''.

	The number is chosen randomly by the SDK code, so you can randomly choose between N different animations by specifying a single anim name.		The number is chosen randomly by the SDK code, so you can randomly choose between N different animations by specifying a single anim name.

	Note that you can still pick a specific animation by requesting a numbered anim name in the first place (e.g. you request "melee_attack2").		Note that you can still pick a specific animation by requesting a numbered anim name in the first place (e.g. you request "'''melee_attack2'''").

	== Playing Animations ==		== Playing Animations ==

Greebo at 02:47, 8 November 2007

2007-11-08T02:47:54Z

← Older revision		Revision as of 02:47, 8 November 2007
Line 26:		Line 26:
	testAnim draw		testAnim draw
	This will place a citywatch torso in front of you and loops the draw animation. You can enter noclip to conveniently inspect the animation.		This will place a citywatch torso in front of you and loops the draw animation. You can enter noclip to conveniently inspect the animation.

			== Animation Groups ==
			For a given animation name (let's say "melee_attack") the game code automatically tries to lookup one of the animations "melee_attack1", "melee_attack2", etc. These animations, sharing the same prefix with a different integer number, form an animation group.

			The number is chosen randomly by the SDK code, so you can randomly choose between N different animations by specifying a single anim name.

			Note that you can still pick a specific animation by requesting a numbered anim name in the first place (e.g. you request "melee_attack2").

	== Playing Animations ==		== Playing Animations ==

Greebo: /* Animation WaitStates */

2007-11-08T00:56:31Z

Animation WaitStates

← Older revision		Revision as of 00:56, 8 November 2007
Line 85:		Line 85:
	Basically this is checking each frame whether the enemy can be hit and if we're not playing the animation already, we're starting it. Note that after calling '''owner->SetAnimState()''', this code also sets the actor's waitstate by invoking '''owner->SetWaitState("melee_attack")''' manually.		Basically this is checking each frame whether the enemy can be hit and if we're not playing the animation already, we're starting it. Note that after calling '''owner->SetAnimState()''', this code also sets the actor's waitstate by invoking '''owner->SetWaitState("melee_attack")''' manually.

	This code relies on the waitstate being cleared by the Animation State's script method '''Torso_QuickMelee''', which is exactly what the previously mentioned '''finishAction()''' script call does. So, after the ~~loop~~ in Torso_QuickMelee is exiting the loop, the flag (set by the SDK) is cleared again and this allows the above code to restart the animation.		This code relies on the waitstate being cleared by the Animation State's script method '''Torso_QuickMelee''', which is exactly what the previously mentioned '''finishAction()''' script call does. So, after the script interpreter in Torso_QuickMelee is exiting the loop, the flag (set by the SDK) is cleared again and this allows the above code to restart the animation.
	{{Things-To-Remember\|		{{Things-To-Remember\|
	* Animations are ideally played by setting the Animation State (this triggers the scriptEvent '''with the same name''').		* Animations are ideally played by setting the Animation State (this triggers the scriptEvent '''with the same name''').

Greebo: /* Animation WaitStates */

2007-11-08T00:55:12Z

Animation WaitStates

← Older revision		Revision as of 00:55, 8 November 2007
Line 66:		Line 66:

	== Animation WaitStates ==		== Animation WaitStates ==
	In the previous example, you might wonder what the '''finishAction'''is supposed to do. The main reason for this call is to allow the SDK code to check whether the animation is done playing. As there is no equivalent to '''eachFrame''' in the SDK code, we must rely on flags being set. The flags are not set automatically (don't ask me why), this is done by the calling code, so let's look at how it's done (this is adapted from MeleeCombatTask.cpp and gets called nearly each frame):		In the previous example, you might wonder what the '''finishAction''' is supposed to do. The main reason for this call is to allow the SDK code to check whether the animation is done playing. As there is no equivalent to '''eachFrame''' in the SDK code, we must rely on flags being set. The flags are not set automatically (don't ask me why), this is done by the calling code, so let's look at how it's done (this is adapted from MeleeCombatTask.cpp and gets called nearly each frame):
	// Can we damage the enemy already?		// Can we damage the enemy already?
	if (owner->GetMemory().canHitEnemy)		if (owner->GetMemory().canHitEnemy)

Greebo: /* Animation States */

2007-11-08T00:54:19Z

Animation States

← Older revision		Revision as of 00:54, 8 November 2007
Line 38:		Line 38:

	== Animation States ==		== Animation States ==
	The AI is always in a certain Animation State, which is usually the Idle state (this is set in the AI's init() script). Each Animation State has an accompanying script function (normally defined in ai_darkmod_base.script), whose task is to monitor the animation status and take the according actions. The Animation State of an AI can be changed by calling the scriptEvent '''animState''' or idAI::SetAnimState():		The AI is always in a certain Animation State, which is usually the Idle state (this is set in the AI's init() script). Each Animation State has an accompanying script function (normally defined in ai_darkmod_base.script), whose task is to monitor the animation status and take the according actions. The Animation State of an AI can be changed by calling the scriptEvent '''animState''' or '''idAI::SetAnimState()''':
	scriptEvent void animState(float channel, string stateFunction, float blendFrame);		scriptEvent void animState(float channel, string stateFunction, float blendFrame);