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

re: S14's 13 are dangling deployments - the unit chain is absent for them

Browse Source 
Two measurements settle the last open cell of the unit partition.

The deployment side is identical. S14's asteroid-cmesh squadron records match a
declaring stage's field for field - same squadron ids (GNN901, GNN902, ...) and
the same Count 1 / SideID Neutral / AIID AI_Structure / FormationID
Formation_1_only / DisableInterval No. Nothing about how S14 deploys them
differs, and these are the same kind of record compared like for like.

The definition side differs completely. Per stage, deployed / declared /
Generic-with-HP / any Generic: S01 8/8/8/8, S04 10/10/10/10, S05 5/5/5/5,
S08 6/6/6/6, S13 4/4/4/4 - 33/33/33 for the five - and S14 p1 9/0/0/0,
S14 p2 4/0/0/0.

So the 13 are not a manifest omission: they have no unit definition anywhere on
the disc, not even an un-HP'd Generic row. UnitGroup_S14.tbl names entities that
do not exist - 13 dangling references. That rescues the law (nothing is
deployed-without-being-loaded in any working sense) and explains why the gap is
exactly the cmesh class and nothing else in S14.

What it predicts needs the emulator: either those collision meshes fail to
appear in Stage 14 - a shipped bug - or another route supplies them. Flying S14
and checking whether the large asteroids collide distinguishes the two; no
static route can. Recorded as NEEDS-HUMAN.

Also recorded so the two asteroid populations are not conflated: asteroid-fields'
AsteroidGroup_00N tables scatter mob_n0NN models, while these are
UN_<stage>_Asteroid_cmesh_* squadron entities. S28.Phase_1 borrows
S14_p2_asteroid.tbl but deploys no cmesh of its own, so the borrow does not
carry the dangling references.

All fifteen artefacts byte-identical.
This commit is contained in:
Sylpheed RE agent
2026-08-28 05:39:44 +00:00
parent 0f7169e14d
commit 0502c736cf
2 changed files with 84 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
docs/re/BACKLOG.md
View File

@@ -6320,3 +6320,35 @@ exists with six names, one of which is `UN_mn040_Asteroid_Big` — S14 declares
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.
---
## ✅ 2026-08-28 — S14's 13 are dangling deployments; the unit chain is absent for them
Item (a). Two measurements settle the last open cell of the unit partition.
**The deployment side is identical.** S14's asteroid-cmesh squadron records match
a declaring stage's field for field — same squadron ids (`GNN901`…) and the same
`Count 1 / SideID Neutral / AIID AI_Structure / FormationID Formation_1_only /
DisableInterval No`. Nothing about how S14 deploys them differs.
**The definition side differs completely.** Per stage, deployed / declared /
`Generic`-with-`HP` / any `Generic`: S01 8/8/8/8, S04 10/10/10/10, S05 5/5/5/5,
S08 6/6/6/6, S13 4/4/4/4 — **33/33/33 for the five** — and **S14 p1 9/0/0/0,
p2 4/0/0/0**.
🔑 The 13 are not a manifest omission: they have **no unit definition anywhere on
the disc**, not even an un-`HP`'d `Generic` row. `UnitGroup_S14.tbl` names
entities that do not exist — **13 dangling references**. That rescues the law
(nothing is deployed-without-being-loaded in a working sense) and explains why
the gap is exactly the cmesh class and nothing else in S14.
🟡 **NEEDS-HUMAN to go further:** either those collision meshes fail to appear in
Stage 14 (a shipped bug) or another route supplies them. Flying S14 and checking
whether the large asteroids collide distinguishes the two; no static route can.
⚠️ Recorded so the populations are not conflated: `asteroid-fields`'
`AsteroidGroup_00N` tables scatter `mob_n0NN` models; these are
`UN_<stage>_Asteroid_cmesh_*` squadron entities. S28.Phase_1 borrows
`S14_p2_asteroid.tbl` but deploys no cmesh of its own, so the borrow does not
carry the dangling references.