fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

re: REGN section 1 slot census, and an index test with no power

Browse Source 
96 bytes is 24 slots. Over all 63410 records: slots 4-6 hold values in the
header bbox range (a position), slot 7 is always positive 519..107600 (a radius
or extent), slots 8-11 are DENORMAL as floats -- 1.4e-45 upward -- so they are
integers a float reader would turn into near-zero garbage, and slots 12-23 are
six pairs with distinct even/odd distributions. Slots 2 and 3 are ~always zero.

Position + positive scalar + integer links is the shape of a BVH node, which
would fit a file carrying a point list and a plane list. That is a reading of
the shape and nothing more.

Recorded a failed test and why it failed: splitting the integer slots into u16
halves and checking them against each section's record count accepts ALL THREE
sections at ~100% for slots 8 and 9. A test that accepts every hypothesis
rejects none -- section 2 has tens of thousands of records, so the check
measures the section's size rather than the field's meaning. Slot 11's halves
are consecutive in 54%, which is suggestive and not a rule.

What would settle it is a test with power: follow a candidate index and check
the target is spatially consistent with the record's own position and radius.
This commit is contained in:
Sylpheed RE agent
2026-08-26 07:14:39 +00:00
parent f481ccbb5f
commit b61351cf94
1 changed files with 53 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -193,11 +193,60 @@ and consistent with `MCOL` sitting beside it.
### ❔ Still open
* **Section 1** (96 bytes/record, 60 631 records disc-wide) is untouched. Its
content is float-dominated with both large coordinates and mid-range values.
96 bytes is 24 floats — a plausible shape for a 4×4 matrix plus extras, or for
two 48-byte plane records, but nothing is measured.
* **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.