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)
-----