The reference time inside Spine is 0.0166.
This is the value of (1.0sec / 60frame).
http://ugken.com/ext/Spine/AnimationTime.zip
*Updated.
In addition, it is possible to obtain events at specific times.
3 of the included sample file (Motion event), there is a sample of a function that can catch specific events when they occur during an animation.
I am not sure about specific animation freezes.
If you have reproducible data, I would appreciate it.
It seems that the json output is missing the time key.
For example, if you look at spineboy-pro.json
The time following the "run" item has keys up to 0.8 ("time": 0.8), and its status is recorded.
And this is the EndTime.
In the file you gave me,
The key recorded in "04_walk_spec" that you are trying to play is
"time":0.6667
and it looks like there are not enough keyframes.
It is certainly conceivable that there may be times when you want to switch animations without animation completion.
Prepare an instruction that allows the animation to be changed without completion.
This was a point that I would not have noticed without actually working on the piece in depth.
Thanks for the report.
A new instruction has been added to clear the animation.
Here is a sample example of how it is applied.
http://ugken.com/ext/Spine/Test_spine.zip
It can be represented by a combination of "ClearAnimation" and "SetUpdate".
That is indeed the case.
However, it is difficult to make special changes to the composite animation behavior for channel IDs because it is part of the SpineSDK specification.
(If the animations manipulate the same material, the latter ID's animation is stronger and overrides the former.)
I think it is appropriate to deal with this in the way events are organized.
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)
-----
