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

@@ -155,9 +155,41 @@ these are metres from the map origin. **There is no scale slot** — an asteroid
size comes from its group's `AsteroidModelName`, which is why one group is one
model plus one placement list.
## 🔴✅ CORRECTION — S28 does have a definition: it borrows Stage 14's (2026-08-28)
Withdrawing "`S28_p1` has an asteroid volume with no definition". That came from a
set-difference over **file names**, which cannot see reuse. Joining the fields
**per phase** instead:
| table | the phases that declare it |
|---|---|
| `S01_asteroid.tbl` | S01.Phase_1, S01.Phase_2 |
| `S04_asteroid.tbl` | S04.Phase_1, S04.Phase_2 |
| `S05_asteroid.tbl` | S05.Phase_1, S05.Phase_2 |
| `S08_p1` / `S08_p2` | S08.Phase_1 / S08.Phase_2 |
| `S13_asteroid.tbl` | S13.Phase_1 |
| `S14_p1_asteroid.tbl` | S14.Phase_1 |
| **`S14_p2_asteroid.tbl`** | **S14.Phase_2 *and* S28.Phase_1** |
| `test_s8p1_asteroid.tbl` | **S02.Phase_1** |
**S28.Phase_1 declares `S14_p2_asteroid.tbl` while using its own
`S28_p1_AsteroidVolume_wp` mesh** — it scatters Stage 14's rock list inside its
own volume. Nine tables, nine volumes, one table shared by two phases.
⚠️ The earlier census's own arithmetic contained this: 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.
⚠️ **`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:**
`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`).
## 🟡 Not settled
* Why `S28_p1` has an asteroid volume and no definition (S28 is the challenge
mission that alone flies `rou_f004`, see [[stage-numbering-and-player-craft]]).
* Whether the quaternion is object→world or world→object, and its handedness —
the norm test cannot tell them apart.