Skip to content

A spent room-traps search is never refunded, so a trap behind a later-discovered secret door can become unfindable #45

Description

@mmacy

The gap

The once-per-character-per-cell-per-kind guard on searching (search_attempts, src/osrlib/crawl/exploration.py) predates the growing scope of a room_traps search: since #35 (PR #44), the search also covers the searched cell's door edges, revealing an open-trigger trap in the area beyond a known door — but an undiscovered secret door rightly hides its trap along with itself (the no-leak doctrine).

Those two rules compose badly. A member who searches the cell while the secret door is undiscovered spends their one-ever attempt without any chance at the trap behind it. Once every member has spent theirs, discovering the secret door later changes nothing: every further room_traps search on that cell rejects with exploration.search.already_tried, and the trap can only be learned by opening the door and eating the 2-in-6 spring.

That silently expires the promise the door-trap feature makes — that the trap beyond a known door is findable before the door is ever opened.

Possible shapes of a fix

  1. Refund on discovery. Discovering a secret door clears that cell's room_traps attempts (or just those spent while the door was hidden). The door's discovery is new information; a fresh search of the same 10' square is a defensible re-roll.
  2. Scope attempts to what was searchable. Record with each attempt the door-knowledge it was made under, and reject only when nothing new is visible. More precise, more state.
  3. Accept and document. B/X is stingy with re-searches; a referee could rule the party had their chance. If so, the adaptations register should say it out loud, because today it reads as an accident.

Related: the exploration.trap.found event carries only trap_ref with no location context, so a front end that marks a found trap on the party's current area — always correct before door-found traps existed — now marks the wrong room for a through-the-door find. Any fix here should consider giving the found event enough context to place the trap.

Found by the review pass on PR #44.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions