From 040386c0fb9a6598cd3d812f6801c976d0e7fe1b Mon Sep 17 00:00:00 2001 From: ReaperOfVeriod Date: Tue, 13 Oct 2026 07:35:58 +0200 Subject: [PATCH] Volumes: the reference that did not generalise Last commit said what would settle the volume candidate and implied one of those was available. They are not. Recording the failure rather than moving on quietly. Level 0's data.bin -- the level's file descriptor -- contains the value 799204 exactly once, at 0xab6360, and 799204 is byte-for-byte the offset of the 20-record 144-byte candidate table. A single 4-byte match in 13.3 MB has a chance expectation of ~0.003, so it was worth checking rather than assuming. It does not hold up. Each level's own best 144-byte table, searched in that same level's own data.bin: level candidate records refs (chance ~0.0035) 0 1,810,724 32 0 1 1,884,884 386 0 2 2,066,804 224 0 3 2,438,228 365 0 4 2,677,780 114 0 5 1,255,780 14 0 6 2,496,020 115 0 7 2,062,072 311 0 None. The level 0 hit at 0xab6360 also sits among high-entropy neighbours, and level 0's own BEST table -- a different offset, 32 records, not the 20-record one -- is not referenced either. So the hit does not generalise and is most likely coincidence. This retracts what the previous commit implied. Nothing links a 144-byte float table to volumes: the table is reached by walking structure rather than by an explicit pointer, so the discriminator I named does not exist, and the candidate stands exactly where it did. Recording the three routes that would actually settle it, all of them unavailable: the game's own volume code (same dead end as the collision anchor -- a GP-relative string search returns nothing); ground truth, such as a count of level 0's trigger volumes from a map; or a correlation with a named class, since gameplay.bin resolves ids through its dispatch records -- but no class name containing "volume" exists on the disc, which is exactly why this is unavailable. No test added, because there is no solid claim here to assert. 240 tests, unchanged. --- docs/formats/core-data-regions.md | 43 +++++++++++++++++++++++++++++++ docs/roadmap.md | 5 +++- 2 files changed, 47 insertions(+), 1 deletion(-) diff --git a/docs/formats/core-data-regions.md b/docs/formats/core-data-regions.md index c79967e..0193b95 100644 --- a/docs/formats/core-data-regions.md +++ b/docs/formats/core-data-regions.md @@ -2245,3 +2245,46 @@ Both were mine, and both produced confident nonsense before being caught. The same shape as every other correction in this log: a clean, small, plausible number read as conclusive because it was not checked against a control that could have disagreed. + +### The reference that did not generalise + +Level 0's `data.bin` -- the level's file descriptor -- contains the value +`799204` exactly once, at `0xab6360`, and `799204` is byte-for-byte the offset +of the 20-record candidate table above. A single 4-byte match in 13.3 MB has a +chance expectation of about 0.003, which is suggestive enough to be worth +checking properly rather than assuming. + +It does not hold up. Taking each level's own best 144-byte table and searching +that level's own `data.bin`: + + level candidate offset records references found (chance ~0.0035) + 0 1,810,724 32 0 + 1 1,884,884 386 0 + 2 2,066,804 224 0 + 3 2,438,228 365 0 + 4 2,677,780 114 0 + 5 1,255,780 14 0 + 6 2,496,020 115 0 + 7 2,062,072 311 0 + +Not one of the eight is referenced. The level 0 match at `0xab6360` sits in a +neighbourhood of high-entropy bytes, and level 0's own *best* table -- a +different offset, 32 records, not the 20-record one -- is not referenced either. +So the single hit does not generalise and is most likely coincidence. + +The consequence is worth stating plainly because it retracts what the previous +section implied: **nothing links a 144-byte float table to volumes.** The table +is reached by walking structure rather than by an explicit pointer, so the +approach that would have settled it does not work, and the candidate stands +exactly where it did. + +What would settle it, and none of these are cheap: + + * The game's own volume code, which has the same byte-order problem as the + collision anchor did -- a GP-relative string search returning nothing. + * Ground truth: a count of level 0's trigger volumes from a map or a guide, + to match against a table's population. + * A correlation with a *named* class, since `gameplay.bin` resolves ids + through its dispatch records. If an id in the candidate resolved to a class + whose name is a volume trigger, that would be decisive. No class name + containing "volume" exists on the disc, which is why this is not available. diff --git a/docs/roadmap.md b/docs/roadmap.md index e95716e..2a871bd 100644 --- a/docs/roadmap.md +++ b/docs/roadmap.md @@ -417,7 +417,10 @@ Phase 1 hands over the extents; this phase works out what each one contains. bugs on the way are written up: a validity test that counted zero as world-plausible scored zero-filled memory perfectly, and the 144-byte stride rested on four eyeballed offsets that the gap histogram did not support. - Not located. Nothing examined so far presents itself as a + A promising lead also failed: level 0's `data.bin` references one candidate + offset exactly once (chance ~0.003), but **none** of seven other levels' + candidates are referenced by their own `data.bin`, so the table is reached + by walking structure and nothing links it to volumes. Not located. Nothing examined so far presents itself as a volume: `core_data`, the chunk region and `gameplay.bin` all yield structures that are accounted for by something else. - [~] `level_overlay` — header, constant block and level data parsed