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

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.

✅ Section 3 is the cell index — and it self-checks 11/11

The fourth section is a one entry per cell table of 8-byte records (count, offset), immediately followed by the records those offsets point at:

index      = offsets[3] .. offsets[3] + cells*8
payload    = align16(index end) ..
record     = 32 bytes (offsets step by 0x20)

Checked over all 11 objects: the lowest offset any cell refers to equals align16(offsets[3] + cells × 8) — 11 of 11. On the six 10×10×10 maps cells × 8 is already 16-aligned and the payload butts straight up against the index; on the three 5×5×5 maps 125 × 8 = 1000 is not, and the payload starts 8 bytes later, which is what makes the alignment rule visible rather than assumed.

Two more invariants from the same sweep:

• every occupied cell has count exactly 1 — total items equals occupied cells on all 11 objects, so this is "one record per cell", not a bucket list;
• counts[4] = occupied cells + 2, exactly, on all 11 (e.g. 997/995, 880/878, 125/123). The +2 is unexplained — two sentinels, or two cells counted differently.

Most cells are occupied: 878–998 of 1 000, 123 of 125.

❔ The other three 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.