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

re: the config sections are real disc data -- 64/65, with a clean 0/54 control

Browse Source 
Testing every literal key from data/config-keys.txt against the 3496
distinct IDXD record keys with tag_hash:

  section names (arg to sub_82448AA0) -> 64 / 65 present
  field  keys  (arg to sub_824482D0) ->  0 / 54 present

The two classes are each other's control and the dissociation is
total, confirming the model: sub_82448AA0 finds a RECORD keyed by
tag_hash(name); sub_824482D0 reads a FIELD whose name is a literal
string in the pool, so none of them can be a record key.

The single absent section is LANGUAGE -- the one real section in the
disc-root config.ini.  The same API serves both stores.

This deflates my own earlier framing: I had listed "64 sections whose
hardcoded fallbacks are worth pinning".  They are not fallbacks; all
but one are real data.  STAGENN_UNIT_MAX is the genuine exception,
because its name is built at runtime from the stage index.

The artefact now names the pak each record lives in -- notably
GP_HANGAR_ARSENAL.pak holds WEAPONS, UNITS, Camera, ControlTweak,
Rendering, AUTO_SETTINGS and IGNORE.

Docs + regenerated artefact; ISL artefacts byte-identical.
This commit is contained in:
Sylpheed RE agent
2026-08-27 11:54:36 +00:00
parent 49b5892df5
commit bc48fa576d
3 changed files with 142 additions and 71 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
docs/re/BACKLOG.md
View File

@@ -717,6 +717,37 @@ unknown, what evidence exists, and what the first step would be. Move an item in
90, `0x82290ED8`). This needs type information the offset index does not carry;
it is not a cheap static question and should not be reopened as one.
* ✅ **(2026-08-27) THE CONFIG SECTIONS ARE REAL DISC DATA — 64/65, and the two
reader functions separate perfectly.
[structures/isl-condition-builtins](structures/isl-condition-builtins.md),
artefact `data/config-keys.txt`.**
Testing every literal key from the artefact against the **3 496 distinct IDXD
record keys** with `tag_hash`:
**section names (arg to `sub_82448AA0`) → 64 / 65 present**;
**field keys (arg to `sub_824482D0`) → 0 / 54 present**.
The two classes are each other's control and the dissociation is total, which
confirms the model exactly: `sub_82448AA0(node, NAME)` finds a **record** keyed
by `tag_hash(NAME)`; `sub_824482D0(node, KEY)` reads a **field**, whose name is
a literal string in the record's pool — so none of them can be a record key.
🔑 **The single absent section is `LANGUAGE`** — precisely the one real section
in the disc-root `config.ini`. The same API serves both stores and the data
shows the seam.
✅ **This deflates my own earlier framing.** I had listed "64 sections whose
hardcoded fallbacks are worth pinning for the port". They are not fallbacks:
**all but one are real data on the disc.** `STAGENN_UNIT_MAX` is the genuine
exception, and only because its name is *built at runtime* from the stage index
rather than being one of these literals.
📎 The artefact now names the pak each record lives in: `tables.pak` for the
global tables (`MISSIONS`, `STAGES`, `SOUNDS`, `SUB_OBJECTIVE`,
`SQUADRON_ORDER_OBJECT`, `EPILOGUE_MOVIES`, `ACHIEVEMENTS_REQUIREMENTS`,
`FONTS`, `BASE_INFO`, …), **`GP_HANGAR_ARSENAL.pak` for `WEAPONS`, `UNITS`,
`Camera`, `ControlTweak`, `Rendering`, `AUTO_SETTINGS`, `IGNORE`** — so the
arsenal pak holds the canonical weapon/unit definitions — and the per-language
`GP_MAIN_GAME_*` paks for the enum tables.
🟡 Not settled: the CONTENTS of those records. Knowing `WEAPONS` lives in
`GP_HANGAR_ARSENAL.pak` is a pointer, not a decode; the field-level read is a
separate job per table.
## ✅✅ SOLVED — the mission freeze was a modal sign-in dialog (2026-08-26)
`XamShowSigninUI` opens a modal dialog and `xeXamDispatchDialog` blocks the