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

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

@@ -453,6 +453,39 @@ attribute. Inside the ISL region the only hits are the two writers in
Dropping this sub-item: it needs type information the offset index does not
carry.
### ✅ (2026-08-27) The two-function model is confirmed by a 64/65 vs 0/54 dissociation
Taking every literal key from `data/config-keys.txt` and testing it against the
3 496 distinct IDXD record keys on the disc (`tag_hash`):
| class | argument to | present as an IDXD **record key** |
|---|---|---|
| section names | `sub_82448AA0` | **64 / 65** |
| field keys | `sub_824482D0` | **0 / 54** |
The two classes are each other's control, and the split is total. It 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 of course none of them is a record key.
🔑 **The single absent section is `LANGUAGE`** — which is precisely the one real
section in the disc-root `config.ini`. The same API serves both stores, and the
data shows the seam.
So the earlier worry that "64 sections have unknown hardcoded fallbacks" was
overblown: **all but one are real data on the disc**. `STAGENN_UNIT_MAX` is the
genuine exception, and it is absent because its name is *built at runtime* from
the stage index rather than being one of these literals.
📎 The artefact now records which 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`**, and the
per-language `GP_MAIN_GAME_*` paks for the enum tables.
🟡 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