jhoferLNW2332 Skeleton setToSetupPose() method sets all bones, constraints, slots, and draw order to their setup pose values, so it should be possible to reset them by this. Disabling and enabling GameObjects alone does not call setToSetupPose(), so I think Spinebot's answer was confusing on that point.

For your information, resetting the physics constraints to their setup poses can also be done individually: PhysicsConstraint-setToSetupPose

jhoferLNW2332 As suggested in the Related Discussions section, I think the following thread may be helpful: https://esotericsoftware.com/forum/d/26747-issue-with-spine-animation-becoming-gradually-slower-after-long-play-sessions

However, we have not tested many cases where physics are used and the animation plays for a very long time like yours, so if your problem persists after consulting Spinebot's answers and the thread above, we would appreciate it if you could create a minimal Unity project that can reproduce the problem and email it to us: contact@esotericsoftware.com
Please include the URL of this forum thread in the email so we know the context. Then we can take a look at what's wrong.

jhoferLNW2332 There is an example of using both StateMachine and SkeletonAnimation in the example included with the spine-unity runtime, so please take a look at it: Spine Examples/Other Examples/StateMachine SkeletonAnimation/Mecanim Logic SkeletonAnimation View.unity

Here's what it looks like when you play back the example scene:

The example scripts (DummyMecanimControllerExample and SkeletonAnimationHandleExample) attached to the Hero GameObject have many comment lines explaining how it works, so please refer to them for more information.

jhoferLNW2332 Myself and our artists have noticed that in the Unity inspector window of a spine asset

By "a Spine Asset" I assume you mean the SkeletonDataAsset and not e.g. an AnimationReferenceAsset.

In general, the Unity Editor update cycle is not consistent and reliable enough to be used as a high-performance view. As a consequence, the Inspector preview is not intended for precise analysis. See it more as a tool showing animations so you know which name is which animation. In general the preview-playback is using the AnimationState API in a standard way, just at a low variable framerate.

The discrepancy you're observing between the Unity inspector preview and the Spine preview window is a known issue. The Unity inspector preview for Spine assets uses the Spine Runtime to render animations, which should ideally match the runtime behavior in your game. However, there are some limitations and differences in how Unity's editor API handles these previews, especially when using Mecanim.

The preview window in Unity does not use Mecanim under the hood; it uses the Spine Runtime directly. This means that while the preview should be similar to what you see in the Spine editor, there can still be differences due to how Unity handles animation states and transitions. The jerky interpolation you're seeing might be due to these differences or specific settings in your Unity project.

For the most accurate representation of your animations, it's recommended to test them in Play mode within Unity. This way, you can see how the animations will behave in the actual game environment, including any transitions and blending that might not be accurately represented in the preview window.

For more detailed troubleshooting, you might want to check if the issue persists with different SkeletonDataAssets or if there are any specific settings in your project that could be affecting the animation playback.

Pentacles As Spinebot replied, this is actually the behavior that was changed because it was problematic. This change was added in 4.1.14:
https://esotericsoftware.com/spine-changelog#v4-1-14
(What you call the "green key" is actually called the Key shown button.)

Here is the issue ticket when we fixed this behavior:
EsotericSoftware/spine-editor712

By the way, did you know that it is not recommended to use the deform key very often? It appears that you are animating a large number of clipping attachments with the deform keys, but I would recommend instead that you bind the clipping attachments to bones and animate them by transforming the bones. See the following section of the User Guide for more information on why using deform keys is not recommended:
https://esotericsoftware.com/spine-keys#Deform-keys

Yep! It's not invalid and exports will work fine now. However, that vertex is not generally useful, so a warning about it is output when exporting (with a clearer message). There is no longer a warning when doing import project. You can ignore the warning (or uncheck Warnings) or have the animator delete the vertex or move it inside the hull in edit mesh mode.

Thanks for the project files. The warning occurs because this mesh has an internal vertex outside the hull:
 Loading Image

It is only a warning, so everything is the same as it has been -- the project isn't damaged and nothing was changed due to this warning. However, in 4.2 the binary format relies on the triangulation having a number of triangles based on the number of vertices. Exporting your project to binary will give a file that can't be read by runtimes.

While it's not illegal, it's not generally useful to have an internal vertex outside the hull of a mesh. To be honest, it's so rare we overlooked that this could happen. We added the warning just to be sure a flag was raised if a project somehow had the wrong number of triangles.

In 4.2.05 we've fixed the binary export and we'll improve the warning, and probably add a warning when exporting.

Yes, you can email the Spine team to get assistance with your issue. Please send your project file to contact@esotericsoftware.com, explaining the steps you took and the error message you encountered when upgrading from 4.1 to 4.2. The Spine team often requests project files to diagnose problems, suggest fixes, or identify bugs. Make sure to include details about the incremental saves where the upgrade method worked and where it subsequently failed, as this information could be crucial for troubleshooting the problem.