- تم التحرير
How should I debug this in Spine 3.5+?
As I understand it, there's no longer 'lingering' elements, right?
Each animation only continues to apply changes to the state of the spine object as long as a track has that animation active within it.
Otherwise, it mixes out and back to the setup pose, right?
Then what should I do to Diagnose this:
When I use Binary Cat's Spine TrackEntry debugger, it only shows me one track running on the character.
Switching to other animations, it looks correct and that specific animation also looks correct part of the time when it is triggered. 
You didn't explain what you are doing, what you expect to happen, and what actually happens.
Argh. Thanks.
Tl;dr - her Spine game object is in the right spot. (0,0 relative to the body) .
The body (green boxes that are not diagonal) are in the right spot.
However, for some reason, one of her bones is shifted down a lot of units. It only happens sometimes and not others.
I can't figure out why any animation track would still be holding onto changes to the skeleton based on the 3.5 dipping debacle.
25 Dec 2016, 04:21
Oh - and her hand should be holding onto the ledge, which is what happens instantly the moment she begins to transition to another animation.
bcat's viewer isn't a mixing debugger. It doesn't show mixing states.
Ok. Where should I be looking to figure out what's going on?
Letting the animation loop, it never 'mixes away'.
Try in Skeleton Viewer and see if you can reproduce the problem by playing one animation, then another. If you can, send us the JSON so we can see the problem. If you can't reproduce it, try to reproduce it consistently in Unity. If you can do that, make a copy of your project and remove everything unrelated to the problem. Post or email this SSCCE and we can dig into why it is happening.
If you suspect the moved bone is because of an old animation, can you confirm one of the old animations is moving that bone down and leaving it there?
You can try this script to also see the mixing state in AnimationState. https://gist.github.com/pharan/a6726f69f7832b02b740c673c039ce7f
Just add it to the GameObject with your SkeletonAnimation.
This is somewhat similar to the mixing information you see in SkeletonViewer.
26 Dec 2016, 03:48
The same animation, but this time playing correctly.
And for sanity, the location of the transforms in unity:
First
Second
Do you know which bone it specifically is? That will probably tell you what animation is moving it and when.
The Advanced... foldout has a new "Show Bone Names" checkbox if you don't know.
Apart from that, try doing what Nate said.
You should be looking for the specific sequence and timing of animations that causes the bug.
And are you using that modified AnimationState.cs to avoid the dip?
Yes, I am using the modified animation state to avoid the dip.
Also, I don't know which bone it is - or which animation is leaving it modified - or I wouldn't need to debug it. :rofl:
The worst part is I can reproduce which in-game motions cause the bug 100% of the time - but in both cases, the same animation sequence is run... but with very slightly different timing, which makes this frustrating.
26 Dec 2016, 23:11
Yep, the checkbox helped - its a bone called the 'TranslateBone' - used to do root-motion type things. I sample the movement of this bone, subtract it out from the model, then apply it as a velocity to the character.
It appears that if the transition (mix) from the jump rising to jump falling animation is occuring when I trigger the 'Grab Corner" animation, it correctly sets all of the bones to the right positions.
If I trigger the Grab Corner animation while only one or the other is playing, the bone remains in the position it was in during the previous animation.
I need to tweak @BinaryCats editor, but you can see here - the first "Mantle High Idle" is the scenario where it worked - while the second is the case where it was broken. Same animation sequence.
27 Dec 2016, 08:28
Yay.
Fixed it by setting a key on the animation that was looping.
Still not sure why its value was persisting, but this works for now 