Add additional "AtTime" switch type to animation transitions

[SaracenOne]

Describe the project you are working on

3D VR online virtual worlds application.

Describe the problem or limitation you are having in your project

The AnimationStateMachine system does not currently allow a desired amount of granularity when it comes to controlling at what points during an animation it should transition to another. Your only real options at the moment is to test every frame, or test at the end of the animation minus the amount of time it would take to transition to the next animation.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

I propose adding a new switch type called 'AtTime' to the existing transition types which would allow the user to define windows of time when a transition test should occur. It should include also a new inspector plugin to allow users to easily visualize the transition between states.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

The new switch type would include a start and end time (in seconds) of when to test the conditions for transitioning to another animation state to another. When the animation hits this point, the regular condition checking for the transition will occur, and if successful, will begin transitioning to the next animation state. It should also include the ability to define tests to only occur ever x number of loops (via modulo testing).

In order to make such a feature easy for users to work, we will likely need to write a new inspector plugins in order to allow them visualize the animation and define the transition points. In order to provide the modulo testing, it may be nessecary to either store the total cumulative time spent on particular animation state or store the amount of loops which have occured somewhere.

I intend to implement this feature myself, and will supplement this with more examples as the feature develops.

If this enhancement will not be used often, can it be worked around with a few lines of script?

Due to how the Animation state machine works, it does not seem possible to do this kind of testing via the expression parser, and even if it is possible, it is highly cumbersome and not condusive to regular animation workflows. Integrating it as a native part of the animation system makes sense and will likely make designing gameplay systems via animation state machines more attractive to users.

Is there a reason why this should be core and not an add-on in the asset library?

The design of the animation system does not currently facilitate implementing a feature such as this without direct integration.

[TokageItLab]

I cannot say that this is the best way to go yet.

If we plan to have every AnimationNode have a "custom length" to get the semantic remaining time more generally, then "custom length + AtEnd" may be sufficient for this purpose. And we also need to consider whether it makes sense to coexist with that.

[SaracenOne]

The concern with that is it wouldn't address situations where you wanted an animation to potentially spin off into more than one other state. Personally, if everything was being done from scratch, I'd actually say it would be better to replace AtEnd entirely, but I think it would be unwise to break backwards compatibility. The reason I feel this is important is it opens the possibility of designing game logic which is more purely animation driven. From some side projects I've been experimenting with, I can actually give some working examples of games designed this way which are simply impossible to replicate with the current state machine system.

The main concerns I have are not so much that I feel this approach is problem. From prototyping in the past, it seems to work fine with minimal changes required, but what's held me back is how to do it in such a way that will be easy for users to understand.

[TokageItLab]

There is no need to break backward compatibility. I think just add some properties the following:

AnimationNode:

• custom_length
• start_offset
• end_offset
• loop (then https://github.com/godotengine/godot/pull/79400 is no longer needed, should be closed)

AnimationNodeSync:

• time_estimation
  • shorter
  • longer
  • override

After doing that, if it is still needed then AtTime transition should be added, so I disagree to implement AtTime transition first.

[SaracenOne]

While I may have accidentally conflated the two, I do actually consider this to be seperate from the need to have full semantic time support, but I do agree that I would prefer that we get semantic time in as a higher priority.