A path that names its own archive is a free name->key fact, since a pak TOC holds
only hashes. Swept them disc-wide and aimed the result at the 2D /
GP_READY_ROOM blocker.
Seven fields carry a game: value - BackGroundPackage 18, StageResourcePackage 23,
TBL_3D 6, LodEnumTable 7, MotionEnumTable 7, one PATH, one anonymous - giving 63
distinct paths in two forms: 42 file-form (41 present on the extracted ISO, the
single miss being the bare directory game:\hidden\Resource3D\, which is not a
file) and 21 archive+entry (20 of 20 resolve inside the archive they name; the
21st is sound.pak+ with an empty entry).
The blocker test is a measured zero. The six 2D paks and GP_READY_ROOM hold 1817
distinct keys between them and NONE is named by a + path. The dictionary's total
reach is 20 of 16630 keys, 0.12%, and every one lands in DefTables or
GP_HANGAR_ARSENAL - archives that are already partly named.
The route is exhausted rather than unlucky: these paths exist only in the seven
fields above, and none of those fields ever addresses a 2D or ready-room asset.
The blocker keeps its earlier structural reason (six identical 711-key TOCs, 0 of
711 shared with any other archive).
The full dictionary is recorded: 6 x <lang>\GP_HANGAR_ARSENAL_3D.tbl in
GP_HANGAR_ARSENAL.pak, and EnumGameModel_* plus EnumLODSet_* for S24, S26, S27,
S28, S29, Tutorial and test in DefTables.pak.
Left unexplained: both DefTables families are seven names with S25 absent and no
story stage present at all.
All fifteen artefacts byte-identical.
Item: retry the blocker with the "wrong prefix" lesson from
StageMessageSet_S02.tbl. The retry was already run and the owning doc says so:
archive-naming's "13 name transformations" list already includes 2d\, eng\,
hud\ and GP_MAIN_GAME_2D\ prefixes, every one scoring 0 against both the E2D
pak and all 16630 entries. Reading the doc end to end first would have shown
that in a minute. Recorded so the idea is not proposed a third time.
What the re-open did add - two measurements the earlier passes did not make:
1. The six 2D archives share ONE key set: 711 keys, identical in all six.
Intersection = union = 711; 4266 entries, 711 distinct keys. The entry names
are language-independent - the language lives in the pak file name, not the
entry path. That refutes any <lang>\ prefix hypothesis structurally, not
merely by a zero score: if the names carried a language directory the six
key sets would differ.
2. The 2D key space is disjoint from the rest of the disc - 0 of 711 appear in
any non-2D archive, while disc-wide 2010 of 16630 keys are shared between
archives. Sharing is common; this set never does it.
The six named GP_READY_ROOM entries are all fonts - deu\GOTHICB.TTF, eng\,
esp\, fra\, ita\ likewise, and jpn\HGRGE00.TTF. The doc recorded the count "6
named" without saying what they are: localisation fonts named from elsewhere on
the disc, not a sample of the archive's own artwork vocabulary, so they cannot
seed the dictionary attack the doc names as the last lever. Only 2 of 1106
GP_READY_ROOM keys appear in another archive.
Still blocked, now for a sharper reason: the 2D names are language-independent,
unshared, and absent from disc and executable alike.
All fifteen artefacts byte-identical.
All six language copies carry the identical 337 unnamed IDXD hashes. Partitioned
by record-name shape (53 shapes), 333 map onto families the corpus already
documents: 131 weapon datasheets, 114 unit datasheets, 64 unit Faces tables, 10
unit message sets, 8 chatter rule tables, 5 enumerations/formations/placement.
114 is exactly the corpus's unit count (43 Craft + 71 Vessel) -- these are the
tables the corpus has always worked with, reached by SHAPE because they have no
names. Naming them adds nothing.
The Enumerate object in each GP_MAIN_GAME_* is EMPTY, zero fields, which is why
route 2 named 1283 entries in DefTables and 0 here.
The 4 unclassified objects are new -> docs/re/structures/player-tuning-tables.md:
the analog stick response curves (8 axes, 11 samples + a named Count = 11, tested
8/8; yaw/roll/throttle are the identity ramp, the shaping is all on pitch and the
camera axes; adv_yaw is non-monotone and unexplained), the player craft's flight
envelope (Booster, 50 fields -- the player side of the AA_/AV_ pair documented
for NPCs -- plus TacticalManeuver, SpecialAttack + three gauge bands,
SpecialWeapon, Misc), the Stage 16 boss (identified by Shell_S16Boss_* ids;
Guardian HP 65000, Core 42000), and one unidentified Generic naming eff_n0071.
New regenerator main_game_unnamed.py, 112-line artefact, byte-identical across
two runs; the other twelve artefacts verify unchanged.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
The string harvest could never name DefTables because those names are not
spelled out as "something.tbl" anywhere on the disc -- they are declared.
An IDXD object whose single record is named Enumerate is a DECLARATION TABLE:
its field NAMES are the names of other objects, each resolving as
name_hash("<field name>.tbl"). EnumLODSet_test.tbl declares 676,
EnumGameModel_test.tbl 360; the disc holds 144 such objects (138 in DefTables,
one in each GP_MAIN_GAME_*) declaring 1298 distinct names.
Route 2 names +1283 entries route 1 could not. 130 + 1283 + 12 = 1425, no
overlap, 99.2 % coverage. Zero partials: of 5 suffixes x 6 prefixes, ('', .tbl)
scored 1036/1036 and every other combination scored 0. Residual in full: 8
declaration tables nothing declares, 2 LOD sets (Model rou_e004 / rou_e013), 2
motion sets; 15 declared names have no pak entry at all.
REFUTED alongside it: the 40 XPR2 manifests are not the naming source -- their
82 Name= values and 82 DataFile/Source paths resolve 0 entries under any of the
5 suffixes. They share the MODEL namespace only: 40 of the 82 appear as the
Model field value inside the tables.
Artefact +17/-18, every line paired, byte-identical across two runs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
Splitting every unnamed entry by magic turns the coverage percentages into an
explanation.
The three low-coverage UI archives have ZERO unnamed IDXD. GP_HANGAR_ARSENAL
is 180 IDXD, 180 named, 0 unnamed -- its 1191 unnamed entries are 1149 T8aD/RATC
plus 42 LSTA, i.e. sprites. GP_MISSION_SELECT and GP_DEBRIEFING_PILOTLOG hold
no IDXD objects at all. So "22.6 % named" is misleading: every data table in
that pak is named, and these three are the same artwork-naming phenomenon as the
blocked 2D and READY_ROOM archives.
DefTables is the only genuine data gap: 1425 IDXD, 130 named, 1295 unnamed, in
17 record-name shapes -- Generic + Level_0..Level_3 (807, LOD sets) and Default +
EnumMotions + Generic + ReferenceFrames +/- Motion_break/dead/down (463, motion
sets). One LOD and one motion table per model. Level_0, EnumMotions and
ReferenceFrames appear in no document.
Control: the 100 % archives have no unnamed entry of any kind, and GP_MAIN_GAME_E
is 667/337 IDXD with zero unnamed artwork -- two failure modes, not a gradient.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
archive_naming.py already harvests 6027 candidate names under 16 prefixes, and
testing its candidate set directly shows it names all 24 StageParameter_S<NN>
objects, 24/24. The previous entry presented that naming as new -- it is not.
What was new was the identification (which object is which stage, the shared
_Tutorial table, IsBoss16Enable = S16), not the method.
The real gap, now closed: the sweep reported only per-archive percentages and
never emitted WHICH entry got which name, which is exactly why nobody could say
the settings objects were StageParameter_*. It now prints the resolved name
families per archive -- 6573 named entries, 1631 families disc-wide.
Determinism caught again by the verify loop: the resolved map was built by
iterating a set, so collided hashes picked a different winner each run. Now
iterated sorted(). Second time in two iterations -- any map built from a set
needs a sort.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
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.
