Add a signal to notify when the animation node changed inside state machine playback

[CrayolaEater]

Added ability to track current animation node using the new animation_playback_node_changed signal.

[TokageItLab]

It is not known how much this type of signal is needed for StateMachine. We may want signals for fades, etc., but for now we should summarise the demand and use cases in the proposal.

At least, adding signals to the AnimationTree probably needs to be thought about a bit more carefully, as it may not return the proper path in cases such as nested AnimationTree and GroupedStateMachine.

[CrayolaEater]

It is not known how much this type of signal is needed for StateMachine. We may want signals for fades, etc., but for now we should summarise the demand and use cases in the proposal.

At least, adding signals to the AnimationTree probably needs to be thought about a bit more carefully, as it may not return the proper path in cases such as nested AnimationTree and GroupedStateMachine.

There are a lot of use cases for this. For example I have multiple animations that I import from blender and I need to trigger different functions according to a different animation playing. I don't want to use call method tracks because when I do modifications and re-import those animations I have to add the tracks again each time.

[TokageItLab]

At least this implementation should not be enough in a real use case. It should not be able to handle fade-ins and fade-outs, and it should not be able to detect changes in the GroupedStateMachine path.

[CrayolaEater]

At least this implementation should not be enough in a real use case. It should not be able to handle fade-ins and fade-outs, and it should not be able to detect changes in the GroupedStateMachine path.

What do you mean "it should not be able to handle fade-in and fade-out" ? Its just signaling the node change.

[TokageItLab]

I mean that this kind of signal should be notified on fade-ins and fade-outs as well. This signal may be sufficient in the limited and specific case of a simple StateMachine, but it is not sufficient for a complex StateMachine (Although I understand the need for them).

[PPillau]

Pls can we merge this into master at some point? It is baffling to me how something as basic and fundamental as notifying/signaling upon a state change in a state machine is not already in the engine.
There are a lot of situations where I want to react to an animation change in code.

The AnimationNodeStateMachine currently exposes no signals at all, effectively leaving the user in the dark about anything that happens inside the state machine.

I think something like a animation_started(animation_name) signal would be even more useful because then you could not only detect a state transition (by comparing previous and current animation) but you can also get notified anytime an animation loops, but the signal in this PR is already a step in the right direction :)

[CrayolaEater]

I mean that this kind of signal should be notified on fade-ins and fade-outs as well. This signal may be sufficient in the limited and specific case of a simple StateMachine, but it is not sufficient for a complex StateMachine (Although I understand the need for them).

If you mean transitions xfade that also works.

[TokageItLab]

What I mean is that changes in fading_from must be signaled as well. Without this, the user will not be able to detect where the fade ended.

Also, if the nested child StateMachine's StateMachineType is STATE_MACHINE_TYPE_GROUPED, the parent StateMachine must signal the internal changes in the child StateMachine on its behalf. Because the user cannot use the child StateMachine's StateMachinePlayback directly.

[CrayolaEater]

Also, if the nested child StateMachine's StateMachineType is STATE_MACHINE_TYPE_GROUPED, the parent StateMachine must signal the internal changes in the child StateMachine on its behalf. Because the user cannot use the child StateMachine's StateMachinePlayback directly.

So the signal should be per StateMachine instead of per AnimationTree?

[TokageItLab]

@CrayolaEater The change in current state of the StateMachine is tied to AnimationStateMachinePlayback, not to AnimationTree, so the signal should be fired by neither AnimationTree nor AnimationNodeStateMachine¹, but by AnimationStateMachinePlayback.

And the signals should have appropriate names such as AnimationStateMachinePlayback.current_changed or AnimationStateMachinePlayback.fading_from_changed. e.g.

emit_signal(SNAME("current_changed"), current);

In this case, the child StateMachine which is is_grouped = true, does not fire the signal on its own, but instead must call a method so that the parent StateMachinePlayback fires the signal with path, e.g.

parent_playback->emit_signal(SNAME("current_changed"), SNAME("action/attack"));

Footnotes

1. In particular, since the StateMachine is a resource, it can be reused, causing confusion when multiple AnimationTrees reference the same StateMachine ↩

[CrayolaEater]

@TokageItLab I have difficulties understanding the concept of Grouped State Machine. What is it achieving? How can I properly set it up ? The docs don't mention anything.

[TokageItLab]

A grouped type state machine differs from other types of state machines in that only indirect access is granted to the user through playback of the ancestor root or nested type state machine.

The concept is described in #75759, but better documentation is not yet available. I am writing an article about it now, but it is taking a while to put together due to the insane large number of changes in Animation from 4.0 to 4.3. I make effort to upload it by 4.3 stable.

[Musashi98]

Hello there and sorry about the next question: do you have an estimate of how much time untill this feature is added to the engine?

Thank you about your hard work Godot community!

[CrayolaEater]

Hello there and sorry about the next question: do you have an estimate of how much time untill this feature is added to the engine?

Thank you about your hard work Godot community!

Hello! Its not up to me. It must be reviewed by the Godot team to make sure its working properly.

[TokageItLab]

fading_from_state_changed must generate a path that takes into account the child_state_machine in the grouped case as well as the current_state_changed case. Some information on the behavior of grouped state machines is summarized here.