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

re: MCOL's 32-byte record is a cell entry, and there are two interleaved arrays

Browse Source 
Read as 8 big-endian words, word 0 as four bytes is (x,y,z,1) -- a 3-D cell
index, matching the object's 5x5x5 grid. Words 4-6 are a position and word 7 a
positive scalar (a bounding sphere); word 1 is a count, word 2 the relocated
pointer. Every record pointer lands in the same region, 8976/8976, each a fixed
distance on with the same stride -- so there are two parallel arrays, A and B.

The 50% is the tell. Three independent criteria -- byte 3 == 1, valid cell
index, sphere reaches that cell -- all land on 50.0%, which says half the
records are not this type rather than that the reading half-works. The POF0 slot
list interleaves both arrays and I was testing B's records against A's layout.

So array A is a per-cell record, the same role REGN's section 3 plays. Array B
is unread, and the criteria have not yet been re-run on A alone -- if the
reading is right they should go to 100%.
This commit is contained in:
Sylpheed RE agent
2026-08-26 08:31:46 +00:00
parent 8df3624b70
commit 900ca6a807
1 changed files with 44 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

43
docs/re/structures/mcol-collision.md
View File

@@ -88,3 +88,46 @@ is a reading of the shape; none of the four blocks has been decoded.
in eleven** where `0x74` does not land 8 before the array, and the 7.3 % of gaps in eleven** where `0x74` does not land 8 before the array, and the 7.3 % of gaps
that are not 32 (they are the boundaries between runs, but that has not been that are not 32 (they are the boundaries between runs, but that has not been
checked). checked).
## 🟡 The 32-byte record — a cell entry, and there are two interleaved arrays
**2026-08-26.** Reading each record as 8 big-endian words (record start =
pointer slot − 8), the first entries of the smallest object are:
@0x6780 00000001 00000001 00007710 00000000 00000000 00000000 00000000 47295092
@0x67A0 01000001 00000001 00007730 00000000 …
@0x67C0 02000001 00000001 00007750 00000000 46023555 C6023555 C6023555 471FA1A7
@0x6820 00010001 00000001 000077B0 00000000 …
Word 0 read as **four bytes** is `(x, y, z, 1)` — a **3-D cell index**. That
object's grid is 5×5×5 (bbox ±25 000, cell 10 000), and the values run 0–4 in
the first byte and step the second byte at the right point. Words 4–6 are a
position and word 7 a positive scalar — a bounding sphere. Word 1 is a count and
word 2 the relocated pointer.
**Every record pointer lands in the same region — 8 976 / 8 976 (100 %)** — and
each points 0xFA0 further on with the same stride, so there are **two parallel
arrays**, not one: array A at `0x6780` and array B at `0x7720`.
### The 50 % is the tell, not a failure
Testing the cell-index reading over *all* relocated records gives almost exactly
half:
byte 3 == 1 4 491 / 8 976 (50.03 %)
bytes 0..2 a valid cell index 4 488 (50.00 %)
the record's sphere reaches that cell 4 485 (49.97 %)
Three independent criteria all landing on 50.0 % is not a partial fit — it says
**half the records are not this type**. The `POF0` slot list interleaves both
arrays, and I was testing array B's records against array A's layout. Reported as
a rate it would read like a half-working hypothesis; split by array it is two
clean populations.
🟡 So array A is a **per-cell record** — cell index, count, pointer into array B,
bounding sphere — the same role `REGN`'s section 3 plays. ❔ Array B's layout is
unread, and the split has not yet been re-run per array to confirm 100 % on A.
**Next step**: separate the two arrays by their start addresses (`0x74` → A,
A's pointers → B), then re-run the three criteria on A alone. If the reading is
right they go to 100 %.