Add state transition signals to AnimationNodeStateMachinePlayback

[TheOrioli]

Adds signals to the AnimationNodeStateMachinePlayback which allow user-level scripts to react to transitions between the various states.

What this means in practice is that it allows users to know when an animation/blend/sub-machine has stopped or started playing inside an AnimationNodeStateMachine. This can be used to solve problems presented in godotengine/godot-proposals#1462, #28311 and #41771

Example project using this PR

This fix can also be easily backported to 3.x , there seem to be no conflicts.

The current ways to do the same thing on a user level are:

• create call method tracks in animations to notify scripts of completion. This is not a scalable solution for games with lots of animations as it's prone to user error.
• apply a special script to every AnimationTree node which manually checks for state changes every idle or physics frame, depending on settings. This is also very prone to user error.

[lufog]

@akien-mga, Is there any chance that this pr will be merged? As I can see, a pretty big amount of people want this functionality.
Some requests/mentions: #1462 #8521 #22137 #26408 #28311, previous attempts to add similar functionality: #24328 #30508 #41771.

[akien-mga]

It needs to be reviewed and approved by contributors familiar with the animation workflows and their implementation.

[reduz]

Looks good! Please address the comments and should be ready to merge.

[Macksaur]

This doesn't seem to initially emit any signals when using .travel() or .start(). Only when the state machine transitions from the first state into the second (i.e. only on the second node).

Should it not emit signals in this case also? Something-something like:

+       // check if we have specifically jumped/teleported into a new state
+       if (current != previous) {
+               if (previous) {
+                       emit_signal(StaticCString::create("state_exit"), previous);
+                       emit_signal(StaticCString::create("state_changed"), previous, current);
+               }
+               emit_signal(StaticCString::create("state_enter"), current);
+       }

above https://github.com/godotengine/godot/blob/72ec76c4c4381d0b09155c8534cde2b91e96e504/scene/animation/animation_node_state_machine.cpp#L381

[TheOrioli]

@reduz Thank you for the review, I have applied the requested changes to SNAME.

I've also added additional emit_signal calls that should cover the use case mentioned by @Macksaur

The new updated example project that allows teleporting/traveling to a specific state animation_state_machine_test.zip

[reduz]

I am wondering if we should have
state_enter, state_changed, state_exit be emitted exclusively and without overlap from one to the other, so the order would be

• state_enter
• state_changed
• state_exit

[TheOrioli]

"exclusively and without overlap" meaning:

• state_enter is only emitted when entering into the machine for the first time, on the first state entered
• state_changed is emitted any time a state transitions into another valid state, automatically or using Start or Travel
• state_exit is only emitted when a machine stops

or something else?

[ballerfuturistic]

Any updates on this? I think still waiting on clarification from @reduz

[AbrahamBrookes]

poke. I too would like this feature

[TheOrioli]

tbh, this is such an ancient PR, it would probably be best to rebuild it from the ground up since a bunch of new animation changes have been made in the mean time.