From 3412bf3a852919131fa1cefe13dec7ae1a1cf95f Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Fri, 28 Aug 2026 10:33:41 +0000 Subject: [PATCH] re: wep_85 is the ONLY declared-but-unshipped asset; the package gaps are unused numbers The obvious follow-up to last commit's wep_85 finding: the weapon packages number 00 to 84 with 26 holes, so are those holes cut weapons too? Partitioning every number 00-85 by package-present x 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. The one occupied cell is the one already known: wep_85, named 16 times, with no package. It is an isolated cut, not a pattern, which refutes the natural expectation that finding one cut weapon means finding a family of them. 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 package set and the weapon vocabulary agree in both directions but for that single entry. Running the identical test on the craft family gives a clean negative. Every rou_f### number appearing inside an .xpr against every number named in the parsed data: 16 in both, 0 named-but-unshipped, 0 shipped-but-unnamed. 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). No craft was cut. So across both families the disc ships exactly what it declares, with the single exception of that one weapon. All seventeen artefacts byte-identical. --- docs/re/BACKLOG.md | 26 ++++++++++++ .../structures/arsenal-item-weapon-chain.md | 42 +++++++++++++++++++ 2 files changed, 68 insertions(+) diff --git a/docs/re/BACKLOG.md b/docs/re/BACKLOG.md index 645904a0..c1c2e390 100644 --- a/docs/re/BACKLOG.md +++ b/docs/re/BACKLOG.md @@ -6854,3 +6854,29 @@ partition is declared × *mounted*, not whether a package ships. `eff_h308`, `eff_j002_e01`, `eff_j002_e02`, `eff_n0071`. ❔ The `.xpr` route is exhausted under every prefix the disc uses; a different container or a runtime generator is the remaining possibility. + +--- + +## ✅ 2026-08-28 — `wep_85` is the ONLY declared-but-unshipped asset; the gaps are unused numbers + +Item (a). The obvious follow-up to `wep_85`: the weapon packages number **00–84 +with 26 holes** — are those holes cut weapons too? Partitioning every number +00–85 by *package present* × *named in the parsed pak data*: + +| | named in data | not named | +|---|---|---| +| **package present** | **59** | **0** | +| **package absent** | **1** | 26 | + +`59 + 0 + 1 + 26 = 86`. 🔑 **The 26 gaps are unused numbers — nothing names +them.** The single occupied cell is `wep_85` (named 16×, no package): **an +isolated cut, not a pattern.** ⚠️ The other zero matters too — **0 shipped +packages are never named**, so the two sets agree in both directions but one. + +✅ **Craft models: 16 of 16, both residuals empty.** Same test on `rou_f###`: 16 +in an `.xpr` and named, **0** named-but-unshipped, **0** shipped-but-unnamed. The +16 are `f001–f004`, `f101`/`f102`/`f104`–`f106`, `f201`/`f202`, `f301`–`f303`, +`f401`/`f402` — the hundreds digit groups them into five families with internal +holes (no `f103`, no `f203`). **No craft was cut.** + +Written up in [arsenal-item-weapon-chain](structures/arsenal-item-weapon-chain.md). diff --git a/docs/re/structures/arsenal-item-weapon-chain.md b/docs/re/structures/arsenal-item-weapon-chain.md index be0d3f5b..65bf9431 100644 --- a/docs/re/structures/arsenal-item-weapon-chain.md +++ b/docs/re/structures/arsenal-item-weapon-chain.md @@ -90,3 +90,45 @@ screen side. * `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.