From 6811fc53d9cc919f07f97429ddf755bbd0d64069 Mon Sep 17 00:00:00 2001 From: Erik Date: Sun, 5 Jul 2026 16:10:34 +0200 Subject: [PATCH] =?UTF-8?q?docs:=20file=20#174=20=E2=80=94=20close-range?= =?UTF-8?q?=20door=20Use=20silently=20swallowed=20(wire-proven)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Facility Hub door investigation evidence: retail's byte-identical UseItem works on the same ACE (door F74C/F74B captured, broadcast to both clients; acdream renders the observed swing), while acdream's later attempts never reach the wire — the AP-23 close-range deferral parks the action on MoveToComplete(None) and the player's speculative TurnToObject never completes after the first use of the session. Candidates: per-attempt user-input cancel vs MotionsPending starvation (the #170 class, local edition). Also noted: GameEventType.UseDone is parsed nowhere, so ACE rejections are invisible. Captures: door-use3/4.pcapng (session scratchpad). Next: ACDREAM_PROBE_AUTOWALK round, then fix per the retail client use flow (§9a/§9b) — no deferral-skipping band-aid. Co-Authored-By: Claude Fable 5 --- docs/ISSUES.md | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) diff --git a/docs/ISSUES.md b/docs/ISSUES.md index 751b621e..4b84cfa8 100644 --- a/docs/ISSUES.md +++ b/docs/ISSUES.md @@ -46,6 +46,64 @@ Copy this block when adding a new issue: --- +## #174 — Door Use dies after the first attempt: close-range deferred uses silently swallowed (player MoveToManager never completes) + +**Status:** OPEN — root under investigation (wire + log evidence in hand; needs one `ACDREAM_PROBE_AUTOWALK=1` round to pick between the two candidate mechanisms) +**Severity:** HIGH (can't open doors reliably → blocks the #137 door acceptance + normal play) +**Filed:** 2026-07-05 +**Component:** interaction — B.4b Use pipeline / AP-23 speculative moveto deferral (R5-V5 facade) + +**Description (user, Facility Hub 0x8A02, door guid 0x78A020C7 Setup 0x02000C9D +useRadius=0.50):** double-clicking / R-using the door does nothing. The same +door opens fine from the retail client on the same ACE, and acdream renders +the observed swing correctly (inbound path healthy). + +**Evidence (3 wire captures + app log, 2026-07-05):** +1. First attempt (log): `use-deferred seq=624` fired (the close-range + deferral COMPLETED once — arrival callback ran), then 625 + 642–647 sent + far-range. Door never opened. ACE's replies to those weren't captured. +2. Retail control (capture `door-use3.pcapng`): retail sent + `[0xF7B1][seq][0x36][guid]` ×5 — ACE responded EVERY time with door + `0xF74C` UpdateMotion + `0xF74B` SetState (ETHEREAL toggling 0x1001C ↔ + 0x10018), broadcast to BOTH clients. Message format identical to ours. +3. acdream re-try (capture `door-use4.pcapng` + log): 2× DoubleClick + 4× R + — picks land, but ZERO `[B.4b] use` lines and ZERO door-guid packets on + the wire. The Use is swallowed CLIENT-SIDE before the send. + +**Mechanism (code trace):** `SendUse` close-range branch (≤2 m by the AP-23 +bucket — this door's flags → 2.0 m, overriding its real 0.5 m) parks the +action in `_pendingPostArrivalAction` and fires it ONLY from +`MoveToComplete(WeenieError.None)` (natural completion of the speculative +TurnToObject installed through the R5-V5 facade). A cancel (user input) or a +never-starting turn silently eats the use — no toast, no log (the deferral +prints are probe-gated). Candidates for "never completes": (a) the +`BeginTurnToHeading` `MotionsPending()` early-return starving the turn (the +#170 class, local-player edition — the log shows a steady +`MOTIONDONE pending=True` stream); (b) every attempt instantly cancelled by +concurrent user movement input (retail-faithful per-attempt, but the user +also clicked while standing still). Also noted: `GameEventType.UseDone` +(0x01C7) is parsed nowhere (not registered in `GameEventWiring`) — ACE +rejection reasons are invisible; and the first attempt's 7 sent uses never +opened the door either (suspect: concurrent outbound movement cancelling +ACE's MoveToChain server-side — unproven, replies not captured). + +**Files:** `src/AcDream.App/Rendering/GameWindow.cs` (`SendUse` ~12607, +`OnAutoWalkArrivedSendDeferredAction` ~12761, `InstallSpeculativeTurnToTarget` +~12842, `MoveToFactory` callback wiring ~13530); +`src/AcDream.Core/Physics/Motion/MoveToManager.cs` (`BeginNextNode` / +`BeginTurnToHeading` gates). Captures in the session scratchpad +(`door-use3.pcapng`, `door-use4.pcapng`). + +**Next:** relaunch with `ACDREAM_PROBE_AUTOWALK=1`; user clicks the door +(a) standing still, (b) right after moving. `[autowalk-end reason=complete +err=…]` vs silence discriminates cancel-vs-starved. Fix per retail: the use +flow must either complete the turn and fire, or surface the cancel +(retail re-queues/cancels visibly — decomp the client use flow §9a/§9b before +patching). DO NOT band-aid by skipping the deferral (the turn-to-face is +retail behavior). + +--- + ## #173 — Observed character jumping into a ceiling hovers at the roof until the arc decays (no collision-velocity response on remotes) **Status:** 🟡 FIX SHIPPED 2026-07-05 (this commit) — pending user visual gate (watch a second client jump into the 0x0007 dungeon roof; it should bounce down immediately like the local player).