# `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.