Sylpheed/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      size of the data area  (the POF0 table starts at 0x04-value + 16)
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.

## ✅ It is a serialised object graph with a `POF0` fixup table

Every one of the 11 objects contains the tag **`POF0`**, always near the tail,
and its position is exactly **`header[0x04] + 16`** — on **11 of 11**:

```
e993b93e  header +0x04 = 0x0b100   POF0 at 45328 = 45312 + 16
e4155d94  header +0x04 = 0x235d70  POF0 at 2317696 = 2317680 + 16
… 11 of 11 identical relation
```

`POF0` is a **pointer-offset (fixup) table**: the file is a serialised C++ object
graph, and the loader patches the recorded slots into real pointers. That
explains a detail that would otherwise be odd — the "offsets" inside the cell
index are absolute **file** offsets, because that is what a fixup table rewrites.

So `header[0x04]` is the size of the data area, and everything past
`header[0x04] + 16` is relocation bookkeeping rather than content.

## 🔴 Two readings of the cell payload, both refuted by generalising

Both came from the smallest object and both died the moment they were checked
against the other ten — recorded because the temptation to keep them was real:

* **"the `f32` at record `+0x1c` is the grid's bounding-sphere radius."** On
  `e993b93e` it is 86 689 against `√3 × 50 000 = 86 603`, a ratio of **1.001**.
  On the other ten the ratio runs **0.13 – 0.27**. Fitted to one sample.
* **"a record's `(count, offset)` pairs point at leaf arrays of `count × 4`
  bytes."** True for the first record of `e993b93e`; across the objects the
  offset deltas fail that rule on **every** object checked (0 of 11 clean).

What survives is only descriptive: the payload area is dominated by **float
data** — the "strings" a printable-run scan finds are all byte patterns like
`0x46`/`0x47` high bytes, i.e. medium-magnitude floats, not text.

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

## ✅ Update: `REGN` is a stage's **MapPath**

The per-stage definition record (see
[stage-definition-table.md](stage-definition-table.md)) has a field
`MapPath = test.rgn`, and `name_hash("test.rgn") = 0x3506e972`, which is one of
the `REGN` objects in `MiscBin.pak`. The sibling field `MapMesh = test.col`
hashes to `0x2cf7eb47`, an `MCOL` object in the same pak.

So `.rgn`/`REGN` is stage navigation/path data referenced by the stage record,
and `.col`/`MCOL` is the stage collision mesh. This does not by itself validate
either of the two refuted cell-payload readings recorded above, but it does
explain why the payload looks like a grid of route data.


## ✅ Sections 0, 1 and 2 have record strides — and section 2 is a PLANE list

**2026-08-26.** The three sections the page called undecoded are fixed-stride
record arrays, and `counts[0..2]` are their record counts. Dividing each
section's byte span by its count over all 11 objects:

| section | stride | evidence |
|---|---|---|
| 0 | **12 bytes** | `count × 12` fits with a remainder of 0–12 in **11 / 11** |
| 1 | **96 bytes** | `count × 96` fits with a remainder of **exactly 0 in 11 / 11** |
| 2 | **48 bytes** | `count × 48` fits with a remainder of **exactly 96 in 11 / 11** |

Section 1 landing on a zero remainder in every object, and section 2 on the same
96-byte tail in every object, is what makes these strides rather than a
coincidence of division.

### ✅ Section 0 is a point list

12 bytes is three `f32`. Over **13 467** records across all 11 objects, **every
one lies inside that object's own header bounding box — 13 467 / 13 467 (100 %)**.
Values land on the box corners (`±250 000`) and inside.

### ✅ Section 2 is a plane list — 48 bytes, and the plane equation closes

Read as twelve `f32`:

    [0..3]   zero
    [4..6]   unit normal          |n| = 1 ± 0.02 in 133 573 / 133 573 (100 %)
    [7]      signed distance d
    [8..10]  a point on the plane, inside the bbox in 133 573 / 133 573 (100 %)
    [11]     1.0 exactly           in 133 573 / 133 573 (100 %)

**The check that makes this a decode**: for a genuine plane, `n·p + d` must be
zero. Over all **133 573** records:

    |n·p + d| / scale :  median 2.29e-08   p90 6.78e-08   max 2.15e-07

That is float round-off, not a fit — the relation holds to the last bits of a
32-bit float in **every record on the disc**. Three independent 100 % properties
(unit normal, point in bbox, trailing 1.0) and an exact algebraic identity are
well past what a wrong reading survives.

