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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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