From 5eb902ffe75ca447384f08a3358dbd0151d016b3 Mon Sep 17 00:00:00 2001 From: Erik Date: Sat, 4 Jul 2026 09:08:58 +0200 Subject: [PATCH] docs: #159 DONE; refine #170 sub-bug 1 (planner unwired, Mite Scamp in correct block) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Mark ISSUES #159 done (2de5a011) and record the key finding for #170: the CombatAnimationPlanner numbering fix is latent (the planner isn't wired into the live dispatch) and the Mite Scamp's 0x62-0x64 attacks were always in the correct block — so #170's visible symptom is sub-bug 2 (the pending_motions MOTIONDONE loop), not command misclassification. Roadmap L.1b note updated. Co-Authored-By: Claude Opus 4.8 --- docs/ISSUES.md | 15 +++++++++++---- docs/plans/2026-04-11-roadmap.md | 4 +++- 2 files changed, 14 insertions(+), 5 deletions(-) diff --git a/docs/ISSUES.md b/docs/ISSUES.md index 2cf86639..1b6a08d0 100644 --- a/docs/ISSUES.md +++ b/docs/ISSUES.md @@ -62,9 +62,16 @@ Because retail gets the identical ACE motion stream and renders it correctly, the divergence is CLIENT-side (acdream's UM/animation handling), **not** ACE. Three distinct sub-divergences: -1. **Wrong/uniform attack animations** → likely **#159** (CombatAnimationPlanner - uses 2013-decomp command numbering, not ACE/DRW; the attacks - `0x10000062/63/64` misclassify → wrong or same animation). +1. **Wrong/uniform attack animations** → **#159 is DONE (`2de5a011`) but was a + RED HERRING for this creature.** The Mite Scamp's attacks are wire + `0x62/0x63/0x64` = `AttackHigh1/Med1/Low1`, which live in the ALREADY-CORRECT + low block — they were never misnumbered, and `CombatAnimationPlanner` isn't + even wired into the runtime dispatch (the live path is `AnimationCommandRouter` + → `MotionInterpreter`/`AnimationSequencer`). #159 fixed a genuine latent bug in + the late block (Offhand*/Attack4-6/Punch*) but does not touch this symptom. + The "uniform/same animation" is therefore NOT a classification-numbering bug — + it is sub-bug 2 below (the same attack replays because `pending_motions` + completes+re-queues) and/or the sequencer not selecting per-command frames. 2. **Over-frequency / stuck attack** — motion trace: ACE streams attack UMs (`mt=0x00 cmd=0x62/0x63/0x64 spd=0.97`) on top of the `mt=0x06` chase; acdream's `pending_motions` completes+re-queues in a tight MOTIONDONE loop @@ -270,7 +277,7 @@ R5/R6 touches the action list. **Where:** ## #159 — CombatAnimationPlanner uses 2013-decomp command numbering, not ACE/DRW -**Status:** OPEN +**Status:** DONE (`2de5a011`, 2026-07-04) — the whole `CombatAnimationMotionCommands` block now derives each constant directly from `DatReaderWriter.Enums.MotionCommand` by name (`= (uint)Drw.Name`), so the values ARE the oracle by construction and can never drift again. Ground truth was taken by reflecting over the same DatReaderWriter 2.1.7 assembly the runtime binds (409 enum values). Blocks 1-2 (stances + single melee, 0x3C-0x12A) were already correct; the late block (Offhand*/Attack4-6/Punch*, 0x173-0x19A) was all +3 shifted; `Reload` was the dead 2013 value `0x100000D4` (absent from DRW) → now the real `0x40000016` SubState. New parity test `PlanFromWireCommand_LateCombatBlock_UsesAceDrwNumbering` pins 14 ACE wire values through the full wire→resolve→classify pipeline. **Caveat (relevant to #170):** `CombatAnimationPlanner` is not yet wired into the runtime — the live dispatch is `AnimationCommandRouter` → `MotionInterpreter`/`AnimationSequencer` — so this is a *latent* correctness fix. It does NOT by itself change the #170 Mite Scamp symptom, whose attacks `0x62/0x63/0x64` live in the already-correct low block. #170 sub-bugs 2 (MOTIONDONE loop) + 3 (glide) remain. **Severity:** MEDIUM (late-combat animation classification wrong against ACE) **Filed:** 2026-06-30 **Component:** animation, combat diff --git a/docs/plans/2026-04-11-roadmap.md b/docs/plans/2026-04-11-roadmap.md index ab6c3398..0109b6c6 100644 --- a/docs/plans/2026-04-11-roadmap.md +++ b/docs/plans/2026-04-11-roadmap.md @@ -616,7 +616,9 @@ change must keep both phase plans in sync. `AceModernCommandCatalog` runtime default + full-extraction `Retail2013CommandCatalog` conformance; deleted the blind 0x016E–0x0197 override; exposed + filed the `CombatAnimationPlanner` 2013-numbering bug - as ISSUES #159. Spec: `docs/superpowers/specs/2026-06-30-movement-wire-parity-design.md`.)* + as ISSUES #159 — **fixed 2026-07-04 `2de5a011`**, the constants now derive + directly from `DatReaderWriter.Enums.MotionCommand` by name. + Spec: `docs/superpowers/specs/2026-06-30-movement-wire-parity-design.md`.)* *(D6.2a, shipped 2026-07-01:* ported `CMotionInterp::adjust_motion` / `apply_run_to_command` / `apply_raw_movement` into `MotionInterpreter` and unified the local velocity + keyboard turn + jump onto one input-built