Go to Page... |
|
Thread Tools | Display Modes |
07/19/22, 01:54 AM | #1 |
[notabug] Is EVENT_MANAGER:RegisterForUpdate still working?
Hi all,
Since yesterday's (18/07) patch I have function calls through EVENT_MANAGER:RegisterForUpdate not working anymore, replacing them by direct function calls or zo_callLater works. Lua Code:
Can any other dev confirm/disconfirm ? |
|
![]() |
07/19/22, 02:41 AM | #2 |
Seems to work normal for me.
![]() You can simply test it with a blank addon and disable ALL other addons and libraries: Lua Code:
Last edited by Baertram : 07/19/22 at 02:47 AM. |
|
![]() |
07/19/22, 02:47 AM | #3 |
Was just preparing this reply, then Baertram replied.
@Masteroshi430 it's interesting that you say zo_callLater works but EVENT_MANAGER:RegisterForUpdate doesn't: in the esoui-8.0.8 source code, file libraries\globals\globalapi.lua shows zo_callLater is implemented using EVENT_MANAGER:RegisterForUpdate. Lua Code:
|
|
![]() |
07/19/22, 02:51 AM | #4 |
Yeah, that too. Would have been a very big suprise if the one works and the others doesn't
![]() You probably have a bug in your code then which will unregister the eventUpdater (seach your code for "FyrMiniMapPOIPinsD") or some other error occurs which will make your function never be called. If not doing this already enable LibDebugLogger, DebugLogViewer and check messages that show after login/load of the addon/after reloadui that won't show with normal d() messages (as the d() messages will only show after event_player_activated as the chat was initialized and addons like pChat or LibDebugLogger also catch those messages). |
|
![]() |
07/19/22, 03:02 AM | #5 | |
I will check code with unregisterforupdate. ![]() |
||
![]() |
07/19/22, 03:24 AM | #6 |
Sounds like your code on live was "buggy" before the live update then already and the bug triggers "only sometimes".
I know these kind of bugs. Either it's a typo somewhere ![]() |
|
![]() |
07/19/22, 09:46 AM | #7 |
Are you calling DelayedPOIPins repeatedly? Cause if so, you'd be re-registering repeatedly, which would keep reseting the delay clock, making it never ultimately fire.
There was a change to RegisterForUpdate recently (to account for a crash) that could result in some changed behavior if you were previously relying on subsequent calls to RegisterForUpdate (without an unregister first) to simply "drop on the ground silently." Now calling RegisterForUpdate again "replaces" whatever is currently registered (including replacing the delay time), rather than silently dropping it on the ground if something is already registered. This can mainly cause weirdness for anyone who was doing the register on a loop, which is not really something you should be doing anyway. |
|
![]() |
07/19/22, 11:40 AM | #8 |
With this changes done, maybe I totally missunderstand your post, but what happens differently now?
If I got a function that was using RegisterForUpdate to e.g. register an inventory refresh via updaterCallbackFunction() after 50ms with unique identifer "UpdateInv1". And after 10ms another RegisterForUpdate for the same inventory refresh using same unique update identifier "UpdateInv1" with 50ms comes in, without unregistering the first updater: Will it overwrite the updater "UpdateInv1" and reset the timer to 50ms again, so that the registered updaterCallbackFunction() is called 50ms after the 2nd RegisterForUpdate was done? Or will the 1st registered "UpdateInv1" call the updaterCallbackFunction() after the 40ms left have passed then, and the 2nd registered "UpdateInv1" will fire after 50ms too? In the past "UpdateInv1" was overwritten and the timer was reset to 50ms. The 1st registered "UpdateInv1" was never triggered, and the 2nd "UpdateInv1" was triggering updaterCallbackFunction() after 50ms then. |
|
![]() |
07/19/22, 12:08 PM | #9 | |
So the new rule for RegisterForUpdate is : - Always unregister before registering again otherwise the new register replaces the previous one with it's own milliseconds value restarting from scratch. Am I right? I will try to see what I can do. Thanks Dan! |
||
![]() |
07/19/22, 04:19 PM | #10 | |
Register updaterCallbackFunction() to "UpdateInv1" with an interval of 1000 After 200 ms, Register updaterCallbackFunction() to "UpdateInv1" with an interval of 1000. (Original registration is now gone.) After 1000 more ms (1200 ms total elapsed), updaterCallbackFunction() will get called for the first time. Calling RegisterForUpdate again with the same identifier will replace everything and reset the timer. You're incorrect though about the "in the past" behavior. In the past, the behavior used to be this: Register updaterCallbackFunction() to "UpdateInv1" with an interval of 1000 After 200 ms, try to register updaterCallbackFunction() to "UpdateInv1" with an interval of 1000. This request just gets dropped on the ground completely, because "UpdateInv1" is already registered. After 800 more ms (1000 ms total elapsed), updaterCallbackFunction() will get called for the first time. In the past, you couldn't replace the function or reset the clock. Again, trying to register again would previously literally just abort because something is already registered. Now, it's a replace and reset. In the past, if you wanted to replace the function or change/reset the interval, you had to manually UnregisterForUpdate the identifier first. |
||
![]() |
07/19/22, 04:25 PM | #11 | |
Calling this every frame will result in myFunction() never getting called, because it will reset the clock every frame, and 50 ms never gets to elapse enough to fire the function. Code:
EVENT_MANAGER:RegisterForUpdate("MyIdentifier", 50, myFunction()) Code:
EVENT_MANAGER:RegisterForUpdate("MyIdentifier", 0, myFunction()) |
||
![]() |
07/20/22, 12:34 AM | #12 |
I think I understood the problem in that precise case:
A function called with EVENT_MANAGER:RegisterForUpdate was calling another function with EVENT_MANAGER:RegisterForUpdate so this made a loop inside the loop, calling the 2nd function with zo_callLater avoids the unnecessary loop. I don't know if it is possible but can EVENT_MANAGER:RegisterForUpdate return something like a warning in case the timer of a function with the same identifier is repeatedly reset and never really triggers? |
|
![]() |
07/20/22, 03:50 AM | #13 | |
Alright, thanks for the details, very appreciated!
I think I always used an unregister before registering a new update task, so it should work the same for my code ![]()
|
||
![]() |
07/20/22, 09:51 AM | #14 | |
The other reason I didn't add the return is because if you call RegisterForUpdate from within some other update function, we actually delay the registration until the end of the frame, because we don't want to insert an update registration in the middle of us looping through all our existing registrations, potentially causing some kind of mismatch or desync of behavior. So technically, when that happens, you haven't actually overwritten anything yet. Most of the time this wouldn't manifest in a way anyone would even notice. But you could set up a situation where it would matter: We register UpdateA and UpdateB. This frame, UpdateA starts running its function. As part of that function, it happens to meet a condition to overwrite the registration for UpdateB. Since we're in the middle of processing all the update functions, we queue that overwrite up and keep going. We then run UpdateB, which is still the old UpdateB. Then, after that's all done, we overwrite UpdateB, and next frame, when UpdateB runs, it'll be the new overwritten behavior. |
||
![]() |
07/20/22, 12:04 PM | #15 | |
![]() |
||
![]() |
ESOUI » Developer Discussions » Bug Reports » [notabug] Is EVENT_MANAGER:RegisterForUpdate still working? |
«
Previous Thread
|
Next Thread
»
|
Display Modes |
![]() |
![]() |
![]() |
|
|