The documented way to run the testbed began with
rm -rf ~/AppData/Roaming/LOVE/Alchemist
which is the player's actual playthrough. It was written down as the
official procedure in four places, so every run of the test suite ate a
real save -- including twice in the session that produced the previous
commit. Reported by Talon.
The testbed does genuinely need an empty save directory: it drives a new
game from the main menu through the prologue, which has already happened
in any real save. So tests/run-testbed.sh MOVES the save aside (never
deletes it), runs, discards the test run's directory and moves the real
one back. Restore is on an EXIT trap plus INT/TERM, so it also happens on
a failed run, a crash and Ctrl-C. If the restore itself fails it says so
loudly and leaves the backup on disk rather than pressing on.
This cannot live inside the mod: love.load calls config.initialize,
keybindings.initialize and user.initialize long before main.lua reaches
require("accessibility").initialize(), so by the time any of our Lua runs
the save directory has already been read. The swap has to happen around
the process.
The rm -rf is removed from all four docs that carried it, each replaced
with the script and the reason not to clear that directory by hand --
being written down as procedure is what made it recur.
accessibility/.gitattributes forces LF on *.sh, or a Windows checkout
hands bash a \r and the script dies. It sits inside accessibility/ on
purpose: a top-level one would show up in the game-file footprint check,
which still reads `main.lua | 1 +`.
Verified with a marker file in a populated save directory: 38 checks, 0
failures, marker intact, no leftover backup directories.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
9.6 KiB
Development setup
How to get from nothing to a tree you can run, test and publish from. The arrangement is a little unusual, because the mod lives inside a copy of a commercial game that must never be published.
If you are already set up, the only things you need daily are Everyday commands and Publishing.
The two trees
This repository exists in two forms, and the same CLAUDE.md ships in both, so
check which one you are in:
| Development tree | Standalone mod repo | |
|---|---|---|
| Contents | The whole extracted game (1838 files) plus accessibility/ |
accessibility/ and the docs only |
Beside accessibility/ |
main.lua, states/, models/, … |
nothing |
| Can you run the game? | Yes | No |
| Can you run the testbed? | Yes | No |
| Remote | None, deliberately — see Publishing | code.iamtalon.me/talon/alchemist-accessibility |
| Where it comes from | You build it, below | Generated from the dev tree by publish.sh |
The standalone repo is derived, never developed in directly. Every publish rewrites its history from scratch, so any commit made there is destroyed on the next publish. Always work in the development tree.
Everything outside accessibility/ in the dev tree is the vanilla game: read-only
reference material. You read it to find out how the game works; you patch it only
where the docs sanction, which currently means exactly one line.
What you need
| Why | Notes | |
|---|---|---|
| The game, 0.4.2, as an extracted source folder | The thing being modded | A directory containing main.lua and conf.lua. Not a packed .love, not the Steam build — see below. |
| LÖVE 11.5 | Runs the game | conf.lua pins t.version = "11.5". Installed here at C:\Program Files\LOVE\. Use lovec.exe, not love.exe. |
| Standalone Lua 5.4 | Unit tests and syntax checks without launching the game | lua and luac on PATH. |
| A screen reader, or nothing | To hear the output | Tolk drives NVDA / JAWS / System Access and falls back to SAPI 5. Dev here uses NVDA. Speech is also mirrored to the console, so you can verify from a log with no reader running at all. |
uv (for uvx) |
git-filter-repo at publish time |
Only needed when publishing. |
Optional: luacheck. .luacheckrc is configured (std = "min+alch" with an
explicit globals list) but the linter is not currently installed — luac -p is
what actually gets run.
Why the game must be an extracted folder
ffi.load("Tolk") goes through the OS loader, not LÖVE's virtual filesystem,
so the TTS DLLs must exist as real files on disk. They can never live inside a
.love archive. This is also why the mod loads them by absolute path via
love.filesystem.getSource(). See accessibility/vendor/love2talk/VENDORED.md.
Building the development tree from scratch
1. Extract the game into a working directory. This tree lives at
D:\code\Sulphur Memories Alchemist 0.4.2 sanctified.
2. Commit the pristine game and tag it, before adding any mod code, so the baseline is genuinely clean:
git init
git add .
git commit -m "Vanilla Sulphur Memories: Alchemist 0.4.2"
git tag vanilla-0.4.2
The tag holds 1838 files and no accessibility/ directory. That is the whole
point of it: it is what makes the footprint check below trustworthy.
3. Add accessibility/ — copy it in, or clone the standalone repo and move
its accessibility/ folder into place.
4. Add the one line to main.lua. In love.load(), immediately after
console.prepare():
require("accessibility").initialize() --ACCESSIBILITY MOD: sole entry point
accessibility/publish/install.patch applies exactly this. The placement is not
arbitrary: by that point templates are preprocessed, keybindings are loaded,
states.setup() has run and the console canvas exists — and it is still before
the first states.switch().
5. Check the TTS DLLs survived the copy. accessibility/lib/ must contain
Tolk.dll, nvdaControllerClient64.dll and SAAPI64.dll.
⚠ .gitignore has a blanket *.dll with a deliberate !accessibility/lib/*.dll
un-ignore. If you ever restructure that folder, the DLLs will silently stop being
tracked and the mod will be mute for anyone who clones it.
6. Verify. Run the everyday commands. A working setup prints, at startup:
[accessibility] TTS: available
[accessibility] speech channel: yes
[speech]! Main menu
speech channel: NO means the DLLs loaded but nothing is listening — start a
screen reader, or expect SAPI.
Everyday commands
Run all of these after any change. The testbed in particular: it has caught essentially every bug in this project, and a change that looks obviously correct is exactly the kind that fails it.
cd "D:/code/Sulphur Memories Alchemist 0.4.2 sanctified"
lua accessibility/tests/test_history.lua # pure Lua, instant
luac -p accessibility/*.lua # syntax only, no LOVE needed
bash accessibility/tests/run-testbed.sh # ~4 min — save-safe, see below
git diff --stat vanilla-0.4.2 -- . ':!accessibility' ':!.gitignore' ':!CLAUDE.md'
The last one must print main.lua | 1 +. That is the invariant that keeps the
mod cheap to lift onto a new game version.
What matters in the testbed run is 0 failures, not the check count, which
varies between runs because several blocks are conditional.
To just play it:
"C:/Program Files/LOVE/lovec.exe" .
Save data
LÖVE writes to ~/AppData/Roaming/LOVE/Alchemist (t.identity = "Alchemist" in
conf.lua). The testbed scenario assumes a fresh save and will not navigate
correctly without one — it drives a new game from the main menu through the
prologue, which has already happened in any real save.
Do not clear that directory by hand. It holds the player's actual
playthrough, and rm -rf on it — which is what these docs used to say — destroys
it. Use accessibility/tests/run-testbed.sh, which:
- Moves the save to
Alchemist.a11y-backup.<pid>(never deletes it), - runs the testbed against the empty directory LÖVE then creates,
- discards the test run's directory and moves the real save back, from an
EXITtrap so this happens on failure, on a crashed run and on Ctrl-C too.
If the restore itself ever fails it says so loudly and leaves the backup on disk rather than pressing on.
Why a wrapper and not something inside the mod: love.load calls
config.initialize, keybindings.initialize and user.initialize long before
main.lua reaches require("accessibility").initialize(). By the time any of
our Lua runs, the save directory has already been read — the swap has to happen
around the process.
Override the interpreter path with LOVE=/path/to/lovec.exe if yours differs.
Runtime files the game also drops next to the source during dev (config.json,
user.json, keybindings.json, savegames) are already in .gitignore.
Reading the console
lovec.exe gives a console window, and every utterance is mirrored there as a
[speech] line — so speech is verifiable from a log rather than only by ear:
| Prefix | Meaning |
|---|---|
[speech]! |
interrupted whatever was being said |
[speech]* |
urgent, spoken immediately (bypasses the frame queue) |
[speech] |
queued normally |
If something mysteriously does not speak
Read the startup self-test. It reports every patch and every descriptor probe.
Most menu narration reads the game's file-local variables via debug.getupvalue,
so a renamed local in a future game version shows up there as
PROBE BROKEN: no upvalue 'x' rather than as silence three screens in.
ok (unset until opened) is normal.
Publishing
The development tree has no git remote, and must not be given one. It holds all 1838 files of a commercial title. Pushing it anywhere would distribute the game.
Publishing therefore means: rebuild a separate repository that contains only the mod, and force-push that.
sh accessibility/publish/publish.sh
This clones the dev tree to ../alchemist-accessibility-publish, runs
git-filter-repo to keep only accessibility/ and CLAUDE.md, lifts
accessibility/publish/README.md and install.patch up to the root (so a visitor
to the mod repo finds them where they expect), and drops the publish machinery
itself.
Then the check that matters: it lists every path in the rewritten history and aborts if anything that is not the mod or its docs survived. A clean run says:
clean: history contains only the mod and its docs
If it says ABORT: non-mod files present in history, do not push — a game
file leaked through the filter.
The script prints the push commands and stops rather than pushing for you:
cd ../alchemist-accessibility-publish
git remote add origin https://code.iamtalon.me/talon/alchemist-accessibility.git
git push --force -u origin master
--force is not a mistake and not a recovery step. git-filter-repo rewrites the
history from scratch every time, so the published commits are new objects on every
publish. The mod repo is derived output; force-pushing it is the normal path.
⚠ Paste those as separate lines. If a shell wraps the remote add line, the
URL ends up on its own and gets run as a command.
Rebasing onto a new game version
Commit the new pristine tree on top of the vanilla-0.4.2 baseline, then replay
the mod commits. The only game-file conflict possible is the single main.lua
line. Then run the startup self-test and read it: it tells you immediately which
patches and probes the new version broke.