There's something I've been calling "auto-reset". If you search for it here in the forums, you'll find many mentions of it.
"Auto-reset" is when the skeleton's state (all of its bones and slots and stuff) reset to the setup pose before playing a new animation.
Spine editor does auto-reset by default, but the runtimes don't. In fact, you have to code it in so you can playback things at runtime like you would expect in the editor.
The fact is that there are at least two solutions for your problem.
One is auto-reset: which is the simplest solution if you can code in Unity. All you need to do is handle AnimationState's Start
event with a skeleton.SetToSetupPose
. Here's what it looks like:
void Start() {
//...
var mySkeletonAnimation = GetComponent<SkeletonAnimation>();
var skeleton = mySkeletonAnimation.skeleton;
skeletonAnimation.state.Start += delegate { skeleton.SetToSetupPose(); };
//...
}
Note that your script here would need to keep its own field reference to skeletonAnimation, and for performance reasons, you might want to skip some member-jumping by keeping a reference to skeleton
too. You may want to look up how inline delegates actually behave (or are compiled) if you're not familiar with that or run into problems. Or just ask here.
The other solution is to add keys for the slots and the bones that you know are going to change at any point in all the other animations, like what @Shiu mentioned.
The difficultly here is maintenance, 'cause there's no telling what bones and slots you'd have to change (and how) in other animations. And you can't just keep going back to all other animations every time you decide to use a new bone or a new transform property of a bone.
And just keying them all for everything like position, rotation, scale, slot image, etc... (the same mistake many other animators have made) is a performance nightmare, especially if you're working on a character or thing that has a lot of bones and is spawned a lot of times in the game.
I think the question of why you have to do this yourself at all is a valid question. : p
The runtimes could easily have an opt-in, opt-out thing for it.