erik/acdream
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 2

docs: #345 live retail trace — the glide is cliff_slide firing every tick; our insert loop never routes there

Browse source 
cdb on the PDB-paired retail client during the user's 45-degree glide:
edge_slide/cliff_slide 594 each in lockstep, set_sliding_normal 538,
step_up ZERO. Ours: 18 edge-family firings total, stuck ticks
dead-looping on insert retries. The divergent branch is
transitional_insert's handling of the refused steep walkable — retail
proceeds into the step-down-failed/edge path per tick, we retry from
scratch. The D0 code-reading's 'retries from scratch, retail-identical'
conclusion is corrected by the runtime evidence: the profile is what
the decomp reading could not see.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-08-07 11:22:27 +02:00
parent 2b5367a81a
commit 3dd41c66e1
2 changed files with 49 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

23
docs/ISSUES.md
View file

@ -206,6 +206,29 @@ and trace validate_walkable @0x0050d010 / transitional_insert @0x0050b6f0 /
adjust_sphere_to_plane @0x00538210 WHILE the glide happens — the diff
between retail's live inputs and ours in the same scenario IS the answer.
### LIVE RETAIL TRACE 2026-08-08 — the glide IS cliff_slide, firing every tick; the divergent branch is pinned
cdb attached to the PDB-paired retail client while the user glided the
45-degree protocol (`345-retail-glide.cdb.log`): `edge_slide` and
`cliff_slide` fired **594 times each, in lockstep** (~30/s through the glide
windows) with `set_sliding_normal` tracking at 538; **`step_up` fired ZERO
times**; `adjust_sphere_to_plane`/`walkable_hits_sphere` zero (outdoor
terrain walkables go through `validate_walkable` only). Ours in the same
scenario: the edge family fired 18 times total and the stuck ticks
dead-looped on insert retries without reaching it.
**The divergence, exactly:** retail's `transitional_insert`, when the
walkable validation refuses the steep plane, proceeds INTO the
step-down-failed/edge_slide path on every tick — the D0 pass's
"Adjusted just retries from scratch" reading missed the branch retail
actually takes here. Ours retries the insert without entering the edge
family, exhausts attempts, restores. The fix target is that one branch in
our `TransitionalInsert` against retail's @0x0050b6f0, with the edge-entry
anchors already mapped in the #32 research (step-down-failed at
~0x0050b8xx-0x0050b921). The response machinery downstream is already
proven faithful AND live-healthy (this morning's 18 firings all applied
clean constraints).
**The two prior validations (both now resolved — the user's observation
answers 1 and mandates 2's runtime session):**
1. **The cheapest decisive test needs no debugger: the USER walks their