Skip to main content

Every Event

Scripts in Hideout never run on their own. They wake up when something happens: a player joins, an object is touched, a timer ticks. Each "something" is an event, and you listen for one with a hat block. This page lists every event there is, what sets it off, and what information you get inside it.

There are 15 hat blocks you can place. Each one starts a stack of action blocks that run when its event fires.

Block snippetAn event fires, its hat catches it, and the stack below runs once: one run per event.
New here?

If "hat block," "scope," and "triggering player" are new words, read Events & Triggers first, then come back to this table as a reference. The Glossary has quick definitions too.


How to read the table

  • What fires it: the real-world thing that sets the event off.
  • Scopes: which behaviors can place the hat. Every hat works in room and object behaviors. (There are no NPC-scoped hats yet, so you react to NPCs from a room or object behavior.) Room Object
  • Picks a target?: whether you must drop a specific object, NPC, or area into the hat. These targets must be fixed blocks (you can't compute them), so the room can find your script quickly.
  • Triggering player: whether the Triggering Player block is available inside this hat.
  • Other context: extra values the event hands you, like the message text or the triggering NPC.

The complete event table

Hat blockWhat fires itPicks a target?Triggering player?Other context
when room startsThe room finishing loading. Fires on every load, not once forever.NoNoNone
when player joins roomSomeone enters the room.NoYesNone
when player leaves roomSomeone leaves (they may already be gone, so use their id/snapshot only).NoYesNone
when object is interacted withA player clicks/uses that object.Yes, one objectYesNone
every N secondsA repeating timer. Minimum 5 seconds in normal rooms.The interval (a fixed number)NoNone
when object state changesThat object switches state (open↔closed, lit↔unlit…).Yes, one objectNoNone
when any object is addedAny object is added to the room. Room-wide.NoNoNone
when object is deletedThat object is removed.Yes, one objectYesNone
when object is grabbedA player picks up that object.Yes, one objectYesNone
when any object is un-grabbedAny held object is let go. Room-wide.NoYesNone
when player says phraseA chat message matches your phrase.The phrase + matcherYesmessage text
when player enters areaA player crosses into an area.Yes, one areaYesNone
when player leaves areaA player crosses out of an area.Yes, one areaYesNone
when NPC is interacted withA player clicks/uses that NPC.Yes, one NPCYestriggering NPC
when NPC finishes walkingThat NPC reaches the spot it was told to walk to.Yes, one NPCNotriggering NPC
Under the hood

Internally there are 16 event kinds, but one of them ("outfit changed") has no placeable hat block yet, so you can't trigger on it. The 15 above are everything you can actually use.


The events one by one

Room and time

When Room Startswhen room starts

when room starts runs as the room loads up. Here's the part that surprises everyone: it fires every time the room loads, not just the very first time. A room unloads when it's empty and loads again when someone returns, so this event can fire over and over across a day.

Gotcha

"When room starts" is not "the first time ever." For true one-time setup, store a room variable like hasInitialized, check it, and set it. Otherwise your setup runs again every reload.

Every N Secondsevery N seconds, defaults to 30

every N seconds is your clock. The number must be a fixed value you type in (not a variable), and it can't go below 5 seconds in a normal room. Two things to keep in mind: the timer doesn't tick while the room is empty and unloaded, and after a long gap it fires just once on reload, not once for every tick it missed. So read it as "no more often than every N seconds, and only while the room is awake."


Player events

When Player Joins Roomwhen player joins room

when player joins room and when player leaves room fire as people come and go. Both give you the triggering player, though on leave that player may already be disconnected, so only their stable id and a safe snapshot are reliable.

When Player Says Phrasewhen player says phrase, with a contains/equals/starts with menu

when player says phrase is special: it's the only event that hands you the message text the player typed. It has a small menu with three ways to match:

MatchFires when the message…Use it for
contains (default)has your phrase anywhere inside itbroad keywords ("anyone who says 'hello'")
equalsis exactly your phrasepasswords ("open sesame" and nothing else)
starts withbegins with your phrasecommand-style chat ("!start the round")

Your phrase can be up to 128 characters. There's no fancy pattern matching beyond these three.

When Player Enters Areawhen player enters area

when player enters area and when player leaves area fire when a player crosses the edge of an area you draw. Enter means "was outside, now inside." A player who spawns inside an area counts as entering it. Both give you the triggering player.


Object events

Objects have the most events of all. There's a pattern worth spotting: some events target one specific object (you drop that object into the hat), and some are room-wide (they fire for any object in the room).

When Object Is Interacted Withwhen object is interacted with, with an optional nearby highlight
HatTargetsGives triggering player?
when object is interacted withone objectYes
when object state changesone objectNo
when object is deletedone objectYes
when object is grabbedone objectYes
when any object is addedany object (room-wide)No
when any object is un-grabbedany object (room-wide)Yes
Why the pairs don't match up

Grabbed targets one object, but un-grabbed is room-wide. Deleted targets one object, but added is room-wide. There's a reason for each: you can't point at a specific object that doesn't exist yet (that's added), and once you've let go of something, un-grabbed just watches everything instead. One more to remember: state changes does not give you a triggering player, even though grabbed and un-grabbed do.

The "highlight when nearby" option

The object interact and NPC interact hats have a handy extra: a highlight when nearby checkbox and a hint text box. Turn the checkbox on and the object gets a glowing outline for players standing close, with an optional hint like "Press to open shop" (up to 64 characters).

This is purely cosmetic. It helps players notice the object is clickable, but it does not change when your script runs.


NPC events

When NPC Is Interacted Withwhen NPC is interacted with

when NPC is interacted with fires when a player clicks an NPC you choose. It's the only event that gives you both the triggering player and the triggering NPC. Like object-interact, it has the optional nearby highlight (e.g. hint "Press to talk").

When NPC Finishes Walkingwhen NPC finishes walking

when NPC finishes walking fires when an NPC you told to walk somewhere reaches its destination. It gives you the triggering NPC, but no triggering player (arriving isn't a player's doing).

tip

Both NPC hats live in room and object behaviors, and you pick which NPC right inside the hat. You can't put a hat inside an NPC-scoped behavior yet.


Which events give you "triggering player"?

This trips people up, so here's the exact list. The Triggering Player block is available only inside these hats:

player joins · player leaves · object interacted with · object grabbed · object un-grabbed · player enters area · player leaves area · player says phrase · NPC interacted with

Not available in: room starts · every N seconds · object state changes · any object added · object deleted · NPC finishes walking

If you place "triggering player" under a hat that doesn't have one, the script won't publish. Reach for all players or a computed group instead.


Targets must be fixed

For events that pick an object, NPC, area, or interval, the target has to be a fixed block you choose, not something the script works out on the fly. This is how the room finds your script fast without checking every behavior. If you try to compute the target, you'll get a "needs a literal" error when you publish.

The exception: inside an object behavior, the object event hats already know which object they mean (it's the object the behavior is attached to), so you don't have to pick it.


What's next?