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

revert: AnimationSequencer locomotion-cycle full-reset and link-skip

Browse source 
Both changes were too aggressive:

1. Full queue reset on locomotion-locomotion transitions (c06b6c5)
   — turned out the user's tests went through Ready (no direct
   walk↔run transitions in the wire), so the fix never fired
   and didn't address the actual bug.

2. Unconditional skip of every transition link
   — killed ALL transition animations across the board (jump
   landing, run-to-stop, sit-down, lie-down, etc.) for every
   entity, not just the locomotion-locomotion case. User
   correctly identified this as a much bigger regression.

Sequencer is back to pre-c06b6c5 baseline: ClearCyclicTail-only
on motion change, transition link enqueued normally. The
walk↔run-direct-transition issue (and the broader
remote-only-doesn't-update issue) remains open and requires a
different approach.

Confirmed regression isolation: local +Acdream's transitions in
acdream client work (visible legs switch correctly), and acdream
chars observed from a parallel retail client also have working
transitions. The bug is specifically when acdream observes a
RETAIL-driven character — somewhere in the inbound
UpdateMotion → animCycle picker → SetCycle path, the visible
cycle update is being lost. Filed for separate investigation.

Adds an env-var-gated HASCYCLE diagnostic in OnLiveMotionUpdated
that confirmed cycle resolution succeeds (HasCycle=True for both
RunForward 0x44000007 and WalkForward 0x45000005 on style
0x8000003D), so the bug isn't in MotionTable cycle lookup.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-05-03 17:35:55 +02:00
parent c06b6c51e1
commit a2ae2aefcc
2 changed files with 9 additions and 23 deletions
Download patch file Download diff file Expand all files Collapse all files

24
src/AcDream.Core/Physics/AnimationSequencer.cs
View file

@ -434,29 +434,7 @@ public sealed class AnimationSequencer
// cycle. Without this, the old RunForward → ??? link would
// continue draining for ~100 ms before the new Falling cycle
// starts, defeating the "skip the link" intent.
//
// 2026-05-03: ALSO do a full drain when transitioning between
// FORWARD-LOCOMOTION cycles (Walk↔Run, Walk↔WalkBackward, etc.)
// — i.e. when both old and new motion's low byte is in the
// {0x05 WalkForward, 0x06 WalkBackward, 0x07 RunForward} set.
// ClearCyclicTail alone leaves _currNode in the previous cycle's
// non-cyclic head (link frames from a Ready→walk transition),
// and the visible legs continue playing those head frames before
// reaching the new run cycle. The user-reported symptom: walk→run
// direct transition (release shift while W held) did not visibly
// switch the leg cycle — body advanced at walk pace until the
// next motion event (turn / stop) re-fired SetCycle and finally
// aligned the queue. Live cdb trace of retail acclient.exe
// 2026-05-03 (tools/cdb-scripts/walk_run_motion_trace.log) shows
// retail uses an additive add_to_queue with no truncate — the
// MotionTableManager's per-tick CheckForCompletedMotions handles
// the natural progression. We don't have that machinery, so we
// emulate via a hard reset on the locomotion-cycle transition.
uint oldLow = CurrentMotion & 0xFFu;
uint newLow = motion & 0xFFu;
bool oldIsForwardLoc = oldLow == 0x05u || oldLow == 0x06u || oldLow == 0x07u;
bool newIsForwardLoc = newLow == 0x05u || newLow == 0x06u || newLow == 0x07u;
if (skipTransitionLink || (oldIsForwardLoc && newIsForwardLoc))
if (skipTransitionLink)
{
_queue.Clear();
_currNode = null;