From f8829b39bea8c3249507aa6fefe6cc4d897f0771 Mon Sep 17 00:00:00 2001 From: Erik Date: Sun, 17 May 2026 16:16:55 +0200 Subject: [PATCH] docs(issues): file #77 (close-range auto-walk + pickup overshoot) + close #76 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit #77 captures two close-range visual bugs observed during Step 2 verification that are pre-existing — not caused by 0b25df5. Both live in PlayerMovementController.DriveServerAutoWalk / threshold logic from Phase B.6 work (#75). Trace evidence captured from launch.log of the verification run. #76 closed with the diag-trace evidence: identity invariants matched across session / _liveSession / _liveSessionController.Session (hashcode=1034657 throughout), so the original suspected bug-class was wrong. The first Step 2 attempt's apparent regression was almost certainly a stale ACE session. Co-Authored-By: Claude Opus 4.7 (1M context) --- docs/ISSUES.md | 106 ++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 104 insertions(+), 2 deletions(-) diff --git a/docs/ISSUES.md b/docs/ISSUES.md index 8d4baee..8e49cca 100644 --- a/docs/ISSUES.md +++ b/docs/ISSUES.md @@ -46,12 +46,114 @@ Copy this block when adding a new issue: # Active issues -## #76 — LiveSessionController extraction (Step 2) regresses interaction + chat outbound +## #77 — Auto-walk doesn't engage at walking range; pickup at walking range overshoots and snaps back **Status:** OPEN +**Severity:** MEDIUM (M1-deferred polish; visible during normal play, doesn't block any phase) +**Filed:** 2026-05-16 +**Component:** physics / auto-walk / `PlayerMovementController.DriveServerAutoWalk` + +**Description:** Two related visual bugs observed during Step 2 (`0b25df5`) +visual verification at Holtburg. Both involve the close-range branch of +the server-driven auto-walk path (Phase B.6 / closed-issue #75 territory). + +**Bug A — NPC at walking range never auto-walks:** +- User clicks on an NPC (e.g. Royal Guard `0x7A9B46AE`) when the player + is in "walking range" — far enough that retail would walk a short + distance, not close enough to immediately Use. +- The client's `WorldPicker` returns `WithinUseRadius=false`, so + `OnInputAction.UseSelected` defers the Use and would expect ACE's + `MoveToObject` to drive the player to the NPC. +- ACE sends back `UpdateMotion` with the auto-walk command — observed in + the log as `OnLiveMotionUpdated: guid=0x5000000A stance=0 cmd=0x0005 + speed=-1.84` immediately after each `[B.4b] use guid=...` outbound. +- But the local player doesn't visibly move. Repeated clicks (the trace + shows seq 81 → 87 → 90 → 96 → 105 → 141 → 146 → 159 → 163 → 169 → 173 + → 177 against the same Royal Guard) produce the same response every + time without movement. + +**Bug B — Pickup at walking range runs/overshoots/snaps back:** +- User presses F on a ground item while in "walking range" of it. +- Player RUNS (not walks) toward the target. +- Overshoots the item, then "blips back" to the correct position before + the pickup actually fires. +- The pickup completes (item ends up in inventory), but the visual is + jarring — clearly the walk/run threshold misclassifies the close-range + case, then ACE's position-correction snaps the player back. + +**Root cause / status:** Unknown. Likely in one of: +- `PlayerMovementController.DriveServerAutoWalk` — engagement condition + (does it activate on negative speed? on cmd=0x0005?) +- Walk/run distance threshold (CLAUDE.md notes 1.0m as the corrected + threshold from Phase B.6, but the `runRate` / `cmd` derivation may + miscalculate at close range) +- Inbound `UpdateMotion` parser — the `speed=-1.84` is suspicious; if + retail sends the magnitude positive with direction encoded elsewhere, + the sign may be a sign-extension bug + +**Step 2 refactor (`0b25df5`) is NOT a cause** — confirmed by diff scope: +`src/AcDream.App/Input/PlayerMovementController.cs`, +`src/AcDream.Core/Physics/PhysicsEngine.cs`, and +`src/AcDream.Core.Net/Messages/UpdateMotion.cs` were untouched. Both bugs +exist on the pre-Step-2 branch (eda936d / 32423c2 / main); the close +visual scrutiny during Step 2 verification just made them obvious. + +**Trace evidence (from `launch.log` of task `b01zkw68w`, Step 2 verification):** +``` +[B.4b] use guid=0x7A9B46AE seq=159 ← outbound Use +OnLiveMotionUpdated: guid=0x5000000A stance=61 cmd=0x speed= ← player → NonCombat +OnLiveMotionUpdated: guid=0x7A9B46AE stance=61 cmd=0x0003 speed= ← NPC turns to face +OnLiveMotionUpdated: guid=0x7A9B46AE stance=61 cmd=0x speed= +OnLiveMotionUpdated: guid=0x5000000A stance=0 cmd=0x0005 speed=-1.84 ← ACE's MoveToObject for player (NOT followed) +OnLiveMotionUpdated: guid=0x5000000A stance=0 cmd=0x speed= +``` + +**Files (where the investigation should start):** +- `src/AcDream.App/Input/PlayerMovementController.cs` — `DriveServerAutoWalk`, + walk/run threshold, runRate derivation +- `src/AcDream.Core.Net/Messages/UpdateMotion.cs` — speed sign-extension +- Phase B.6 spec: `docs/superpowers/specs/2026-05-14-phase-b6-design.md` + +**Research:** Recommend an `ACDREAM_PROBE_AUTOWALK=1` trace run capturing +the player's body state every frame between Use-outbound and arrival, +correlated with the inbound `UpdateMotion`. The probe already exists in +`PhysicsDiagnostics` from Phase B.6 work — should produce the per-frame +evidence needed without a fresh investigation tool. + +**Acceptance:** +- Click NPC at walking range → player walks (not runs) directly to NPC, + Use fires on arrival, NPC dialogue appears. +- Press F on ground item at walking range → player walks (not runs) the + short distance, no overshoot, no blip-back, item enters inventory. + +--- + +## #76 — [DONE 2026-05-16 · `0b25df5`] LiveSessionController extraction (Step 2) regresses interaction + chat outbound + +**Status:** DONE **Severity:** MEDIUM (refactor blocker; doesn't affect main branch which is unchanged) **Filed:** 2026-05-16 -**Component:** app / refactor (Step 2 of `docs/architecture/code-structure.md` §4) + +**Resolution (2026-05-16 · `0b25df5`):** Step 2 re-attempted with +`[step2-diag]` traces at every hypothesized fault point. The traces +showed all four hypotheses were wrong — `session.hashcode` was identical +through `_liveSession`, `_liveSessionController.Session`, and the +captured `liveSession` local in the chat-bus lambda, ruling out +identity mismatches and closure-capture bugs. Doors verified via +inbound `OnLiveMotionUpdated` round-trip (cmd=0x000B open, cmd=0x000C +close). Pickup verified via 4 successful `[B.5] pickup` calls. The +previous broken run was almost certainly a stale ACE session (no other +code-level explanation survives the diag trace). One small material +diff: the chat-bus lambda's `var liveSession = _liveSession;` capture +became `var liveSession = session;` (the non-null parameter) so the +compiler can statically prove non-null inside the lambda — both pointed +to the same `WorldSession` instance, only the static analysis changed. + +Traces stripped before commit. Walking-range auto-walk bug observed +during the second verification run is pre-existing (filed as #77, not +caused by this refactor). + +**Description:** A first attempt at Step 2 — extracting `LiveSessionController` **Description:** A first attempt at Step 2 — extracting `LiveSessionController` out of `GameWindow.cs` — was implemented and reverted in the same session