Acdream-side capture for the Holtburg inn doorway walk, paired with
the v4 retail capture committed at 180b4a5. 84,130 lines total.
Probe line distribution (~30 sec session, ~2 sec actual walk):
[push-back] (adjust_sphere): 8 hits — vs retail BP5 12 hits
[push-back-disp] (dispatch): 295 — vs retail BP4 5818 (!)
[push-back-cell] (other_cells): 5 — vs retail's check_other_cells
[indoor-bsp]: 26
[cell-transit]: 30 (cell ID changes)
[cp-write]: 73,304 (per-field writes) — vs retail BP7 18 fn calls (!)
[cell-cache]: 540
Two major divergences already visible from this single scenario:
1. DISPATCH FREQUENCY: retail's BSPTREE::find_collisions fires 20×
more than acdream's BSPQuery.FindCollisions. Could reflect either
different physics tick rate, different sub-step cadence, or
different call paths into the dispatcher.
2. CONTACTPLANE LIFECYCLE: acdream writes CP fields 73,304 times
in 30 seconds (~2,400/sec). Retail calls set_contact_plane 18
times (~0.6/sec). Even with a 6× field-write multiplier per
set_contact_plane call, that's ~100 actual CP updates in retail
vs ~12K in acdream — 100-1000× more frequent in acdream. This
directly confirms the spec's hypothesis that FindEnvCollisions
indoor branch is rewriting CP every frame (sub-step?) instead
of retaining it across frames. Same family as the
TryFindIndoorWalkablePlane workaround.
Per-call shape comparison (BP5 hit#1):
Retail: plane=(0,0,1) d=-0.0, sphere=(0.0046,10.31,-0.27) r=0.48,
mvmt=(0,-0,-0.75), winterp=1.0
Acdream: plane=(0,0,1) d=-0.0, sphere=(-0.43,11.02,0.46) r=0.48,
mvmt=Z-down, winterp 1.0→0.96 (small adjust applied)
Identical operation SHAPE (ground plane + vertical step-down probe
+ same radius). XY positions differ because walks were independent.
Scenario 1 complete. Remaining 8 scenarios deferred per user
direction. Python hex→float decoder + A6.P1 handoff doc to follow.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
8ca718a56d