martinr

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?
martinr
帖子: 10

badlogic

This sounds like a bug indeed. I've added an issue here [runtimes] AddAnimation after current tracks entry has finished adds delay · #1064
头像
badlogic

Mario
帖子: 1140

badlogic

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

Mario
帖子: 1140

martinr

And thank you for making swift progress of the bug reports
martinr
帖子: 10

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.

:beer:
头像
Nate

Nate
帖子: 7697


回到 Runtimes