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

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

@@ -303,3 +303,55 @@ ninth is that Prometheus-driver test entry, so **all 9 are accounted for**.
not the 13 `Asteroid_cmesh` entities it deploys. So "asteroids are exempt from
the manifest" is **refuted for S14 itself**; whatever the cause, it is specific
to the collision-mesh entities.
### ✅ S14 resolved: the 13 are **dangling deployments**, not a manifest omission
The previous pass left S14 as the one unexplained cell and offered no cause.
Two measurements settle what kind of thing it is.
**1. The deployment side is identical.** S14's asteroid-cmesh squadron records are
indistinguishable from a stage that declares its own — same squadron ids
(`GNN901`, `GNN902`, …) and the same five named fields with the same values:
```
Count 1 SideID Neutral AIID AI_Structure FormationID Formation_1_only DisableInterval No
```
So nothing about *how* S14 deploys them differs. **The wrong record would not have
been a control here; these are the same kind of record, compared field for field.**
**2. The definition side is where they differ — completely.** Asking whether each
cmesh entity has a unit definition at all:
| stage | deployed | declared in `EnumUnit` | has a `Generic` record with `HP` | has **any** `Generic` record |
|---|---:|---:|---:|---:|
| 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 |
| **S14 p1** | 9 | **0** | **0** | **0** |
| **S14 p2** | 4 | **0** | **0** | **0** |
🔑 **33 / 33 / 33 for the five, and 0 / 0 / 0 for S14.** The 13 are not merely
absent from the load manifest — 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.
That reframes the exception and rescues the law. Nothing is "deployed without
being loaded" in any working sense: **S14's roster holds 13 dangling references**,
and the manifest is consistent with them being unloadable. It also explains why
the omission is exactly the cmesh class and nothing else in S14 — the other six
units S14 deploys are declared and defined normally.
🟡 **What this predicts, and what would settle it, needs the emulator.** Either
those 13 collision meshes simply fail to appear in Stage 14 — a shipped bug — or
some route outside the unit chain supplies them. Flying S14 and checking whether
the large asteroids collide would distinguish the two. **NEEDS-HUMAN**; no static
route here can tell them apart.
⚠️ Note the two asteroid populations are different sets and must not be 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` (the scatter table) but deploys **no** cmesh entity
of its own, so the borrow does not carry the dangling references with it.