- Modificato
How to set an event on the exact last frame?
Hi,
I need to trigger things on the completion of an animation which is created at runtime. However, the animation names are 'complex' and that makes it not easy to filter the type of animation.
It's way easier to just fire a 'animation-complete' custom event on the end of some of these animations.
However, when setting that custom event at the duration of the animation it doesn't (always) get fired. Which obviously makes sense, as it's just outside the duration of the clip.
So now I need to know how to set the event on the exact last frame of the animation while still being 100% sure it ALWAYS gets fired, so never skips.
Is that possible? How can we reliably set an event on the exact last frame of an animation which always gets fired when the end is reached? (without expanding the duration of the clip)
An event on the same frame as the animation duration should always be fired. If it's not, that's a bug we should fix.
We have some unit tests for events and AnimationState (which also tests events) that cover this scenario, unless you are applying your animations differently from the tests in some way.
If there is a bug, what we need to fix it is code that reproduces the issue. You could use our test.json that has the events on frames 0, 14, and 30 then write code that applies that animation in the same way you do, but using a fixed time step so the failure is repeatable. For example if you are using AnimationState, something like this pseudo code:
AnimationState state = ...
state.setAnimation(0, "events0", false);
state.apply(skeleton);
state.update(0.1f); // time step
state.apply(skeleton);
state.update(0.1f);
...
// Whenever the event should be fired by the next update:
state.addListener({
event: function (entry, event) {
print("fired: " + event);
}
});
state.update(0.1f);
If you can show the event doesn't fire when it should, then we can figure out what's going on!
Thanks for your response and extended information Nate. The project I'm working on has a tight deadline, so before receiving your post I decided to switch to using the build in complete-event, so skipped the custom event at the end that was having issues. I decided to solve it with regular expressions on the animation names and in the end it was way easier than I initially thought it would be and works fine with the standard spine complete-event now. I'm using pixi-spine btw.
It's good to know that setting a frame on 'duration' seconds should indeed work. That's the most easy way to do it. Well if it works of course.
Because of the deadline I don't have much time to do more testing at the moment, but if I find the time I will later, because it's obviously important we can rely on events being fired!
Thanks again for your quick and helpful response. I have it bookmarked for when there's more time.
Totally understable, thanks! If you get a chance to reproduce it, we're here to take a look.
I hate throwing a problem back at users for them to figure out, but from what I can tell it should be working and I'm not sure what you've got different going on. If you apply the animation to its duration or past that, any events on the last frame should fire before the AnimationState complete event.
After working my way through Spine events intensively for the last days and creating a test project showing all events and when what fires, my conclusion is I probably either made a mistake somewhere in the old code of the project I talked about in this thread (before I renewed it), or it was my lack of complete understanding of the event system at that time (for instance the fact that complete events DO fire when mixing, but custom 'last-frame' events are not per default, which was confusing to me). While doing tests with the created events test demo I always saw the 'last-frame' event being fired when not currently mixing, so it worked as expected in the test/demo.
I'd say this one can be closed. Thanks again for your help Nate. I appreciate you taking the time! This week I definitely learned a thing or two about Spine events and that's valuable! Keep up the great work.
Great, glad it's working as it should now! No problem, glad to help. Most of all I'm glad we don't have any AnimationState bugs to fix.
Nate ha scrittoGreat, glad it's working as it should now! No problem, glad to help.
Most of all I'm glad we don't have any AnimationState bugs to fix.
haha, yeah, that's a stroke of luck!