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

docs: #345 D0 verdict — the stuck-tick fingerprint is retail's own algorithm; fix attempt correctly stopped

Browse source 
Five links traced from the named decomp: the below-push never executes
(OnWalkable guard — the probe printed the wrong guard pair), the
from-scratch retry is retail-identical, and validate_transition's
failure path manufactures every captured field including the (0,0,1)
default. Stopping dead may simply BE retail. Two validations remain:
the user observing their RETAIL client at a comparable slope (the
cheapest decisive test there is), and — only if retail visibly
slides — the find_cell_list broadphase question via the cdb toolchain.
The mechanism paragraph's wrong-cause framing is retained and
corrected in place, per the register's own honesty pattern.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-08-07 11:11:19 +02:00
parent 2098fa6690
commit 18289f95f8
2 changed files with 292 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

27
docs/ISSUES.md
View file

@ -178,7 +178,32 @@ position. Zero yield. (`oiContact=True, spStepDown=False, guardPassed=False`
on every line — the morning's `collN=(0,0,1)` comes from the failure path's
result-filling, not from ValidateWalkable's guard, which never passes here.)
**The fix contract's question is now precise:** what does RETAIL's
### D0 VERDICT, same day — the fingerprint IS retail's own algorithm; the fix attempt STOPPED itself
The fix implementer's mandatory pseudocode pass traced all five links from
the named decomp (addresses in
`docs/research/2026-08-08-345-pseudocode.md`) and found the mechanism
paragraph above named the right symptom with the WRONG cause: the below-push
never executes at all (its guard is `step_down || !OnWalkable || walkable`,
and the player IS OnWalkable on the flat approach — the probe printed the
SetCollisionNormal guards, not this one); `Adjusted` retrying the whole
insert from scratch is retail-identical (`transitional_insert` @0x0050b6f0);
and `validate_transition` @0x0050aa70 on failure kills velocity, restores
the flat plane, DEFAULTS the collision normal to (0,0,1), reverts CheckPos,
and forces OK — producing every field of the captured fingerprint from
retail's own code. **Stopping dead here may simply BE retail.**
**Two open validations before this closes either way:**
1. **The cheapest decisive test needs no debugger: the USER walks their
RETAIL client into a comparable just-too-steep hillside at ~45° and
reports slide vs dead stop.** Their expectation of sliding is currently
the only evidence against retail-faithfulness.
2. If retail visibly slides: the remaining suspect is UPSTREAM of the
walkable response — whether retail's `find_cell_list` broadphase even
queries the steep cell from this position (the pseudocode doc's open
question) — a runtime question for the cdb toolchain, not code-reading.
**The fix contract's question (superseded by the verdict above, retained):** what does RETAIL's
transitional_insert do with validate_walkable's Adjusted on a non-walkable
plane — does the adjusted CheckPos feed the NEXT attempt (convergence), or
does retail take a different branch entirely (slide/collision) instead of