From 3c1d1d99f99fdb79e6222a10deba50e17decffd3 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Mon, 24 Aug 2026 10:22:54 +0000 Subject: [PATCH] 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) Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE --- docs/re/structures/regn-map-grid.md | 70 +++++++++++++++++++++++++++++ 1 file changed, 70 insertions(+) create mode 100644 docs/re/structures/regn-map-grid.md diff --git a/docs/re/structures/regn-map-grid.md b/docs/re/structures/regn-map-grid.md new file mode 100644 index 0000000..eaa34e2 --- /dev/null +++ b/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.