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

re: record an open conflict with auto/regn-reader over the +0x10 base

Browse Source 
That branch decodes REGN as a tetrahedral navmesh with strong checks and claims
the POF0 fixup base is chunk+0x10, so every offset on this page was read 16
bytes early.

I could not reproduce that on the one independently checkable thing here: the
plane list gives 133573/133573 unit normals at the unshifted base and 0/133573
at +16, and n.p+d = 0 holds to float round-off unshifted. A 16-byte shift
destroys it, so the blanket statement does not hold for this record.

Likely reconciliation is bookkeeping: a 48-byte face whose plane fields sit at a
different intra-record offset addresses the same bytes from a different origin.
That is a guess and I am not adopting either wording until checked.

Also confirmed: my own section-0 point test passes at 100% at BOTH bases, so it
never had power to distinguish them and should not be cited as validating the
offsets.
This commit is contained in:
Sylpheed RE agent
2026-08-26 07:55:12 +00:00
parent 59c659460f
commit 81d6bb4bed
1 changed files with 40 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -373,4 +373,43 @@ nothing rises above chance.
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.
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.