docs: Campaign P final physics slice — ledger updates (#116, #166, P2)

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 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-07-30 12:59:23 +02:00
parent 252e806804
commit 464005ef2b
2 changed files with 127 additions and 23 deletions

View file

@ -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"]

View file

@ -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