Tips and Pitfalls

• Choosing which animation graph an Entity will use is specified at the entity level. It is specified in the .lua files in Game\Scripts\Entities.
• Normally, having separate nodes for 'walk' and 'run' is not recommended if you are using LMGs (Locomotion Manager Groups).
• All range-based criteria have a hysteresis behavior. In other words, even if there is some overlapping in a range, the current state is always favoured.
• To avoid always having to manually input the Action, Item, and Stance values in 'State Query', you can use the preselection system. You can have *_preselections.xml associated with an AG, .xml, and describe your pre-selections there.

<PreselectionLists Filename="Animations\Graphs\fullbody.xml">

  <Preselection Type="Basics" name="IdleHealthy">
      <Selection Input="Action" value="idle" />
      <Selection Input="Health" value="100" />
      <Selection Input="Item" value="pistol" />
      <Selection Input="Signal" value="none" />
      <Selection Input="Stance" value="nav" />
      <Selection Input="Vehicle" value="none" />
      <Selection Input="waterLevel" value="5.0" />
      <Selection Input="Wound" value="none" />
  </Preselection>

</PreselectionLists>

• The combination of a null node and a forcefollow link is useful to "trick" the state selection. For example, you may want an animation to begin to be loop played when some input combination is given, but it remains in that state until one of just two inputs in the combination is changed. In other words, changing other inputs in the combination does not stop the animation.
• Guarded input: It is a safeguard in case you want to make sure that a specific input is not ignored. The animation graph has the need to always come up with a state that matches the inputs as closely as possible. If the code sets the inputs and no state matches, it will start ignoring inputs with a lower priority. It's important to note that it absolutely cannot ignore guarded inputs.

• Structure property: All states with the same structure will be time/phase-aligned when blending. Therefore, in the case of walk and run blending, the correct portion of the cycle will be blended in.

• Some extra properties don't work in the states that don't have any animation. The problem is, as you can see in AGSetInput.cpp, the real job of the 'SetInput' is done in CAGSetInputNode::EnteredState(). However, for states that don't have any animation, they never reach the entered state. Hence, if you want the 'SetInput' to work in those states, you can move the job performed in CAGSetInputNode::EnteredState() to CAGSetInputNode::EnterState(). For example, the 'CAGSound' class was actually implemented as such.

• AttachmentEffect: You can see available particle effects in the DataBase View. It should be a full path to a specific effect. For example, "explosions.rocket.cliff". It has the following structure: 'libraryname dot itemname dot effectname'.
• If you use forceInStateUntil="0.98" in the animation graph template, then, that state will not be left until the animation proceeds to 98% of the whole period. Also, that template must use !LoopAnimation="0". In other words, looping is not compatible with it.