Animation: StateMachine's fading doesn't finish correctly [Godot 4 beta 10]

[ywmaa]

Godot version

4.0.beta10

System information

Nobara Linux

Issue description

after updating my project Advanced-Movement-System-Godot to Godot 4 beta 10 state machines are broken ( I usually fix stuff every beta but this time I couldn't)
at first I made a condition in the advance_condition and changed it through code : set("parameter",value)

but currently after I think a pull request is merged I think this one : #65312

having the condition mode set to Enabled or Auto doesn't advance/travel the animation.

Steps to reproduce

make a state machine in an AnimTree and make a condition in the travel between two animation nodes in the state machine.

Minimal reproduction project

https://github.com/ywmaa/Advanced-Movement-System-Godot

[Calinou]

cc @SaracenOne

[TokageItLab]

Perhaps this can be fixed by replacing the property in .tres for now.

auto_advance = true

↓

advance_mode = 2

Also, the disabled property may have been changed, but I don't know too much.

[ywmaa]

advance_mode = 2

I can't change it, because the editor doesn't detect changes and just resets it to auto_advance = false

[Remi123]

I share the same problems. The animationtree is in complete regression to unusable state. The only consistent bug I can find is that as soon as an AnimationNodeStateMachineTransition have any blend time, either travel or auto_advance, if fail to change animation state.

It is even worse for auto-advance. I have tested for a simple transition from Idle to Walk animations, and I can transition from Idle to Walk, but going back to Idle give me my T-pose, as if it loss the reference to the animation.

The only saving grace is that travel without blend time works as expected, as well as auto-advance without advance_condition, at least those that transition at the End.

[TokageItLab]

Can anyone send a minimal project reproducing the problem with simple StateMachine?

[SaracenOne]

Let me go have a look and see what's wrong.

[SaracenOne]

An MRP would be really useful for this. I was concerned about this change and wish I had a migration path, but we discussed this and felt that from a broader design pattern that auto-advance should always be a requirement rather than simply the presence of expressions and/or conditions in the transition. If I can see exactly how this broke, I'll attempt to fix it ASAP.

[ywmaa]

@SaracenOne
here it is :
StateMachineMRP.zip

I wasn't even able to switch to the first anim state.

[SaracenOne]

Thank you! I'll see what I can do

[SaracenOne]

@ywmaa Okay, I've been testing the MRP, and there's a few things I'm confused about. So, I don't see anything wrong with the transitions so far, but the most obvious thing I notice immediately is in spite of the AnimationTree seeming to be functioning, the animations themselves do not seem to do anything when played via the AnimationTree (they work on the AnimationPlayer though). The issue here seems to be with the way that the AnimationTree's _process_graph method blends the animations, and it appears to be rooted in the presence of both a value track for position, and the presence of an empty Position3D track forcing it to be Vector3(0.0, 0.0, 0.0) every frame. Removing the Position3D track makes it work again.

I don't know if this has always been the behaviour of _process_graph, but it doesn't seem to have anything to do with the auto_advance behaviour since that appears to be working correctly. I don't know if this has any bearing on @Remi123's issue, but if anyone has anymore MRPs, more examples would be appreciated.

[matt08-prog]

This State_Machine_MRP.zip shows a state machine with three states each traveled to with a button. After transitioning back to the "spin" state, however, the state machine stops working. This only happens if the xfade time between the "left and right" and "spin" states is non-zero.

[TokageItLab]

I have looked into ywmaa's MRP and there doesn't seem to be any bug, I guess the Position3D track was inserted incorrectly during the creation of the MRP. AutoAdvance + ImmediateSwitch will be the action to skip that animation. In that MRP, both fast and slow conditions are enabled, so move_fast is skipped.

[TokageItLab]

@matt08-prog Oh, that looks like a regression by #70278. It looks like the switching decision after the fade was shifted by one frame in order to handle the end flag correctly, which is bad...

[TokageItLab]

I sent #70572. Please confirm if that will close this issue. Since I cannot determine if the problems @Remi123 & @matt08-prog 's problem and @ywmaa 's problem are the same or not.

[SaracenOne]

Yes, I'm looking at this too, and it does indeed seem to be seperate issues.

[ywmaa]

I have looked into ywmaa's MRP and there doesn't seem to be any bug, I guess the Position3D track was inserted incorrectly during the creation of the MRP. AutoAdvance + ImmediateSwitch will be the action to skip that animation. In that MRP, both fast and slow conditions are enabled, so move_fast is skipped.

No I don't think that's my issue, I probably didn't do animation probably in this MRP, I will check matt8s' MRP probably it is the same problem for me.

[TokageItLab]

@ywmaa So is the issue correct as the title I rewrote? I'll pin this issue until beta 11.

[ywmaa]

I share the same problems. The animationtree is in complete regression to unusable state. The only consistent bug I can find is that as soon as an AnimationNodeStateMachineTransition have any blend time, either travel or auto_advance, if fail to change animation state.

It is even worse for auto-advance. I have tested for a simple transition from Idle to Walk animations, and I can transition from Idle to Walk, but going back to Idle give me my T-pose, as if it loss the reference to the animation.

The only saving grace is that travel without blend time works as expected, as well as auto-advance without advance_condition, at least those that transition at the End.

@TokageItLab
so I think my issue is exactly as his,

if the switch_mode set to "sync" or "immediate" it won't transition at all, be it auto advance or enabled,

if I set it to "At The End" it works with advance_mode = "auto advance"
also if I set "advance_mode" to "Enabled", it doesn't transition the animation .
finally for me xfade doesn't fix anything nor worsn it.

I am not sure if the title describes what I am saying

[TokageItLab]

as well as auto-advance without advance_condition

finally for me xfade doesn't fix anything nor worsn it.

I cannot determine these problems from the MRPs that are currently in place. It seem to be the intended behavior.

At least the fade blending will be fixed by #70572, so if there are still problems after that, someone will need to open another issue again. Since there are currently two issues mixed up in this discussion, the problem should be solved separately.