1. A different hash family. The corpus knows three (idxd-tag-hash.md):
name_hash, tag_hash, ixud_hash. Scoring all 5977 harvested names x 6
prefixes: GP_TITLE 8/16 and GP_PAUSE_MENU 6/11 under name_hash (the
positive controls), and tag_hash and ixud_hash explain NOTHING anywhere
-- including the paks name_hash does explain. So they are not the TOC
function, and the unnameable pair is not keyed by a different one.
GP_MAIN_GAME_E2D stays at 0/711 under all three.
2. The executable. sylpheed.db's strings table holds 7140 rows, of
which exactly two look like asset paths -- Data\gmicon002_2.t32 and
Data\gmicon006_2.t32, in a Data\ directory nothing else on the disc
uses -- and neither resolves in any archive. The binary is not the name
source; it holds two strays and no table.
3. Name transformations -- 13 of them on the 419 config paths, all 0.
The container runs out here. Those TOC keys hash names that exist on
neither the disc nor the executable in readable form. The only lever
left is a dictionary attack using name_hash's shape (top byte = the
character-sum checksum), and that needs a plausible name corpus this
disc does not contain. Noted as blocked rather than improvised around.
The port does not need these names: sprites and bundles are readable by
content (T8aD, RATC), and the config records already say which asset
each HUD element uses. Only the archive-key to name mapping is missing.
Artefact +22 lines / 0 deletions; the other eight regenerate
byte-identical.
Chasing more prefixes for the 419 HUD config paths would have been the
same mistake twice, so this censuses the whole disc: harvest every
plausible asset-name string from every archive (6027), hash each under
the 16 known path prefixes, and ask per archive what fraction of its TOC
that explains. idxd-container.md and idxd-tag-hash.md own the hash;
neither says which archives are reachable by it.
The result is bimodal. GP_TITLE 16/16, GP_PAUSE_MENU 11/11,
GP_STAGE_CLEAR 44/44, GP_CHALLENGE 151/151, GP_MOVIE_THEATER 56/56,
MiscBin 40/40, GP_GAMEOVER, GP_BUNK, GP_SYSTEM, GP_TUTORIAL and fonts
are at 100%; tables.pak 78/79, GP_DIALOG 139/140, the six language paks
115/117; GP_MAIN_GAME_* 751/1119. Then the cliff: the six
GP_MAIN_GAME_*2D.pak at 0 of 711 each, and GP_READY_ROOM at 6 of 1106 --
the largest UI pak on the disc, not previously noted anywhere.
Eleven paks at 100% in the same run is the control that makes 0.0% a
finding rather than a failed guess.
So the 419 HUD paths are not missing assets: nothing in the 2D paks is
reachable by name from the disc's own strings at all. Those TOC keys
hash names that are not written anywhere readable.
Also refuted first: the 419 values under 13 name transformations, every
one scoring 0 against the E2D 711 and against all 16630 entries.
Not settled: what those names are. The lever left is the hash's shape
-- the top byte is the character-sum checksum -- but that needs a name
corpus the disc does not contain.
New structure doc, artefact and regenerator; the other eight regenerate
byte-identical.
