RegisterForUpdate - Form: Difference between revisions
Jump to navigation
Jump to search
Important warning
imported>JustinOther m (→Examples: Floatified float parameter) |
imported>Perdev (Important warning) |
||
| Line 24: | Line 24: | ||
RegisterForUpdate(10.0) | RegisterForUpdate(10.0) | ||
</source> | </source> | ||
==Important Warning== | |||
'''Using this function should be done with great care and [[RegisterForSingleUpdate - Form|RegisterForSingleUpdate]] should be preferred in almost every circumstance.'''<br/> Indeed, RegisterForUpdate comes with a few problems: | |||
* If a mod is removed, its OnUpdate handler will still be registered and the game engine will continue to try to invoke it. This will result in periodic errors on every tick because of the game reporting that the handler no longer exists. If you initially registered a small update interval, this can harm performances significantly. | |||
* Even if your mod still exists, you may not exclude the possibility that a bug manifests itself and causes periodic errors. A better behavior if your event handler contains a bug would be to cancel the automatic updates, which is achieved through RegisterForSingleUpdate. | |||
* This also complicates development since simply modifying the OnUpdate handler has no effect: as long as the old handler was registered, it will continue to be used unless you explicitly unregister for updates, then register again. This will also output periodic error messages because of the game reporting that the executed version is different from the current one. | |||
* Last but not least, OnUpdate is a very frequent cause of savegames bloat and general bugs, forcing the user to abandon their current game and restart a new one. This occurs when the OnUpdate handler takes more time to run than the update interval it was registered with. The result is that new calls are queued faster than they are processed, preventing other scripts to run, consuming increasing memory and can lead to savegames as large as one gigabyte! Unfortunately, since almost every call to a native function suspends a function's execution for one whole frame, the phenomenon is bound to happen if the handler contains more native calls than the number of frames between each handler's call. | |||
Also note that other events do not have those problems. This is specific to RegisterForUpdate. | |||
Anyway, all of those problems are avoided by using [[RegisterForSingleUpdate - Form|RegisterForSingleUpdate]] instead: | |||
* If the script is missing or contains an error, it will never be called again. | |||
* If you modify OnUpdate and reload your game, the old version will be only called once. After that the new version will be the one to be called. | |||
* The next call can never happen before the previous one completed. | |||
<source lang="papyrus"> | |||
function SomeInitializationFunction() | |||
RegisterForSingleUpdate(0.5) ; OnUpdate will be called once. | |||
endfunction | |||
Event OnUpdate() | |||
; Do some stuff | |||
RegisterForSingleUpdate(0.5) ; OnUpdate will be called one more time. | |||
endEvent | |||
</source> | |||
It may also be wise to add a handler for [[OnPlayerLoadGame - Actor|OnPlayerLoadGame]]. That way, if OnUpdate previously contained an error and is no longer fired as a result, it will resume once the game is reloaded, hopefully with a modified version that fixes the problem. Note that this event is only fired on the player actor, on the ActiveMagicEffects put on the player and on ReferenceAliases that reference the player. | |||
<source lang="papyrus"> | |||
Event OnPlayerLoadGame() | |||
RegisterForSingleUpdate(0.5) | |||
EndEvent | |||
</source> | |||
== Notes == | == Notes == | ||