fix(re-capture): name_block_bases reads the disc from $SYLPHEED_DISC, loudly #44

fabi · 2026-09-16T19:08:58Z

fabi commented

2026-09-16 19:08:58 +00:00

name_block_bases.py's data-table section globbed /work/sylph_extract/**/*.pak, which has existed nowhere since /work became a clone. It matched nothing and reported "0 disc names" with no error. The committed artefact records 13,450, from back when that path existed. The disc now comes from $SYLPHEED_DISC, and running without it is an error (exit 1).

Verified: with SYLPHEED_DISC=…/sylph_extract, the section reproduces the committed figures exactly: 13,450 names, 50 / 261 rows, sub_82341A20 r30 0x82088F94 217 names 89% disc. Without the disc it exits 1.

⚠️ The artefact is deliberately not regenerated

Rebuilding docs/re/data/name-block-bases.txt from the current database changes findings: solved bases move, three perfect 15/15 rows vanish, and the file loses 280 lines. The cause is the database, not this script.

The string extractor's Shift-JIS path requires kana, so kanji-only Japanese never reaches strings. That includes the allocator's debug lines, e.g. 32B 未開放 %4d : 最大…使用量 %4d / %4d. The bases those names pinned no longer resolve: sub_8285F2C8 r5 @ 0x820AE7AC got 15/15 before and 7 now. The rule is a precision trade-off: of the 133 strings it rejects, the sample is mostly binary noise (%垂MAp). Loosening it is a heuristics decision, and regenerating first would bake the loss into an artefact that player-tuning-tables.md cites.

🤖 Generated with Claude Code

`name_block_bases.py`'s data-table section globbed `/work/sylph_extract/**/*.pak`, which has existed nowhere since `/work` became a clone. **It matched nothing and reported "0 disc names" with no error.** The committed artefact records 13,450, from back when that path existed. The disc now comes from `$SYLPHEED_DISC`, and running without it is an error (exit 1). **Verified:** with `SYLPHEED_DISC=…/sylph_extract`, the section reproduces the committed figures exactly: **13,450** names, **50 / 261** rows, `sub_82341A20 r30 0x82088F94 217 names 89% disc`. Without the disc it exits 1. ## ⚠️ The artefact is deliberately *not* regenerated Rebuilding `docs/re/data/name-block-bases.txt` from the current database **changes findings**: solved bases move, three perfect 15/15 rows vanish, and the file loses 280 lines. The cause is the database, not this script. The string extractor's Shift-JIS path **requires kana**, so kanji-only Japanese never reaches `strings`. That includes the allocator's debug lines, e.g. `32B 未開放 %4d : 最大…使用量 %4d / %4d`. The bases those names pinned no longer resolve: `sub_8285F2C8 r5` @ `0x820AE7AC` got **15/15** before and **7** now. The rule is a precision trade-off: of the 133 strings it rejects, the sample is mostly binary noise (`%垂MAp`). Loosening it is a heuristics decision, and regenerating first would bake the loss into an artefact that `player-tuning-tables.md` cites. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

fabi added 1 commit 2026-09-16 19:08:58 +00:00

fix(re-capture): name_block_bases reads the disc from $SYLPHEED_DISC, loudly

CI / Native — linux (pull_request) Successful in 2h3m46s

Details

CI / WASM — Web (pull_request) Successful in 28m6s

Details

CI / Formatting (pull_request) Successful in 1m19s

Details

4b022ca03b

Its data-table section globbed `/work/sylph_extract/**/*.pak`, a path that has
existed nowhere since `/work` became a clone. The glob matched nothing, so the
section reported "0 disc names" and an empty table with no error — while the
committed `docs/re/data/name-block-bases.txt`, generated back when the path
existed, records 13 450. The disc is required for that section, so a missing or
non-disc `$SYLPHEED_DISC` is now an error (exit 1), not an empty result.

Verified: without the disc, exit 1 with the message; with
`SYLPHEED_DISC=…/sylph_extract` (the original /work/sylph_extract), the section
reproduces the committed figures exactly — 13 450 distinct disc names,
50 / 261 data-table rows, `sub_82341A20 r30 0x82088F94 217 names 89% disc`.

⚠️ The artefact itself is deliberately NOT regenerated. Rebuilt from the current
database it changes findings — solved bases move, three 15/15 rows vanish, −280
lines — and the cause is the database, not this script: the string extractor's
Shift-JIS path requires kana, so kanji-only Japanese (e.g. the allocator's
`32B  未開放 %4d : 最大…使用量 %4d / %4d` debug lines) is not in `strings`, and
the bases those names pinned no longer resolve (sub_8285F2C8 r5 @ 0x820AE7AC:
15/15 before, 7 now). Regenerating would bake that regression into a cited
research artefact (`docs/re/structures/player-tuning-tables.md`).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

fabi merged commit 8865507880 into main

2026-09-16 20:02:53 +00:00

fabi referenced this issue from a commit

2026-09-16 20:02:54 +00:00

Merge pull request 'fix(re-capture): name_block_bases reads the disc from $SYLPHEED_DISC, loudly' (#44) from fix/name-block-bases-disc into main

fabi referenced this issue from a commit

2026-09-16 20:35:06 +00:00

chore: retire the last dead paths and names from the consolidation

fabi referenced this pull request

2026-09-16 20:35:25 +00:00

chore: retire the last dead paths and names from the consolidation #47

fabi referenced this pull request