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.
0502c736cf