fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues 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 7ba415fbae
commit 33671c5086
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).