Script Law — Rooms

Hand-holding for room SpecProcs. Classic Diku room triggers / dg_scripts are not how Neo works — you create a named Beanshell room proc with @proc room, then attach that name on a room prototype with @room proc.

Hub: Script Law. Build the room first: Creation Law — Rooms.

• [ ] Room prototype exists and is @saved (Rooms)
• [ ] @proc room new <name> then @proc room script <name> with Beanshell
• [ ] index proc_room / @proc room examine <name> to verify
• [ ] @load room <vid> → @room proc <name> → @examine room → @save room
• [ ] Walk into the room / wait for UPDATE to test

Attaching a proc name that does not exist yet is the usual first failure — create, then attach.

> @proc room new quiet_enter
Okay.
> @proc room script quiet_enter
(writer opens — paste Beanshell, finish writer)
> @proc room examine quiet_enter
…script text…
> @proc room matrix quiet_enter 0.0
Okay.
> index proc_room quiet
>

Help pattern: @proc room [delete|examine|new|matrix|rename|script] <name>. Names are lowercased, alphabetic/underscore, length 3–16.

Rename / delete when you outgrow a name:

> @proc room rename quiet_enter alley_enter
Okay.
> @proc room delete alley_enter
Okay.
>

Detach rooms that still name a proc before you delete it if you want clean references.

> script room list
> script room write
(writer opens for the SpecProc named like your player)
>

Usage: script (mobile|item|room) (list|write) [player]. Implementors may pass another player name.

> @load room 1200
Okay.
> @room proc quiet_enter
Okay.
> @examine room
(confirm proc name)
> @save room
Okay.
> goto 1200
>

If @load room complains about an open draft, @examine room then @save or @clear.

Branch on var.STATE (see hub table). For rooms you will use most:

• STATE_ENTER (-4) — someone entered
• STATE_UPDATE (-6) — periodic room update
• STATE_SCRIPT (0) — script pulse / roomact-style
• Interpreter / post-interpreter when commands involve the room context

Return true only when you intend to block the triggering command; otherwise return false;.

Prefer methods that already appear in live procs / RoomShell. Examples used in world data and shell surface:

• var.room.echo(…) / related echo helpers
• Door helpers such as lockNorth, unlockEast, …
• Weather-related helpers on the room shell where present

Also: var fields (STATE, mobile, item, command, args, scratch aliases) and util.roll / util.chance. Do not invent method names — @proc room examine an existing proc or read shell code when unsure.

Paste into @proc room script … only after you understand it blocks nothing:

if (var.STATE == var.STATE_ENTER) {
  if (util.chance(50)) {
    var.room.echo("The air shifts as someone arrives.");
  }
}
return false;

Attach, goto the room from next door, and confirm you see the echo sometimes. If nothing happens: confirm @examine room shows the proc name, you @saved, and your script actually branches on ENTER (not only SCRIPT).

Some rooms use compiled SpecRoom via @room attrs rather than a free-form script name (e.g. patterns like RoomSkullDoor). That is Creation-side attribute work, not @proc room — see Rooms and the Script Law hub note on Java specials.

• @room proc before @proc room new/script
• Forgetting @save room after attach
• Branching only on STATE_SCRIPT when you meant ENTER
• Returning true by accident and blocking movement/commands
• Deleting a proc still named on live rooms

• Script Law — hub
• Creation rooms — build / dig / doors
• Script zones — zones do not hold room scripts