From 3c866f95f7d7d1c0d8c64402176792e9635d3cf2 Mon Sep 17 00:00:00 2001 From: Erik Date: Fri, 3 Jul 2026 16:25:07 +0200 Subject: [PATCH] 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) --- docs/ISSUES.md | 34 +++++++++++++++++++++++++--------- 1 file changed, 25 insertions(+), 9 deletions(-) diff --git a/docs/ISSUES.md b/docs/ISSUES.md index 662060bf..b2f36d37 100644 --- a/docs/ISSUES.md +++ b/docs/ISSUES.md @@ -73,15 +73,31 @@ actually steps at (Player_Move.cs / Creature GetRunRate usage). ## #161 — Remote jump landing holds the falling pose (no landing anim) -**Status:** OPEN (2026-07-03, R4-V5 live verify) -**Symptom:** observing a retail player jump from acdream: the arc plays, -but on touchdown the character stays in the falling pose instead of the -landing/idle transition. Landing path: the remote resolver landing block -(GameWindow `rm.Motion.HitGround()` + K-fix17 SetCycle) — instrument -whether HitGround's re-apply dispatches, whether the landing SetCycle -fires, and whether the InWorld link fix (350fb5e3) changed it (links were -being stripped on every remote dispatch until then — retest FIRST, this -may already be fixed by TS-40's landing-transition links surviving). +**Status:** OPEN (2026-07-03; retested after TS-40/`41006e79` — still +broken; user: stuck in falling until the char moves or the window loses +focus). +**Evidence (launch.log, session bklydthrr, guid 0x50000001):** `VU.land` +fires; Falling completions (0x40000015) flow; but the FIRST post-landing +UM still reports `seq now motion=0x40000015` — the landing block's reset +(rm.Motion.HitGround() apply + K-fix17 SetCycle) did NOT move the cycle +off Falling. Recovery happened only via SUBSEQUENT wire UMs (the mover +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)