From ddfbc6eb33cb286987195cd0333f6b5eb6c5da10 Mon Sep 17 00:00:00 2001 From: ReaperOfVeriod Date: Sun, 11 Oct 2026 04:29:44 +0200 Subject: [PATCH] Find moby class references in chunk records at 38x chance Range measured: level 0, the 900000 bytes before the trailer; 28 chunks, 475 records, 67780 u16 slots. Reference set: the 238 distinct o_class values from level 0's moby class table, read through LevelCoreHeader. Method: scan every u16 in every record, count membership in the moby class set, and compare against the chance rate of 238/65536 per slot. Result: 9493 hits against 246.1 expected, a 38.6x excess. The hits are concentrated, not spread. Slots 129 through 140 -- twelve consecutive u16, bytes 258 to 280 of the record -- carry 105 to 188 hits each. Nothing else comes close except a separate cluster at slot 38. Every chunk contributes in proportion to its record count. A contiguous twelve-value array that is mostly moby class identifiers is what a model or instance definition listing referenced mobies would look like. Enrichment is not identification. A 38x excess over chance is strong evidence these are moby class IDs rather than incidental small integers, but it does not establish that the chunk is moby_anim: an instance table, a model list and an animation table would all reference class IDs. The format and the meaning of slots 129-140 are both still unnamed. Also unverified: whether the twelve slots are always the same fields. The offsets come from the largest records, and this scan pooled all chunk types together, so a type with a different stride could place them elsewhere. Process note: the first version of this test extracted the moby class table by hand and got 67 entries instead of 238, which made every chunk look like a hit and would have supported any conclusion. Reading it through LevelCoreHeader was what made the measurement meaningful. --- docs/formats/core-data-regions.md | 42 +++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/docs/formats/core-data-regions.md b/docs/formats/core-data-regions.md index 2393675..2c1c0df 100644 --- a/docs/formats/core-data-regions.md +++ b/docs/formats/core-data-regions.md @@ -874,3 +874,45 @@ correlating. **Still open:** what the 64 types mean, which record fields are index/length/offset, and whether any type is moby_anim. + +## Chunk records reference moby class IDs at 38x chance + +**Range measured:** level 0, the 900,000 bytes before the trailer; 28 chunks, +475 records, 67,780 `u16` slots. Reference set: the 238 distinct `o_class` +values from level 0's moby class table, read through `LevelCoreHeader`. + +**Method:** scan every `u16` in every record; count how many are in the moby +class set. Compare against the rate expected if hits were chance, at +238/65536 per slot. + +**Result: 9,493 hits against 246.1 expected -- 38.6x excess.** + +The hits are not spread. They concentrate in a contiguous run of `u16` slots: + +| slot | hits | | slot | hits | +|---|---|---|---|---| +| 138 | 188 | | 134 | 173 | +| 135 | 182 | | 136 | 168 | +| 137 | 180 | | 129 | 139 | +| | | | 130 | 131 | + +Slots 129 through 140 -- twelve consecutive `u16`, that is bytes 258 through +280 of the record -- carry 105 to 188 hits each, and nothing else in the record +comes close except a separate cluster at slot 38. + +**What this looks like.** A contiguous twelve-value array in which most entries +are moby class identifiers is what a model or instance definition listing the +mobies it references would look like. Every chunk contributes in proportion to +its record count: the stride-340 chunk with 77 records has 1,451 hits, the +stride-368 chunk 1,384, the stride-148 chunk with 10 records has 254. + +**What this does not show.** Enrichment is not identification. A 38x excess +over chance is strong evidence that these values are moby class IDs rather +than incidental small integers, but it does not establish that the containing +chunk is `moby_anim` -- an instance table, a model list and an animation table +would all reference class IDs. The format is still unnamed, and so is the +meaning of slots 129-140. + +**Also unverified:** whether the twelve slots are always the same fields. The +offsets are quoted from the largest records; a chunk type with a different +stride would place them elsewhere, and this scan pooled all types together.