bc1be26907
P2 / M1.5 "blocked at the last step" cellar-lip wedge. This session built a faithful deterministic reproduction and peeled the cause through six evidence-disproven framings to one bounded question. NO fix landed — the last layers were each disproven by evidence, and guessing at the load-bearing collision code is the saga's failure mode. Apparatus: - CellarLipWedgeTests.cs + Fixtures/cellar-lip/ (3 real cell dumps + wedge-records.jsonl = 29 captured ACDREAM_CAPTURE_RESOLVE wedge calls). Replays the exact calls + body-before through the lip-cell engine: all 29 reproduce at 0% advance in <200 ms. Tests are documents-the-bug / diagnostics (GREEN while the wedge exists). - TEMP probes ([path5-wall]/[fw-enter]/[find-walkable] in BSPQuery; [neg-poly]/[stepsphereup]/ [stepdown-decide]/CheckOtherCells cn/sn/negHit in TransitionTypes), gated on ACDREAM_PROBE_INDOOR_BSP, marked STRIP. TransitionTypes neg-poly shortcut has a reverted-fix comment (slide attempt didn't clear the wedge). - tools/cdb/retail-*-trace.cdb (retail cdb traces). Findings (handoff: docs/research/2026-06-04-p2-cellar-lip-flatfloor-cp-handoff.md, see the "NEXT-SESSION KICKOFF" at top): - Flat-floor contact plane is retail-faithful (v1 trace, full-file correlation). NOT the bug. - PosHitsSphere cull sign is retail-faithful (cdb -z verified; the Binary Ninja `test ah,N; jp` parity-jump reads inverted — caught + reverted a wrong fix from that mis-read). - Sphere radius correct (0.48 player / 0.30 camera probe). - Retail connector cell 0xA9B40175 never blocks (CEnvCell::find_collisions trace: 0 Collided/Slid). - PINNED: during the step-up's step-down, BSPQuery.FindWalkableInternal is never called for cell 0171, so the cottage floor (poly 0x0023, Z=94) is never tested as walkable -> no contact plane -> step-up fails -> StepUpSlide=Collided -> wedge. Next: trace FindEnvCollisions -> FindCollisions path dispatch for 0171 during StepDown=true (why StepSphereDown/find_walkable is skipped), port retail, validate via CellarLipWedgeTests, regress DoorBugTrajectoryReplayTests + visual gate. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
26 lines
1.7 KiB
Text
26 lines
1.7 KiB
Text
$$ Retail flat-floor contact-plane trace (2026-06-04, v2 — CORRECTED).
|
|
$$ Decisive question: when retail lands on the FLAT cottage floor during the climb, does
|
|
$$ BSPTREE::step_sphere_down SET the contact plane (return 3) or NOT (return 1)?
|
|
$$
|
|
$$ v1 (gu-in-bp-action) FAILED: "commands skipped ... target execution inside an event
|
|
$$ handler" corrupted eax -> a perfect 1,3,1,3 alternation artifact. DO NOT use `gu` in a
|
|
$$ bp action. v2: stash the carried cell in $t3 at ENTRY (arg2 = sphere_path at [esp+4],
|
|
$$ before the prologue), then break at the TWO RETURN addresses and print SET/NO + $t3.
|
|
$$
|
|
$$ STEP 0 (do this FIRST, before driving): the +0x218 (return 3) / +0x227 (return 1) offsets
|
|
$$ below are from the decomp (step_sphere_down @0x53a210; return 3 @0x53a428; return 1 @0x53a437)
|
|
$$ and MUST be verified against the live binary. After attaching, read the log: the `u` output
|
|
$$ (below) disassembles the function — confirm which addresses load eax=3 vs eax=1 (or jmp to the
|
|
$$ shared epilogue) and FIX the two `bp ...+0xNNN` offsets if they differ, then re-attach.
|
|
$$
|
|
$$ No qd / no Stop-Process needed if the user closes retail (debuggee exit detaches cdb).
|
|
.logopen C:\Users\erikn\source\repos\acdream\.claude\worktrees\thirsty-goldberg-51bb9b\retail-flatfloor-trace.log
|
|
.sympath C:\Users\erikn\source\repos\acdream\refs
|
|
.symopt+ 0x40
|
|
.reload /f acclient.exe
|
|
u acclient!BSPTREE::step_sphere_down L90
|
|
r @$t3 = 0
|
|
bp acclient!BSPTREE::step_sphere_down "r @$t3 = @@c++(((acclient!SPHEREPATH *)poi(@esp+4))->check_pos.objcell_id); gc"
|
|
bp acclient!BSPTREE::step_sphere_down+0x218 ".printf \"SET-CP cell=0x%x\\n\", @$t3; gc"
|
|
bp acclient!BSPTREE::step_sphere_down+0x227 ".printf \"NO-CP cell=0x%x\\n\", @$t3; gc"
|
|
g
|