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:
@@ -5703,3 +5703,52 @@ S7–S16 + S24–27,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.
|
||||
|
||||
Reference in New Issue
Block a user