e31c3a1854
MCOL sits beside REGN in hidden/MiscBin.pak, 11 of each, never decoded. Over all 11: POF0 at data_size+16 11/11, bbox pad words 1.0/1.0/0.0 11/11, and extent == max-min 11/11. So the header prefix is the same shape as REGN's and the POF0 mechanism applies, which means the chunk+0x10 base and the loader's own pointer list -- the two things that cracked REGN -- are available here too. The map parameters are not merely similar but identical in distribution: bboxes 2/6/3 at 250k/50k/25k and the 0x40 triple 2 at 50000 and 9 at 10000, matching REGN exactly. Eleven maps, each with an MCOL and a REGN over the same volume at the same cell size. Noted that this matches distributions, not a demonstrated object-to-object pairing. Everything past 0x40 diverges from REGN and is open. Also recorded that my own POF0 delta decoder is wrong here -- eight leading zero deltas -- and that the working one is regn_decode.py on auto/regn-reader, which should be used rather than re-derived. Re-deriving it is the mistake I made.
2.6 KiB
MCOL — the same container as REGN, and the same map parameters
🟡 Opened 2026-08-26. MCOL sits beside REGN in hidden/MiscBin.pak, 11
of each, and has never been decoded. This page establishes what it shares with
REGN — which is a lot, and gives the next attempt a large head start.
✅ Same container
Over all 11 objects:
POF0 fixup table at data_size@+4 + 16 |
11 / 11 |
bbox pad words are 1.0 / 1.0 / 0.0 at +0x1C, +0x2C, +0x3C |
11 / 11 |
extent == max − min for the 0x30 block |
11 / 11 |
So the header prefix is byte-for-byte the same shape as REGN's: magic, data
size, then bbox min / bbox max / extent as f32[4], then a triple at 0x40.
The POF0 mechanism applies, which means the chunk + 0x10 base and the
loader's own pointer list are available here too — the two things that cracked
REGN.
✅ And the same map parameters, exactly
The bounding boxes and the 0x40 triple are not merely similar — the
distributions are identical:
MCOL |
REGN |
|
|---|---|---|
| bbox ±250 000 | 2 | 2 |
| bbox ±50 000 | 6 | 6 |
| bbox ±25 000 | 3 | 3 |
0x40 = 50 000 |
2 | 2 |
0x40 = 10 000 |
9 | 9 |
Eleven maps, and for each one an MCOL and a REGN describing the same volume
at the same cell size. 0x40 is the cell size in REGN; the same values in
the same multiplicities here is strong evidence it is the cell size in MCOL
too — though note this is a match of distributions, not a demonstrated
object-to-object pairing, which would need the two linked by name or by a stage's
tables.
❔ What is not yet known
- Everything past
0x40.MCOL's words at0x50–0x84do not look likeREGN's (REGNhas grid dims at0x50, sixu16counts at0x60and six section pointers at0x70;MCOLhas a large value, two mid-range values and112at0x50, mostly zeros at0x60, and0x05050501at0x70). The headers agree on the spatial prefix and diverge after it. - My
POF0delta decoder is wrong here — it emits eight leading zero deltas before plausible offsets, so either the stream has a preamble I am not skipping or my 6/14/22-bit reading is off. The working decoder istools/re-capture/regn_decode.pyon branchauto/regn-reader; use that rather than re-deriving it, which is the mistake I made here.
First step for whoever continues: run the known-good POF0 reader over an
MCOL, list which words are relocated, and read the header slots those pointers
occupy. That is exactly the move that turned REGN from twenty failed
correlations into a decode.