Agreed, we'll make those changes to the API reference!
Strange behavior after AddAnimation on Empty track under special conditions
Doing a huge refactoring and have a question regarding setEmptyAnimation.
From docs: A mix duration of 0 still mixes out over one frame.
So what is the best way to mix directly the next frame without calling Update(0)?
Calling ClearTrack is not what I want, I want to directly mix to setup on a specific track right the next frame. What am I missing now? 
@abuki Thanks for pointing out the exact misleading passages.
Regarding 1:
Yes, please note that track and track entry may sound similar, but are as different as road and car. An empty car on a road is not the same as an empty road.
This in general applies to all our documentation, we strive to choose the wording as technically precise and short as possible, we never use "approximations" just to sound better. In your case I assume that you missed the important documentation about what the empty animation is, so that might be the main cause (which we are trying to improve).
Regarding 2:
We're improving the spine-unity documentation currently in this regard (it's updated and improved, but not yet final):
https://esotericsoftware.com/spine-unity-main-components#Setting-Animations
https://esotericsoftware.com/spine-unity-main-components#Empty-Animation-and-Clearing
We hope that these changes prevent such misunderstanding and missing important documentation sections in the future.
abuki To mix back to the setup pose, set an empty animation with no mix duration. The note about needing one more frame when mix duration is zero is trying to explain that it will take one more apply to do the mixing out, and then the update after that will be able to "end" the track entry (the end AnimationStateListener event).
You don't normally need to worry about this. You just set the empty animation and continue on as normal.
4 gün sonra
Hi again, this is on very similar topic. My default mix duration is set to 0.1 on the asset:
private void Start()
{
skeletonAnimation.AnimationState.ClearTrack(0);
}
private void Update()
{
if (Input.GetKeyDown(KeyCode.K))
{
Debug.Break();
skeletonAnimation.AnimationState.SetEmptyAnimation(0, 0);
skeletonAnimation.AnimationState.AddAnimation(0, animationReference, false, 0f);
// The added animation starts at track time 0.14, how to force it to 0 or 0.04 or anything similar?
}
}It works fine when default mix duration on asset is 0
The animation always starts at track time 0. Do you mean the first time the animation is applied the track time is already at 0.14 seconds, so you don't see the first 0.14 seconds of the animation? I'm not seeing that with:
state.getData().setDefaultMix(1f);
state.setEmptyAnimation(0, 0);
state.addAnimation(0, "walk", true, 0);Nate Do you mean the first time the animation is applied the track time is already at 0.14 seconds, so you don't see the first 0.14 seconds of the animation?
Yes.
For some reason, it works fine for default mix = 1 or 0. Tried your code (in Unity) and was playing with the following:
skeletonAnimation.AnimationState.Data.DefaultMix = 0.1f;
If you set the default mix to anything between 0.01 and 0.99 this mix duration is added to the animation time at the start of the animation. The same happens if you set it to e.g. 1.2, but in that case only 0.2 is added.
I am seeing this in a basic script I posted above, no special conditions project specific.
I am also playing it with animation that is non-looping (seems it is not relevant) and is longer than 2s (not sure how long is your walk loop).
The beta won't be considered stable until it's no longer beta. Can't say yet when that will be.
We might backport this fix to 4.2, as it's pretty nasty. I'll check with the team.
Well, to sum it up. I removed all calls to Update(0) and refactored these places to with better understanding what Spine is doing. So it is not a black box anymore for us. Thanks for helping me with that! Now a lot of things seem obvious, but e.g. playing empty animations for proper mixing is nothing easily understandable.
And still, I found a runtime bug
Next time I will directly try to isolate and understand what is going on instead of quickly hacking it with Update(0) call.