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

32
docs/re/BACKLOG.md
View File

@@ -660,6 +660,38 @@ unknown, what evidence exists, and what the first step would be. Move an item in
🟡 Still open: who CONSUMES `[phase+356]`/`[phase+360]`, and whether
`Stage30`–`Stage33` exist on disc.
* ✅🔴 **(2026-08-27) THE SECTION READER IS NOT INI-ONLY — it is a generic
accessor over the IDXD tables — and `UNIT_MAX`'s absence now has a REAL control.
[structures/isl-condition-builtins](structures/isl-condition-builtins.md),
artefact `data/config-keys.txt`.**
🔴 **Correction to yesterday's label.** Resolving the `r4` string at *every*
call site of `sub_82448AA0` and `sub_824482D0` yields **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. Decisive:
**`BASE_INFO`, `SYSTEM`, `MISSIONS`, `FONTS` are all present as IDXD record keys
on the disc.** So the pair is a **generic named-section accessor over the IDXD
`.tbl` containers**, with `config.ini` as one small extra input — not "the INI
reader".
⚠️ **My first re-test was INVALID and only its control caught it.** IDXD record
keys are **`tag_hash`**, not `name_hash` (case-sensitive, modulus `0x00FFFFDF`;
`unitgroup.py` documents the difference). Scanning 190 782 records with
`name_hash` returned 0 for `STAGENN_UNIT_MAX` **and 0 for every control name** —
which is exactly how a bad test announces itself.
✅ **Redone with `tag_hash`:** 7 750 / 7 750 IDXD entries parsed (matches the
corpus census), **190 782 records, 3 496 distinct keys**, controls
`BASE_INFO`/`SYSTEM`/`MISSIONS`/`FONTS` **found**, and
**`STAGE01…33_UNIT_MAX` → 0 records**. With the literal search (0 in 26 443
entries) and `config.ini` printed in full, the section exists **nowhere on the
disc**. The `GP_HANGAR_ARSENAL` word-hit that worried me is settled — not a
record key. ⇒ **`PLANE = 200` / `VESSEL = 20` for every stage**, now on a
controlled test.
📎 `data/config-keys.txt` lists the whole vocabulary — a lower bound (literal
`addis`/`addi` keys only), but it is the engine's own configuration surface and
directly useful to the port.
🟡 Still open: who CONSUMES `[phase+356]`/`[phase+360]`; whether `Stage30`–`Stage33`
exist; and the fallbacks behind the other 64 sections.
## ✅✅ SOLVED — the mission freeze was a modal sign-in dialog (2026-08-26)
`XamShowSigninUI` opens a modal dialog and `xeXamDispatchDialog` blocks the