formats: decode the REGN header - a per-map spatial grid, new to the corpus

hidden/MiscBin.pak was undocumented: 40 entries, none name-resolved, holding 11
REGN objects and 11 MCOL objects (plus 18 others). Eleven of each pairs them one
per map.

The REGN header decodes to a bbox, an extent, a cell size, grid dimensions, six
counts and four section offsets - and it self-checks twice over all 11 objects:
extent == cell x dims holds exactly 11 of 11, and counts[3] equals the cell count
(1000 on every 10x10x10 map, 125 on every 5x5x5). Two independent fields
reproducing the same grid is what makes it a decode rather than a guess.

Three map sizes exist: half-extent 250000 with 50 km cells, 50000 with 10 km
cells, and 25000 with 10 km cells on a 5x5x5 grid.

Written without overclaiming against the question that prompted it: a mission's
enemy count rises and falls, so a scheduler with parameters exists somewhere, and
a per-map cell grid is the kind of structure such a thing is indexed by - but the
four data sections are unread and nothing here shows spawn parameters.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE

docs/re/structures/regn-map-grid.md

@@ -0,0 +1,70 @@
+# `REGN` — a per-map spatial grid (and `MCOL` beside it)
+
+**Status: ✅ `CONFIRMED` for the header**, which self-checks on all 11 objects on
+the disc. ❔ the four data sections are undecoded. **New to this corpus** — no
+document mentioned `REGN`, `MCOL` or `hidden/MiscBin.pak` before 2026-08-24.
+
+## Where it is
+
+`hidden/MiscBin.pak` — 40 entries, **none** name-resolved, in three groups:
+
+| magic | count | sizes |
+|---|---|---|
+| `REGN` | **11** | 49 KB … 3.1 MB |
+| `MCOL` | **11** | 37 KB … 81 KB |
+| (other) | 18 | — |
+
+Eleven of each, which pairs them: one `REGN` and one `MCOL` per map. `MCOL` is
+untouched here; the name and the size range read like mesh collision.
+
+## The header, and why it is believable
+
+```
+0x00  char[4]  'REGN'
+0x04  u32      section-data size
+0x10  f32[4]   bbox min   (x, y, z, 1.0)
+0x20  f32[4]   bbox max   (x, y, z, 1.0)
+0x30  f32[4]   extent     (max - min)
+0x40  f32[4]   cell size
+0x50  u32[4]   grid dimensions
+0x60  u16[6]   six counts
+0x70  u32[4]   four section offsets (the first is always 0x80)
+```
+
+**The check that makes this a decode rather than a guess** — over all 11 objects:
+
+* `extent == cell × dims` holds **11 of 11**, exactly;
+* `counts[3]` equals the **cell count**: `1000` on every 10×10×10 map and `125`
+  on every 5×5×5 one.
+
+Two independent fields reproducing the grid is what rules out coincidence.
+
+## The three map sizes on the disc
+
+| half-extent | cell | dims | objects |
+|---|---|---|---|
+| 250 000 | 50 000 | 10×10×10 | 2 |
+| 50 000 | 10 000 | 10×10×10 | 6 |
+| 25 000 | 10 000 | 5×5×5 | 3 |
+
+So every map is a cube partitioned into 125 or 1 000 uniform cells — 10 km cells
+in a 100 km cube for the common case, and one pair of maps five times larger.
+
+## ❔ The four sections
+
+Their offsets scale with the object, and `counts[0..2]` scale with them —
+`(318, 1172, 2584)` for the 350 KB map against `(2936, 14967, 31155)` for the
+3.1 MB one, a roughly `1 : 4.5 : 10` ratio that holds across all eleven. The
+smallest object (49 KB) is nearly empty by comparison — `(8, 6, 18)` — which
+makes it the cheapest one to decode first.
+
+## Why this matters, stated without overclaiming
+
+A mission's enemy count **rises and falls** as waves arrive and are destroyed, so
+somewhere there is a scheduler with parameters — what spawns, where, and on what
+trigger. A per-map uniform grid indexed by cell is exactly the structure such a
+thing is indexed *by*.
+
+🔴 **But nothing here shows spawn parameters yet.** The header is a spatial
+partition and no more; the sections are unread. Treat this as the location of the
+world's spatial data, not as the wave table.