So a `REGN` object carries, alongside its uniform grid, a **point list** and a
**plane list** — which is the shape of collision or region-boundary geometry,
and consistent with `MCOL` sitting beside it.

### ❔ Still open

* **Section 1** (96 bytes/record, **63 410** records disc-wide) — a per-slot
  census is below, but what the record *means* is still ❔.
* **What the planes are for.** "Collision or region boundary" is a reading of the
  shape; nothing here shows what queries them.
* The **zeros at `[0..3]`** of every plane record, and the constant `96`-byte
  tail after section 2, are unexplained.


## 🟡 Section 1, slot by slot — measured, but not read

**2026-08-26.** 96 bytes is 24 slots. Censusing every one of the **63 410**
records across all 11 objects gives a clear regional structure, even though the
record's purpose is not settled:

| slots | what the values are | reading |
|---|---|---|
| 0–3 | slots 2 and 3 are zero in ~100 %; 0 and 1 mostly small | ❔ |
| **4–6** | 96 % have \|v\| > 1 000, range **±250 000** — the header bbox range | 🟡 a **position** |
| **7** | 99.9 % > 1 000, always positive, 519 … 107 600 | 🟡 a **radius or extent** |
| 8–11 | as `f32` these are **denormals** (1.4 × 10⁻⁴⁵ upward) — i.e. they are **integers**, not floats | ✅ integer fields |
| 12–23 | six **pairs**: the even slot 200 … 67 000 and never zero, the odd 0 … 212 000 and zero in 7–13 % | ❔ |

The denormal signature in slots 8–11 is worth stating plainly: a float field
never holds `1.4e-45`, so those four words are integers that a float reader
would silently turn into near-zero garbage.

A position plus a positive scalar plus integer links is the shape of a
**bounding-volume hierarchy node**, which would fit a file that also carries a
point list and a plane list. That is a reading of the shape and nothing more.

### ❌ The index test has no discriminating power

I tried to confirm the integer slots are indices by splitting each into two
`u16`s and checking them against each section's record count. The result is
useless, and the reason is worth recording:

| slot | halves valid for section 0 | section 1 | section 2 |
|---|---|---|---|
| 8 | 100.00 % | 100.00 % | 100.00 % |
| 9 | 100.00 % | 99.99 % | 100.00 % |
| 10 | 8.78 % | 44.19 % | 100.00 % |
| 11 | 8.76 % | 44.16 % | 100.00 % |

**A test that accepts every hypothesis rejects none.** Section 2 has tens of
thousands of records, so "is this `u16` below the plane count" is satisfied by
almost any small number — it measures the size of the section, not the meaning
of the field. Only slots 10 and 11 discriminate at all, and they merely rule
*out* section 0.

`slot 11`'s halves are consecutive (`n`, `n+1`) in 54 % of records and slot 10's
in 12 % — suggestive of paired links, but 54 % is not a rule and I am not
promoting it.

❔ So section 1 stays open. What would settle it is a test with power: pick a
record, follow a candidate index, and check that the thing it lands on is
spatially consistent with that record's own position and radius. That needs the
tree walked, not the fields counted.

## ❌ The BVH reading is refuted — and slot 7 is a *local* scale

**2026-08-26.** Last iteration I wrote that "position + positive scalar +
integer links is the shape of a bounding-volume hierarchy node", explicitly as a
reading of the shape. Tested with a design that has power, it fails.

**The containment test.** If slots 8–11 hold child indices, a child's sphere
should sit inside its parent's. Following every `u16` half of every integer slot
and checking `|C_child − C_parent| + R_child ≤ R_parent` (2 % slack):

    RANDOM control                   0 of 126 787  =  0.00 %
    slot 8 half 0    63 389 tried    0.00 %
    slot 8 half 1    63 395 tried    0.00 %
    …every candidate…                0.00 %

**The random control is the informative row.** It is also 0.00 %, which means no
node's sphere contains any other node's sphere *anywhere in the file* — so there
is no nesting for an index to point at, whatever the indices mean. The
hypothesis fails before the indices are even in question.

**Why**: slot 7 is far too small to bound neighbours.

| | median | p10 | p90 |
|---|---|---|---|
| slot 7 | **3 139** | 1 965 | 9 275 |
| pairwise centre distance | **45 457** | 19 071 | 126 295 |

