Thanks for your answers.
@Pharan:
I understand your instinct, and yeah generally speaking I tend to rely too much on animation for my gameplay logic. That being said, if I want my character to go back to idle after attack, it seems okay to rely on attack's OnComplete event to do that job correctly (and once again, until now, it always worked out...). Actually, I don't even know how I should do otherwise :think: Except with an arbitrary timer..? Meh.
It does sound like AnimationState is doing what it's supposed to be doing: Whenever an animation reaches the end of its duration, even if it's fading out, Complete will fire. [...]
The question is, when is Complete when fading out desired or not desired, not just for your game but for most people's?
I'd gladly share my opinion on that: If I play an animation, I'm not expecting the previous one to send an OnComplete event in the background just because it was reaching its end, the fact that it currently does honestly defy all logic for me. Although I might not see the whole picture, it just instinctively feels wrong. By playing a new animation, I clearly state, as a developer, that I want to change the animation, so the next time OnComplete is called, it should be about THAT animation, not the previous one. So yeah, unless I'm missing something, I'd definitely suggest to consider that an animation that has been interrupted by another should not be able to send an OnComplete event.
I'm really not a fan to make change to the plugin as I think it's always more clever to respect and adopt the philosophy of the people developing it. You guys work hard on this, so if you don't agree with me, you probably have your reasons, and I shall try to work with your logic.
@Nate:
The complete event happens every time an animation has reached the end. For looping animations (like your idle, I assume) it will occur many times.
Yup, I'm aware of the event behavior, the doc is cristal clear, what I meant was: for me, the idle animation shouldn't ever send an OnComplete event after it has been canceled/replaced.
It is trivial to check if the track entry for the complete event is the current entry for that track.
I'm not sure I agree with that for my situation, but it might be because I've not figured out the whole thing yet :tmi:
Thanks for the heads up with queuing, I'll dig into that more, maybe I should rethink my whole transition logic using those.