Possible bug in using two anim state machines

Hi,

I’m experiencing a problem where I have 2 state machines working together to produce the final pose, but when one of these state machines makes a transition the other one is reset and the current state discarded.

I will start with some screenshots to show you my setup.

39581-animsetup.png

The Locomotion state machine drives the whole body of my character. Then the UpperBody state machine drives the aiming and some additional “upper body only” animations.

The problem is that when the UpperBody state machine does a transition and goes to a new state, the Locomotion state machine is reset and goes back to its entry state.

To explain the issue better these are my Locomotion and UpperBody state machines

UpperBody:

Locomotion:

For example when the UpperBody transitions from “Look_Aim” to “EquipWeapon” and the Locomotion state machine is in state “Walk” (for example), the Locomotion goes back to Idle and then re-evaluates the all the transitions and eventually starts the Walk state again. The restarting of the state machine can be seen visually and it looks very ugly and buggy, like in the middle of the walk cycle the character goes to idle and then back to walk.

Is this a bug or the intended behavior? I will appreciate help or suggestions!

P.S: Just so you know, I debugged the code a bit, and what I discovered is that every time the upper body changes state the following function is called for the Locomotion state machine which basically resets the whole state machine.

USTRUCT()
struct ENGINE_API FAnimNode_StateMachine : public FAnimNode_Base
{
	......
	
	// FAnimNode_Base interface
	virtual void Initialize(const FAnimationInitializeContext& Context) override;
	
	......
};

We have exactly the same issue:How to connect two state machines? - Character & Animation - Unreal Engine Forums

Here a simple test case to reproduce. Tested on Win 7 64 / UE 4.7.6 binary

  1. Start with ThirdPerson template

  2. Replace ThirdPersonAnimBlueprint and ThirdPersonCharacter by files from : this archive

  3. Play and press F key few times when running. Every time the character will jump a little.

How it works:

  • In ThirdPersonAnimBlueprint a new state called Test is added to the Default state machine. This state is only reachable from the Entry node, so it’s played only when the state machine is initialized. This state is playing the JumpLand anim, making it simple to see that the Default state machine is reset.

  • The pose produced by Default state machine is stored in DefaultCache

  • Another state machine called Test is composed in two identical nodes A and B. Each node simply copies the DefaultCache to the final pose.

  • Boolean variable “IsB?” drives the transition between A and B. This variable is switched between true and false in ThirdPersonCharacter BP.

This example shows that the Default state machine is reset every time the Test state machine goes from A to B, even if both A and B just copy DefaultCache to output.

I would expect that Default state machine is not reset. Is this a bug or there is some explanation for this behavior?

Bump. This issue is kind of a show stopper for me. I would appreciate if someone can give me more info.

Did anyone at U4 dev team had a chance to confirm this as a bug and maybe offer some work around or a actual fix?

Hey everybody,

I have an email out to some devs regarding this topic. I’ll update here with any news.

-.

Hey Everybody,

After some discussion, I’ve entered UE-15825 with links to this answerhub and the forum post. Thanks for the input, and I’ve made sure to mention in the bug that it’s a showstopper for some of you.

-.

Sorry for poking you about this again, but is there any chance we can get a fix for this anytime soon or some kind of a workaround?

Looks like a fix is in the GIT master branch Engine/Source/Runtime/AnimGraphRuntime/Private/AnimNodes/AnimNode_SaveCachedPose.cpp

Fuzzycode, what commit are you referring to? The bug is still open in our system and if it was fixed by an unrelated commit, I’d like to test it and close it out.

Hi ,

I was informed that the bug was fixed on UDN and just taking a look at the master branch on here it looks like the same code in the last commit to that file.