Hello

I am using the latest unity runtimes + new animationstate from pharan (question in runtimes because more of a runtime design question)

there are a few wierd behaviours that I have not noticed in other runtimes, or just didn't happen and I'm not sure which.

Firstly, The complete event fires after every loop.

Also, the interrupt event fires after the complete event on a non looping animation.

The below code is a check for when an animation ends:

private void AnimationComplete(TrackEntry trackEntry)
{
    if (!trackEntry.Loop)
    {
        m_History.Add(new EntryData(trackEntry, Time.time, Time.time - trackEntry.TrackTime));
        m_MoveScrollpos = true;
    }

}
private void AnimationInterupt(TrackEntry trackEntry)
{
    if (!trackEntry.IsComplete || trackEntry.Loop)
    {
        m_History.Add(new EntryData(trackEntry, Time.time, Time.time - trackEntry.TrackTime));
        m_MoveScrollpos = true;
    }
}

note the convoluted checks to see if it really fired (I had to repeat this pattern a lot when I upgraded the runtimes)

So my questions really is, should the complete event fire on every loop of an animation, should the interrupt event fire after a complete event? And is there a better way to get when an animation end? (not End event, as that fires too late, iirc depending on the mix)

Ah, its strange how this hasn't come up before now :s , the track end time has just exposed this design.

I would say an animation ends when the data gets added to the m_history above. there are a few times where we want something to happen to a gameobject when an animation completes/interrupted, but there isn't an event for that, you have to do use hook into both events and do the above checks.

but complete also fires when the animation is played fully, and then the queued animation will will.
how do you know the difference?

I thought, interrupt only fires if the animation was unable to complete because a new animation was set on the track.

setanimation("a",0,false);
addanimation("b",0,false,nodelay);//a->b mix = 0

complete will fire just before/sameframe as "b" starts
interrupt will not fire as "a" was allowed to complete

setanimation("a",0,false);
//wait 1 second
setanimation("b",0,false);//a->b mix = 0

complete will not fire because it did not complete
interrupt will fire as "a" was interrupted by "b"

this is how I thought it worked. Maybe that changed with the latest runtimes, because trackend is #inf, so a completed animation would also be a interrupted animation.

ah it seems you are correct, listening to complete is pointless, I should just listen to interrupt and that catches all cases except trackend and cleartrack. Those two exceptions would explain bugs we have been having!

I feel we should be using these events more in our codebase (to be fair). but legacy systems are a bitch to change. currently we check for animations like this

public bool IsAnimationPlaying(int track)
{
    Spine.TrackEntry entry = m_Animation.state.GetCurrent(track);
    return (entry != null && ( entry.Loop ||  !entry.IsComplete ) );
}

(it use to be a null check but now trackend is big the two other checks are needed

public bool IsAnimationPlaying(string name, int track)
{
    Spine.TrackEntry entry = m_Animation.state.GetCurrent(track);
    if (entry != null)
    {
        if (!entry.Animation.Name.Equals(name))
            return false;
        else if (entry.loop)
            return true;
        else
            return !entry.IsComplete;
    }
    else
        return false;

(eww string checks)

Pharan ha scritto

How else can it be done?

Need a link between the data (animation name, set in editor) and the trackentry. I didn't think string.gethashcode() would be guaranteed because its compiled separately

that would be a pain in the ass to do because of the previous implementations :bang: I have thought about doing it before though

We also sometimes want to wait until an animation is playing, :bang: Basically I want to re-write our spine implementation as is wasn't written by me lol

I guess I could do a check trackentry.animation rather than trackentry though :wonder: