# Pickup prompt — #170 "sustain the creature run" (paste into a fresh session)

Read `docs/research/2026-07-04-170-creature-run-handoff.md` first — it is the SSOT
for this task and carries the full evidence, the retail cdb numbers, the apparatus,
and the DO-NOT-RETRY list. Then continue #170.

**Where we are:** the primary #170 bug is FIXED and user-verified at `427332ac`
(branch `claude/vigorous-joliot-f0c3ad`). A per-frame `apply_current_movement`
re-dispatch was flooding `CMotionInterp.pending_motions` to ~1.3M entries, which
kept `MotionsPending()` permanently true and blocked the MoveTo chase turn
(`BeginTurnToHeading`), so a chasing creature slid in an idle+attack pose instead
of running. Deleting that per-frame call (GameWindow ~9992) dropped the queue to
depth ~1 (add≈done), killed the "stuck in attack animation", and the run cycle now
installs (`BeginMoveForward` 1→10). The "stuck attack" is confirmed gone by the user.

**Your job — the ONE remaining residual: "sustain the run."** The run isn't
sustained yet: `BeginTurnToHeading` is still blocked `motionsPending=True` ~94% of
the time because a small **`Ready` (0x41000003) stop-node backlog** keeps
`pending_motions` from ever fully emptying between swings. acdream gets ~10
run-starts vs retail's 21, so the creature now twitches-forward + glides instead of
a clean run-then-stop. Retail hits `add_to_queue == MotionDone` EXACTLY (cdb-proven);
acdream's `Ready` stop-nodes drain a beat slower.

**Do this, in order:**
1. Re-read the handoff's "residual" + "DO-NOT-RETRY" sections. In particular: the
   `BeginTurnToHeading` `if (motions_pending) return` guard is retail-faithful — DO
   NOT patch it; fix the DRAIN so the queue empties like retail.
2. **Retail is the oracle** (Step -1). Retail's cdb is available; the binary matches
   `refs/acclient.pdb`. Trace the `Ready`-stop drain on a live chasing monster to
   settle the two hypotheses in the handoff: (a) do acdream's `Ready` stop entries
   carry `outTicks > 0` (so they wait for `AnimationDone` instead of the per-frame
   0-tick `CheckForCompletedMotions`) while retail's are 0-tick? (b) does retail fire
   `CheckForCompletedMotions`/`MotionDone` more aggressively than acdream's
   once-per-frame `Manager.UseTime`? Reuse `scratchpad/cdb-drain.cdb` +
   the addrs in the handoff. Ask the user to make a monster chase their retail char
   during the trace.
3. The env-gated acdream probes are already in place (`ACDREAM_MVTO_DIAG=1`) —
   `[drainq]` dumps the queue contents (this is what named `Ready` as the lingering
   node). Capture a chase (aggro + RUN AWAY) to compare against retail.
4. Implement the faithful drain fix (verbatim-ported R2/R3 machinery — get it EXACTLY
   right, no redesign; this is the revert-prone area). Acceptance: acdream
   `add==done` (queue fully empties between swings) → `BeginMoveForward ≈ MoveToObject`
   per chase → creature runs to close distance, plants to swing. **Visual-gate with
   the user (retail side-by-side)** — that is the acceptance test.
5. When it lands + is visually confirmed: **STRIP all the temporary #170 probes**
   (`s_mvtoDiag` in MoveToManager.cs, `s_drainDiag` in MotionInterpreter.cs, the
   `[npc-tick]` lines + the `UM ↳ actions` dump in GameWindow.cs), move #170 to
   Recently-closed in `docs/ISSUES.md` with the SHAs, and update the animation
   research/memory index.

**Gotchas:** both acdream (+Acdream char) and retail hit the same local ACE
(127.0.0.1:9000); trace the CHASE (player fleeing), not attack-in-place — no chase ⇒
no `[mvto]` lines; PowerShell Tee logs are UTF-16 (`tr -d '\000'` before grep); user
manages client lifecycle (graceful close). Trust the live cdb over the earlier
workflow synthesis (its "run from mt-6" map was refuted for attack-in-place).