2b9709eaa0
Settled by elimination with two controls. The 15 loadout names appear as a field VALUE nowhere on the disc -- 0 occurrences across every pak -- while the control Arbalest_155KG, which is referenced, appears 150 times as a value in the same pak. They occur only as the field names of the UNITS record. They are not in the executable either; control: WEAPONS (a section key) is, Arbalest_155KG is not. So nothing references a loadout by name. The selection is which pak entry the Hangar loads. GP_HANGAR_ARSENAL.pak has 180 IDXD entries in 10 shapes; 168 carry a UNITS roster = 28 stages x 6 languages, and the other 12 = 2 x 6. Each entry is one stage's whole Hangar config, and its UNITS roster is the flight for that stage -- 5 distinct rosters over 15 / 5 / 5 / 2 / 1 stages, including one where Rhino2-Katana flies alone. Every count is a multiple of 6 and they sum to 28, the disc's stage count by a fourth independent route. Corrects the previous commit: it read the pak with setdefault, so '15 loadouts / 24 allow-lists / STANDARD_ARM1 has 11 entries' is the union of first-seen records, not one table. Contents vary per entry -- PlayerSET_ARM1 has 5 distinct contents, STANDARD_ARM1 3, ExSET_NOSE 4. The chain and both controls (60/60, 70/88) are per-record and unaffected; only the per-list sizes were over-generalised. Not settled: the entry filenames. name_hash probing over 8 templates x 40 indices x 6 languages resolved 0, while the same probe's controls <lang>\weapon.tbl and <lang>\strings.tbl resolved 12/12. Artefact +40 lines / 1 changed heading; the other four regenerate byte-identical.