Slot 7 is **14× smaller** than the typical distance between nodes, and a random
other centre falls within it only **0.40 %** of the time. It is also smaller
than the smallest grid cell on any map (10 000).

So ✅ **slot 7 is a local scale, not a hierarchy radius** — sub-cell sized, with a
narrow spread. Together with 63 410 scattered centres across a 500 km cube, that
is the shape of **many small independent volumes**, not a tree.

🟡 That fits per-object collision volumes — a map's asteroids and debris, which
the mission `Route` tables independently show as `Frame_S<NN>_Asteroid` records.
Stated as a reading, not a measurement; nothing here counts objects.

❔ Still open: what slots 8–11 index, and what the six pairs in 12–23 are. What
this iteration removed is a wrong frame — the file is not a tree, so tree-shaped
tests will keep returning nothing.

## ❌ The cell index does not reference section 1 — two powered tests, both negative

**2026-08-26.** The obvious coupling in a file with a uniform grid and a list of
small volumes is that the grid indexes the volumes. It does not, by the only
test that could show it: **spatial agreement**.

**Test 1 — the cell payload as indices.** For every occupied cell, read its
32-byte payload record and try each `u16` in it as a section-1 index, then check
whether that node's centre lies **inside the cell that referenced it**:

    RANDOM control            0.138 %
    +0    0.08 %      +2    0.18 %      +4    0.11 %      +8    0.08 %
    +10   0.10 %      +12   0.08 %      +14   0.08 %      … 

Every field sits at the chance rate. **Nothing points at section 1.**

**Test 2 — the cell payload as coordinates.** 32 bytes is eight floats, so a
position could be in there. Trying every float triple and asking whether it lies
inside its own cell:

    +0  0.81 %   +4  0.81 %   +8  0.15 %   +12  0.16 %   +16  0.26 %   +20  0.78 %

Also chance.

### ⚠️ And the tempting number in that table is worthless

The same run reported those triples lie **inside the object's bounding box in
100.00 %** of cases, at five different offsets. That looks like a decode and is
not: the bbox spans the entire 500 km map, so *any* mid-range float triple
passes, and overlapping windows starting at +0 and +4 both scoring 100 % is the
tell — a real field would not survive being read at a four-byte shift. It
measures the size of the box, not the meaning of the bytes. This is the third
time in this file's investigation that a containment test against something
large has produced a meaningless 100 %, so it is recorded rather than quietly
dropped.

❔ So the grid and section 1 have no demonstrated link, and how a cell reaches
its geometry is unknown. What is now excluded: the cell payload holding
section-1 indices, and holding cell-local coordinates.

✅ Incidental, from the same sweep: `u32` slots at **+0, +8 and +12** of the
payload record are below `0x10000` in **100 %** of records, while +4, +16, +20
and +24 are in only 11 % and +28 never — so the record has three index-shaped
fields and four wide ones, whatever they refer to.

## ❌ …nor the point list, nor the plane list — the static coupling search is exhausted

**2026-08-26.** The previous test only tried section-1 targets, which left the
obvious gap: the payload's three index-shaped `u32`s might address the **points**
or the **planes** instead. Tested the same way — follow the index, ask whether
the target lies inside the cell that referenced it:

    RANDOM control                    0.203 %
    +0  -> points 0.17 %   planes 0.16 %
    +8  -> points 0.81 %   planes 0.09 %
    +12 -> points 0.81 %   planes 0.09 %

All at the control rate. The two 0.81 % cells are 4× the baseline, and I am
**not** treating that as a signal: across this and the previous iteration I have
now run on the order of twenty of these tests (three index fields × three
sections × two readings × several offsets), and at that count a single 4×
enrichment on ~8 000 trials is what noise looks like. Reporting it as a lead
would be exactly the multiple-comparisons error that a long hypothesis sweep
invites.

### Where this leaves `REGN`

✅ Decoded: the header and grid, section 0 (points), section 2 (planes), section
3 (the cell index), and the strides and field regions of section 1.

❌ Not decoded, and **not reachable by the tests available statically**: any link
between the grid and the geometry. Every index-shaped field has been followed
into every section and checked for spatial agreement, against controls, and
nothing rises above chance.

❔ **What would actually settle it** is the code — find what reads a `REGN`
object in the executable and watch which fields it dereferences. That is static
PE work (`/work/*.pe`, offset = VA − 0x82000000) of the same kind that cracked
the `.slb` packing phase, and it is the honest next step rather than a
twenty-first correlation.

