User walked retail UP the same Holtburg cottage cellar that acdream
gets stuck on. cdb captured retail's BSP behavior for paired
comparison against the acdream polydump trace (0b44996).
Retail (successful walk):
BP1 transitional_insert: 2,651
BP2 step_up: 29 (incl. 1 hit on the ramp slope, n.z=0.6950)
BP4 find_collisions: 4,032
BP5 adjust_sphere: 30 (ALL on FLAT planes; ZERO on the ramp)
BP6 check_walkable: 25
BP7 set_contact_plane: 18 (ALL set the SAME flat plane:
(0,0,1) d=-93.9998 = world Z=94 =
cottage main floor)
Acdream (stuck — from scen4_cottage_cellar_polydump):
cp-write: 229,300
push-back: ~1000 (270 on the RAMP slope poly 0x0008)
step_up_slide: 159
THE DIVERGENCE — pinpointed:
Retail's BSP path-selection for the cellar ramp picks Path 6 (find_walkable
land) — the ramp is treated as a walkable floor to LAND ON. Result:
BP7 sets the contact plane to the cottage main floor (Z=94). No push-back
needed on the ramp.
Our BSP picks Path 5 (Contact → step_up → adjust_sphere push-back) for the
SAME ramp polygon. Result: 270 push-backs against the ramp slope; step_up
keeps failing → step_up_slide loop → player stuck.
NEXT STEP (new session): trace why our BSP picks Path 5 instead of Path 6
for the ramp. Likely in BSPQuery.FindCollisions dispatcher's
path-selection logic. The ramp is walkable (N.Z=0.695 > FloorZ=0.6642) so
Path 6 should fire. Maybe a wrong ObjectInfo state flag, or a sub-step
order issue, or the ramp polygon's BSP-side classification is wrong.
This capture + the polydump capture give a complete picture for the next
investigation session. No more guess-fixes today — the data is now sharp.
Test suite: 1148 + 8 (unchanged this commit).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
134c9b87f3