re: EnumUnit_S<NN> is the stage's LOAD MANIFEST; all 9 never-deployed units named

Joining each stage's own EnumerateUnit table to its own EnumerateSquadron table
is far sharper than the global partition: declared == deployed EXACTLY in 20 of
22 stages. S16 declares 4 it never deploys; S14 deploys 13 it never declares.
Every per-stage deployed-but-undeclared count is 0 except S14's 13, and that 13
is the entire disc-wide total - so the exception is one stage, not a scattering.

S16 explains what the table is. It declares 6 and deploys 2, and two of the six
are UN_e901_ADAN_Boss and UN_e910_core_ADAN_GeneratorCore - exactly the units
stage16-boss shows are brought in by their own loader chain (sub_82315AE8),
not by the squadron roster. So EnumUnit_S<NN> is the stage's load manifest, not
a mirror of the roster: a unit that code spawns is declared but never deployed.

That also closes the 9 declared-but-never-deployed units by name: the S16
code-spawned pair above, Test_ADAN_PrometheusDriver_InsideP2_01, and six
Ship_Test* placeholders.

S14 remains the one unexplained cell, and it is not a missing table:
EnumUnit_S14.tbl exists and declares six names, one of which is
UN_mn040_Asteroid_Big. S14 therefore declares an asteroid but not the 13
Asteroid_cmesh entities it deploys, which refutes "asteroids are exempt from the
manifest". Whatever the cause, it is specific to the collision-mesh entities.

All fifteen artefacts byte-identical.
This commit is contained in:
Sylpheed RE agent
2026-08-28 05:24:09 +00:00
parent 0ae295e9eb
commit f0dfff4fcd
2 changed files with 68 additions and 0 deletions

View File

@@ -6291,3 +6291,32 @@ deployed-but-undeclared = 0**. Narrower law: every deployed unit is declared,
🟡 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.
---
## ✅ 2026-08-28 — the per-stage view: `EnumUnit_S<NN>` is the stage's LOAD MANIFEST
Item (a). Joining each stage's own `EnumerateUnit` table to its own
`EnumerateSquadron` table is far sharper than the global partition:
**`declared == deployed` exactly in 20 of 22 stages**; S16 declares 4 it never
deploys; S14 deploys 13 it never declares. Every per-stage
deployed-but-undeclared count is 0 except S14's 13 — which is the entire
disc-wide total, so the exception is one stage, not a scattering.
🔑 **S16 explains the table's role.** It declares 6 and deploys 2; two of the six
are `UN_e901_ADAN_Boss` and `UN_e910_core_ADAN_GeneratorCore` — exactly the units
`stage16-boss` shows are loaded by their own chain (`sub_82315AE8`), not by the
squadron roster. So `EnumUnit_S<NN>` is the stage's **load manifest**: a unit
that code spawns is declared but never deployed.
**All 9 declared-but-never-deployed units are now named and accounted for**:
`UN_e901_ADAN_Boss`, `UN_e910_core_ADAN_GeneratorCore` (S16's code-spawned boss
pair), `Test_ADAN_PrometheusDriver_InsideP2_01`, and six `Ship_Test*`
placeholders (`Ship_Test`, `_Test2`, `_Test_2`, `_TestS01`, `_TestS01_2`,
`_TestS01_3`).
🟡 **S14 is still unexplained, and it is not a missing table.** `EnumUnit_S14.tbl`
exists with six names, one of which is `UN_mn040_Asteroid_Big` — S14 declares an
asteroid but not its 13 `Asteroid_cmesh` entities, which **refutes** "asteroids
are exempt from the manifest". Whatever the cause is, it is specific to the
collision-mesh entities.