fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: which archives the disc can name -- 100% for menu paks, 0.0% for the 2D paks and READY_ROOM

Browse Source 
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.
This commit is contained in:
Sylpheed RE agent
2026-08-27 15:08:24 +00:00
parent 152704afeb
commit 4e9d7deeb8
5 changed files with 199 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

66
docs/re/structures/archive-naming.md Normal file
View File

@@ -0,0 +1,66 @@
# ✅ Which archives the disc can name — and the two it cannot
The previous pass found that **0 of 419** in-game HUD config paths hash to a pak
entry ([hud-config](hud-config.md)). Chasing more prefixes would have been the
same mistake twice, so this censuses the whole disc instead: harvest **every**
plausible asset-name string from **every** archive, 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 (`name_hash` = a
checksum byte over a 24-bit modular value, case-insensitive, distinct from
`tag_hash`); neither says which archives are *reachable* by it. Artefact
`../data/archive-naming.txt`, regenerator `tools/re-capture/archive_naming.py`
(**6 027** candidate names × 16 prefixes).
## The result is bimodal
| archive | entries | named | |
|---|---:|---:|---|
| `GP_TITLE`, `GP_PAUSE_MENU`, `GP_STAGE_CLEAR`, `GP_CHALLENGE`, `GP_MOVIE_THEATER`, `GP_GAMEOVER`, `GP_BUNK`, `GP_SYSTEM`, `GP_TUTORIAL`, `MiscBin`, `fonts` | 2–151 | **all** | **100 %** |
| `tables.pak` | 79 | 78 | 98.7 % |
| `GP_DIALOG` | 140 | 139 | 99.3 % |
| `deu/eng/esp/fra/ita/jpn.pak` | 117 | 115 | 98.3 % |
| `GP_SAVE_LOAD` / `GP_LEADERBOARD` / `GP_OPTIONS` / `GP_MISSION_LOG` | 24–108 | | 91–94 % |
| `GP_MAIN_GAME_{D,E,F,I,J,S}` | 1 119 | 751 | 67.1 % |
| `GP_DEBRIEFING_PILOTLOG` | 234 | 78 | 33.3 % |
| `GP_HANGAR_ARSENAL` | 1 538 | 347 | 22.6 % |
| `DefTables` | 1 465 | 130 | 8.9 % |
| `GP_MISSION_SELECT` | 88 | 22 | 25.0 % |
| **`GP_READY_ROOM`** | **1 106** | **6** | **0.5 %** |
| **`GP_MAIN_GAME_{D,E,F,I,J,S}2D`** | **711** each | **0** | **0.0 %** |
| `sound.pak` | 9 519 | 1 | 0.0 % (a separate format — [sound-pak-contents](sound-pak-contents.md)) |
🔑 **The six 2D paks are at exactly 0.0 %, all six, 711 entries each** — while
eleven menu paks are at 100 % by the same method in the same run. That is the
control that makes it a finding rather than a failed guess: the method works, and
these archives are outside it.
🔑 **`GP_READY_ROOM` is a second such archive** — 1 106 entries, **6** named.
Not previously noted anywhere in `docs/re/`; it is the largest UI pak on the
disc and its names are as unreachable as the 2D paks'.
## What that means for the 419
The in-game HUD's asset paths are not "missing". **Nothing in the 2D paks is
reachable by name from the disc's own strings**, whatever the extension. So the
2D and READY_ROOM TOC keys are hashes of names that are **not written anywhere
we can read** — built by the tool chain, or from a string the executable
composes, or from a name list held outside these archives.
## 🧪 Also refuted here — 13 name transformations
Before the census, the 419 config values were re-hashed under 13 rewrites:
as-is, forward slashes, basename, basename without extension, without extension,
uppercased, `.rat` substituted, `2d\`/`eng\`/`hud\`/`GP_MAIN_GAME_2D\` prefixed,
and first-directory stripped. **Every one scored 0, both against the E2D pak's
711 entries and against all 16 630 entries on the disc.**
## 🟡 Not settled
* What names the 2D and `GP_READY_ROOM` TOCs actually hash. The one lever left is
the hash's own shape — the top byte is the character-sum checksum, so any
candidate is cheap to reject — but that needs a name corpus this disc does not
contain.
* Why `DefTables` (8.9 %) and `GP_HANGAR_ARSENAL` (22.6 %) sit in the middle;
probably just that most of their entries are tables referenced by records this
harvest does not treat as filenames. Not chased.