Unfortunately we are limited here by the Mecanim API providing playback time information, which does not seem to include or expose any cycle offset. For more details see this posting here:
Offsetting spine animation with cycle offset

PeterBacall написал

Thanks for the quick reply! What about the "Motion Time" parameter (in the animator state inspector), I think it's the "normalizedTime" https://docs.unity3d.com/ScriptReference/AnimatorStateInfo.html, I'm not sure but Motion Time used to be named "Normalized Time" in the inspector way back.

The SkeletonMecanim component uses AnimatorStateInfo.normalizedTime already to determine the animation playback timepoint:
https://github.com/EsotericSoftware/spine-runtimes/blob/4.1/spine-unity/Assets/Spine/Runtime/spine-unity/Components/SkeletonMecanim.cs#L267
If your modifications have no effect, the problem is as described earlier, unfortunately we are limited to what the Mecanim API provides as playback time.

Edit, more clarification: If I add a parameter now, I get those errors (the first post). But it should be able to work?

State "Aim Down" in Controller "Character Controller" uses parameter "" which does not exist.

If Animator.Rebind() causes the above error, perhaps your Mecanim state machine has not been saved, or something similar. Does that also happen after saving and if so, after closing and reopening the asset or the Unity Editor as a whole? In general there is no reason why adding parameters to the state machine should be incompatible with SkeletonMecanim.

I just tried it myself, strangely it seems that setting Motion Time via an Animator parameter has no effect, not even on the blue progress-bar in the playback preview of the Animator window. Admittedly I don't know what else could be done about it, as on the Unity forum users describe to have working solutions with just the above setup. If you would like to spend more time on this, you could have a try if a normal animated 3D asset shows is affected by set Motion Time and if perhaps just the blue playback progress-bar displays incorrectly.

If switching from Mecanim is an option, we highly recommend using the SkeletonAnimation AnimationState API instead of the Mecanim API, which allows you to customize any time offsets reliably.

PeterBacall написал

Unfortunately I have no experience with 3D, but will try to find an asset and check. But the SkeletoMecanim is definitely not updating correctly, or it’s events.
[..]
Thank you for looking into it. In your opinion, should I move on and forget about it or is there a plan to try and fix it?

The problem is that SkeletonMecanim can only update to the information it receives. Here Mecanim is either used incorrectly to set the motion offset (and the blue progress bar in the Animator window is correct), or it is used correctly (it would animated a normal 3D or 2D animation asset correctly) and does not forward the relevant data. If it does not forward / provide the required data, we're out of luck on our side with SkeletonMecanim.

[Edit:] Since you said you have no experience with 3D: To find out if it would work in general I only mentioned testing with a 3D asset, but you can as well use a 2D Unity asset, any standard asset that can be used in a Mecanim controller for testing purposes will do.

Thanks for sharing your findings!

PeterBacall написал

Testing the Skeleton Mecanim, it seems to ignore whatever I input to the Motion Offset, the events are fired randomly instead of where they should.

Events firing randomly is something I haven't yet encountered (or noticed). I assume that you saw the animation playing back from the start (ignoring any offset) all the time, is that right? Or did you also see the animation playing at random offsets?

Sorry for the late reply.

PeterBacall написал

Yes, the animation was playing from the back, but the events were fired out of order (not where they were placed).

Hm, this is unfortunate, I'm afraid there is not much we can do on thye spine-unity side then. :wounded: