Locate the region after shrub, 690 KB on level 0

Range measured: each level's last shrub class data_offset field (class + 0x2c) through to the start of the constant trailer. Nothing outside that range is read. Method: the last shrub class's body is an array of 8-byte records whose final two bytes are 00 00. Scanning forward in 8-byte steps for the first record whose trailing pair differs locates the body's end. That is a search for a stated pattern rather than a statistic, so it either finds the boundary or says it did not. Result: on 24 of 24 levels the boundary lands exactly on an 8-byte record boundary, with body lengths of 192, 208, 224 or 240 bytes -- the same sizes seen when shrub classes were grouped and diffed. Level 0: last shrub class data 16046800 .. 16047040 240 bytes next region 16047040 .. 16737344 690,304 bytes constant trailer 16737344 .. 16969296 231,952 bytes So 690,304 bytes between the last shrub class and the trailer are a distinct region rather than shrub data. What is in them is not established. They are the leading candidate for moby_anim, now that collision..moby has been ruled out as texture. Worth recording how a wrong conclusion nearly happened here. An earlier probe searched for PS2 NaN filler at the start of this range, found none, and was about to report the body as having zero length. That would have been wrong: the last shrub class is a real class with real data, and NaN filler only appears in degenerate ones. Checking the actual byte pattern instead of concluding from a failed heuristic is what caught it.
2026-10-11 03:14:28 +02:00
parent 6afcfa8608
commit 352a4e5ad7
1 changed files with 34 additions and 0 deletions
@@ -116,3 +116,37 @@ Where `moby_anim` actually lives is therefore still open, but it is not here.
 The remaining candidate is the unresolved tail after the last shrub class,
 which on level 0 is ~925 KB of real, non-zero data that nothing yet accounts
 for.
+
+## Where shrub data ends, and the region after it
+
+**Range measured:** for each level, the last shrub class's `data_offset` field
+(`class + 0x2c`) through to the start of the constant trailer. Nothing outside
+that range is read.
+
+**Method:** the last shrub class's body is an array of 8-byte records whose
+final two bytes are `00 00`. Scanning forward in 8-byte steps for the first
+record whose trailing pair differs locates the body's end. This is a search
+for a specific stated pattern, not a statistic, so it either finds the
+boundary or reports that it did not.
+
+**Result:** on **24 of 24** levels the boundary lands exactly on an 8-byte
+record boundary. Body lengths are 192, 208, 224 or 240 bytes -- the same sizes
+seen when shrub classes were grouped and diffed earlier.
+
+On level 0:
+
+| what | range | bytes |
+|---|---|---|
+| last shrub class data | 16046800 .. 16047040 | 240 |
+| **next region** | 16047040 .. 16737344 | **690,304** |
+| constant trailer | 16737344 .. 16969296 | 231,952 |
+
+So the 690,304 bytes between the last shrub class and the trailer are a
+distinct region, not shrub data. What they contain is not established.
+
+Two things are worth noting about how this was found, given the rule in
+`AGENTS.md`: the earlier NaN-filler search found nothing at the start of this
+range and was about to conclude the body had zero length, which would have been
+wrong. The last shrub class is a real class with real data, and the NaN filler
+only appears in degenerate ones. Checking the actual byte pattern rather than
+concluding from a failed heuristic is what caught it.