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

re: every weapon placed (declared x mounted, 131); a fourth undeclared table

Browse Source 
Partitioned all 131 Weapon.ID records against the two data routes by which a
weapon is ever named - a field name in an EnumWeapon record, and a Turret_NNN
record's WeaponID value:

                    mounted   not mounted
  declared            105         22
  not declared          0          4

105 + 22 + 0 + 4 = 131, with no unexplained cell. Both marginals re-derive
unit-substructure-records' own numbers independently: mounted 105, and
22 + 4 = its "26 weapons no turret mounts".

The empty cell is the result: nothing is mounted without being declared, 0 of
131, so declaration is the superset of mounting. The four undeclared and
unmounted records are therefore reachable by neither route. Each appears
exactly once per pak copy (x6) and only as a Weapon record's ID value; the live
control Weapon_TCAF_DeltaSaber_Beam appears x18 as an EnumWeapon field name and
x228 as a Turret_NNN.WeaponID. That places Weapon_TCAF_DeltaSaber_Laser_Ttrl,
the weapon this pass set out to find, and unifies all four as orphan datasheet
rows.

Recorded as powerless rather than as evidence: the image holds 0 exact strings
for the four, but also 0 for the live control and 0 for Weapon_NULL. Only three
Weapon_-prefixed strings exist at all and 0 contain Ttrl - the executable names
no weapon, so the negative does not discriminate.

New: sweeping EnumWeapon RECORDS rather than the three declared tables gives 130
distinct field names, not 127. The extra three come from a fourth record, pak
key 305595319, resolved as EnumWeapon_TestS01.tbl, carrying Weapon_TestS01_Gun/
_Laser/_Missile. It dangles at both ends - no stage declares it, and its three
weapons are the only declared names with no Weapon.ID record. 130 - 3 = 127
restores the previous pass's union.

All fifteen artefacts byte-identical.
This commit is contained in:
Sylpheed RE agent
2026-08-28 04:50:35 +00:00
parent a304df1e50
commit 074c0296af
2 changed files with 94 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

58
docs/re/structures/weapon-struct-runtime.md
View File

@@ -310,3 +310,61 @@ definition whose fields the disc defaults — craft/`UNIT` stats, which the Hang
UI exposes only as a `Gross Weight` class and which
[the menu route could not reach at all](../weapon-datasheet-runtime.md), are the
obvious next target.
## ✅ Every weapon placed: declared × mounted, 131 with no unexplained cell
The previous pass left four weapons "declared by no table". Partitioning all
**131** `Weapon.ID` records against the two routes by which a weapon is ever
named in data — a field name in an `EnumWeapon` record, or a `Turret_NNN`
record's `WeaponID` value — closes them:
| | mounted on a turret | not mounted |
|---|---:|---:|
| **declared** by an `EnumWeapon` table | **105** | 22 |
| **not declared** | **0** | **4** |
`105 + 22 + 0 + 4 = 131`. Two independent checks land exactly:
* **105 mounted** re-derives [unit-substructure-records](unit-substructure-records.md)'s
own "`Weapon.ID` 131, mounted 105" from a different direction.
* **22 + 4 = 26** re-derives that document's "The 26 weapons no turret mounts".
🔑 **The empty cell is the result.** *Nothing is mounted without being
declared* — 0 of 131. Declaration is the superset of mounting, so the four
undeclared-and-unmounted records are reachable by **neither** data route:
```
Weapon_TCAF_DeltaSaber_Laser_Ttrl Weapon_TCAF_DeltaSaber_NoseGun_Ttrl
Weapon_TCAF_DeltaSaber_NoseGun_None Weapon_ADAN_Attacker_S_GunTurret
```
That places `Weapon_TCAF_DeltaSaber_Laser_Ttrl`, the one this pass set out to
find, and unifies all four: **orphan datasheet rows.** Sweeping every archive,
each appears exactly **once per pak copy (×6) and only as a `Weapon` record's
`ID` value** — never as an `EnumWeapon` field, never as a `WeaponID`, never
anywhere else. The live control `Weapon_TCAF_DeltaSaber_Beam` behaves completely
differently: ×18 as an `EnumWeapon` field name and ×228 as a `Turret_NNN.WeaponID`.
### ⚠️ One route was run and has NO power — recorded so it is not re-run
"Does the executable name them instead?" The image contains **0** exact strings
for all four — but it also contains **0** for `Weapon_TCAF_DeltaSaber_Beam` and
**0** for `Weapon_NULL`. Only three strings start with `Weapon_` at all
(`Weapon_Release`, `Weapon_NoEquipment`, `Weapon_CurrentWeapon` — UI/field keys,
not weapon ids), and **0** contain `Ttrl`. The image names no weapon whatsoever,
so this negative does not distinguish the four from a live weapon. **Powerless,
not evidence.**
### ✅ A fourth `EnumWeapon` table — `EnumWeapon_TestS01.tbl`, declared by nothing
Sweeping `EnumWeapon` records rather than the three *declared* tables gives
**130** distinct field names, not the 127 of the previous pass. The extra three
come from a fourth record, pak key **305595319**, present in the same six
archives and carrying exactly three fields — `Weapon_TestS01_Gun`, `_Laser`,
`_Missile`. Its name resolves as **`EnumWeapon_TestS01.tbl`**.
It dangles at **both** ends: **no stage declares it** (the 22 stage objects use
only `_Test`, `_EX5`, `_Tutorial`), and **none of its three weapons has a
`Weapon.ID` record** — they are the only 3 of the 130 declared names with no
datasheet row. `130 − 3 = 127`, restoring the previous pass's union. A shipped
table, referenced by nothing, naming weapons that do not exist.