re: the config is an INI that ships nearly empty -- every stage takes 200/20
Corrects my own label: sub_824480D0/sub_82448AA0/sub_824482D0 is not an XML reader. The 40 <?xml pak entries are XPR2 resource manifests (XBGMesh/Texture declarations). The real config is a loose config.ini at the disc root, header comment "application / game-part initial- settings table", and every key this code touches is an INI section or key name. The shipped file is 400 bytes: [SYSTEM] (empty) and [LANGUAGE]. No [STAGENN_UNIT_MAX] anywhere, and UNIT_MAX/VESSEL appear in 0 pak entries -- so the lookup always misses and every stage runs on the defaults PLANE=200, VESSEL=20. The absence is controlled: the same scan decompressed 26443 entries across 41 paks and found MSG_DEMO 192x, mapmesh_box_500km 162x and <?xml exactly 40x, the census number. Last iteration's null was worthless -- it used s[8:] instead of s[10:] for the Z1 header and searched the index rather than the .pNN data. Using the corpus's own reader was the whole difference. Docs only; artefacts byte-identical.
This commit is contained in:
Sylpheed RE agent
@@ -627,6 +627,39 @@ unknown, what evidence exists, and what the first step would be. Move an item in
|
||||
🟡 Whether `Stage30`–`Stage33` exist on disc (33 table slots, 28 scripts) is
|
||||
still open.
|
||||
|
||||
* ✅🔴 **(2026-08-27) THE CONFIG IS AN INI, IT SHIPS NEARLY EMPTY, AND EVERY STAGE
|
||||
TAKES `PLANE = 200` / `VESSEL = 20`.
|
||||
[structures/isl-condition-builtins](structures/isl-condition-builtins.md).**
|
||||
🔴 **Correction to my own label.** I called `sub_824480D0`/`sub_82448AA0`/
|
||||
`sub_824482D0` an *XML* config reader on the strength of the pak census's 40
|
||||
`<?xml` entries. Those 40 are **XPR2 resource manifests** (`<RDF Version="XPR2">`,
|
||||
`<XBGMesh>`, `<Texture … D3DFMT_DXT1_SRGB>`) — mesh/texture declarations, not
|
||||
config.
|
||||
✅ **The real config is a loose `config.ini` at the disc root**, header comment
|
||||
「アプリケーション/ゲームパート初期設定テーブル」 — "application / game-part
|
||||
initial-settings table", noting that `SYSTEM` holds what the game and every game
|
||||
part share. That matches every key this code touches (`SYSTEM`, `GP_SCRIPT`,
|
||||
`SCRIPTS`, `Resource2D`, `TABLE`, `GRAPH_PATH`, `EX_FONT`, `SCRIPT_ID`,
|
||||
`SCRIPT_PATH`, `BASE_INFO`, `PLANE`, `VESSEL`, `STAGENN_UNIT_MAX`) — they are INI
|
||||
section and key names.
|
||||
🔑 **The shipped file is 400 bytes**: `[SYSTEM]` (empty) and `[LANGUAGE]`
|
||||
(`= eng` default plus `#0x01…#0x06`). **No `[STAGENN_UNIT_MAX]` anywhere**, and
|
||||
`UNIT_MAX`/`VESSEL` appear in **0** pak entries.
|
||||
✅ **The absence is CONTROLLED.** The same scan over all 41 paks decompressed
|
||||
**26 443 entries** and found `MSG_DEMO` 192×, `mapmesh_box_500km` 162× and
|
||||
`<?xml` exactly **40×** — the census number. ⚠️ Last iteration's null was
|
||||
worthless: that hand-rolled scan used `s[8:]` instead of `s[10:]` for the `Z1`
|
||||
header and searched the index file rather than the `.pNN` data. **Using the
|
||||
corpus's own reader (`unitgroup.py`) was the whole difference.**
|
||||
⇒ **The lookup always misses, so every stage runs on the defaults: `PLANE = 200`,
|
||||
`VESSEL = 20`.** For the port these are hardcoded fallbacks, not per-stage data.
|
||||
🟡 A hash search (in case the section were name-hashed like a pak entry) found
|
||||
**0** of `name_hash("STAGE01…33_UNIT_MAX"/"PLANE"/"VESSEL")` as pak entry keys;
|
||||
8 of 35 appeared as 4-byte words inside entries, seven in the 1.1 GB `sound.pak`
|
||||
— the chance rate for a 32-bit needle at that size, not a finding.
|
||||
🟡 Still open: who CONSUMES `[phase+356]`/`[phase+360]`, and whether
|
||||
`Stage30`–`Stage33` exist on disc.
|
||||
|
||||
## ✅✅ SOLVED — the mission freeze was a modal sign-in dialog (2026-08-26)
|
||||
|
||||
`XamShowSigninUI` opens a modal dialog and `xeXamDispatchDialog` blocks the
|
||||
|
||||
@@ -335,6 +335,60 @@ offsets recur, and the one ISL-region hit that looked promising
|
||||
(`0x82273400 lwz r11, 360(r11)`) is a **vtable slot 90 call** — `r11` is the
|
||||
vptr — which is built-in 123, consistent with the known mapping.
|
||||
|
||||
### ✅🔴 (2026-08-27) The values: the config is an **INI**, it ships nearly EMPTY, and every stage takes the defaults
|
||||
|
||||
🔴 **First, my own label from the previous pass is wrong.** I called
|
||||
`sub_824480D0` / `sub_82448AA0` / `sub_824482D0` an *XML* config reader because
|
||||
the pak census counts 40 `<?xml` entries. Those 40 are **XPR2 resource
|
||||
manifests** — `<RDF Version="XPR2">`, `<XBGMesh Name=… DataFile=…/>`,
|
||||
`<Texture Name=… Source=… Format="D3DFMT_DXT1_SRGB"/>` — mesh and texture
|
||||
declarations, nothing to do with game config.
|
||||
|
||||
The real config is a **loose INI at the disc root**, `config.ini`, whose header
|
||||
comment reads *「アプリケーション/ゲームパート初期設定テーブル」* — "application /
|
||||
game-part initial-settings table" — and notes that the `SYSTEM` section holds
|
||||
settings the game and every game part share. That matches every key this code
|
||||
touches: `SYSTEM`, `GP_SCRIPT`, `SCRIPTS`, `Resource2D`, `TABLE`, `GRAPH_PATH`,
|
||||
`EX_FONT`, `SCRIPT_ID`, `SCRIPT_PATH`, `BASE_INFO`, `PLANE`, `VESSEL`,
|
||||
`STAGENN_UNIT_MAX` — INI section and key names.
|
||||
|
||||
**And the shipped file is 400 bytes.** In full it has two sections:
|
||||
|
||||
```
|
||||
[SYSTEM]
|
||||
|
||||
[LANGUAGE]
|
||||
= eng ; default
|
||||
#0x01 = eng ; XC_LANGUAGE_ENGLISH
|
||||
#0x02 = jpn ; XC_LANGUAGE_JAPANESE
|
||||
… deu / fra / esp / ita
|
||||
```
|
||||
|
||||
`[SYSTEM]` is **empty**, and there is no `[STAGENN_UNIT_MAX]` anywhere.
|
||||
|
||||
| check | result |
|
||||
|---|---|
|
||||
| `.ini` files on the extracted disc | **1** — `config.ini`, 400 bytes, printed in full |
|
||||
| `[STAGENN_UNIT_MAX]` sections in it | **0** |
|
||||
| `UNIT_MAX` in any pak entry | **0** |
|
||||
| `VESSEL` in any pak entry | **0** |
|
||||
|
||||
The pak scan is **controlled**: the same loop over all 41 paks decompressed
|
||||
**26 443 entries** and found `MSG_DEMO` 192×, `mapmesh_box_500km` 162× and
|
||||
`<?xml` exactly 40× — the census number. So the reader works and the absence is
|
||||
real. (An earlier hand-rolled scan used `s[8:]` instead of `s[10:]` for the `Z1`
|
||||
header and searched the index file rather than the `.pNN` data — that one's null
|
||||
result was worthless.)
|
||||
|
||||
> ⇒ **The lookup always misses, so every stage runs on the defaults:
|
||||
> `PLANE = 200`, `VESSEL = 20`.**
|
||||
|
||||
🟡 A hash search was run too, in case the section were name-hashed like a pak
|
||||
entry: `name_hash("STAGE01…33_UNIT_MAX")`, `name_hash("PLANE")`,
|
||||
`name_hash("VESSEL")` — **0 hits as pak entry keys**. Eight of the 35 hashes did
|
||||
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.
|
||||
|
||||
🟡 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
|
||||
|
||||
Reference in New Issue
Block a user