From 5ec24b8ef90bd0ce680a70545239225795050432 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Fri, 28 Aug 2026 05:39:44 +0000 Subject: [PATCH] re: S14's 13 are dangling deployments - the unit chain is absent for them 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__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. --- docs/re/BACKLOG.md | 32 ++++++++++++++++ docs/re/structures/unit-group-table.md | 52 ++++++++++++++++++++++++++ 2 files changed, 84 insertions(+) diff --git a/docs/re/BACKLOG.md b/docs/re/BACKLOG.md index 9ea7607a..0b87f1c9 100644 --- a/docs/re/BACKLOG.md +++ b/docs/re/BACKLOG.md @@ -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__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. diff --git a/docs/re/structures/unit-group-table.md b/docs/re/structures/unit-group-table.md index 95ab1ed1..5d87d59e 100644 --- a/docs/re/structures/unit-group-table.md +++ b/docs/re/structures/unit-group-table.md @@ -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__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.