Details.
Line 113.
"getAnimationEndTime( "hal_platform", 0 )" is
"getAnimationEndTime( "hal_platform", 2 )"
is the corresponding track ID, I think.
Although it is conceivable that it is the keyframes that are the cause, just in case
Viewing post in Spine Extension for Clickteam Fusion 2.5 comments
Thanks for the tip. The solution turned out to be simpler. Each animation channel needs its own global value. Keys and time doubtfully play a role, I tried different things. It remains to figure out how to reset the animation to inactivity.
https://skrinshoter.ru/vMvKyPAIiQV?a
I did a little research to see what was going on.
Basically, when multiple SetAnimation calls are made
The animation does not switch immediately.
The intermediate animation is complemented, and then the motion set later on is applied.
In this case, when SetAnimation("17_aim") is called for the second time
SetAnimationSpeed(0) interferes with the transition from the first motion to the second motion, causing the animation to freeze.
However, when I try to reproduce this under the same conditions using SpineBoy, it works fine.
Therefore, it seems to me that the structure of the file (existence of keyframes?) is not the only thing that needs to be taken into account.
It is highly possible that this is a bug in the SpineRuntimeSDK, including the structure of the file
In the meantime, it is possible to protect the animation by preventing it from playing back when the same animation is attempted to be played back.
I think it can be handled by using an instruction on the CF2.5 side to let the same animation not be performed.
(Or perhaps adding some kind of keyframe to the file?)
-----
+ getAnimationName$( "hal_platform", 1 ) <> "17_aim"
hal_platform : SetAnimation( 1 , "17_aim" , loop=0)
-----