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

re: the weapon law does not generalise to units; the whole exception is S14

Browse Source 
Applied the declared x deployed partition to units. Three vocabularies had to
be separated first: declared = field names of the 31 EnumUnit records (118);
deployed = slot 0 of each UnitGroup member tuple (122); datasheet = Generic
records carrying HP (114, which re-derives unit-datasheet-static's own number
from a different direction, as a control). Declared and deployed share the UN_*
vocabulary and overlap on 109; the datasheet's IDs are a third naming, disjoint
from both.

                    deployed   not deployed
  declared            109           9
  not declared         13           1

The cell that is empty for weapons (0 mounted-but-undeclared of 131) holds 13
for units, so the general form of that law is refuted: a unit CAN be deployed
with no table declaring it.

But the 13 are one coherent family - every one is UN_S14_p1_Asteroid_cmesh_* or
UN_S14_p2_Asteroid_cmesh_*. Asking the other population settles it: S01 8/8,
S04 10/10, S05 5/5, S08 6/6, S13 4/4 declared - 33 of 33 - while S14 declares
0 of 13, and non-asteroid deployed-but-undeclared is 0. The law survives in a
narrower form: every deployed unit is declared, except S14's asteroid collision
meshes.

Why S14 differs is not settled. It is the stage whose asteroid table S28
borrows, but nothing measured connects the borrow to the missing declarations,
so that is recorded as a coincidence rather than a cause.

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

31
docs/re/BACKLOG.md
View File

@@ -6260,3 +6260,34 @@ declares it**, and its three weapons are the only declared names with **no
🟡 Not settled: why those four were kept on the disc; whether the debriefing code
selects the `EX_` key list for challenge missions; which challenge stage is which
leaderboard mode.
---
## ✅❌ 2026-08-28 — the weapon law does not generalise to units; the exception is all S14
Item (b): apply the declared × deployed 2×2 to units.
Three vocabularies had to be separated first: **declared** = field names of the
**31** `EnumUnit` records (118); **deployed** = slot 0 of each `UnitGroup` member
tuple (122); **datasheet** = `Generic` records carrying `HP` (**114**, which
re-derives `unit-datasheet-static`'s own number as a control). Declared and
deployed share the `UN_*` vocabulary (109 overlap); the datasheet's `ID`s are a
third naming, disjoint from both — the "two vocabularies" trap, now three.
| | deployed | not deployed |
|---|---:|---:|
| declared | 109 | 9 |
| **not declared** | **13** | 1 |
❌ **Refuted as a general law:** the cell that is empty for weapons
(0 mounted-but-undeclared of 131) holds **13** for units.
✅ **The 13 are one family** — all `UN_S14_p{1,2}_Asteroid_cmesh_*`. The other
population settles it: S01 8/8, S04 10/10, S05 5/5, S08 6/6, S13 4/4 declared —
**33 of 33 — while S14 declares 0 of 13**, and **non-asteroid
deployed-but-undeclared = 0**. Narrower law: every deployed unit is declared,
*except* S14's asteroid collision meshes.
🟡 Not settled: **why** S14 differs. It is the stage whose asteroid table S28
borrows, but nothing measured links the borrow to the missing declarations — a
coincidence recorded as a coincidence.

54
docs/re/structures/unit-group-table.md
View File

@@ -210,3 +210,57 @@ record inside the table, not by hashing the name.**
[`tag_hash`](idxd-tag-hash.md), recovered since this was written. Record keys
and field keys are both `tag_hash` of their own name — 6960 / 6960 field keys
across all 28 `UnitGroup` tables, 0 matching `name_hash`.
## ✅❌ Declared × deployed — the weapon law does **not** generalise, and the whole exception is S14
[weapon-struct-runtime](weapon-struct-runtime.md) established that nothing is
*mounted* without being *declared* — 0 of 131, an empty cell. Running the same
partition over units refutes the general form of that law.
Three vocabularies had to be separated first, because they are not the same set:
| set | source | size |
|---|---|---:|
| **declared** | field names of the **31** `EnumUnit` records | 118 |
| **deployed** | slot 0 of each `UnitGroup` member tuple | 122 |
| datasheet | `Generic` records carrying `HP` | **114** |
The datasheet count re-derives [unit-datasheet-static](unit-datasheet-static.md)'s
own **114** from a different direction, as a control. `declared` and `deployed`
share one vocabulary (`UN_*`), overlapping on 109; the datasheet's `ID`s are a
third naming, disjoint from both.
| | deployed | not deployed |
|---|---:|---:|
| **declared** | 109 | 9 |
| **not declared** | **13** | 1 |
❌ **The cell that was empty for weapons holds 13 for units.** Units *can* be
deployed without any table declaring them.
✅ **But the 13 are one coherent family, not strays** — every one is
`UN_S14_p1_Asteroid_cmesh_*` or `UN_S14_p2_Asteroid_cmesh_*`. Asking the other
population settles it:
| stage | asteroid meshes deployed | of those, declared |
|---|---:|---:|
| S01 | 8 | **8** |
| S04 | 10 | **10** |
| S05 | 5 | **5** |
| S08 | 6 | **6** |
| S13 | 4 | **4** |
| **S14 p1** | 9 | **0** |
| **S14 p2** | 4 | **0** |
**33 of 33 declared everywhere else; 0 of 13 in S14.** And
**non-asteroid deployed-but-undeclared = 0** — the entire violation is this one
stage's asteroid field. So the law survives in a narrower form: *every unit that
is deployed is declared, except S14's asteroid collision meshes.*
🟡 **Why S14 differs is not settled here.** It is suggestive that S14 is the
stage whose asteroid table S28 borrows (see
[asteroid-fields](asteroid-fields.md)), but nothing measured connects the borrow
to the missing declarations — **a coincidence worth recording, not a cause.**
The remaining cells are small and benign: 9 declared-but-never-deployed units,
and one datasheet id, `Ship_`, that is neither.