From 7c0df0f89302ff750658e3a8e80a824d4ae39b35 Mon Sep 17 00:00:00 2001 From: ReaperOfVeriod Date: Sun, 11 Oct 2026 04:42:53 +0200 Subject: [PATCH] Characterise shrub body records on level 0 as a per-level partition Range measured: level 0, shrub class table, 7 entries at core index offset 10176. Six classes are bounded by a successor; the seventh runs to the end of core_data and is excluded because its span contains the whole post-shrub region. Method: bound each span by the next class geometry offset, take the body from data_offset to the span end, split into 8-byte records. Result: 164 records across 6 bounded bodies, lengths 192 twice, 208 twice, 224, 240. Per byte over those 164 records: byte 0: 74 distinct, 60 zero byte 4: 72 distinct, 35 zero byte 1: 58 distinct, 65 zero byte 5: 59 distinct, 38 zero byte 2: 76 distinct, 43 zero byte 6: 1 distinct, 164 zero byte 3: 62 distinct, 48 zero byte 7: 1 distinct, 164 zero Bytes 6 and 7 are zero in every record; bytes 0 to 5 take 58 to 76 distinct values with only 21 to 39% zero, so uniformly varied rather than sparse. Read as u32 the fields are not plausible: u32[0] spans 0 to 4294871316 and no field is monotone across the body. The six bytes are not two packed 32-bit values. This settles the six-varying-plus-two-constant shape on level 0 as a per-level partition, rather than only in aggregate over the disc's 8938 records, which is what rule 3a asks for. Two trailing zero bytes are padding or a flag pair. Unresolved: whether the six bytes are six u8, an f32 plus two u16, or something else. The u32 reading is excluded but no positive reading is established. Process note: the first attempt used ClassEntry and a hand-computed o_class instead of ShrubClassEntry, and every ShrubHeader::region call failed. The parser was fine; the caller was not. --- docs/formats/core-data-regions.md | 48 +++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) diff --git a/docs/formats/core-data-regions.md b/docs/formats/core-data-regions.md index 5d1d65d..ceca9c1 100644 --- a/docs/formats/core-data-regions.md +++ b/docs/formats/core-data-regions.md @@ -983,3 +983,51 @@ array is a per-type field, not a common one at a fixed offset. The moby reference itself is unaffected: 38.6x excess measured across all records stands, since it does not depend on which slots were counted. + +## Shrub body records on level 0: six varying bytes, two constant + +**Range measured:** level 0, shrub class table 7 entries at core index offset +10176. Six classes are bounded by a successor; the seventh runs to the end of +`core_data` and is excluded, because its span contains the whole post-shrub +region and is not wholly records. + +**Method:** bound each span by the next class's geometry offset, take the body +from `data_offset` to the span end, and split into 8-byte records. + +**Result: 164 records across 6 bounded bodies**, body lengths 192 (twice), 208 +(twice), 224, 240. + +Per-byte, over those 164 records: + +| byte | distinct | zero | +|---|---|---| +| 0 | 74 | 60 | +| 1 | 58 | 65 | +| 2 | 76 | 43 | +| 3 | 62 | 48 | +| 4 | 72 | 35 | +| 5 | 59 | 38 | +| **6** | **1** | **164** | +| **7** | **1** | **164** | + +Bytes 6 and 7 are zero in every record. Bytes 0 to 5 take 58 to 76 distinct +values of a possible 164, with only 21-39% zero -- that is, uniformly varied +rather than sparse. + +Read as `u32` the fields are not plausible: `u32[0]` ranges 0 to 4,294,871,316 +and no field is monotone across the body. So the six bytes are not two packed +32-bit values. + +**What this settles.** The six-varying-plus-two-constant shape holds on level 0 +as a per-level partition rather than only in aggregate across the disc's +8,938 records, which is what rule 3a asks for. Two trailing zero bytes are +padding or a flag pair, not data. + +**What it does not.** Whether the six bytes are six `u8` fields, or an `f32` +plus two `u16`, or something else, is unresolved -- the `u32` reading is +excluded but no positive reading is established. + +**Process note.** The first attempt at this used `ClassEntry` and a +hand-computed `o_class` offset instead of `ShrubClassEntry`, and every +`ShrubHeader::region` call failed. The parser was not wrong; the caller was. +The working call shape was already in the disc test.