What is the benefit compared to the existing timer functions (RegisterForUpdate, RegisterForUpdateGameTime) ? Multiple timers would only make sense if there is a timer id, so I can identify which timer was triggered: SetTimer(intervall, myID) RegisterForTimer(myID,callback)
Or even better: timerID = SetTimer(intervall, callback) PauseTimer(timerID) ContinueTimer(timerID) StopTimer(timerID)
And a guarantee that it is thread safe : what will happen if the callback processing takes longer than the intervall? Is the callback called in a paralell thread, is it stacked, is it dropped?
As a modder I whish to be able to control if it is stacked or dropped because I see uses cases for both variants. Example:
The benefit right now is only for convenience. The idea came because someone asked in the forums how to do multiple timers on the same script. https://forums.nexusmods.com/index.php?/topic/11503763-multiple-registerforsingleupdategametimes-on-one-script/ . If you look at the example script provided, you can differentiate timers, but by object and not by ID.
The timers are threaded as they use mod events. What this does is create a new object reference using placeAtMe, then attaches the TimerObj script to it via ConsoleUtil. The TimerObj script still uses RegisterForSingleUpdate and RegisterForSingleUpdateGameTime, but with OnUpdate it sends a mod event that your main script registers for. You could also use separate events for each timer you create if you wish.
Hey, yes Events are still called on the TimerObj even after the parent cell is unloaded. Also, it appears that mod events are persistent, I didn't have to re-register after loading a game. I tested by starting a gametime timer for 1 hour, saving then quitting to desktop, then loading the save and waiting an hour. The event still triggered.
11 comments
Multiple timers would only make sense if there is a timer id, so I can identify which timer was triggered:
SetTimer(intervall, myID)
RegisterForTimer(myID,callback)
Or even better:
timerID = SetTimer(intervall, callback)
PauseTimer(timerID)
ContinueTimer(timerID)
StopTimer(timerID)
And a guarantee that it is thread safe : what will happen if the callback processing takes longer than the intervall? Is the callback called in a paralell thread, is it stacked, is it dropped?
As a modder I whish to be able to control if it is stacked or dropped because I see uses cases for both variants. Example:
SetStackedTimer(1min,updateStats)
SetDropableTimer(6h,eating)
SetDropableTimer(3h,drinking)
Better naming required :-)
More open questions:
The timers are threaded as they use mod events.
What this does is create a new object reference using placeAtMe, then attaches the TimerObj script to it via ConsoleUtil.
The TimerObj script still uses RegisterForSingleUpdate and RegisterForSingleUpdateGameTime, but with OnUpdate it sends a mod event that your main script registers for. You could also use separate events for each timer you create if you wish.
Don't get this (separate events), could you give an example?
Is included...