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

docs: #161 landing-pose evidence trail from the live retest (seq still Falling at first post-landing UM; suspect the funnel's Falling dispatch writing interpreted fwd + HitGround re-apply)

Browse source
This commit is contained in:
Erik 2026-07-03 16:25:07 +02:00
parent 6870857cc2
commit 3c866f95f7
1 changed files with 25 additions and 9 deletions
Download patch file Download diff file Expand all files Collapse all files

34
docs/ISSUES.md
View file

@ -73,15 +73,31 @@ actually steps at (Player_Move.cs / Creature GetRunRate usage).
## #161 — Remote jump landing holds the falling pose (no landing anim) ## #161 — Remote jump landing holds the falling pose (no landing anim)
**Status:** OPEN (2026-07-03, R4-V5 live verify) **Status:** OPEN (2026-07-03; retested after TS-40/`41006e79` — still
**Symptom:** observing a retail player jump from acdream: the arc plays, broken; user: stuck in falling until the char moves or the window loses
but on touchdown the character stays in the falling pose instead of the focus).
landing/idle transition. Landing path: the remote resolver landing block **Evidence (launch.log, session bklydthrr, guid 0x50000001):** `VU.land`
(GameWindow `rm.Motion.HitGround()` + K-fix17 SetCycle) — instrument fires; Falling completions (0x40000015) flow; but the FIRST post-landing
whether HitGround's re-apply dispatches, whether the landing SetCycle UM still reports `seq now motion=0x40000015` — the landing block's reset
fires, and whether the InWorld link fix (350fb5e3) changed it (links were (rm.Motion.HitGround() apply + K-fix17 SetCycle) did NOT move the cycle
being stripped on every remote dispatch until then — retest FIRST, this off Falling. Recovery happened only via SUBSEQUENT wire UMs (the mover
may already be fixed by TS-40's landing-transition links surviving). pressed keys); a stand-still landing gets none → stuck forever. The
focus-change unstick hints a frame-advance/big-dt interaction as well.
**Prime suspect:** the funnel's airborne branch dispatches Falling via
DoInterpretedMotion with ctor-default ModifyInterpretedState=true →
InterpretedState.ForwardCommand becomes 0x40000015; HitGround's
apply_current_movement (interpreted branch for remotes) then re-applies
the interpreted state — i.e. re-dispatches FALLING — instead of the
pre-fall wire command. Check retail: does apply_interpreted_movement's
falling dispatch (raw ~305730, fresh local var_2c params) really write
interpreted fwd (bit 0x4000 in the local's 0x1EE0F default) — and if so,
what exits Falling on a retail REMOTE landing (HitGround raw @305949
apply_current_movement(this, 1, ...) — the arg2=1 semantics)? Also
verify K-fix17's SetCycle actually executes there (add a probe) and
whether it lost a fight with the same-frame HitGround apply ordering.
**Where:** GameWindow remote landing block (`VU.land` region);
MotionInterpreter.ApplyInterpretedMovement falling branch;
HitGround/apply_current_movement.
## #162 — Observer-side moveto cancelled by ACE's autonomous MTS reflections (the "glide" class) ## #162 — Observer-side moveto cancelled by ACE's autonomous MTS reflections (the "glide" class)