From 6c4f6be1b4895f8b3e4f9ec489c3f011e6fbac41 Mon Sep 17 00:00:00 2001 From: Erik Date: Mon, 18 May 2026 09:34:54 +0200 Subject: [PATCH] docs(issues): close #77 in ISSUES.md (closed by 3be7000) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Moves #77 from Active to Recently closed with the resolution writeup (both halves — walk-vs-run misclassification + velocity-leak in turn-in-place — plus the decomp anchors and verification record). Co-Authored-By: Claude Opus 4.7 (1M context) --- docs/ISSUES.md | 145 +++++++++++++++++++++---------------------------- 1 file changed, 63 insertions(+), 82 deletions(-) diff --git a/docs/ISSUES.md b/docs/ISSUES.md index 8e49cca..1dc8147 100644 --- a/docs/ISSUES.md +++ b/docs/ISSUES.md @@ -46,88 +46,6 @@ Copy this block when adding a new issue: # Active issues -## #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 @@ -2645,6 +2563,69 @@ Unverified. The likely culprits, ranked by suspected probability: # Recently closed +## #77 — [DONE 2026-05-18 · 3be7000] Auto-walk doesn't engage at walking range; pickup at walking range overshoots and snaps back + +**Closed:** 2026-05-18 +**Commit:** `3be7000` — fix(physics): close #77 — auto-walk honors ACE CanCharge bit; zero velocity in turn-in-place +**Component:** physics / `PlayerMovementController` / `GameWindow.OnLiveMotionUpdated` / `CreateObject.ServerMotionState` + +**Resolution.** Two coupled bugs sharing a root in +`PlayerMovementController.DriveServerAutoWalk` + `BeginServerAutoWalk`. + +1. **Walk-vs-run misclassification (the user-visible "always runs at walk range" half).** + `BeginServerAutoWalk` decided `_autoWalkInitiallyRunning = (initialDist − + distanceToObject) >= 1.0f`, forcing run at any chase past ~1.6 m. + ACE's wire-level walk-vs-run answer is the MovementParameters + **CanCharge** bit (0x10), which `Creature.SetWalkRunThreshold` + sets when server-side player→target distance ≥ `WalkRunThreshold/2` + (= 7.5 m default). Retail's `MovementParameters::get_command` + (decomp `0x0052aa00`, `acclient_2013_pseudo_c.txt:307946+`) gates + the run path on CanCharge first; the inner walk_run_threshold + check practically always walks given ACE's 15 m default. The + hardcoded 1.0 m threshold pushed run into the 3-5 m walk-range the + user reported should walk. + +2. **Velocity leak in turn-in-place phase (the user-visible "overshoots + and snaps back" half).** When the auto-walked body crossed the + destination, `desiredYaw` flipped ~180°, `walkAligned` dropped to + false, and the `if (!moveForward) return true;` branch returned + without zeroing body velocity. The body kept the prior frame's + running velocity (`RunAnimSpeed × runRate ≈ 11 m/s`) and slid 4-5 m + past the target before the turn-around rotation completed. + +**Changes:** +- `CreateObject.ServerMotionState.CanCharge`: new bool prop reading + bit 0x10 of `MoveToParameters`. Cross-ref ACE + `MovementParams.CanCharge = 0x10`. +- `PlayerMovementController.BeginServerAutoWalk`: replaces the unused + `walkRunThreshold` parameter with `bool canCharge`; sets + `_autoWalkInitiallyRunning = canCharge`. +- `PlayerMovementController.DriveServerAutoWalk` turn-in-place branch: + calls `_motion.DoMotion(Ready, 1.0)` and zeros body horizontal + velocity (preserving Z for gravity). No-op for initial-turn with a + stationary body; fixes overshoot-recovery and settling cases. +- `GameWindow.OnLiveMotionUpdated`: passes + `update.MotionState.CanCharge` through; `[autowalk-begin]` trace + now shows `canCharge=` instead of `walkRunThresh=`. +- `GameWindow.InstallSpeculativeTurnToTarget`: predicts ACE's + CanCharge from local distance using ACE's exact 7.5 m rule, so the + speculative install agrees with the wire-triggered overwrite that + arrives moments later. + +**Verification.** Build green; all targeted test projects pass cleanly +(Core.Net 294/294, UI.Abstractions 419/419, App 10/10; Core 1073 passed +/ 8 pre-existing failures unchanged). Visual-verified at Holtburg +2026-05-18: walk-range NPC click walks + Use fires + dialogue appears, +walk-range F-key pickup walks + no overshoot + item enters inventory, +far-range pickup (8-10 m+) still runs. + +**Lesson archived:** `memory/feedback_autowalk_cancharge_bit.md`. When +ACE already encodes a decision on the wire (CanCharge IS the walk-vs-run +answer), relay it — don't reinvent the bucket with a locally-computed +threshold. + +--- + ## #56 — [DONE 2026-05-12 · 8735c39] `ParticleHookSink` ignores `CreateParticleHook.PartIndex`; multi-emitter scripts collapse to entity root **Closed:** 2026-05-12