#116 oracle desk read: slide-response leads pinned, needs a live cdb to finish

Read both sides quote-for-quote (verified against source): our
CSphere::slide_sphere port (TransitionTypes.cs:3054-3133) vs retail
0x00537440 (decomp 321403-321532). Findings:

1. Shape-1 (tick-22760 lost 3.57cm slide) is NOT the degenerate-offset
   guard - retail's guard only kills slides under ~1.4cm. The real
   divergence is the collision-normal SOURCE: our harness cn=(0,0,1) vs
   live cn=(0,+1,0). Strong lead: TransitionTypes.cs:3701-3702 defaults
   cn=Vector3.UnitZ when no valid normal.
2. Shape-2: retail's slide_sphere applies the slide IN-FRAME
   (add_offset_to_check_pos @0x53777e, return SLID) - our in-frame slide
   to Z=1.92 is likely retail-faithful and the D4 frame-1 hard-stop pin
   is the stale one (pending the first-airborne-frame plane state).
3. Candidate epsilon-squaring divergence: retail compares SQUARED
   quantities against 0.000199999995 (non-squared) while we compare
   against EpsilonSq=0.0002^2 - possibly 1e4x too small. Explains
   neither shape; DO NOT change without cdb (the test ah,5 branch
   polarity is the undecodable BN construct from the PosHitsSphere saga).

No code change (oracle-first; the issue title calls for cdb and the BN
decomp is provably ambiguous on the branch signs). ISSUES.md #116 +
physics digest carry the leads + the scoped cdb plan.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-06-13 10:11:34 +02:00
parent fbfecd20ca
commit 35961f2039

View file

@ -3968,6 +3968,51 @@ them byte-identical):**
fixture as the acceptance pair. Do NOT patch the degenerate-offset guard
ad hoc — the DO-NOT-RETRY table's slide entries (physics digest) apply.
**ORACLE DESK READ DONE (2026-06-12) — needs a LIVE cdb session to
finish.** Both sides quoted + verified against source (our
`CSphere::slide_sphere` port = `TransitionTypes.cs:3054-3133`; retail
`CSphere::slide_sphere` = decomp `0x00537440`, lines 321403-321532).
Three concrete leads, none safely fixable from the static BN decomp:
1. **Shape-1 re-attributed — it is NOT the degenerate-offset guard
threshold.** Retail's guard kills slides under ~1.4 cm (`|offset|² <
0.000199999995` at `0x537735`); the lost tick-22760 slide was 3.57 cm
(`X 0.0357`), well above it — retail would keep it too. The real
divergence is the COLLISION-NORMAL SOURCE: our harness recorded
`cn=(0,0,1)` (ground), live retail `cn=(0,+1,0)` (the door face).
Strong lead: `TransitionTypes.cs:3701-3702` — on a blocked move with
no valid collision normal we DEFAULT `cn = Vector3.UnitZ` ("push up");
that exact (0,0,1) is what the harness sees. Whether retail has an
equivalent default (vs keeping the wall normal) is a runtime question.
2. **Shape-2 — retail's slide_sphere applies the slide IN-FRAME**
(`add_offset_to_check_pos` @`0x53777e`, returns 4=SLID), so our
in-frame slide to Z=1.92 on frame 1 is likely retail-faithful and the
D4 frame-1 hard-stop pin (`BSPStepUpTests.D4_*`, expects Z=2.0) is the
STALE expectation. BUT retail always uses `contact_plane` OR
`last_known_contact_plane` (`0x53755a`); it has no "airborne wall-only,
no plane" third branch like ours (`TransitionTypes.cs:3080-3092`) — the
first-airborne-frame plane state needs a trace before flipping the pin.
3. **Candidate epsilon-squaring divergence (real, but explains neither
shape).** Retail compares SQUARED quantities (`|cross|²` @`0x5375a5`,
`|offset|²` @`0x537735`) against `0.000199999995` (≈0.0002, NON-squared);
our port compares against `EpsilonSq = 0.0002²` (line 3105 + the
`dirLenSq >= EpsilonSq` branch @3098) — potentially ~10⁴× too small.
DO NOT change this without cdb confirmation: the BN `test ah, 0x5`
branch polarity (lines 321466-321467/321484-321485) is the exact
undecodable construct the PosHitsSphere saga warned about, and the
register reuse garbles which quantity is squared. A wrong guess here
regresses ALL wall-slide behavior.
**Next (cdb session, well-scoped):** (a) `cdb -z uf
acclient!CSphere::slide_sphere` OR a live attach to disassemble
`0x00537440` and settle the two `test ah,5` branch signs + the
squared-vs-not threshold (prefer LIVE attach — prior lesson: static
`-z uf` misdecodes at OMAP boundaries); (b) live trace the tick-22760
door push to confirm whether the `cn=(0,0,1)` comes from our
`UnitZ`-default (lead 1) and what retail's normal is at that instant.
---
## #117 — Aperture-shaped see-through: doors/interiors visible through terrain hills and through nearer buildings — [DONE 2026-06-11 · 478c549, user re-gate "Yes solved"]