3c1d1d99f9
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
2.6 KiB
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 × dimsholds 11 of 11, exactly;counts[3]equals the cell count:1000on every 10×10×10 map and125on 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.