# ✅✅ 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](unit-substructure-records.md) 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](unit-substructure-records.md) 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](../arsenal-develop-economy.md) 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.