e46055ffae
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.