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

re: who selects a loadout -- the pak entry does; the Arsenal pak is stage-scoped

Browse Source 
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.
This commit is contained in:
Sylpheed RE agent
2026-08-27 13:09:07 +00:00
parent 2b2d984f0c
commit 2b9709eaa0
4 changed files with 156 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

35
docs/re/BACKLOG.md
View File

@@ -827,6 +827,41 @@ unknown, what evidence exists, and what the first step would be. Move an item in
field; the stat keys in records not opened here (`MegaTons`, `BulletLimit`,
`CrewCount`, `HP_CLASS`); why the roster lists 59 of 131.
* ✅ **(2026-08-27) WHO SELECTS A LOADOUT: THE PAK ENTRY DOES — the Arsenal pak
is STAGE-SCOPED, 168 entries = 28 stages x 6 languages.** Also a **correction
to the entry below**.
[structures/hangar-loadout-system](structures/hangar-loadout-system.md),
artefact `data/hangar-loadouts.txt` (+40 lines, 1 changed heading).
🧪 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 x 6**, and the other 12 = 2 x 6 (the item
table and a sibling). Each entry is one stage's whole Hangar config.
🔑 The `UNITS` roster is **the flight for that stage**, and it changes across
the campaign as the story does — 5 distinct rosters over 15 / 5 / 5 / 2 / 1
stages: Bird 1-4 + `Rhino1-Katana`/`Rhino2-Ellen`/`Rhino3-Gene`/`Rhino4-Yoji`;
a Raymond/Gene/Katana/Ellen variant; **`Rhino2-Katana` ALONE** (5 stages);
a 7-pilot variant; and one with `Rhino4-Brandon`. **Every count is a multiple
of 6 and they sum to 28** — the disc's stage count by a fourth independent
route.
⚠️ **CORRECTION to the entry below**: 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. The contents genuinely vary per entry —
`PlayerSET_ARM1` has **5** distinct contents, `STANDARD_ARM1` **3**,
`ExSET_NOSE` **4**; the `SNNSET_*`/`NULL_*` sets have exactly 1 each. 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** — the method
works, the convention is not one of the eight guessed. So which entry is which
stage is still unknown.
* ✅ **(2026-08-27) THE HANGAR LOADOUT SYSTEM — the layer above the item chain.**
[structures/hangar-loadout-system](structures/hangar-loadout-system.md),
artefact `data/hangar-loadouts.txt`, regenerator