Syplheed-Reborn/docs/re/structures/arsenal-item-weapon-chain.md

✅✅ The 59-of-131 arsenal question — an item names a HARDPOINT, not a weapon

Open since the weapon datasheet was decoded: the Hangar's arsenal lists 59 weapons, the disc's Weapon table has 131, and the previous pass showed the two name sets overlap in 0 values. This closes it.

An Arsenal item does not reference a Weapon record. It references a Turret_NNN HARDPOINT SLOT on the player craft's own unit table, and the slot is what carries the WeaponID. Three hops:

GP_HANGAR_ARSENAL.pak      Arbalest_155KG
   .PlayerWeapon    ───▶   Turret_050            (a slot on UN_f001_TCAF_DeltaSaber_T_Player)
       .WeaponID    ───▶   Weapon_DSaber_P_wep_50_Cannon   (a Weapon record)

Artefact ../data/arsenal-chain.txt, regenerator tools/re-capture/arsenal_chain.py.

🧪 The controls

WEAPONS roster values	59
arsenal ITEM records (field set Model/Package/PlayerWeapon/Points/Power/Range/…)	59
item names that are roster values	55
roster values with no item record	4 — No_Equipment, NullWeapon_Arm1/2/3
distinct PlayerWeapon values that are a Weapon.ID	0 / 59
distinct PlayerWeapon values that are a Turret_NNN slot id	59 / 59
the full chain lands on a Weapon.ID	59 / 59

WingmanWeapon resolves identically, 59/59. The 4 roster entries with no item record are the empty-slot sentinels, so the roster is 55 real weapons + 4 nulls against 59 item records — the item table is the superset.

🔑 Wingmen fly a cheaper gun

Following the same 59 slots on different craft variants splits them cleanly:

craft variant	slots	distinct Weapon.ID reached
…DeltaSaber_T_Player, _W_Player, _A_Player	63	59 (Weapon_DSaber_P_wep_NN_*)
…DeltaSaber_T, _W, _T_EX5, _T_EX5_el	63	10 (Weapon_TCAF_DeltaSaber_Beam, …_Gun, …)

Same slot ids, same 59 arsenal items, but the _Player tables give each item its own weapon record while the AI tables collapse all 59 onto 10 generic behaviour classes. A wingman carrying an Arbalest_155KG does not fire the player's wep_50 ballistics.

That also explains the 131: 59 player weapons + 10 AI-Saber classes + the ship guns and ADAN weapons the turrets use.

Four of the player craft's 63 slots are referenced by no item: Turret_000 (the Weapon_NULL slot) and Turret_097 / _098 / _099.

✅ Upgrades a 🟡 from the previous pass

unit-substructure-records read the player craft's 63 Turret_NNN records as "a hardpoint catalogue, TurretCount 4 = how many mount at once", marked 🟡 because nothing showed the selection. The arsenal table is the selection, from an independent file, 59/59. Adopted.

The item record

Model / Package            rou_f001_wep_50_hangar (+ .xpr)   the Hangar display mesh
PlayerPackage / _LOD / _Motion    rou_f001_wep_50.xpr, Equip_EnumLODSet_wep_50.tbl,
WingmanPackage / _LOD / _Motion   Equip_EnumGameModel_wep_50.tbl
SilhouetteModel            rou_f001_wep_50_NA
PlayerWeapon / WingmanWeapon      Turret_050
Points 25000   Stage 6            develop cost, and the stage that unlocks it
Power B  Range B  Size L  Speed -  Weight 1.5    the Hangar's stat bars
Type g04b                  the slot-compatibility class
Dependency  MissionObjective      (empty on this item)

Model ties an arsenal entry to the meshes the corpus already decodes; Points and Stage are the develop economy that arsenal-develop-economy recovered from the screen side.

🟡 Not settled

• Type (g04b) is a slot-compatibility class. STANDARD_ARM1/2/3, STANDARD_NOSE, PlayerSET_*, ExSET_*, S01SET_*, S02SET_* are records whose only field is Type — the per-slot allow-lists — and the loadout records (Bird1-Sandra, Rhino1-Katana, … with Arm1/Arm2/Arm3/Nose/ UnitID) are the wingman loadouts. Named here, not opened.
• Dependency and MissionObjective are empty on the sampled item; what fills them elsewhere is unread.
• Which Weapon records the 26 never-on-a-turret weapons are.

✅ wep_85 is the only declared-but-unshipped asset — the gaps are unused numbers

The previous iteration found wep_85 declared in the datasheets with no rou_f001_wep_85.xpr. The obvious next question is whether it is the tip of a family: the shipped packages number 00–84 with 26 holes, so are those holes cut weapons too?

Partitioning every number 00–85 by package present × named anywhere in the parsed pak data:

	named in data	not named
package present	59	0
package absent	1	26

59 + 0 + 1 + 26 = 86 — the numbers 00 through 85.

🔑 The 26 gaps are simply unused numbers, not unshipped weapons. Nothing in the data names them at all. And the one occupied cell is the one already known: wep_85, named 16×, with no package. It is an isolated cut, not a pattern.

⚠️ The other zero is worth as much: 0 shipped packages are never named — every rou_f001_wep_NN.xpr on the disc is referenced by the data. So the weapon package set and the weapon vocabulary agree in both directions but one entry.

✅ Craft models: 16 of 16, both residuals empty

Running the identical test on the rou_f### craft family — every number that appears inside an .xpr against every number named in the parsed data:

• in an .xpr and named: 16
• named but not in any .xpr: 0
• in an .xpr but never named: 0

The 16 are f001–f004, f101, f102, f104–f106, f201, f202, f301–f303, f401, f402 — the hundreds digit groups them into five families, with holes inside each (no f103, no f203).

So no craft was cut, and the method that found wep_85 returns a clean negative here. Across both families the disc ships exactly what it declares, with the single exception of that one weapon.