## ⚠️ Open conflict with `auto/regn-reader` over the `+0x10` base

**2026-08-26.** Branch `auto/regn-reader` decodes `REGN` as a **tetrahedral
navigation mesh** and reports the cell→geometry link solved, with strong checks
(faces passing through 3 of 4 tet vertices, 253 722/253 722; portal cost equal to
the distance between face centroids, 380 460/380 460). Its load-bearing structural
claim is that the `POF0` fixup base is **`chunk + 0x10`**, and therefore that
"every offset previously recorded on that page was read 16 bytes early" — offered
as the reason the ~20 correlation tests on this page returned chance.

**I could not reproduce that as stated, on the one thing here that is
independently checkable.** Re-reading the plane list at both bases:

| | records | unit normals |
|---|---|---|
| section at `chunk + offset` (what this page used) | 133 573 | **133 573 (100.00 %)** |
| section at `chunk + 16 + offset` | 133 573 | **0 (0.00 %)** |

And the plane identity `n·p + d = 0` holds to float round-off at the **unshifted**
base. A 16-byte shift destroys it completely. So for *this* record the unshifted
reading is right, and the blanket statement is not.

🟡 **The likely reconciliation is bookkeeping, not disagreement.** The other
branch describes a 48-byte **face** record whose plane fields sit at a different
intra-record offset; `chunk+16` with the plane at `+0` addresses the same bytes as
`chunk+0` with the plane at `+16`, which is exactly what this page uses. If so
both readings are correct and only the origin convention differs — but that is a
guess, and I am not adopting either page's wording until it is checked.

**Also confirmed here, incidentally**: my section-0 point test passes at **100 %
at both bases**, so it never had the power to distinguish them. That test could
not have caught a 16-byte error and should not be cited as if it validated the
offsets.

❔ Until the conflict is resolved, treat the plane/face layout on this page as
verified by its own arithmetic and the tetrahedral decode on `auto/regn-reader`
as verified by its own — and do not merge the two offset conventions without
re-running one check from each.

## ✅ RESOLVED — the base IS `chunk + 0x10`, and my section-0 offsets were wrong

**2026-08-26, same day.** The conflict above is settled, and it settles against
me on the boundary while leaving the plane arithmetic intact.

**The plane fields were never in dispute.** For object `3506e972`, the other
branch's face record 0 begins at `0x1c700`, and its plane normal begins at the
same address; my `chunk + offset_at_0x78 + 16` gives `0x1c700` too. **Same bytes,
different bookkeeping** — exactly the reconciliation guessed above. The
`n·p + d = 0` result stands unchanged.

**The base is `chunk + 0x10`**, on evidence that has power where my tests did
not:

* the loader does it: `8246519c  addi r3, r31, 16`;
* at `+0x10` the six `POF0`-relocated slots land exactly on `0x70`–`0x84`, the six
  section pointers. At `+0` they would land on `0x60`–`0x74` — relocating the
  `u16` **counts** and leaving two section pointers unrelocated. Not merely
  wrong, non-functional;
* section-0 record 0 reads as a bbox corner at `+0x10` and as garbage at `+0`.

### ❌ And my point-list evidence was vacuous

I reported "13 467/13 467 section-0 points lie inside the bbox" as the check that
made section 0 a decode. Read at the correct base, record 0 of four objects is:

    base +0    (1.4e-41, 5.3e-41, 0)      (2.2e-40, 2.7e-40, 0)
    base +16   (-50000,-50000,-50000)     (-250000, 250000, -250000)

So my offsets were 16 bytes early throughout. **Only 11 of 13 467 points read as
denormal at the wrong base** — the rest were still plausible coordinates inside
the box, because a 16-byte shift within a packed array of `f32` triples yields
*other floats from the same array*. That is the general form of the failure and
it is worth stating plainly:

> **A containment test cannot detect a shift inside a homogeneous array.** The
> shifted values are drawn from the same distribution as the correct ones, so the
> test passes at 100 % either way. It is not a weak check — for this class of
> error it is no check at all.

The conclusion "section 0 is a point list" happens to be right. The evidence I
gave for it was not evidence.

✅ **Adopt `chunk + 0x10`.** The plane *fields* need no change; the record
*boundary* moves, and the four integer words I described as "four zeros" move
with it into the record they describe — which is where the face adjacency, and
the answer to the cell→geometry question, was hiding. See branch
`auto/regn-reader` for the tetrahedral decode.