Oh no, please don't look at AnimationState! :yuno: If you find any bugs, they tend to be difficult to reproduce and fix! :p
When animation A finishes and triggers the complete handlers, from within that handler function animation B is started with setAnimation(). But for some strange reason this triggers the interrupt event, while the animation was never interrupted, but finished. Otherwise the complete event should never be fired.
The complete event doesn't mean a track entry is finished, it means it completed one loop. If the track entry is looping and you let the animation play, you'll see the complete event again and again.
In your scenario the animation A was indeed interrupted, meaning another entry (animation B) has replaced it as the current entry for the track. When any mix duration is finished, you'll see for animation A an end event (because it will not be applied anymore) and then a dispose event (because everything is done with the track entry object and it may be reused or the memory freed). That covers all the events except start, which happens when the track entry has become the current entry for a track.
You mentioned addAnimation and setAnimation, but the interrupt event should happen for both
any time the entry is no longer the current entry. If you've reached the animation duration (and you have if you've seen a complete event) then addAnimation and setAnimation should be equivalent (should be, they are slightly different code paths).
Here's an interesting tidbit: TrackEntry events are collected during AnimationState update and AnimationState apply and fired only after those methods are finished. I'll add this note to the documentation. It means that if you make changes in an AnimationStateListener, the collected events are still fired, even if your listener makes changes, like clearing a track. This can be a surprise
you can set an animation or clear a track (from listener code) and afterward you may still get some events for the old track entry that is no longer the current entry for the track. If you come across this, you can check if the track entry for the event is the current entry for the track. In some cases it doesn't matter (eg to turn off particle effects) but in others it might (eg if you are setting the next animation in a sequence, you probably only want to do that when the event is for the current entry).
The events are collected and fired later as described because if we fired them in the middle of update or apply and your listener code called other AnimationState methods, it could change the internal AnimationState state, make for difficult to solve problems.
spineappletree wrotemax amount of chars in the title of threads
We didn't change this recently, but I never noticed. I suppose I rarely post new threads! Looks like it's 60 characters. There's no setting to increase it so we'd have to hack up the forums. We can do that, but not right now since we've got things going on and more effort is needed to see what might break, if the DB has a limit, etc. You'll have to be creative and concise with your titles! 😉
