The request
A room trap can only ever spring on enter. _room_trap_check returns early otherwise:
if area is None or area.trap is None or area.trap.trigger != "enter":
return [](src/osrlib/crawl/exploration.py:747.)
TrapSpec.trigger accepts enter or open, so open is a legal value on a room trap that the engine then silently ignores — the trap is authored, saved, validated clean, and never fires.
Why an author reaches for it
A trap on the door into a room is a standard B/X construction — the poisoned lock, the blade that drops when the door swings. Today the only way to model it is a treasure-cache trap, which requires a cache to hang it on, or the manual prose fallback, which leaves resolution to the referee.
An author who tries the obvious thing — a room trap set to spring when the door is opened — gets something that looks right everywhere except at the table.
Two ways to close it
- Make it fire. Honour
open on a room trap by springing it from the door-opening path, the way the cache path springs a treasure trap when the cache is opened.
- Make it illegal. If an area genuinely has nothing to open, reject
trigger="open" on kind="room" at the model, so the combination cannot be authored at all rather than being accepted and ignored.
Either is better than the current state, where the field accepts a value the engine drops. (1) is the feature; (2) is the honest minimum.
What osr-editor did meanwhile
osr-editor stopped offering the dead value: its trap builder no longer presents a trigger select, showing a room trap's trigger as read-only text and omitting the field entirely on a cache trap, since the cache path never reads it. Because earlier releases did offer open on room traps, it also warns when a document carries one and offers a one-click repair to enter.
That is a workaround in the editor, not a fix — a rule about which triggers are meaningful belongs here, not in an editor that has to guess it from engine behaviour. Filed from mmacy/osr-editor#34.
The request
A room trap can only ever spring on
enter._room_trap_checkreturns early otherwise:(
src/osrlib/crawl/exploration.py:747.)TrapSpec.triggeracceptsenteroropen, soopenis a legal value on a room trap that the engine then silently ignores — the trap is authored, saved, validated clean, and never fires.Why an author reaches for it
A trap on the door into a room is a standard B/X construction — the poisoned lock, the blade that drops when the door swings. Today the only way to model it is a treasure-cache trap, which requires a cache to hang it on, or the
manualprose fallback, which leaves resolution to the referee.An author who tries the obvious thing — a room trap set to spring when the door is opened — gets something that looks right everywhere except at the table.
Two ways to close it
openon a room trap by springing it from the door-opening path, the way the cache path springs a treasure trap when the cache is opened.trigger="open"onkind="room"at the model, so the combination cannot be authored at all rather than being accepted and ignored.Either is better than the current state, where the field accepts a value the engine drops. (1) is the feature; (2) is the honest minimum.
What osr-editor did meanwhile
osr-editor stopped offering the dead value: its trap builder no longer presents a trigger select, showing a room trap's trigger as read-only text and omitting the field entirely on a cache trap, since the cache path never reads it. Because earlier releases did offer
openon room traps, it also warns when a document carries one and offers a one-click repair toenter.That is a workaround in the editor, not a fix — a rule about which triggers are meaningful belongs here, not in an editor that has to guess it from engine behaviour. Filed from mmacy/osr-editor#34.