re: S28 does have an asteroid definition - it borrows Stage 14's

Withdrawing my own repeated claim that S28_p1 has an asteroid volume with no
definition. It came from a set-difference over FILE NAMES, which cannot see
reuse. Joining the fields per PHASE settles it:

  S28.Phase_1   MapMesh = S28_p1_AsteroidVolume_wp.col
                AsteroidDefinition = S14_p2_asteroid.tbl

S28 scatters Stage 14 phase 2's rock list inside its own volume. Nine
definition tables and nine _AsteroidVolume_wp meshes, with one table shared by
two phases: S14_p2_asteroid.tbl -> S14.Phase_2 and S28.Phase_1.

The earlier census's own arithmetic already contained the answer: the four
values counted x12 (2 per language pack) were S01, S04, S05 - two phases of ONE
stage - and S14_p2, which is two phases of TWO different stages. The count was
right; reading x12 as "two phases of the same stage" was the error.

test_s8p1_asteroid.tbl is not test-only either - it is what S02.Phase_1 ships
with. A test_ name here is a leftover, not a dead table.

The true residual is two phases and it is the opposite pairing to what I
recorded: S01.Phase_3 has the volume and no definition (S01 keeps its volume
across all three phases but scatters rocks only in 1-2), and S02.Phase_1 has a
definition and no volume (MapMesh is the plain mapmesh_box_500km).

All fifteen artefacts byte-identical.
This commit is contained in:
Sylpheed RE agent
2026-08-28 03:44:14 +00:00
parent 5787b04f28
commit cdd4af98bd
3 changed files with 73 additions and 3 deletions

View File

@@ -6060,3 +6060,41 @@ dictionary-attack lever remains without a corpus.
🟡 Not settled: why `S28_p1` has an asteroid volume with no definition; the two
unnamed `_Test` variant objects; what `Placement_*`/`RouteTest_*` are for.
---
## 🔴✅ 2026-08-28 — S28 does have an asteroid definition: it borrows Stage 14's
Item (a). **Withdrawing my own repeated claim** that "`S28_p1` has an asteroid
volume with no definition". It came from a set-difference over **file names**,
which cannot see reuse. Joining the fields **per phase** settles it:
```
S28.Phase_1 MapMesh = S28_p1_AsteroidVolume_wp.col
AsteroidDefinition = S14_p2_asteroid.tbl
```
**S28 scatters Stage 14 phase 2's rock list inside its own volume.** Nine
definition tables ↔ nine `_AsteroidVolume_wp` meshes, with **one table shared by
two phases** — `S14_p2_asteroid.tbl``S14.Phase_2` *and* `S28.Phase_1`.
⚠️ **The earlier census's own arithmetic already contained the answer.** The four
values counted **×12** (2 per language pack) were `S01`, `S04`, `S05` — two phases
of *one* stage — and `S14_p2`, which is two phases of **two different stages**.
Reading ×12 as "two phases of the same stage" was the error; the count was right
and my interpretation of it was not.
⚠️ **`test_s8p1_asteroid.tbl` is not test-only either** — it is what
**`S02.Phase_1`** ships with. A `test_` name here is a leftover, not a dead table.
(That also softens the `_Test`-dangling pattern: a `test_`-named *table* can be
live even when `_Test`-named *declarations* dangle.)
✅ **The true residual is two phases, and it is the opposite pairing to what I
recorded**: `S01.Phase_3` has the volume and no definition (S01 keeps its volume
across all three phases but scatters rocks only in 12), and `S02.Phase_1` has a
definition and no volume (its `MapMesh` is the plain `mapmesh_box_500km`).
Corrected in `asteroid-fields.md` and `INDEX.md`.
🟡 Not settled: whether the quaternion is object→world or world→object; the two
unnamed `_Test` variant objects; what `Placement_*`/`RouteTest_*` are for.