re: the asteroid-field tables (AsteroidGroup_00N) decoded

New doc docs/re/structures/asteroid-fields.md, indexed.

Half the chain was already in the corpus: stage-definition-table and
stage-mission-tables record the per-phase AsteroidDefinition naming a .tbl,
and unit-datasheet-static partitions Generic and finds 10 per pack whose only
field is {EnumAsteroidGroup}, "an asteroid-group file". Neither says what is
inside them.

The table: 10 objects per pack x 6 packs = 60, 384 AsteroidGroup_* records,
4 or 7 groups per object. Every record carries exactly three fields, all 384,
no partials - AsteroidModelName (28 distinct; mob_n050..n056 x24 each,
mob_n040..n043 x18), AsteroidFrameName (64 distinct, Frame_S<NN>[_pN]_
Asteroid_NN, the same names regn-map-grid reports the Route tables showing),
and EnumAsteroid (37 distinct, 1..588, 6633 per pack summed).

Enum<Thing> is a COUNT; Enumerate<Thing> names a TABLE. EnumAsteroidGroup
equals its object's group count in 54 of 60 and EnumAsteroid is a plain
integer - the opposite of the Enumerate* join rule. The -erate is the
difference. Count-style fields still are not safe: the 6 failures are ONE
object repeated per language pack, declaring 4 while holding 7.

The tenth object is unreferenced and it is the one that miscounts. Joining by
frame prefix, nine objects match the nine AsteroidDefinition values one to
one; the tenth carries Frame_Alpha_S01_Asteroid, Frame_Alpha_S01_Haze and
Frame_TAlpha_S01_Asteroid and is named by nothing.

S28 has an asteroid VOLUME but no asteroid DEFINITION: mcol-collision lists
nine _AsteroidVolume_wp meshes (…, S28_p1); the nine AsteroidDefinition values
are those eight plus test_s8p1. Eight shared, one different each way.

Not settled: what EnumAsteroid counts of; why S28_p1 has a volume and no
definition. The name->object join did not reproduce by hash under name_hash,
mod 0x00FFF9D7, or a 24-bit mask - the join used is by frame prefix.

All fifteen artefacts byte-identical.
This commit is contained in:
Sylpheed RE agent
2026-08-28 01:32:52 +00:00
parent 80235857af
commit a6e8eca436
3 changed files with 136 additions and 0 deletions

View File

@@ -5703,3 +5703,52 @@ S7S16 + S2427,29 and for S28, and the roster omits both while keeping
corpus already decodes"; what it does not say is that there are only **46
distinct** values disc-wide. `AsteroidGroup_00N` / `AsteroidModelName` are new to
the corpus. Written up in `docs/re/structures/player-tuning-tables.md`.
---
## ✅ 2026-08-28 — the asteroid-field tables (`AsteroidGroup_00N`) decoded
Item (a), the new nouns from the roster census. New doc
`docs/re/structures/asteroid-fields.md`, indexed.
The chain was already half in the corpus: [[stage-definition-table]] /
[[stage-mission-tables]] record the per-phase **`AsteroidDefinition`** naming a
`.tbl`, and [[unit-datasheet-static]] partitions `Generic` and finds **10 per pack
whose only field is `{EnumAsteroidGroup}` — "an asteroid-group file"**. What
neither says is what is inside them.
**The table.** 10 objects per pack × 6 packs = 60, **384 `AsteroidGroup_*`
records**, 4 or 7 groups per object (12 objects with 4, 48 with 7). Every record
carries exactly **three** fields, all 384, no partials: `AsteroidModelName` (28
distinct — `mob_n050``mob_n056` ×24 each, `mob_n040``mob_n043` ×18),
`AsteroidFrameName` (64 distinct, `Frame_S<NN>[_pN]_Asteroid_NN` — the same names
[[regn-map-grid]] reports the `Route` tables showing), and `EnumAsteroid`
(37 distinct, **1…588**, 6 633 per pack summed).
**`Enum<Thing>` is a COUNT; `Enumerate<Thing>` names a TABLE.**
`EnumAsteroidGroup` equals its object's group count in **54 of 60**, and
`EnumAsteroid` is a plain integer — the opposite of the `Enumerate*` join rule.
**The `-erate` is the difference.** ⚠️ And `Count`-style fields still are not
safe: the 6 failures are **one object repeated per language pack**, declaring
`4` while holding `7`.
🔑 **The tenth object is unreferenced, and it is the one that miscounts.**
Joining by frame prefix: nine objects match the nine `AsteroidDefinition` values
one-to-one (S01 4 groups, S04/S05/S13/S14_p1/S14_p2/S08_p1/S08_p2 7 each, Test 4),
and the tenth carries **`Frame_Alpha_S01_Asteroid`, `Frame_Alpha_S01_Haze`,
`Frame_TAlpha_S01_Asteroid`** and is named by nothing — an `Alpha` Stage-01
variant with its own haze. An abandoned table is exactly what a wrong declared
count looks like.
🔑 **S28 has an asteroid *volume* but no asteroid *definition*.**
[[mcol-collision]] lists nine `_AsteroidVolume_wp` meshes — S01, S04, S05,
S08_p1, S08_p2, S13, S14_p1, S14_p2, **S28_p1**. The nine `AsteroidDefinition`
values are those eight plus **`test_s8p1`**. Eight shared, one different each way.
🟡 Not settled: what `EnumAsteroid` counts *of* (instances per frame fits the
1…588 range, untested); why S28_p1 has a volume and no definition. 🔴 **The
name→object join did not reproduce by hash** — `AsteroidDefinition` values do not
map to their objects' pak entry keys under `name_hash`, nor under that key
reduced `mod 0x00FFF9D7` or masked to 24 bits. The join above is by frame prefix,
which is direct evidence; either those keys are not name hashes or
[[archive-naming]]'s resolver differs from `unitgroup.name_hash`. Not chased.