ReaperOfVeriod/Going-Commando
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Decode the collision payload's leading two counts

Browse Source 
Range measured: the first four bytes of the payload on all 19 levels that carry
a non-empty one.

Result: two u16 at payload +0 and +2, both non-zero on all 19, ranging 1..74 and
13..112, products 53 to 3256.

  level  0  11 x 33  =   363   payload   903248
  level  1  24 x 16  =   384   payload  2800496
  level  2   1 x 53  =    53   payload  2315296
  level  7  40 x 35  =  1400   payload  4049232
  level  9  74 x 44  =  3256   payload  2518352
  level 13   2 x 64  =   128   payload  3333520
  level 26  27 x 112 =  3024   payload   652176

Reported as two counts, not as a named grid. They have the shape of collision
grid dimensions -- bounded, both non-zero, products in the hundreds to thousands
-- but nothing measured ties the product to the payload size or to any per-cell
stride. Level 2's 1 x 53 giving a 2.3 MB payload and level 26's 27 x 112 giving
652 KB shows the product does not size the payload, so either cells vary wildly
in size or these are not grid dimensions. Naming them width and depth would be a
reading, not a measurement.

After the two counts comes a run of u16 that stays below 8192 for 30 to 58
entries depending on level, always an even count, and is not ascending. That is
where the per-cell table most likely starts, and it is the next thing to
resolve.

Exposed as CollisionHeader::first and ::second. They live in the payload rather
than the header, so CollisionHeader::region fills them in and the bare
CollisionHeader::parse leaves them zero -- documented at the call site so the
difference is not mistaken for an absence.
This commit is contained in:
ReaperOfVeriod
2026-10-12 02:58:46 +02:00
parent 72bbd5da38
commit 2569cc06ab
2 changed files with 70 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/plan/level-assets.md
+33
View File
@@ -1486,3 +1486,36 @@ alignment, and they carry no measurable periodicity. With every slot position
taking ~256 distinct values they are dense data -- fat vertices, as the roadmap
expects -- and locating the vertex layout inside them needs a reference for this
game's instanced-geometry format, not another stride scan.
## The collision payload opens with two counts
**Range measured:** the first four bytes of the payload on all **19** levels
that carry a non-empty one.
**Result:** two `u16` at payload `+0` and `+2`, both non-zero on all 19, ranging
1..74 and 13..112, products 53 to 3,256.
| level | first | second | product | payload bytes |
|---|---|---|---|---|
| 0 | 11 | 33 | 363 | 903,248 |
| 1 | 24 | 16 | 384 | 2,800,496 |
| 2 | 1 | 53 | 53 | 2,315,296 |
| 7 | 40 | 35 | 1,400 | 4,049,232 |
| 9 | 74 | 44 | 3,256 | 2,518,352 |
| 13 | 2 | 64 | 128 | 3,333,520 |
| 26 | 27 | 112 | 3,024 | 652,176 |
**Reported as two counts, not as a grid.** They have the shape of collision
grid dimensions -- bounded, both non-zero, products in the hundreds to
thousands -- but nothing measured ties the product to the payload size or to any
per-cell stride. Level 2's `1 x 53` giving a 2.3 MB payload and level 26's
`27 x 112` giving 652 KB shows the product does not size the payload, which
means either cells vary wildly in size or these are not grid dimensions. Naming
them width and depth would be a reading, not a measurement.
**After the two counts** comes a run of `u16` that stays below 8,192 for 30 to
58 entries depending on level, always an even count, and is not ascending. That
is where the per-cell table is likely to start, and it is the next thing to
resolve.
Exposed as `CollisionHeader::first` and `::second`.