Entry Points and Events

Every script needs somewhere to begin. Entry points are the nodes that start execution — they have an outgoing execution pin but no incoming one, and they are all collected in the Events folder of the node palette, whichever type they belong to.

A script can have several. Each one starts its own independent path through the graph.

The two you will use most

Node	When it runs
OnSimulationStarted	Once, when the game starts running
Update	Once every frame

If you are not sure which to use, use OnSimulationStarted for setup and Update for anything that needs checking continuously.

The full lifecycle

These fire in a fixed order. All of them are optional — add only the ones you need.

Node	When	How often
Initialize	The object exists and its position is known	Once, always
OnActivated	The component becomes active	Every time it is activated
OnSimulationStarted	The game begins simulating	Once
Update	Every frame	Continuously
OnDeactivated	The component becomes inactive	Every time it is deactivated
Deinitialize	The component is being destroyed	Once

In order, for a normal object in a running scene:

Initialize            ← position already valid here
OnActivated           ← only if the component is active
OnSimulationStarted   ← only if the game is simulating
Update, Update, Update, …
OnDeactivated         ← on deactivation, and again during destruction
Deinitialize          ← on destruction

Which one should I use?

OnSimulationStarted is the right default for game logic. The engine guarantees that every component in the scene has finished Initialize and OnActivated before any component gets OnSimulationStarted. That makes it the first moment where it is safe to look up another component and expect it to be ready.

Initialize runs earlier, and always — even on components that start inactive. The object's global position is already correct by this point, so it is fine for setup that depends only on this object. It is not safe for reaching out to other components, because they may not have initialised yet.

OnActivated and OnDeactivated pair up. Use them when a component can be switched on and off during play and needs to set up or tear down each time. Note that OnDeactivated also runs during destruction, before Deinitialize.

Update only runs while the component is active and initialised. Its DeltaTime output is the time since the last frame — multiply movement by it so behaviour does not change with frame rate.

In the editor, simulation is separate from existence

Placing an object in a scene gets you Initialize and OnActivated immediately. OnSimulationStarted waits until you actually run the scene. This is why a script can look correct in the viewport and do nothing until you press play.

warning

Deinitialize is immediate

It runs at the moment the component is deleted, not at the end of the frame. Do not assume other objects are still around to talk to.

Reacting to messages

The other kind of entry point is a message handler. Every message type in the project generates one automatically, named On followed by the message name:

Node	Runs when
OnMsgTriggerTriggered	Something enters or leaves a trigger
OnMsgDeleteGameObject	This object is about to be deleted
OnMsgAnimationReachedEnd	An animation finishes

Which handlers exist depends on your project — see Reading the Palette.

Message handlers are usually more efficient and easier to follow than polling for the same thing in Update. If you find yourself checking a condition every frame that something else already announces, look for a handler first.

What a handler gives you

A handler outputs the message's own data as pins. OnMsgTriggerTriggered, for example, provides:

• TriggerState — whether this was an entry or an exit.
• GameObject — the object that touched the trigger.

That second output matters. In the jump pad recipe, the force is applied to the object the handler reports, not to the pad — the handler is how the script learns who set it off.

Every handler also outputs a CoroutineID, which you can use to cancel that particular run later.

When an entry point fires while it is still running

Entry points can be triggered again before their previous run has finished — a trigger fired twice quickly, or an Update path that waits. Each entry point has a Coroutine Mode setting that decides what happens:

Mode	Behaviour
Stop Other	Cancel the previous run and start again. The default
Don't Create New	Let the previous run finish; ignore the new trigger
Allow Overlap	Run both at once

Choose by asking what should happen if the event repeats:

• A door that should finish opening before responding again — Don't Create New.
• A creature that should walk to the newest clicked point — Stop Other.
• A timer where every tick matters — Allow Overlap.

This only matters for paths that span more than one frame. See Coroutines.

Getting at the object your script is on

Inside any entry point you will usually want the object the script is attached to:

Node	Returns
GetScriptOwner	The owning game object, the component, and the world
GetOwner	The game object this component is attached to
GetWorld	The world it lives in

From the owner you can reach everything else — FindChildByName for child objects, TryGetComponentOfBaseType for other components on the same object.

See Also

• Key Nodes
• Recipes — entry points in working scripts
• Reading the Palette