Originally Posted by Baertram
Those RegisterForUpdate timers might be okay to update a counter showing on screen but they should not be used to run timers in general, where other ways are better. e.g. events fire or CALLBACK_MANAGER is available to register a callback function to run, or you can hok into Zos code to run your code befre/after it.
For example if you only want to react on real changes try my example code and just add your on screen information into that.
Instead of the
Code:
if currentBounty >= x then
else
end
add a
Lua Code:
d("Current bounty: " ..tostring(currentBounty))
and you should see the actual bounty in gold in a chat debug message.
Hope that works, have not tested it so far. |
Baertram - Thanks, I'm adding this to my "to read / to understand / to use" list.
I'm not yet seeing the triggers that will update as often as I want but the callbacks may have unseen surprises (ok, unseen, as yet, to me...) After reading through (some) of your helpful hints, my sense now is the bounty is continuously decreasing - which would explain the (current?) absence of triggers when something changes.
For now, I've folded in the timer-approach and it actually works reasonably well (in that updates do occur fairly often, no longer requires any other activity / intervention, the timer is useful [when needed], and polite [goes away when not needed]). The feedback that it provides a "quasi-realtime" bounty countdown seems to be generally positive. However, your point that "
they should not be used to run timers in general" is well taken. One (future) option would be to make the 15 seconds a configurable value, but I'd likely hold the minimum close to 15 just to avoid any onerous server loads.
For an interim solution, this seems like a decent balance. I have to remind myself: if it is truly a burden, it is limited to the duration of a bounty.
Thanks again for your help, I'll keep poring over your suggestions and learn more for the next update.
-V