erik/acdream
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1

docs: #159 DONE; refine #170 sub-bug 1 (planner unwired, Mite Scamp in correct block)

Browse source 
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 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-07-04 09:08:58 +02:00
parent 2de5a011b4
commit 5eb902ffe7
2 changed files with 14 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

15
docs/ISSUES.md
View file

@ -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

4
docs/plans/2026-04-11-roadmap.md
View file

@ -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