fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

formats: REGN carries a POF0 fixup table, and two payload readings are refuted

Browse Source 
Every one of the 11 objects contains POF0 near the tail, at exactly
header[0x04] + 16 - an 11 of 11 relation. POF0 is a pointer-offset fixup table,
so the file is a serialised C++ object graph the loader patches on load, which
also explains why the offsets inside the cell index are absolute FILE offsets.
header[0x04] is therefore the size of the data area.

Two readings of the cell payload are recorded as refuted rather than dropped,
because both were tempting and both came from the smallest object alone: the f32
at record +0x1c is NOT a bounding-sphere radius (ratio to sqrt(3)*half-extent is
1.001 on that one object and 0.13-0.27 on the other ten), and a record's
(count, offset) pairs do NOT point at leaf arrays of count*4 bytes (0 of 11
objects clean). What survives is descriptive only: the payload is dominated by
float data, and the printable runs a string scan finds are float high-bytes
rather than text.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
This commit is contained in:
Sylpheed RE agent
2026-08-24 10:39:47 +00:00
parent 051e165cc1
commit 2ab0f1647d
1 changed files with 36 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

37
docs/re/structures/regn-map-grid.md
View File

@@ -21,7 +21,7 @@ untouched here; the name and the size range read like mesh collision.
```
0x00 char[4] 'REGN'
0x04 u32 section-data size
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)
@@ -77,6 +77,41 @@ Two more invariants from the same sweep:
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 —