fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: wep_85 is the ONLY declared-but-unshipped asset; the package gaps are unused numbers

Browse Source 
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.
This commit is contained in:
Sylpheed RE agent
2026-08-28 10:33:41 +00:00
parent 09b7ac7b7f
commit 3412bf3a85
2 changed files with 68 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
docs/re/BACKLOG.md
View File

@@ -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).

42
docs/re/structures/arsenal-item-weapon-chain.md
View File

@@ -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.