From 464005ef2b4102f7888e5e8d4be915ea9a5424de Mon Sep 17 00:00:00 2001 From: Erik Date: Thu, 30 Jul 2026 12:59:23 +0200 Subject: [PATCH] =?UTF-8?q?docs:=20Campaign=20P=20final=20physics=20slice?= =?UTF-8?q?=20=E2=80=94=20ledger=20updates=20(#116,=20#166,=20P2)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Per docs/research/2026-07-30-ts4-116-oracle-plan.md, following the four code commits that closed out TS-4 (5e2be19b), #116 shape-2 (01492205), and AD-55 (252e8068), plus #116 shape-1's Path-6 fix (db2889af) and the TransitionalInsert return-value fix (7e1be3de): - ISSUES.md #116: shape-2 marked CLOSED (D4 un-skipped, structurally confirmed, no cdb needed). Shape-1 narrowed, not closed: the Path-6 head-sphere fix is a real, independent improvement but the tick-22760 confirming replay showed it doesn't explain that specific symptom -- the mover is grounded there (Path 5, not Path 6) and the actual no-normal-recorded mechanism (SpherePath.PrecipiceSlide's find_crossed_edge-false fallback) is independently confirmed byte-exact retail behavior too. Recorded the concrete next step (re-run against the faithful Setup-based door registration instead of the simplified fixture) rather than closing on an unmet acceptance criterion. - ISSUES.md #166: noted TS-4 and AD-55 landed (the AP-7-family completion this note was waiting on); closure still pends the visual- matrix scenario-5 recheck against live retail. - Campaign P plan (2026-07-29-physics-parity-campaign.md) P2 status block: TS-4 outcome (retired, not deferred), #116 outcome (shape-2 closed / shape-1 narrowed), AD-55 outcome (retired). Docs-only; no build/test change required for this commit. Co-Authored-By: Claude Fable 5 --- docs/ISSUES.md | 112 +++++++++++++++--- .../2026-07-29-physics-parity-campaign.md | 38 ++++-- 2 files changed, 127 insertions(+), 23 deletions(-) diff --git a/docs/ISSUES.md b/docs/ISSUES.md index 12ecd79f..540b4689 100644 --- a/docs/ISSUES.md +++ b/docs/ISSUES.md @@ -4382,7 +4382,9 @@ wall from acdream, matching the retail-observer view side-by-side. ## #166 — Slope-landing glide + bounce absent (retail "sled" on downhill jumps) -**Status:** OPEN (post-R6 polish — user: "we could polish later") +**Status:** OPEN (post-R6 polish — user: "we could polish later"); all +four register-predicted composite deviations (AD-25, AP-7, AD-55, TS-4) +are now landed as of 2026-07-30 — pending only a visual-matrix recheck **Severity:** LOW (feel/polish) **Filed:** 2026-07-03 (user observation during the R2-R4 visual pass) **Component:** physics, landing @@ -4439,24 +4441,43 @@ transition except grounded→grounded-and-not-sledding, matching retail's `shouldReflect = !(prevOnWalkable && nowOnWalkable && !sledding)`. Both halves of AD-25 (local player and remote) are now retired. -Closure of #166 therefore pends only: (a) TS-4 actually landing, and (b) -re-checking Campaign P's final visual matrix item 5 ("Downhill jump -landing: sled glide + bounce") against a fresh capture — if the glide/ -bounce still visibly mismatches retail after AP-7 and AD-25 (with TS-4 -still deferred), that capture, not a guess, is what should drive any -further work here, and it should go through cdb against live retail -before any client-side Sledding-state mechanism is written. +**TS-4 landed (2026-07-30, Campaign P final physics slice):** the +Path-6 steep-poly shortcut this note previously flagged as "deferred" is +now retired — the decisive confirming run +(`Ts4SteepRoofWedgeCaptureTests`, horizontal-velocity variant) showed the +shortcut-removed engine converges cleanly for the realistic (non- +degenerate) case. See `docs/research/2026-07-30-ts4-116-oracle-plan.md` +§1 and its own register row (struck through, TS-4). + +**AD-55 also landed the same slice** (the sled-flatness constant in this +SAME `calc_friction` function AP-7 already fixed): retail's Sledding +fast-sled override compares against `cos(10°) ≈ 0.98480775f`, byte-proven +against `0x0050ee70`, not the previously-carried ACE-derived `0.99999536f` +(≈0.175° from flat, essentially unreachable). This is the AP-7-family +completion the "sled deceleration differs" framing above was waiting on — +all four of AD-25, AP-7, AD-55, and TS-4 are now landed. + +Closure of #166 therefore pends only re-checking Campaign P's final +visual matrix item 5 ("Downhill jump landing: sled glide + bounce") +against a fresh capture — if the glide/bounce still visibly mismatches +retail now that every register-predicted composite deviation is retired, +that capture, not a guess, is what should drive any further work here, +and it should go through cdb against live retail before any client-side +Sledding-state mechanism is written (recall: no client-side +`PhysicsState.Sledding` auto-toggle exists in retail per the reattribution +above — a data-authored toggle exists only server-side). **Where:** `src/AcDream.Runtime/Physics/RuntimeRemotePhysicsUpdater.cs` (remote reflect, AD-25 — DONE 2026-07-30), -`src/AcDream.Core/Physics/PhysicsBody.cs` (`calc_friction`, AP-7 — DONE -2026-07-30), `src/AcDream.Core/Physics/BSPQuery.cs` (Path 6 steep branches, -TS-4 — deferred, shortcut still in place). +`src/AcDream.Core/Physics/PhysicsBody.cs` (`calc_friction`, AP-7 and AD-55 +— both DONE 2026-07-30), `src/AcDream.Core/Physics/BSPQuery.cs` + +`FlatBspQuery.cs` (Path 6 steep branches, TS-4 — DONE 2026-07-30). **Acceptance:** side-by-side downhill jump: acdream glides/bounces like retail; flat-ground landings unchanged; no micro-bounce death spiral -(the reason AD-25 existed) reintroduced. Blocked on TS-4's eventual -landing per the note above. +(the reason AD-25 existed) reintroduced. Every code-side composite +deviation is now landed; only the visual-matrix recheck remains before +this issue can close. ## #164 — UM action-replay dispatches drop the per-action Autonomous bit @@ -8615,8 +8636,12 @@ retail's viewer-distance smoothing (update_viewer region) before touching. ## #116 — Slide-response divergence family: near-perpendicular lateral slide lost + first-airborne-frame in-frame slide vs hard stop -**Status:** OPEN (narrowed) — one Ghidra-confirmed faithfulness fix -SHIPPED 2026-06-12; both reported shapes still need a runtime trace. +**Status:** OPEN (narrowed further, 2026-07-30) — **shape-2 CLOSED** +(D4 un-skipped and passing, oracle-plan-confirmed, no cdb needed after +all — see the 2026-07-30 update below); **shape-1 narrowed, not closed**: +a real, independently-decomp-confirmed Path-6 head-sphere fix landed, but +it does NOT explain the tick-22760 symptom this issue was filed against — +see below for the new evidence and the concrete open candidate. **Severity:** LOW-MEDIUM (over-blocking, never under-blocking — no walk-throughs; feel-level divergence at walls/doors) **Filed:** 2026-06-11 (BR-7 / A6.P4 ship session) @@ -8734,6 +8759,63 @@ door push to confirm whether the `cn=(0,0,1)` comes from our **2026-07-09 triage:** investigated, verdict STILL_OPEN — the pinned harness diagnostic (`Diagnostic_Tick22760_DumpEngineInternals`) still shows the harness hard-stopping laterally where live retail slides, and `BSPStepUpTests.D4_AirborneMover_TallWall_PersistsSlidingNormalAcrossFrames` remains explicitly `Skip`-tagged citing this issue; only one Ghidra-confirmed partial fix (`bf18a543`, `F_EPSILON` vs `EpsilonSq`) has landed. +**2026-07-30 (Campaign P final physics slice) — shape-2 CLOSED, shape-1 +narrowed with new evidence, no cdb session needed for either after all:** + +- **Shape-2 CLOSED — no cdb needed.** The oracle plan + (`docs/research/2026-07-30-ts4-116-oracle-plan.md` §3, cross-referencing + the raw BN pseudo-C, ACE's `BSPTree.cs`, and current source) found the + ROUTING question (does retail's first airborne wall-contact frame reach + `slide_sphere`?) answerable from static structure alone: retail's + dispatch never calls `slide_sphere` on a genuine first-airborne-frame + FOOT-sphere hit — `Path 6` sets `Collide` without repositioning, the + retry routes to `Path 4` (`find_walkable`), which for a sheer vertical + wall finds no candidate, and `Phase 3`'s `sp.Collide` block then hard- + stops with the wall's real normal. A confirming instrumentation run + (probes on which `BSPQuery.cs` path fires + whether `FindWalkableInternal` + finds a candidate, added in `5e2be19b`) reproduced exactly this sequence + for the D4 fixture once TS-4's shortcut was removed (`5e2be19b`) — Path 6 + → Path 4 (`changed=false`) → Phase 3 `Collided` with `StepUpNormal`. D4 + un-skipped as a test-only change (`01492205`) and passes. TS-4's own + removal is what unblocked this; D4's own code was never wrong. +- **Shape-1: the Path-6 head-sphere fix landed, but does NOT explain + tick-22760.** The oracle plan's §2.3 hypothesis (a foot-clear/head-hit + airborne contact deferred through `SetCollide`/`Adjusted` instead of + retail's direct `Collided`+`SetCollisionNormal`) is CONFIRMED as a real, + independently-decomp-confirmed divergence (pc:323824-323834, ACE + `BSPTree.cs:221-230`) and is now fixed in both `BSPQuery.cs` and + `FlatBspQuery.cs` (`db2889af`). **But re-running + `Diagnostic_Tick22760_DumpEngineInternals` after the fix shows NO + CHANGE** (harness still `cn=(0,0,1)` vs live `cn=(0,+1,0)`). New + dispatch-entry probes (`[path-dispatch]`, `[path5-diag]`, permanent, + gated on `ProbeIndoorBspEnabled`) traced the ACTUAL tick-22760 call + sequence: the mover is GROUNDED (`Contact` bit set in the seeded + snapshot), so it never reaches Path 6 at all. It dispatches Path 5 → + `StepSphereDown` (Path 3, both `DoStepDown` half-steps fail to find a + walkable candidate on the door's simplified BSP registration) → + `EdgeSlideAfterStepDownFailed` → `SpherePath.PrecipiceSlide`, whose + `find_crossed_edge`-false fallback returns `Collided` with **no** + collision-normal write. A fresh byte-level read of retail's + `SPHEREPATH::precipice_slide` (pc:274316-274326, `0x0050cc80`) confirms + this is byte-exact retail behavior (`if (eax == 0) { walkable = 0; + return 2; }`, no `set_collision_normal` call) — not a bug; `validate_transition`'s + `UnitZ` default fires identically in both engines here. **The tick-22760 + divergence is therefore NOT explained by anything in the response/slide + layer this issue was filed against.** Leading candidate (not yet + chased): `DoorBugTrajectoryReplayTests.BuildEngineWithDoorFixture` + registers the door's raw BSP directly at its captured bounding-sphere + center rather than via the faithful `ShadowShapeBuilder.FromSetup` + + `PlacementFrame` transform `BuildFaithfulDoorEngine` uses elsewhere in + the same file — the harness's door geometry may simply not be where + live retail's was at that exact tick, which would make this a + test-fixture gap, not an engine bug. See + `docs/research/2026-07-30-ts4-116-oracle-plan.md` Addendum 2 for the + full trace. **Next step, if picked back up:** re-run the tick-22760 + capture against `BuildFaithfulDoorEngine`'s Setup-based registration + (not the simplified fixture) to see whether a real BSP hit against the + door — instead of the seeded generic floor triangle — changes the + outcome, before considering any further code change. + --- ## #118 — Character clipped + disappears for a moment when exiting houses — [DONE 2026-06-11 · 5a80a2e, user re-gate "Yes solved"] diff --git a/docs/plans/2026-07-29-physics-parity-campaign.md b/docs/plans/2026-07-29-physics-parity-campaign.md index 21ac740e..bd38f8e3 100644 --- a/docs/plans/2026-07-29-physics-parity-campaign.md +++ b/docs/plans/2026-07-29-physics-parity-campaign.md @@ -94,14 +94,36 @@ character state continuously. ### P2 — Response-layer edge family — retires TS-1, TS-4, AP-7; closes #166, #116 -**Status (2026-07-30):** TS-1 and AP-7 retired; #166 reattributed in -ISSUES.md (no new code — see the research doc §3). **TS-4 is deferred, not -retired** — the fixture-first removal attempt this doc's §6 Step 3 requires -reproduced the historical 2026-04-30 L.4 wedge (a dat-free capture, -`Ts4SteepRoofWedgeCaptureTests`); the shortcut stays in `BSPQuery.cs`. Root -cause and the concrete next research step are recorded in -`docs/research/2026-07-30-response-layer-edge-family-pseudocode.md` §7 item -6. #116 is untouched (oracle-first, own session). +**Status (2026-07-30, FINAL — Campaign P final physics slice):** TS-1 and +AP-7 retired same-day as originally recorded. **TS-4 is now ALSO +RETIRED** — the oracle follow-up pass +(`docs/research/2026-07-30-ts4-116-oracle-plan.md`) found the freeze the +first implementation attempt hit was one layer downstream of Path 6 +(inside `AdjustOffset`'s crease projection against a purely-vertical +offset — a genuine retail-identical degeneracy, not a bug) and ran the +plan's own decisive confirming test: `Ts4SteepRoofWedgeCaptureTests`'s +horizontal-velocity variant (matching the realistic live-play input that +originally validated the shortcut) converges cleanly with the shortcut +removed. The Path-6 steep-poly shortcut is deleted from both +`BSPQuery.cs` and `FlatBspQuery.cs`; the pure-vertical degenerate case is +pinned (not fixed) as register row AD-56. **#116 is narrowed, not +closed**: shape-2 (D4 first-airborne-frame hard-stop) is CLOSED — the +oracle plan's structural dispatch-routing hypothesis was confirmed by +instrumentation with no cdb session needed, and the D4 pin is un-skipped. +Shape-1 (tick-22760 lateral-slide loss) got a real, independently-decomp- +confirmed fix (Path 6's foot-clear/head-hit branch now returns `Collided` ++ `SetCollisionNormal` directly, matching pc:323824-323834/ACE +`BSPTree.cs:221-230`), but the confirming replay showed this does NOT +explain tick-22760 itself — that mover is grounded (dispatches through +Path 5, not Path 6) and the actual "no normal recorded" mechanism +(`SpherePath.PrecipiceSlide`'s `find_crossed_edge`-false fallback) is +independently confirmed byte-exact retail behavior too. The remaining +divergence is most likely this test's simplified door-registration +fixture, not the response layer — see ISSUES.md #116 and the oracle +plan's Addendum 2 for the full trace and the concrete next step (re-run +against the faithful Setup-based door registration). AD-55 (the sled +slope-flatness constant, split out of AP-7's retirement) is ALSO retired +this same slice — byte-proven `cos(10°)` per the oracle plan's Addendum. The collision *response* layer (what happens after a hit): ground friction, cliff edges, downhill landings, near-perpendicular wall