Script Processing

How Often are Scripts Processed?

Actors (Creatures and NPCs)

Processed every time the actor's AI is processed. In high process (the loaded area around the player), this is every frame. When the player leaves the area, the actor goes into Medium Level Processing and the script runs about every 9 minutes (game time) or 18 seconds (real time). Later, when the actor cell is unloaded and the actor does not have the “No low level processing” flag checked, it goes into Low Level Processing and the scripts run every hour (game time) or 2 minutes (real time). Of course, if the actor has the “No low level processing” flag checked, its scripts stop running at his point. Scripts on items in the actor's inventory run when the actor script run. These are still the only scripts (aside from quest scripts) that are processed when the player is not around.

Doors

A bit of a special case, these scripts are processed like other scripts on references (every frame when loaded), but they will also be processed once any time an actor activates the door.

Objects in Containers

Processed when the container's script is processed -- so, items on actors are processed when the actor is processed; items in other containers are processed every frame when the cell is loaded.

Quests

Processed every 5 seconds (by default) when the quest is running. You can change how often quest scripts are processed by changing a default variable in the quest's script. When a game is first loaded there will be a brief period when quest scripts will not run, even if fQuestDelayTime is very small. The first time a game is loaded in a given game session this delay will be longer, perhaps 5 seconds or so. This does not happen for other script types.

References

Processed every frame when its cell is loaded, not at all when the cell is not loaded. So these scripts run only when the player is nearby (which means these are often a good place to put relatively expensive scripts, doing things like distance checks).

Order of Script Processing

Scripts are run sequentially i.e., no two scripts ever run concurrently. The order in which they are processed is the same as the one by which their scripted objects were added to the game/brought into scope.

Quest scripts are processed before object and magic effect scripts. They follow the same order as the scripts on objects - The order in which their parent quest was added to the game ( essentially in order of their formIDs ).

Remote Ref Heartbeat

Whenever a local variable on a persistent ref is set, the script of that reference will be run in the next frame. Hence if a script continually sets a variable on itself, then it will continue to run in every frame.

Positive

This can be used to effectively keep a remote reference in "high processing". E.g. if items are stored in a remote container, then ordinarily the OnDrop and OnUnequip blocks of those items will not be run since the container is not local, and thus not in high processing. But by "heartbeating" the remote container ref, the item blocks can be made to run.

Negative

Unintentional heartbeating of remote references will keep them permanently in high processing and thus hurt performance. Modders should ensure that script for persistent refs do not set a variable in every frame. (Be careful of this particularly in gameMode blocks, which are occasionally run even for out of scope persistent references.)

Notes/Questions

• This does not appear to happen for non-persistent refs.
• How about actors with no low level processing?

Sample Script

scn HeartbeatOS
;--Heartbeats a reference. Useful for remote containers.

short heartbeat

begin menuMode
    if heartbeat > 0
        set heartbeat to heartbeat
    endif
end

begin gameMode
    if heartbeat > 0
        set heartbeat to heartbeat - 1
    endif
end