Add animation_started/finished signals to AnimationTree and fix time accuracy in StateMachine

[TokageItLab]

In the past, many times we received reports of problems with AnimationTree not firing signals for AnimationPlayer, since AnimationTree only gets the AnimationPlayer's animation list and the AnimationPlayer does not process anything.

However, there seemed to be a demand for signals, and a common workaround was to add a MethodTrack at the end of the Animation. This has caused also some reported problems in the past with MethodTracks at the end not being processed, but this should be fixed with the recent overhaul of the animation process.

But it is not wise to leave workarounds in place, so adding a signal to the AnimationTree eliminates the need for such workarounds.

I am not sure if only the animation name is sufficient as a signal argument. This means that it is currently impossible to identify which NodeAnimation processed the Animation.

The reason for this is that it is the NodeAnimation that can fire the signal, and the NodeAnimation itself does not have a name, its label is held by the NodeBlendTree or NodeStateMachine map. Well, considering that we are replacing a workaround that has a MethodTrack at the end of the animation, I guess this is sufficient.

Closes #28311 Fixes #70318

animsignal.mp4

animation_tree_signal_test.zip

[TokageItLab]

Work in progress as there seems to be a problem with the StateMachine transition process.

[lufog]

Perhaps related #55423 (comment) (probably not 🤷‍♂️)

[TokageItLab]

I expect this is probably due to the hack use of the context blend time = -1 in the StateMachine algorithm... Not related, see comment below.

[TokageItLab]

Okay, fixed. The problem was that the time in the StateMachine was not a double but a float, so it was not precise enough, and the fade end was determined too early¹.

animation_tree_signal_test_statemachine.zip

By the way, there is a issue with the "animation_started" signal not firing in travel mode with no connection, which is the same problem as in #70318. Currently, travel mode transitions with no connection do not do a 0-seek, so start cannot be detected. We will need to pick up it later.

Footnotes

1. When fade_blend == 1.0 in crossfades, the old animation must play with a blend value of 0 (CMP_EPSILON) in order for the end of the animation to be processed. ↩

[TokageItLab]

Included fix for #70318. Force playback from the head when teleporting travel (with no connection) from another state.

[SaracenOne]

Yes, this makes sense so as not have to rely on the MethodTrack workaround, and while I was a little concerned with the implication of issues surrounding floating point precision, moving to double makes sense from a consistency standpoint nonetheless, so this all seems fine to me.

[akien-mga]

Thanks!

[Valeryn4]

I've been waiting for this for four years! Sorry...

[sirmike]

@TokageItLab Have you checked if this code can also be backported to 3.x?

[TokageItLab]

Unfortunately, this depends on a bit large refactoring done in #69336, so it would be difficult to backport.