From 508a03fa4a3184a6a0906ce9e58fbc1b55e6990c Mon Sep 17 00:00:00 2001 From: ReaperOfVeriod Date: Wed, 14 Oct 2026 03:11:13 +0200 Subject: [PATCH] The decomp names both collision functions; their addresses are not ours rac2-gc-decomp names the two collision entry points: Camera_CollPrimTest 0x001E7A50 camera-to-world boundary check MB_CheckCollPill 0x001E8890 pill/capsule check for moby instances That looked like the collision unblock. The $gp string search has failed twice now, and a named function at a known address is exactly what it failed to produce. They are not usable. Checked against levels 0, 5, 13 and 26 with parse_overlay_sections: Camera_CollPrimTest @ 0x1e7a50 -> section 1, kind 8 (NOBITS) MB_CheckCollPill @ 0x1e8890 -> section 1, kind 8 (NOBITS) Both land inside the level program's zero-filled section. Every byte is zero and the following 256 bytes contain no non-zero byte at all -- code cannot be there. Same on all four levels, so it is not a level with an unusual layout. So the addresses belong to a different address space than a parsed level overlay. Most likely the boot executable's own layout, or the v2.00 build; that repository covers both. SCUS_972.68 is USA v1.01 and our disc matches it exactly, but that fixes the disc, not which program's address space a symbol address is quoted in. The disc matching is exactly the kind of check that looks sufficient and is not -- a disc can pin the bytes and still leave you looking in the wrong program. Worth noting the method that caught it. The temptation was to take the address, open the overlay at that offset, and start reading instructions. What settled it was checking which section the address falls in, and its KIND: a NOBITS section is zero-filled by definition, so an address inside one is a contradiction rather than a lead. The section table made that a two-line check. This closes the shortest route to the collision cell layout, for a checkable reason rather than a vague one. The route that remains is the one already recorded: find how the code addresses the Camera_CollPrimTest assert string, which is not by a $gp-relative load. --- docs/formats/core-data-regions.md | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/docs/formats/core-data-regions.md b/docs/formats/core-data-regions.md index ffb7182..bbbf2c2 100644 --- a/docs/formats/core-data-regions.md +++ b/docs/formats/core-data-regions.md @@ -2907,3 +2907,33 @@ size. Asserted in `sound_bank_sblk_body_head_carries_the_daw_size_twice`. The remainder of the body -- a per-sound record table -- is still undecoded. + +## The decomp names the collision functions, but their addresses are not ours + +`OpenRAC/rac2-gc-decomp` names both collision entry points: + + Camera_CollPrimTest 0x001E7A50 camera-to-world boundary check + MB_CheckCollPill 0x001E8890 pill/capsule check for moby instances + +These looked like the collision unblock: a named function at a known address is +exactly what the `$gp` string search failed to produce. They are not usable. +Checked against four levels -- 0, 5, 13, 26 -- with `parse_overlay_sections`: + + Camera_CollPrimTest @ 0x1e7a50 -> section 1, kind 8 (NOBITS) + MB_CheckCollPill @ 0x1e8890 -> section 1, kind 8 (NOBITS) + +Both land inside the level program's zero-filled section. Every byte there is +zero, and the following 256 bytes contain no non-zero byte at all. Code cannot be +there, and both addresses are in the same place on all four levels. + +So those addresses belong to a different address space than a parsed level +overlay -- most likely the boot executable's own layout, or the v2.00 build, both +of which that repository also covers. `SCUS_972.68` is USA v1.01 and our disc +matches it exactly, but that fixes the *disc*, not which program's address space a +symbol address is quoted in. + +This closes the shortest route to the collision cell layout that the decomp +appeared to offer, and it closes it for a checkable reason rather than a vague +one. The route that remains is the one already recorded: find how the code +addresses the `Camera_CollPrimTest` assert string, which is not by a `$gp`-relative +load.