Update: I’ve reproduced the issue on a new project using Epic’s Animation Starter Pack: [Google Drive Download][1]
This is a difficult issue to explain/replicate.
I have directional melee animations, let’s just consider attacking from the left and attacking from the right (for context, they’re from this marketplace asset: FPP Melee Animset in Animations - UE Marketplace but that’s irrelevant). Each of these attacks are broken down into 4 separate anims with the following states:
, and within each I use a Blend by Int (using Blend by Bool for illustrative purposes here but the behaviour is the same for all BlendByList type nodes) to determine which directional attack should be played:
Please note that the extra state (AttackReset) is to allow attack combos. It’s content is exactly the same as the Holding state, it’s just the transition rule that differs (it will transition to Executing as soon as it’s fully blended into the animation).
The directional attack value to use is set with State Entered events on AttackPreparing and AttackReset.
The issue here is that when I do a combo, it seems that the AttackReset’s Blend by Int is still playing the previous combo’s animation for a fraction of a second before switching to the correct one:
[Bad Blending][4]
I’ve tried the following and nothing solves the issue:
Setting the direction variable in the AttackReturning Left State event but the behaviour is exactly the same.
Setting all blend times to 0 Setting all States to Reset on Entry
Setting all Blend by Int nodes to Reset Child on Activation.
If I implement the behaviour with a state per attack direction the behaviour is as expected:
This leads me to believe that this is a bug as surely one would expect the behaviour to be the same when simply using a list to determine which animation should be played?
This is a really frustrating bug because the permutations of state transitions and duplications would be absurd if I had to implement a state per direction. Any ideas?
Compare this to the first screenshot in my post above. We haven’t even plugged in all the other states like jumping, sprinting, magic, kick etc which can all transition from the AttackRet states.
In the blend by bool node, the blend times default should be 0.0, and what happens if you add something like 0.2?
What is the AttackReset, maybe this should be just Idle? If you want some sort of Reset animation maybe direct from all states to the Reset state (bool for IsAttacking And IsResetting = True…).
Thanks for the response unit23. I have tried all possible combinations of Blend Times (for state transitions as well as in the BlendByInt node) and resetting of states and Nodes.
Furthermore I’ve simplified my state machine to only have 5 relevant states:
(Idle → AttackPrep → AttackHold → AttackExec → AttackReturn → Idle). The only difference between a normal strike and a combo is that the combo allows the AttackReturn state to be exited earlier.
I suppose it should be noted that I store two variables in the AnimInstance to know that the player has requested an attack, and which attack direction was requested. In the AttackPrep Entered Event I then set the effective attack direction to the requested attack direction, which is the variable driving the actual animations:
Scrutinizing this more carefully I now see that when requesting an attack during the AttackReturn state (as is perfectly expected for a combo) , the animation system immediately starts playing the new attack direction’s AttackReturn animation (for a few milliseconds) before it starts playing the correct AttackPrep state’s animation (Idle state is skipped due to MaxTransitionsPerFrame=3 ). Most importantly, the behaviour described in the previous sentence should not be occurring as the new attack direction is only applied during the AttackPrep state entered event. The animation and variables are out of sync!
I am now 100% convinced this is a bug as a simple repeat of a state chain leads to different behaviour than executing it once.
See the pose at 5 seconds is the same as the pose at 9 seconds. The pose at 5 seconds should not be happening: [Video][4].
