Hi Pharan,

This seems to work! Thanks for your quick replies and your commitment to support.
Much appreciated.

Cheers
GP

Hi,

If you repeatedly prevent a mix from completing, it may look a little snappy when you disallow the mix to not proceed, but the unintended setup pose mix SHOULD be gone.

This is exactly what I'm seeing. To be honest, it doesn't look acceptable. It's very obvious.

Is this an edit of the official AnimationState or the modified one?

Hi,

edit: Initially I only wrote here about our issue with modified AnimationState.cs but since the mixing problems are different between regular and modified I decided to elaborate.

Using the official AnimationState.cs:

1. Idle animation loops. (no input)
2. Input happens, mix to walk (0.2s)

At this point I can see the setup pose being mixed with our walk.

Using the modified AnimationState.cs that was recommended here ( Blend Weirdness in Unity 3.5?).

We're seeing issues when mixing our player character skeleton:

1. Idle animation loops. (no input)
2. Input happens, mix to walk (0.2s)
3. Within the mixing window input stops ( < 0.2s), we mix black to idle.

At this point, we see blending from the setup pose to idle instead of whatever pose the skeleton was in mid-mix.

For both situations, the questions are the same:

1. Why is it using the setup pose? We never want to see the setup pose at all.
2. How do we fix this? I'm considering the Unity runtime broken at this point. we can't use it.

Thanks.

Hi,

Either I've found a bug or am not quite understanding of what's going on.
Issue is this, when I call this method on AnimationState:

public TrackEntry AddAnimation (int trackIndex, Animation animation, bool loop, float delay)

with the delay parameter set to 0, according to the comment and documentation it should calculate the proper delay time based on the previously queued animations.
However, this didn't seem to be working for me. After some investigation I found that this line:

delay += duration * (1 + (int) (last.trackTime / duration)) - data.GetMix(last.animation, animation);

can generate delay times that are negative (less than 0).

The result of that is that those animations that should be queued aren't played at all.
Since I'm not intimately familiar with the Spine codebase, my quick fix has been to add parenthesis to avoid ever generating negative numbers:

delay += duration * ((1 + (int) (last.trackTime / duration)) - data.GetMix(last.animation, animation));

I'd like to know if this is a bug and how to properly fix this.

Thanks.