Difference between revisions of "RegisterForSingleUpdate - Form"

From the CreationKit Wiki
Jump to navigation Jump to search
imported>Imp of the Perverse
imported>Imp of the Perverse
Line 23: Line 23:


== Notes ==
== Notes ==
Aliases and quests will automatically unregister for this event when the quest stops. Active magic effects will automatically unregister when they are removed.
*Aliases and quests will automatically unregister for this event when the quest stops. Active magic effects will automatically unregister when they are removed.
 
*Subsequent calls to ResisterForSingleUpdate will override previous ones - i.e. calling it back to back will result in the second registered update occurring, but not the first. It will not interfere with updates started by RegisterForUpdate however.
Subsequent calls to ResisterForSingleUpdate will override previous ones - i.e. calling it back to back will result in the second registered update occurring, but not the first. It will not interfere with updates started by RegisterForUpdate however.


== See Also ==
== See Also ==

Revision as of 14:21, 4 March 2012

Member of: ActiveMagicEffect Script, Alias Script, and Form Script

Registers this form/alias/magic effect for a single update event. Which also means you don't need to call UnregisterForUpdate() unless you want to cancel the update early. Only the specific form, alias, or magic effect that registered will get the event - it will not be relayed to attached aliases or magic effects.

Syntax

Function RegisterForSingleUpdate(float afInterval) native

Parameters

  • afInterval: In how much time (in seconds, ignoring menu-mode time) the OnUpdate() should be triggered

Return Value

None

Examples

; Register for a single update in 1337 seconds - does not count menu-mode time.
RegisterForSingleUpdate(1337)

Notes

  • Aliases and quests will automatically unregister for this event when the quest stops. Active magic effects will automatically unregister when they are removed.
  • Subsequent calls to ResisterForSingleUpdate will override previous ones - i.e. calling it back to back will result in the second registered update occurring, but not the first. It will not interfere with updates started by RegisterForUpdate however.

See Also