fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

re: the section reader is a generic IDXD accessor; UNIT_MAX absence re-tested

Browse Source 
Resolving the r4 string at every sub_82448AA0 / sub_824482D0 call site
gives 65 section names and 54 int keys (data/config-keys.txt) -- far
more than the 400-byte config.ini holds -- and BASE_INFO, SYSTEM,
MISSIONS and FONTS are all present as IDXD record keys on the disc.  So
it is a generic named-section accessor over the .tbl containers, not
"the INI reader" as I labelled it yesterday.

My first re-test was invalid: IDXD record keys are tag_hash, not
name_hash.  Scanning with name_hash returned 0 for STAGENN_UNIT_MAX and
0 for every control name too -- the control is what exposed it.

Redone with tag_hash: 7750/7750 entries parsed, 190782 records, 3496
distinct keys, controls BASE_INFO/SYSTEM/MISSIONS/FONTS found, and
STAGE01..33_UNIT_MAX -> 0 records.  With the literal search and
config.ini printed in full, the section exists nowhere on the disc, so
PLANE=200 / VESSEL=20 for every stage now rests on a controlled test.

Docs + one new artefact; ISL artefacts byte-identical.
This commit is contained in:
Sylpheed RE agent
2026-08-27 11:33:30 +00:00
parent e46055ffae
commit 731c3cd849
3 changed files with 196 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

35
docs/re/structures/isl-condition-builtins.md
View File

@@ -389,6 +389,41 @@ entry: `name_hash("STAGE01…33_UNIT_MAX")`, `name_hash("PLANE")`,
appear as 4-byte words *inside* entries, seven of them in the 1.1 GB `sound.pak`;
that is the chance rate for a 32-bit needle in a blob that size, not a finding.
### ✅ (2026-08-27) The absence re-tested properly — and the reader is NOT INI-only
🔴 **Correction to the label above.** `sub_82448AA0` is not "the INI config
reader". Resolving the `r4` string at **every** call site of it and of
`sub_824482D0` (artefact `data/config-keys.txt`) gives **65 section names and 54
int keys** — `MISSIONS`, `FONTS`, `StageResource`, `EPILOGUE_MOVIES`, `WEAPONS`,
`UNITS`, `SOUNDS`, `ACHIEVEMENTS_REQUIREMENTS`, `LINE_PITCH`, `MSG_FONT_SIZE`,
`SUBTITLE_Y` … far more than the 400-byte `config.ini` holds. And the decisive
check: **`BASE_INFO`, `SYSTEM`, `MISSIONS` and `FONTS` are all present as IDXD
record keys on the disc.** So this pair is a **generic named-section accessor
over the IDXD `.tbl` containers**, with `config.ini` as one small extra input.
⚠️ **My first re-test was invalid, and only its control showed it.** IDXD record
keys are **not** `name_hash` — they are **`tag_hash`** (case-sensitive, modulus
`0x00FFFFDF`; `unitgroup.py` documents it). Searching 190 782 records with
`name_hash` returned 0 for `STAGENN_UNIT_MAX` *and* 0 for every control name,
which is what exposed it.
Redone with `tag_hash`:
| | |
|---|---|
| IDXD entries parsed | **7 750 / 7 750** (matches the corpus census) |
| records scanned | **190 782**, 3 496 distinct keys |
| control names found as record keys | **`BASE_INFO`, `SYSTEM`, `MISSIONS`, `FONTS`** ✅ |
| `STAGE01…33_UNIT_MAX` records | **0** |
With the literal search (0 in 26 443 decompressed entries) and `config.ini`
printed in full, the section exists **nowhere on the disc** — not as an INI
section, not as an IDXD record. The earlier worry that the `GP_HANGAR_ARSENAL`
word-hit might be real is settled: it is not a record key.
> ⇒ **`PLANE = 200` / `VESSEL = 20` for every stage** — now on a controlled test
> rather than a scan whose reader had never been checked.
🟡 Its neighbours belong to the same cluster: `builtin103` reads
`[phase+10156]` and `[phase+10152]` (9 and 7 writers), and a sibling vtable stub
clears `[phase+10152]`. The shape is an engine→script status trio, but that is a