- Editado
Hey. Still a bit confused here. But after taking a closer look at the C# AnimationState class, I have a better idea of how it does things.
But there's this block in the SkeletonComponent.Update() method in the Unity runtime that I find peculiar:
// Keep AnimationState in sync with animationName and loop fields.
if (animationName == null || animationName.Length == 0) {
if (state.Animation != null) state.ClearAnimation();
} else if (state.Animation == null || animationName != state.Animation.Name) {
Spine.Animation animation = skeleton.Data.FindAnimation(animationName);
if (animation != null)
state.SetAnimation(animation, loop);
}
state.Loop = loop;
Based on the Spineboy example in Unity, the expectation is to change the value of the string animationName and this block takes care of changing the AnimationState accordingly (by calling SetAnimation for you).
But it seems like it would also negate any attempts to use AnimationState's methods like AddAnimation or ClearAnimation and it would also simply just stop the queue system from working at all, 'cause it would just give a higher priority to the string animationName and call SetAnimation based on it whenever (animationName != state.Animation.Name).
Should I/can I safely remove this block and not rely on the change-this-string-to-change-the-animation interface?
I might be missing something though.
UPDATE (June 2013):
Fixed since May 2013. SkeletonComponent has since been refactored as SkeletonAnimation and the new default expects you to call SetAnimation (which plays the animation immediately) or AddAnimation (which adds an animation to the AnimationState's queue), not change the string. The latter behavior is still available but it's slightly less efficient and also still makes AnimationState's queuing capability nonfunctional.