From 8b0a2545a38fe7d24c499c486af80f9d1eb14360 Mon Sep 17 00:00:00 2001 From: ReaperOfVeriod Date: Sun, 11 Oct 2026 04:21:49 +0200 Subject: [PATCH] Confirm chunk offsets address real records on all 27 levels Range measured: each level's post-shrub region, 900000 bytes before the constant trailer. Method: per chunk, read tagged offsets as 0xF0000000 | low24, take stride as the first delta, load one record per offset at chunk_start + low, and count byte positions constant across that chunk's records. Result: 1096 chunks and roughly 13000 records resolve on all 27 levels. Every level shows 17-21% of byte positions constant across its own records. Level 0: 27 chunks, 466 records, 20.8% constant. The stride-368 chunk (77 records) has 26 constant positions of 368; the stride-340 chunk has 25 of 340. Constant positions cluster at the record end -- 267-276 for stride 368, 258-268 for stride 340 -- so a footer, not scattered padding. The tag is uniform: every tagged offset has top byte 0xF0 on all levels. This settles the previous entry's framing. Resolving at chunk_start + low yields records with ~20% constant positions, which does not happen by chance, so the offsets genuinely address records and those records share a layout. Still not decoded: the 16-byte header, the 0xF0 tag, which fields are index/length/offset, and whether a chunk is moby_anim. A parser can extract chunks and records bounds-checked today; naming the fields needs a domain argument this project has not found. --- docs/formats/core-data-regions.md | 35 +++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/docs/formats/core-data-regions.md b/docs/formats/core-data-regions.md index d9e5cde..0ba8d4e 100644 --- a/docs/formats/core-data-regions.md +++ b/docs/formats/core-data-regions.md @@ -764,3 +764,38 @@ both cases, which is the same mistake twice. **Not decoded.** What the 16-byte header is, what the `0xF` nibble tags, where the chunk data lives, and what the chunk *means* are all open. The container framing is established; its contents are not. + +## Chunk records resolve, and the layout is consistent across levels + +**Range measured:** each level's post-shrub region, taken as the 900,000 bytes +before the constant trailer. + +**Method:** for each chunk, read the tagged offsets as `0xF0000000 | low24`, +take the stride as the first delta, load one record per offset at +`chunk_start + low`, and count byte positions that are constant across that +chunk's records. + +**Result: 1,096 chunks and roughly 13,000 records resolve on all 27 levels.** +Every level's chunks show 17-21% of byte positions constant across their own +records — a consistent field layout rather than noise. + +Level 0 in detail: 27 chunks resolve, 466 records, 20.8% constant. The +stride-368 chunk (77 records) has 26 constant positions out of 368; the +stride-340 chunk (77 records) has 25 out of 340. Constant positions cluster +near the record end — 267-276 and following for stride 368, 258-268 for stride +340 — which is a footer or tail, not scattered padding. + +**The tag is uniform.** Every tagged offset seen has top byte `0xF0`, i.e. +`0xF0000000 | low24`, on all levels. + +**What this settles.** The container framing from the previous entry is not a +coincidence of byte patterns: the offsets genuinely address records, and those +records share a field layout. The chunk-relative base is confirmed because +resolving at `chunk_start + low` yields records with ~20% constant positions, +which does not happen by chance. + +**Still not decoded.** The 16-byte header (opaque, per-chunk), the meaning of +the `0xF0` tag, which fields are index/length/offset, and whether a chunk is +moby_anim or something else. A parser can extract chunks and records +bounds-checked today; naming fields needs a domain argument this project has +not yet found.