Skip to content

fix(dungeon): make Ctrl reach Int. Walls, not just Rooms/Doors - #136

Open
DimitroffVodka wants to merge 1 commit into
mainfrom
claude/festive-neumann-a31740
Open

fix(dungeon): make Ctrl reach Int. Walls, not just Rooms/Doors#136
DimitroffVodka wants to merge 1 commit into
mainfrom
claude/festive-neumann-a31740

Conversation

@DimitroffVodka

Copy link
Copy Markdown
Owner

What

The Dungeons tab footer renders Ctrl to switch mode in all three modes, but the handler in scripts/tray/TraySD.mjs only toggled tiles <-> doors. Int. Walls was unreachable from the keyboard, and pressing Ctrl while in it dropped back to Rooms.

This started as "delete the dead hint row" — but the handler is not dead. A grep ctrlKey misses it because it keys on event.key === "Control". The hint was 2/3 true, so the fix is on the handler, not the template. tray.hbs is untouched.

How

  • nextDungeonMode() cycles all three in tab order, off a single DUNGEON_MODES list that setDungeonMode now validates against — so tab order and cycle order can't drift apart unnoticed.
  • Added an event.repeat guard. Chromium auto-repeats modifier keydown, so a held Ctrl would spin the cycle and renderTray() on every tick. This was latent in the old toggle too.
  • nextDungeonMode lives in dungeon-tool-state.mjs, the leaf module that already owns the mode vocabulary and imports nothing, so the test needs no Foundry harness.

Test plan

dev/tests/dungeon-mode-cycle.test.mjs — asserts the cycle visits every mode and wraps, that an unknown mode restarts it rather than wedging, and that every cycled value is one setDungeonMode accepts. The load-bearing one parses data-dungeon-mode out of tray.hbs and asserts that order equals DUNGEON_MODES, so reordering the tabs alone fails the suite.

  • npm test — 1501 pass, 0 fail
  • npm run verifyverify: OK, 0 errors, BLOCKING section empty

Not covered by Node tests: that Ctrl actually fires in a live world. The listener is a document-level keydown registered inside initTray(), gated on the tray being expanded and in dungeons view — that needs live-V14 acceptance.

Known gap, not fixed here

Ctrl is also the prefix of Ctrl+Z / Ctrl+S, so those still cycle the mode as a side effect while the Dungeons tab is open. Pre-existing in the old toggle, not introduced here. A real fix needs keyup-without-combo detection rather than a one-liner.

🤖 Generated with Claude Code

The Dungeons tab footer advertises "Ctrl to switch mode" in all three
modes, but the handler in TraySD only toggled tiles <-> doors, so the
Int. Walls tab was unreachable from the keyboard and Ctrl from within
it dropped back to Rooms.

Cycle all three in tab order instead, off a single DUNGEON_MODES list
that setDungeonMode now validates against, so the tab order and the
cycle order cannot drift apart unnoticed.

Also guard on event.repeat: Chromium auto-repeats modifier keydown, so
a held Ctrl would spin the cycle and re-render the tray on every tick.

The test asserts the cycle order equals the data-dungeon-mode order
parsed out of tray.hbs, so reordering the tabs alone fails it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant