feat: old standalone trigger systems completely unified into trigger->condition->action system

1 files changed, 136 insertions, 80 deletions

diff --git a/building_guide/rooms.md b/building_guide/rooms.md
index 3834a56..602e449 100644
--- a/building_guide/rooms.md
+++ b/building_guide/rooms.md
@@ -111,9 +111,9 @@ exits:
 
 #### Exit on_traverse — actions when walked through
 
-An exit can carry an `on_traverse` list. Interactions fire when the player moves through the
-exit (not when it's blocked). The first whose condition passes wins. Supports the full
-`Interaction` shape — condition, message, and action:
+An exit can carry an `on_traverse` list of Triggers. The first whose filters pass fires when
+the player moves through the exit (not when it's blocked). Supports the full Trigger shape —
+`condition`, `item_id`, and a `steps` list. See `triggers.md` for the reference.
 
 ```yaml
 exits:
@@ -123,8 +123,9 @@ exits:
       player_flag: lined_up
     blocked_message: "You're not in line yet."
     on_traverse:
-      - set_player_flags:
-          boarded_shuttle: true
+      - steps:
+          - set_player_flags:
+              boarded_shuttle: true
 ```
 
 #### Hidden exits
@@ -252,8 +253,9 @@ objects:
     inroom_description: "A large framed sign is mounted near the cockpit door."
     description: "Safety instructions are printed in bold lettering."
     on_look:
-      - set_player_flags:
-          1001_look_sign: true
+      - steps:
+          - set_player_flags:
+              1001_look_sign: true
 ```
 
 See `objects.md` for the full object reference — local objects, file objects, behaviors,
@@ -263,82 +265,128 @@ interactions, safespots, stealing, and hidden objects.
 
 ### On-enter scripts
 
-Each `on_enter` step shows a `message`, optionally gated by a `condition`. Steps whose
-condition fails are skipped.
+`on_enter` is a `[]Trigger` list. The first entry whose `condition` (and `item_id`, if
+present) passes fires, and its `steps` run as a scripted sequence (see `triggers.md` for the
+full Trigger/Step reference). The classic welcome sequence in room 1001 is a single entry
+whose steps are each gated by their own `condition`:
 
 ```yaml
 on_enter:
-  - message: "The guard barks: \"State your business!\""
-    condition:
-      player_flag: talked_to_guard
-      not: true                  # only the first visit
+  - steps:
+      - condition:
+          not: true
+          player_flag: 1001_welcome
+        messages:
+          - "{0B bold}Welcome to The House of Icarus{/}"
+        wait: 5
+      - condition:
+          not: true
+          player_flag: 1001_welcome
+        messages:
+          - "{0B}Type{/} {0A}look sign{/} {0B}or{/} {0A}talk attendant{/} {0B}to get started{/}"
+        set_player_flags:
+          1001_welcome: true
+        wait: 7
+      - condition:
+          not: true
+          player_flag: 1001_welcome
+        messages:
+          - "{0B}Type{/} {0A}help newplayer{/} {0B}for the new player's guide.{/}"
+        wait: 7
+```
+
+Room 1002's on_enter is the same shape — condition per step, plain-string `messages`, and a
+`wait` to pace the lines:
 
-  - message: "The guard nods. \"Back again?\""
-    condition:
-      player_flag: talked_to_guard   # subsequent visits
+```yaml
+on_enter:
+  - steps:
+      - condition:
+          not: true
+          player_flag: 1002_lined_up
+        messages:
+          - A young boy the crowd openly look you up and down a little bemused, as if you're heading the wrong direction.
+        wait: 7
+      - condition:
+          not: true
+          player_flag: 1002_lined_up
+        messages:
+          - The pilot pops out of the hatch of the craft and calls out "Shuttle to Passenger Barge Denali. Tickets out, please! Nice and orderly!"
+        wait: 7
+      - condition:
+          not: true
+          player_flag: 1002_lined_up
+        messages:
+          - The people all shuffle into a line, dragging their luggage out of the path to clear the way for you.
+        set_player_flags:
+          1002_lined_up: true
+        wait: 7
 ```
 
 #### Timed sequences
 
-A step may carry a `delay` (ticks to wait before firing) and/or set flags. If any step has a
-delay or sets a flag, the whole sequence runs as a scheduled enter sequence; plain
-message-only scripts print instantly.
-
-```yaml
-on_enter:
-  - condition: { player_flag: boarded, not: true }
-    delay: 5
-    message: "Some of the crowd look you up and down."
-  - condition: { player_flag: boarded, not: true }
-    delay: 5
-    message: "The pilot calls out: \"Tickets, please!\""
-    set_player_flags:
-      lined_up: true               # opens an exit, flips a description, etc.
-  - condition: { player_flag: boarded, not: true }
-    message: "The crowd forms a single-file line."
-```
+`wait: N` on a step is the number of ticks to pause **before** that step fires (replaces the
+old `delay`). Messages are plain strings; effects on a step fire together when the wait
+elapses. A step with no `wait` fires on the next tick.
 
 #### Step actions
 
-On-enter steps support all the same actions as triggers: `broadcast`, `broadcast_global`,
-`spawn_mob`, `despawn_mob`, `give_item`, `take_item`, `teleport`, `heal`, `credits`,
-`aps_node`, `set_global_flags`, and `set_player_flags`. See the
-[trigger step actions](triggers.md#step-actions) table.
+On-enter steps support the full Step vocabulary: `messages`, `broadcast`,
+`broadcast_global`, `spawn_mob`, `despawn_mob`, `give_item`, `take_item`, `teleport`,
+`heal`, `credits`, `aps_node`, `set_global_flags`, `set_player_flags`, plus a per-step
+`condition`. See the [Step vocabulary](triggers.md#step-vocabulary) table.
 
 ```yaml
 on_enter:
-  - condition: { player_flag: boss_summoned }
-    delay: 10
-    broadcast: "The ground trembles..."
-  - condition: { player_flag: boss_summoned }
-    delay: 20
-    broadcast: "A massive guardian emerges from the shadows!"
-    spawn_mob:
-      id: altar_guardian
-      owner_only: true
-      despawn_on_leave: true
+  - condition:
+      player_flag: boss_summoned
+    steps:
+      - wait: 10
+        broadcast: "The ground trembles..."
+      - wait: 20
+        broadcast: "A massive guardian emerges from the shadows!"
+        spawn_mob:
+          id: altar_guardian
+          owner_only: true
+          despawn_on_leave: true
 ```
 
-#### Step-level conditions
+#### First-match-wins and migration
+
+Entries in `on_enter` are walked top-to-bottom; the first whose `condition` passes fires
+and its steps run. The old on_enter ran **every** matching step, so migration wraps the old
+step list into a single Trigger entry to preserve behavior. For new content where steps
+are mutually exclusive, use multiple entries with distinct conditions.
+
+Notes:
+- `wait: 0` (or omitted) fires on the next tick.
+- Gate a sequence on a flag the sequence itself sets so it doesn't replay on return visits.
+- A `lock: true` Trigger resumes on reconnect; unlocked sequences are not persisted across
+  disconnect.
+- Setting player flags from on_enter steps fires flag-change triggers watching those flags.
+
+---
+
+### On-exit scripts
 
-Each step can have a `condition:` that gates it individually. Unlike the step's action
-fields, the condition is evaluated **once** on entry — a flag set by a later step won't
-cancel an earlier step.
+`on_exit` is the mirror of `on_enter`: a `[]Trigger` list that fires when a player **leaves**
+the room. It runs **before** `RoomID` is updated to the destination, so broadcasts and
+`spawn_mob` resolve against the room the player is leaving.
 
 ```yaml
-on_enter:
+on_exit:
   - condition:
-      player_flag: 1001_welcome
-      not: true
-    delay: 5
-    message: "Welcome to The House of Icarus"
+      player_flag: boarded
+    steps:
+      - broadcast: "The shuttle hatch clanks shut behind the departing passenger."
+      - set_player_flags:
+          left_pad: true
 ```
 
-Notes:
-- `delay: 0` (or omitted) fires on the next tick.
-- Gate a sequence on a flag the sequence itself sets so it doesn't replay on return visits.
-- If a player disconnects mid-sequence it resumes on reconnect.
-- Setting player flags from on_enter steps fires room triggers watching those flags.
+Use on_exit for parting messages, closing out a spawn when a player departs, or recording
+that the player has passed through an area. It obeys the same first-match-wins rule and the
+same Step vocabulary as on_enter. (New event block — did not exist before the Trigger
+unification.)
 
 ---
 
@@ -384,34 +432,38 @@ mobs:
 
 ---
 
-### Room triggers
+### Room flag triggers
 
-A room can carry a `triggers:` block. Each trigger watches a player or global flag and fires
-a sequence of timed steps when the flag's value changes. See `triggers.md` for the full
-reference.
+A room that needs to react when a flag changes uses the `on_flag_change:` / `on_global_flag_change:`
+blocks (these replace the old `triggers:` block). Each entry watches one flag, runs a `steps`
+sequence when that flag changes, and resolves broadcasts/spawns against the room. See
+`triggers.md` for the full reference.
 
 ```yaml
-triggers:
-  - on_player_flag: 1001_look_sign
+on_flag_change:
+  - on_player_flag: lever_pulled
+    condition:
+      room: 1001                   # opt-in: only fires if the player is in this room
     steps:
-      - delay: 5
-        message: "The cabin shakes as the small craft touches down"
-      - delay: 5
-        message: "The pistons hiss as the rear staircase opens"
+      - wait: 5
+        messages: ["The cabin shakes as the small craft touches down"]
+      - wait: 5
+        messages: ["The pistons hiss as the rear staircase opens"]
       - set_player_flags:
           1001_touchdown: true
 ```
 
-Room triggers are scoped to the room — broadcasts go to that room, mobs spawn there, and the
-trigger only fires when the flag-setting player is in that room. For server-wide events, use
-global triggers in `data/triggers/` instead.
+Flag triggers listen **globally** — they fire regardless of where the flag is set. The old
+room `triggers:` block was implicitly room-scoped; migration injects `condition: { room:
+<id> }` to preserve that. Delete the `room` condition to make the trigger fire wherever the
+player is. For server-wide events use global trigger files in `data/triggers/` instead.
 
 ---
 
 ### Conditions Reference
 
-Conditions are used in exit gates, on-enter steps, room descriptions, on_use/on_look/on_kill
-interactions, talk option guards, talk node conditions, and trigger value matching.
+Conditions are used in exit gates, Trigger and step gates, room descriptions, talk option
+guards, and flag-trigger value matching.
 
 #### Simple conditions
 
@@ -455,6 +507,10 @@ condition:
 # Player has enough credits
 condition:
   min_credits: 50
+
+# Player is currently in a specific room (use for flag-trigger scoping)
+condition:
+  room: 1001
 ```
 
 #### Compound conditions
@@ -507,10 +563,10 @@ on_use:
   - condition:
       global_flag: secret_door_open
       not: true
-    message: "You press the stone button. You hear grinding stone in the distance."
-    action:
-      set_global_flags:
-        secret_door_open: true
+    steps:
+      - messages: ["You press the stone button. You hear grinding stone in the distance."]
+        set_global_flags:
+          secret_door_open: true
 ```
 
 **Room 7** — contains the door: