SoulKarl escribióEDIT: I for sure misread what you had said haha. Added the update followed by the apply and it seems to work! Would still be interested in hearing more about how to implement the handler skip though.
The technical term is reentrancy. Making your function reentrant is just the code I posted. The handle
function is your event handler. You use a boolean variable to know that you should disregard your handler function being called when apply
is called inside your handler function. If you have multiple handler functions, you should use the same boolean for all handlers, so they all know to disregard the event when any of them calls apply
. Note you don't need the boolean if you use the update
solution.
SoulKarl escribióAlso, I mentioned before I have blinks and talks triggered by 2 separate events, and in this instance they trigger at the same time. Is it okay to call that 0.0001f update and the apply in 2 different functions called at the exact same time?
Yep.
SoulKarl escribióWould the end result just be that it works but fastforwards 0.0002f?
Yep. Calling update(0.0001f)
advances the animation time 0.0001 seconds. It won't be noticeable at 0.0002 or even 10x that at 0.002 seconds.
SoulKarl escribióAlso how granular can I actually get with the update time? Is 0.0001f the smallest interval we update on?
The animation time is stored as a float
type. The minute details about how floating point works are extremely complex. Don't try to push it to the extremes, as it will almost always not behave as you expect.
In a nutshell, the larger the number you have, the less precise it can be. The smallest value you can store in a 32-bit float is 1.4e-45
, which means move the decimal left 45 decimal places (an extremely small number). However, if you have 10
you cannot add that tiny number to it. If you try, the result will be 10
. This is because 10
is a bigger number and therefore there is less space in the 32-bit float to store such a precise value. The next largest value you can store after 10
is 10.000001
. The doesn't mean you can just add 0.000001
to any value. If you had 1000
the next possible value is 1000.00006
. To make it even more fun, you also can't necessarily trust that these are the exact values on every computer your code could run on.
The moral of the story is just to be as precise as needed with floats.
SoulKarl escribióAlso I'm assuming by the fact we can update at such a small % that the updates are called far more frequently than once a frame,
No, update
is normally called once per frame. The value passed is the time in seconds since the previous frame.
SoulKarl escribióso I guess my earlier question about just moving the triggers one frame earlier in the animation won't actually solve the problem?
The problem is you set new animations, but don't apply them. The problem will occur on whatever frame you have the event keys.
SoulKarl escribióCheers and thanks for all the help!
Sure, no problem! I'm just happy you didn't find obscure bugs that we have to fix. 😃