Animator Controller Changes

To support the new motion forms, the basic “Humanoid” Motion Controller animator has been updated. During the pack setup process, I’ll update your animator for you.

Just in case, here’s the changes:


  1. Change the second layer name to “Upper Layer”
  2. Set the mask to be the “Upper” mask


  1. Add L0MotionForm as an int parameter
  2. Add L1MotionForm as an int parameter


Motion Forms

As mentioned, the MC now supports the idea of a “form”. Think of the form as a way of determining the “style” in which you’ll do things. For example, the Basic Walk Run Pivot motion will allow you to walk… But, will you walk like a male, a female, with a bow in-hand, etc?

These differences are now all stored in the same sub-state machine for the motion:

In the BasicWalkRunPivot-SM, you can see that we have the mecanim states for several different walking forms.

We can add more by simply creating the sub-state machines and blend trees as needed.

The LxMotionForm condition (shown in the image above) is what’s used to determine which animation flow will play.

Setting the Motion Forms

Most of the new motions will allow you to explicitly set which “form” value to use.

This will force the LxMotionForm value.

However, you can usually leave the value at “0” which means the motion will grab the value from the Actor Core’s State called “Default Form”.

This allows us to change the form value on the fly…

For example, the Weapon Sets in the Basic Inventory allow you to change the Default Form automatically when the weapon set is equipped.

Here you can see that we use “200” for the Longbow weapon set. We then use “200” as the LxMotionForm condition value in the Basic Idle, Basic Walk Run Pivot, etc.

Mind you, these values are just numbers. I’m using “200” to mean something, but you can add your own animations and use 3191 or some other number to represent your form.




“Basic” Motions

The Motion Controller (and packs) now includes a set of “basic” motions that support the LxMotionForm parameter discussed earlier.

These motions allow us to extend the animator sub-state machines to support different animations. For example, instead of having the following setup:

We can simply have the following:

Using the example images above, different versions of the “Idle” animation actually live with in the BasicIdle-SM animator sub-state machine that is associated with the “Basic Idle” motion.


Multiple Motion Layers

The MC has always supported animator controller layers. This allows you to run multiple animations at that same time. The “Basic Motions” improve this and make it easier to walk-and-swing or walk-and-shoot at the same time.
For example, you can add your idle and walk motions to the first layer (Locomotion):

Then, add your equip and attack motions to the second layer (Upper Body):

Just remember…

  • Motion’s sub-state machine must exist on the matching animator layer
  • Not all animations are built to use multiple layers and masks

Setting up walk & attack

In order to “walk and equip” or “walk and attack”, you have to have the sub-state machine on the second layer. You also have to have the motions created on the second motion layer.

You can do this on the “Packs” view by simply changing the “Animator Layer” property to “1” and pressing “Setup Pack”.

Once done, you’ll need to disable or remove the motions from the first layer so they aren’t triggered. This will allow you to walk on the first layer and attack or equip on the second



Reactors allow you to tap into state changes and messages that are passed around. The reactors are part of the ActorCore component.

In fact, the new combat flow uses the reactors to send and respond to combat messages. With this new approach, you can customize your character’s behavior or simply report on events using simple reactors.

This reactor looks for the message ID “1100” which equates to “Before I actually swing my weapon”. When found, it uses Unity’s event system to call any function you want. In this case, I’m calling a function I created named “OnPreAttack”.

This function exists on a totally different component which means you can customize it without modifying any ootii code at all. In this case, the OnPreAttack function looks like this:

        public void OnPreAttack(ReactorAction rAction)
            mActorCore.SetStateValue("State", ATTACKING);

            if (rAction == null || rAction.Message == null) { return; }

            // Choose the attack style
            if (rAction.Message != null && rAction.Message.Data is BasicMeleeAttack)
                CombatMessage lCombatMessage = rAction.Message as CombatMessage;
                if (lCombatMessage == null) { return; }

                lCombatMessage.StyleIndex = 2;

In this function, we set the NPC’s state to “ATTACKING”. Then, we choose which attack style to use.

This becomes pretty powerful as you can change which attack the NPC uses right before he does it. For example, you could check who the defender in the CombatMessage is and change your attack to be more effective.

Reactor Events

Right now, I’ve got messages being sent for attacking, defending, equipping items, equipping weapon sets, etc. The goal is to continue adding messages so that you can tap into anything through the reactors.


Target Locking

In the Sword & Shield Motion Pack, I used a separate “PSS_WalkRunTarget” motion in order to lock-on to a target and allow the character to strafe around the target. That is no longer needed. Instead, we can simply use the Basic Walk Run Strafe motion and check the “Activate With Target” option.

This allows us to use targeting with bows and other weapons and not just with the Sword & Shield Motion Pack.

When “Activate With Target” is checked, this instance of the motion will only activate if the associated Combatant component has a target set or if the “Activation Alias” is held. It will deactivate when the target is lost or the “Activation Alias” is released.

“Activate With Target” will force the character to rotate towards the target. When strafing, it basically forces the character to orbit around the target.

This motion will not force the camera to only look at the target. It will just rotate the character.

Note that locking-on requires the Basic Walk Run Strafe motion. It won’t work with Basic Walk Run Pivot because the pivot doesn’t have an animation for strafing left, strafing right, or walking backwards. So, it would look odd to move right while animating a forward walk. Basic Walk Run Strafe supports all of the animations.


Another option for target locking is to allow the Combatant component on the PC to do it. This approach is more “absolute” as it works for all motion and all cameras. However, because of that it tends to be more rigid.

To force target locking this way, simply check the check-boxes as needed:

Page Contents