Main Content

If calling AddAnimation on a track where an animation has played to end, the added animation is queued with a delay that is a factor of the previous animations duration. E.g. if an animation has a duration of 10 seconds, and, after 15 seconds, AddAnimation is called, the animation is played after 20 seconds (2 * 10 seconds). The expected behavior would be to add the animation immediately as if the track was empty.

This seems to be an issue in multiple runtimes - I have observed it in the TS runtime, and looking at the code, it looks like the c-sharp runtime behaves the same way. Is it the intended behavior?

This has been fixed in the 3.6 and 3.7-beta branches. Thanks for reporting!

11 months ago

badlogic

Posts: 1472

martinr

And thank you for making swift progress of the bug reports

11 months ago

martinr

Posts: 17

Nate

To be clear, it is the intended behavior for looping animations: when you addAnimation with 0 delay, it will wait until the end of the current loop, then play the queued animation. For non-looping animations, it will also wait until the end of the animation, then play the queued animation. However, with the new fix, if the animation is already past the end, for non-looping animations it will play the queued animation right away.

The reasoning for this behavior is that the intent of addAnimation with 0 delay is to play the new animation at the end of the previous animation. With looping, the end comes many times. With non-looping, the end only comes once.

Note you can always use setAnimation to change the current animation right away.