Accessibility ModandClaude Opus 5
50b226620e
Game-file footprint unchanged: still one line in main.lua. The slider turned out to be genuinely generic: modules/slider.lua is a factory, so one wrapper on it narrates all four users -- craft, refine, trade and ingame_wait (the wait-N-turns screen). Same leverage as the console.print and inventoryCursorPopup patches. The options screens do NOT share it, though: config_menu changes values through config.increase/config.decrease, so it needed its own descriptor. It reports tab, option name and value, and its focus key includes the value so left/right re-announce even though the focused option has not moved. states/_itemgrid.lua is now shared by inventory, craft, refine and trade, all of which build a views/inventoryWindow. It stays silent while confirmationWindowEnabled is set so the slider owns speech during quantity selection instead of the two fighting. testbed gains walkTo(), which navigates using the game's own pathfinder rather than hardcoded direction sequences -- those drift as soon as anything moves the player. The config test only adjusts a value when the focused option is demonstrably safe, and puts it straight back. The slider patch is applied and confirmed by the self-test but not exercised live: ingame_wait is unreachable in the prologue because tutorial_bed overrides bed's tryInteractFunction with an empty function by design, and the crafting screens need an alchemy table and real items. Recorded as a NOTE rather than a failing check, since it is a property of the game and not of the mod. 25/25 testbed checks, history unit tests passing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Accessibility mod — documentation
Research and planning for making Sulphur Memories: Alchemist 0.4.2 blind-accessible.
| Doc | Contents |
|---|---|
| 01-architecture.md | How the game is built: states, console, level model, keybindings, where text already exists. |
| 02-hooking-strategy.md | How to attach the mod with (near) zero edits to game files. |
| 03-implementation-plan.md | Six phases, each independently testable. |
| 04-open-questions.md | Decisions needed before/while building. |
| 05-decisions.md | Answers given so far, and what they imply. Supersedes Q1/Q2/Q7/Q10. |
The short version
Three findings shape everything:
-
The game is already keyboard-complete. All 28 states implement
keypressed; there's a full rebindable-keys system with contexts. The accessibility gap is that nothing announces what is focused — not that things are unreachable. This makes the job much smaller than a typical mouse-driven game. -
The game already writes the text we need to speak.
console.printis a single chokepoint for all log messages.level.getCursorMessage()returns tile/creature descriptions.getCursorPopupStats()feeds the item popups in five screens. We are mostly re-routing existing strings to speech, not writing a description engine. -
Everything is a
required singleton, anddebug.getupvalueworks. Module functions can be monkey-patched in place, and the file-localselectedOptionvariables in menu states are readable from outside. A one-line bootstrap inmain.luais the only unavoidable edit.
Proposed footprint: 1–3 lines added to main.lua, everything else new files under accessibility/. A git baseline tagged vanilla-0.4.2 makes re-application on future versions a rebase.