# 2026-08-04 — Bug A / H3 diagnosis: why a remote's detected landing edge does not advance its animation

**Status:** REPORT-ONLY. No source or test edits. Companion to
`docs/research/2026-08-04-remote-landing-investigation.md` (hypotheses + decision
table) and `docs/ISSUES.md` #32.

**Capture that drives this report:** `launch-4b2.log:809-827`, six
`[remote-landing]` lines for guid `0x5000000F` between `t=85680843` and
`t=85748328` (67.5 s), all identical:
`airborneBefore=True gravitySet=True contact=True onWalkable=True
hasDefaultSink=True resolveIsOnGround=True seqStyle=0x8000003D
seqMotion=0x40000015`. Four `site=per-tick`, two `site=controller`.
`ACDREAM_DUMP_MOTION` was NOT enabled for this run, so there are no
`VU`/`VU.land`/`UM`/`SetCycle` lines to correlate against.

---

## Headline

**Retail leaves the Falling cycle on landing as a purely LOCAL consequence of
the observer's own physics.** The driver is the false→true edge of the
`ON_WALKABLE_TS` bit inside `CPhysicsObj::set_on_walkable`
(`named symbol @0x00511310`, pseudo-C :279287), which is reached
unconditionally from `CPhysicsObj::SetPositionInternal`
(`@0x00515330`, :283399) on every completed transition, for every object —
there is no `IsThePlayer` / `IsCreature` / ownership gate anywhere on that path.

**acdream has a verbatim port of that edge**
(`src/AcDream.Core/Physics/PhysicsObjUpdate.cs:137-142`) and wires it for the
local player, for ordinary bodies, for placements, for spawn settle, and even
for *hidden* remotes. **The one path that does not use it is the visible
remote per-tick tick** — `src/AcDream.Runtime/Physics/RuntimeRemotePhysicsUpdater.cs:471`
calls `HandleAllCollisions` alone, skipping the whole `SetPositionInternal`
contact/on_walkable prefix that owns the HitGround/LeaveGround edge, and
substitutes a hand-rolled, **wire-latched** landing heuristic at
`:493-580`.

That substitution is the defect. Its two measurable consequences are named in
§2 and §5. This is the same site and the same root as Bug B (ISSUES #32's
2026-08-04 addendum): the remote's `OnWalkable` bit is *asserted*, never
*derived*.

---

## 1. Where a remote's animation sequence is advanced — every writer

`seqMotion` is `AnimationSequencer.CurrentMotion`, a read-only mirror of
`MotionState.Substate` (`src/AcDream.Core/Physics/AnimationSequencer.cs:126`;
style at `:117`). `MotionState.Substate` is written in exactly two places:
`src/AcDream.Core/Physics/Motion/CMotionTable.cs:323` (Branch 1, style change)
and `:414` (Branch 2, cycle change), both inside `GetObjectSequence`
(`:255-516`), plus the baseline install at `:622` (`SetDefaultState`).

Every route into `GetObjectSequence` for a live entity:

| # | Entry point | Reachable for a PLAYER remote? |
|---|---|---|
| W1 | `MotionTableDispatchSink.ApplyMotion/StopMotion/StopCompletely` (`src/AcDream.Core/Physics/Motion/MotionTableDispatchSink.cs:34-57`) → `AnimationSequencer.PerformMovement` (`:473-477`) → `MotionTableManager.PerformMovement` (`src/AcDream.Core/Physics/Motion/MotionTableManager.cs:409-444`) | **Yes — the only live route.** |
| W2 | `AnimationSequencer.SetCycle` (`:353-413`) from `RemoteServerControlledVelocityCycle.cs:78` | **No** — gated `!IsPlayerGuid(serverGuid)` at `src/AcDream.Runtime/Physics/RuntimeRemotePhysicsUpdater.cs:181`. NPC/monster only. |
| W3 | `AnimationSequencer.SetCycle` from `src/AcDream.App/Rendering/SpawnMotionInitializer.cs:34,60` | Spawn only. |
| W4 | `AnimationSequencer.SetCycle`/`PlayAction` from `src/AcDream.Core/Physics/AnimationCommandRouter.cs:78,81` | Command/emote routing, not locomotion. |
| W5 | `MotionTableManager.InitializeState` (`:353-362`) / `Reset` (`AnimationSequencer.cs:598-609`) | Lifecycle only. |

Note: the `SetCycle` block advertised at
`src/AcDream.App/Physics/LiveEntityNetworkUpdateController.cs:413-463` is
**dead for the cycle** — `fullMotion` computed there is immediately overwritten
by the funnel dispatcher's result at `:602` and used only for the
locomotion-timestamp bookkeeping at `:630-638`. The comment block is stale; do
not read it as a second cycle writer.

**So for a player remote there is exactly ONE writer, W1, and exactly two
things drive it:**

- **(a) the inbound wire funnel** — `RemoteInboundMotionDispatcher.Apply`
  (`src/AcDream.App/Physics/RemoteInboundMotionDispatcher.cs:112`) →
  `MotionInterpreter.MoveToInterpretedState`
  (`src/AcDream.Core/Physics/MotionInterpreter.cs:2741-2788`) →
  `ApplyInterpretedMovement` (`:2764`).
- **(b) the local ground edges** — `MotionInterpreter.LeaveGround` (`:2374-2395`)
  and `HitGround` (`:2426-2444`), each ending in
  `apply_current_movement` (`:1460-1473`) →
  `ApplyCurrentMovementInterpreted` (`:1547-1563`) →
  the **same** `ApplyInterpretedMovement` (`:2842-2903`) through the **same**
  `DefaultSink`.

**Answer to "can anything other than an inbound `UpdateMotion` move a remote
out of Falling?" — Yes, exactly one thing: `HitGround` (b).** There is no
timer, no per-frame recompute, and no NPC-style velocity-cycle fallback for a
player remote. If (b) is a no-op, the wire is the only escape — which is
precisely the reported symptom.

---

## 2. Where the landing edge is detected, and what each site does with it

Two sites, both real, neither of which silently drops the edge:

**Site A — `site=per-tick`**, `src/AcDream.Runtime/Physics/RuntimeRemotePhysicsUpdater.cs:493-580`
```
:493  if (rm.Airborne && resolveResult.IsOnGround && rm.Body.Velocity.Z <= 0f)
:497      rm.Airborne = false;
:502      rm.Interp.Clear();
:503-504  rm.Body.TransientState |= Contact | OnWalkable;     // ASSERTED, not derived
:505-506  rm.Body.Velocity = (X, Y, 0)
:538-557  [remote-landing] probe
:559      rm.Movement.HitGround();
:574-576  rm.Body.State &= ~Gravity;
```

**Site B — `site=controller`**, `src/AcDream.App/Physics/LiveEntityNetworkUpdateController.cs:2019-2117`
```
:2019 if (rmState.Airborne)
:2021     rmState.Airborne = false;
:2023-24  rmState.Body.TransientState |= Contact | OnWalkable;   // ASSERTED, not derived
:2065-69  EnsureRemoteMotionBindings (creates the sink if missing)
:2077-96  [remote-landing] probe
:2100     rmState.Movement.HitGround();
:2114-15  rmState.Body.State &= ~Gravity;
```

Both reach `MovementManager.HitGround`
(`src/AcDream.Core/Physics/Motion/MovementManager.cs:153-156`) →
`MotionInterpreter.HitGround`. **The edge is not dropped at either site.** Under
the captured probe values every gate in `HitGround` passes:
`PhysicsObj` non-null (`MotionInterpreter.cs:2428`), `IsCreature` true
(`RemoteWeenie` inherits the `IWeenieObject.IsCreature() => true` default at
`MotionInterpreter.cs:462`), Gravity set (`:2435`, probe `gravitySet=True`),
`Initted` true by default (`:747`). `apply_current_movement`'s dual dispatch
(`:1465-1470`) routes a remote to the INTERPRETED branch because
`RemoteWeenie.IsThePlayer()` is the `false` default (`:475`), and
`ApplyCurrentMovementInterpreted` takes the sink branch (`:1558-1563`) because
`DefaultSink` is bound (probe `hasDefaultSink=True`).

**The real defect is not that the edge is dropped — it is that the edge is
INVENTED.** `rm.Airborne` is an acdream latch, not retail state. It is set at
exactly one place:

```
src/AcDream.App/Physics/LiveEntityNetworkUpdateController.cs:1265-1273
    if (update.Velocity.Z > 0.5f) {            // 0xF74E VectorUpdate only
        rm.Airborne = true;
        rm.Body.TransientState &= ~(Contact | OnWalkable);
        rm.Body.State |= PhysicsStateFlags.Gravity;
        ...
:1290   rm.Motion.LeaveGround();
    }
```
(the other setter, `RemoteTeleportController.cs:399`, is the teleport path).

So for a visible remote, **both** ground edges and **both** the Gravity bit and
the contact bits are driven by one wire packet with a `0.5 m/s` magic
threshold, rather than by the resolved contact plane. Retail's contact bits are
derived from `contact_plane.N.z >= floor_z` on every transition
(`@0x00515330`, :283501-283509) and `GRAVITY_PS (0x400)` is a persistent object
property, never a per-jump latch.

Two direct consequences, both citable:

- **C1 — the edge cannot fire at all for an airborne episode that does not
  begin with a `+Z > 0.5` VectorUpdate** (walk off a ledge, step off a porch,
  a dropped/reordered `0xF74E`). In that case `LeaveGround` also never runs, so
  Falling would instead have to be engaged by the wire funnel's own airborne
  substitution (`MotionInterpreter.cs:2864-2868`) — which requires Gravity set,
  which also never happened. The remote then falls with its grounded cycle
  playing.
- **C2 — Gravity is cleared immediately after the first landing edge**
  (`RuntimeRemotePhysicsUpdater.cs:574-576`,
  `LiveEntityNetworkUpdateController.cs:2114-2115`), whereas the local player's
  body is constructed with Gravity (`src/AcDream.Runtime/Gameplay/PlayerMovementController.cs:689`)
  and never clears it. With Gravity clear, `contact_allows_move` returns `true`
  early (`MotionInterpreter.cs:2142-2143`) and `HitGround` no-ops outright
  (`:2435`) — so a *second* airborne episode before the next VectorUpdate has no
  animation response at all in either direction.

Neither C1 nor C2 explains the six captured edges (all had `gravitySet=True`),
but both are the same root cause and both must be fixed by the same change.

---

## 3. What retail does — LOCAL, unconditional, contact-driven

Sourced from `docs/research/named-retail/acclient_2013_pseudo_c.txt`.

**3.1 `CPhysicsObj::set_on_walkable` — `@0x00511310`, :279287** is the driver:
```
00511336  if ((transient_state & 2) == 0)          // OLD value not walkable
00511358      if (arg2 != 0)                       //   -> false->true EDGE
0051135a          movement_manager_1 = this->movement_manager;
00511364          MovementManager::HitGround(movement_manager_1);
00511336  else if (arg2 == 0)                      // true->false edge
00511346      MovementManager::LeaveGround(movement_manager);
```
The only condition is `movement_manager != 0`. **No ownership, creature, or
player gate.** (`ON_WALKABLE_TS = 0x2`, `docs/research/named-retail/acclient.h:3691`.)

**3.2 `CPhysicsObj::SetPositionInternal` — `@0x00515330`, :283399** calls it,
unconditionally, from the resolved contact plane:
```
00515430  if (collision_info.contact_plane_valid == 0) ts &= ~1; else ts |= 1;   // CONTACT_TS
00515465  if ((ts & 1) == 0) { ts &= ~2; MovementManager::LeaveGround(...); }
0051548e  else if (contact_plane.N.z < PhysicsGlobals::floor_z) set_on_walkable(this, 0);  // :283507
00515482  else                                                  set_on_walkable(this, 1);  // :283509
005154fe  CPhysicsObj::handle_all_collisions(this, &collision_info, ts&1, ts&2);
```
`handle_all_collisions` (`@0x00514780`, :282647) does **not** touch
`on_walkable` — it only does the elasticity reflect and the
`frames_stationary_fall` bookkeeping. **The contact/walkable recompute lives
exclusively in `SetPositionInternal`, and it runs BEFORE
`handle_all_collisions`.**

Wire-driven placements reach the same code:
`CPhysicsObj::SetPositionInternal(Position*, SetPositionStruct*, CTransition*)`
(`@0x00515bd0`, :283892) calls the transition form at `@0x00515c94` (:283942).

**3.3 Retail runs full physics for objects it does not own.**
`CPhysics::UseTime` (`@0x00509950`, :271586) iterates the whole object hash and
calls `CPhysicsObj::update_object` on every entry (:271643); the only
player-specific line is an extra
`SmartBox::PlayerPhysicsUpdatedCallback` notification, not a skip.
`update_object` (`@0x00515d10`, :283950) early-outs only on
`parent != 0 || cell == 0 || (state & 0x1000000)` — nothing about ownership.
`UpdateObjectInternal` (`@0x005156b0`, :283611) →
`UpdatePositionInternal` (`@0x00512c30`, :280817) →
`CPhysicsObj::transition` (`@0x005158b2`) → `SetPositionInternal` (`@0x00515914`).
**So on a retail observer, a remote player's landing animation exit is a local
physics consequence, not a wire event.**

**3.4 The re-apply.** `MovementManager::HitGround` (`@0x00524300`, :300425) →
`CMotionInterp::HitGround` (`@0x00528ac0`, :305996 — creature gate,
`state & 0x400` gravity gate, `RemoveLinkAnimations`,
`apply_current_movement(0,0)`) → `apply_current_movement` (`@0x00528870`,
:305838; its `IsThePlayer` test is a *source selector* — raw vs interpreted —
not a skip) → `apply_interpreted_movement` (`@0x00528600`, :305713):
```
0052866c  if (contact_allows_move(this, interpreted_state.forward_command) == 0)
005286ee      DoInterpretedMotion(this, 0x40000015, &var_2c);      // :305729  FALLING
0052866c  else
00528687      DoInterpretedMotion(this, interpreted_state.forward_command, ...);  // :305744
```
`contact_allows_move` (`@0x00528240`, :305471) returns 1 iff
`CONTACT_TS && ON_WALKABLE_TS` (given a gravity-bound creature). **`0x40000015`
is dispatched from exactly one site in the entire 1.4 M-line binary** — that
one line. Entry to and exit from Falling are both decided by the contact bits.

**3.5 There is no other landing path.** `symbols.json` contains no
`land`/`land_on_ground` animation function (only `CSphere::land_on_sphere`
`@0x005379A0` and `CCylSphere::land_on_cylinder` `@0x0053B3D0`, both collision
geometry). The complete caller set of `apply_current_movement` is `HitGround`
(`@0x00528af7`), `LeaveGround` (`@0x00528b66`), `set_hold_run` (`@0x00528b9e`),
`SetHoldKey` (`@0x00528bd4`/`@0x00528bef`), `ReportExhaustion` (`@0x005288ed`),
`SetWeenieObject` (`@0x00528955`), and `@0x00528a08`. Landing is `HitGround`
and nothing else.

**3.6 The retail default that matters:** `InterpretedMotionState::InterpretedMotionState`
(`@0x0051e8d0`, :293418) sets `forward_command = 0x41000003` (Ready). A remote
that never received an mt-0 `UpdateMotion` still re-applies **Ready** on
landing, never Falling. acdream matches this
(`src/AcDream.Core/Physics/MotionInterpreter.cs:215-224`).

---

## 4. Does the local player differ? Yes — and that is the shape of the fix

**The local player implements retail's contact-derived edge inline.**
`src/AcDream.Runtime/Gameplay/PlayerMovementController.cs:2607-2645`:
```
:2608  if (resolveResult.Ok && candidateMoved) {
:2610-13   Contact  <- resolveResult.InContact
:2616      if (resolveResult.InContact && resolveResult.OnWalkable) {
:2618          bool wasAirborne = !_body.OnWalkable;      // read BEFORE the write
:2619          _body.TransientState |= OnWalkable;
:2620-27       if (wasAirborne) { Movement.HitGround(); landedThisQuantum = true; }
:2630-33      } else { _body.TransientState &= ~OnWalkable; }
:2641-44   PhysicsObjUpdate.HandleAllCollisions(...);      // AFTER the edge, as retail
:2650-51  if (!_body.OnWalkable && !_wasAirborneLastFrame) _motion.LeaveGround();
```
That is `set_on_walkable`'s edge, derived from the resolved contact plane,
with `handle_all_collisions` in retail's order.

**Four other acdream paths already use the extracted seam:**

| Path | Call |
|---|---|
| Local player, hidden/PositionManager | `PlayerMovementController.cs:2044-2053` → `CommitSetPositionTransition(..., Movement.HitGround, _motion.LeaveGround)` |
| Ordinary live bodies | `src/AcDream.Runtime/Physics/RuntimeOrdinaryPhysicsUpdater.cs:168` |
| Canonical placements (incl. remotes) | `src/AcDream.Runtime/Physics/RuntimeSetPositionState.cs:4912-4919` → `..., remote.HitGround, remote.LeaveGround, guard.IsCurrent` |
| **Hidden remotes** | `src/AcDream.Runtime/Physics/RuntimeRemotePhysicsUpdater.cs:778-796` → `CommitSetPositionTransition(..., rm.Movement.HitGround, rm.Motion.LeaveGround, ...)`, then `:796 rm.Airborne = !rm.Body.OnWalkable;` |
| Spawn settle | `src/AcDream.Core/Physics/SpawnPlacementSettler.cs:62` |

The seam is `src/AcDream.Core/Physics/PhysicsObjUpdate.cs:120-151`:
```
:131  bool finalOnWalkable = CommitSetPositionContactPrefix(body, inContact, onWalkable, previousOnWalkable);
:137      if (!previousOnWalkable && finalOnWalkable) hitGround?.Invoke();
:143      else if (previousOnWalkable && !finalOnWalkable) leaveGround?.Invoke();
```
with `finalOnWalkable = inContact && onWalkable` at `:169` and
`IsWalkableContact(inContact, n) => inContact && n.Z >= PhysicsGlobals.FloorZ`
at `:20-21` — a verbatim port of :283501-283509.

**The VISIBLE remote per-tick path is the only one that bypasses it.**
`RuntimeRemotePhysicsUpdater.cs:471-477` calls `PhysicsObjUpdate.HandleAllCollisions`
directly — the *tail* of `SetPositionInternal` without its *prefix* — so the
remote's `Contact`/`OnWalkable` bits are never derived from the resolve, the
false→true edge never exists, and `HitGround`/`LeaveGround` have no driver.
The `rm.Airborne` latch at `:493` is the stand-in.

**So yes: the same mechanism is simply not wired for visible remotes, and it
is already wired 300 lines below in the same file for hidden ones.** The fix is
small.

---

## 5. Proposed fix

### 5.1 The change (H3's file, per the investigation doc's three-file split)

The investigation doc says H1's fix is in the Gravity-clear sites, H2's is in
the sink-binding race, and **H3's is "the animation-scheduler consumption
path, not physics."** That framing needs one correction, which this trace
establishes: the consumption path is fine (see §5.3) — H3's actual file is
**`src/AcDream.Runtime/Physics/RuntimeRemotePhysicsUpdater.cs`**, the *producer*
of the animation command, not `LiveEntityAnimationScheduler`/`Presenter`.

**Target: `src/AcDream.Runtime/Physics/RuntimeRemotePhysicsUpdater.cs:471-580`.**

Replace the direct `HandleAllCollisions` call at `:471-477` **and** the entire
hand-rolled landing block at `:493-580` with the same call the hidden path
already makes at `:778-796`:

```csharp
// retail CPhysicsObj::SetPositionInternal @0x00515330 (:283501-283509) ->
// set_on_walkable @0x00511310 (:279287): contact/on_walkable derived from the
// contact plane, HitGround/LeaveGround on the false<->true edge, then
// handle_all_collisions @0x00514780. Same order, same seam as the hidden
// remote path below and the local player at PlayerMovementController:2607.
if (!PhysicsObjUpdate.CommitSetPositionTransition(
        rm.Body,
        resolveResult.InContact,
        resolveResult.OnWalkable,          // DERIVED, not asserted
        resolveResult.CollisionNormalValid,
        resolveResult.CollisionNormal,
        previousContact,
        previousOnWalkable,
        rm.Movement.HitGround,
        rm.Motion.LeaveGround,
        () => IsCurrentOwner(record, rm, objectClockEpoch, externalOwnerValid)))
{
    return false;
}
rm.Airborne = !rm.Body.OnWalkable;          // derived state, not a wire latch
```

Three supporting deletions/changes fall out of it, all required for the seam to
be the single owner:

1. **Delete the unconditional `TransientState |= Contact | OnWalkable`** at
   `:152-154` (the `!rm.Airborne` per-tick force) — it is what makes the edge
   structurally impossible. This is also Bug B's forced-`OnWalkable`
   (ISSUES #32 addendum), so the two bugs close together.
2. **Delete the twin landing block** at
   `src/AcDream.App/Physics/LiveEntityNetworkUpdateController.cs:2019-2117`'s
   `TransientState |= Contact | OnWalkable` + `HitGround` + Gravity-clear, and
   the `rm.Airborne = true` + contact-clear + Gravity-set at `:1265-1273`.
   `LeaveGround` at `:1290` goes with them — retail fires it from
   `set_on_walkable`, not from a `0xF74E` handler. The VectorUpdate keeps only
   what retail's `PhysicsDesc` write does: install the wire velocity.
3. **Make Gravity persistent on remote bodies**, matching
   `PlayerMovementController.cs:689`: construct `RemoteMotion.Body` with
   `PhysicsStateFlags.Gravity | PhysicsStateFlags.ReportCollisions`
   (`src/AcDream.Runtime/Physics/RemoteMotion.cs:278`) and delete both
   Gravity-clear sites (`RuntimeRemotePhysicsUpdater.cs:574-576`,
   `LiveEntityNetworkUpdateController.cs:2114-2115`). Retail's `GRAVITY_PS`
   (`0x400`) is an object property, and both `HitGround` (`:2435`) and
   `contact_allows_move` (`:2142`) read it as one. Without this, C2 (§2)
   survives the fix.

This is *not* a symptom-site guard: it deletes the invented mechanism and
installs the retail one that the rest of the codebase already uses.

### 5.2 Blast radius

- **Player remotes** — the intended target. Landing/leaving-ground animation
  becomes local and unconditional, as retail. Also removes the `0.5 m/s`
  magic threshold and the wire dependency for the whole ground-edge family.
- **NPCs / monsters** — same code path (`#184` Slice 2b unified them; there is
  no player/NPC fork in `Tick`). They gain a correct `LeaveGround` when they
  walk off a ledge, which they do not have today. Their separate
  stale-velocity cycle stop (`RuntimeRemotePhysicsUpdater.cs:181-192` →
  `RemoteServerControlledVelocityCycle.cs:78`) is untouched.
- **Local player** — untouched. It already does this inline
  (`PlayerMovementController.cs:2607-2645`).
- **Projectiles** — untouched. They use
  `ProjectilePhysicsStepper.cs:374` (`ApplySetPositionContact`) and are
  excluded from this branch by `projectileHandlesMovement`
  (`LiveEntityAnimationScheduler.cs:336`).
- **Hidden remotes / placements / spawn settle** — untouched; they already
  call the seam.
- **Bug B** — expected to change behavior at the same commit, because a steep
  roof stops being force-marked `OnWalkable`. §5.5 covers the coupling.
- **Register bookkeeping** — this retires the "forced Contact|OnWalkable on
  remote landing" deviation and the `rm.Airborne` wire-latch deviation, and it
  touches AD-25's call-site note at `RuntimeRemotePhysicsUpdater.cs:449-470`
  (the comment claims the direct `HandleAllCollisions` call matches "retail's
  own unconditional call site" — it does not, because retail's call site is
  *inside* `SetPositionInternal`, after `set_on_walkable`). Per CLAUDE.md the
  register rows must be updated in the same commit.

### 5.3 What this fix does NOT do — and why the scheduler is exonerated

The animation-scheduler consumption path was H3's literal wording. It is
clean:

- `LiveEntityAnimationScheduler.cs:323-326` advances the sequencer and captures
  the pose, **then** `:351-364` runs `_remotePhysics.Tick` (where `HitGround`
  fires). So a cycle change lands in the *next* quantum's pose — a one-frame
  lag, not a multi-second one.
- `LiveEntityMotionRuntimeController.cs:39-47` creates `rm.Sink` once over
  `ae.Sequencer` and binds it as `rm.Motion.DefaultSink` (`:46`). The **same**
  cached sink is handed to the inbound funnel at
  `LiveEntityNetworkUpdateController.cs:756,766`. A stale-sequencer theory is
  therefore refuted by observation: if the sink pointed at a dead sequencer,
  the wire path could not clear the pose either — and the user reports it does.
- `RemoveLinkAnimations` is bound to `sequencer.Manager.HandleEnterWorld`
  (`LiveEntityMotionRuntimeController.cs:63`), which is the correct `#174`
  binding.

### 5.4 Second, independent hazard found on the way — flag, do not fix blind

`MovementParameters.ModifyInterpretedState` defaults to **true**
(`src/AcDream.Core/Physics/Motion/MovementParameters.cs:140`), and
`MoveToInterpretedState`'s action-replay loop
(`MotionInterpreter.cs:2766-2784`) dispatches with ctor-default params
(`DispatchInterpretedMotion`, `:3222-3225`). `InterpretedMotionState.ApplyMotion`
(`:285-313`) writes `ForwardCommand = motion` for **any** id carrying
`0x40000000` (`:299-304`) — which includes `Falling` (`0x40000015`).
`InboundInterpretedMotionFactory.Create`
(`src/AcDream.App/Physics/InboundInterpretedMotionFactory.cs:46-63`) restores
the real class byte via `MotionCommandResolver.ReconstructFullCommand`, whose
catalog is built from the DatReaderWriter `MotionCommand` enum — so a wire
`Commands[]` entry of `0x0015` would resolve to `0x40000015`.

If that ever happens, `InterpretedState.ForwardCommand` becomes `Falling`, and
`HitGround`'s re-apply at `MotionInterpreter.cs:2878` re-dispatches Falling —
producing **exactly** "stuck in Falling until the next motion update
overwrites ForwardCommand." This mechanism would survive the §5.1 fix.

**NOT ESTABLISHED:** whether ACE ever puts a `0x4x`-class command in
`Commands[]` for a jumping/falling player. Retail's own outbound cannot
(its `ModifyInterpretedState=false` invariant keeps Falling out of
`interpreted_state`), but ACE is an emulator. **Settle it with one capture:**
`ACDREAM_DUMP_MOTION=1 ACDREAM_REMOTE_VEL_DIAG=1` across a remote jump, and
read the `[UM_RAW]`/`[FWD_WIRE]` lines
(`LiveEntityNetworkUpdateController.cs:373-386`, `:777-786`) for a
`ForwardCommand` or `Commands[]` entry of `0x0015` during the airborne window.

### 5.5 Sequencing note

Bug B's addendum (ISSUES #32) records that correcting `OnWalkable` alone may
not reproduce retail's roof slide, because it also depends on **#173**'s remote
collision-velocity reflect (shipped, gate unrun) and **AD-10**'s terrain-only
slope projection. That does not block this fix — the animation edge is
independent of the slide response — but expect the roof case to change
appearance at the same commit, and gate both together.

---

## 6. How to test

### 6.1 The measurement that is still missing

**The existing probe reads the wrong side of the call.** It captures state
immediately *before* `HitGround` (`RuntimeRemotePhysicsUpdater.cs:538-557`,
`LiveEntityNetworkUpdateController.cs:2077-2096`), and the investigation doc
already flagged for H3 that "the read happens immediately before HitGround
runs, so this alone doesn't distinguish success from H3." The six captured
lines therefore prove the gates pass and prove nothing about the outcome.

Before or alongside the fix, one line of instrumentation settles it: emit a
second `[remote-landing-after]` line immediately after `rm.Movement.HitGround()`
carrying `seqMotion`, `InterpretedState.ForwardCommand`, and the
`MotionTableManagerError` returned by the sink's `ApplyMotion`. Three outcomes,
three different conclusions:

| post-`seqMotion` | `ForwardCommand` | Conclusion |
|---|---|---|
| Ready (`0x41000003`) | Ready | The edge works; the residual is elsewhere (re-verify the user's observation) |
| Falling (`0x40000015`) | Falling | §5.4 — the wire clobbered `ForwardCommand` |
| Falling | Ready, sink returned `0x43` | `CMotionTable.IsAllowed` (`CMotionTable.cs:172-188`) refused the Ready cycle because its `MotionData.Bitfield & 2` is set — a DAT fact, not a source fact |

### 6.2 Automated

New tests in `tests/AcDream.Runtime.Tests/Physics/` (the layer under test):

1. **Edge from contact, not from the wire.** Drive `RuntimeRemotePhysicsUpdater.Tick`
   with a stubbed resolve returning `InContact=false, OnWalkable=false` then
   `InContact=true, OnWalkable=true`, with **no** VectorUpdate ever delivered.
   Assert `HitGround` fired exactly once on the transition and `LeaveGround`
   exactly once on the opposite one. This fails today (C1).
2. **Steep contact does not land.** Resolve returns `InContact=true` with a
   contact normal whose `Z < PhysicsGlobals.FloorZ`. Assert `OnWalkable` stays
   clear and `HitGround` did **not** fire. This is the Bug B assertion at the
   same site.
3. **Idempotence.** Two consecutive grounded quanta fire `HitGround` once, not
   twice.
4. **Gravity persistence.** After a landing, assert
   `rm.Body.State.HasFlag(PhysicsStateFlags.Gravity)` — then run a second
   airborne→grounded cycle and assert `HitGround` fires again. This fails today
   (C2).
5. **End-to-end cycle exit.** With a real `MotionTableDispatchSink` over a test
   `AnimationSequencer` seeded to `Substate = Falling` and
   `InterpretedState.ForwardCommand = Ready`, assert `CurrentMotion` leaves
   `0x40000015` after the grounded commit. This is the assertion that makes the
   §6.1 table unnecessary going forward.
6. **Regression guard on the existing contract:**
   `tests/AcDream.Core.Tests/Physics/MotionInterpreterFunnelTests.cs:201`
   (`HitGround_AfterFall_RedispatchesPreservedForward_ExitsFalling`) already
   covers the interp layer with a fake sink and must stay green.

### 6.3 What the user would see

Two-client route 4a, retail driving `+Acdream`'s neighbour:

- **Jump on flat ground** — the falling pose clears the instant the remote's
  feet touch, with no wire round-trip and no wait for the next `UpdateMotion`.
- **Walk off a low ledge / porch step** (no jump packet at all) — the remote
  now plays the falling cycle on the way down and exits it on landing. Today it
  keeps its grounded cycle the whole way, because `rm.Airborne` never latches.
- **Two jumps in quick succession** — the second one animates identically to
  the first (today the Gravity clear can mute it).
- **Jump onto a house roof (Bug B)** — the remote should now slide rather than
  plant, subject to the #173 / AD-10 coupling in §5.5. Gate this together with
  Campaign P matrix scenario 8.

---

## NOT ESTABLISHED

1. **Which of the two terminal failures actually fires at the captured edges.**
   The probe measures before the call. §6.1 names the exact one-line
   instrumentation and the three-way decision table. Everything upstream of the
   sink call is established: all gates pass, the sink is bound, and the dispatch
   target is `InterpretedState.ForwardCommand`.
2. **Whether ACE emits a `0x4x`-class motion command for a falling player**
   (§5.4). Settled by `ACDREAM_DUMP_MOTION=1` + `ACDREAM_REMOTE_VEL_DIAG=1`
   across a remote jump.
3. **Whether the humanoid MotionTable's `Ready` cycle carries
   `MotionData.Bitfield & 2`.** This is DAT content, not source. If set,
   `CMotionTable.IsAllowed` (`:172-188`, retail `is_allowed @0x005226c0`,
   :298526) refuses a Ready cycle requested while the substate is Falling,
   because Falling is not any style's default substate. Observation argues
   against it — the wire path uses the identical `GetObjectSequence` call and
   does clear the pose — but it is not proven. Settle by dumping
   `MotionData.Bitfield` for cycle key `(style << 16) | 0x000003`, or with
   `bp acclient!CMotionTable::is_allowed` reading `[edx+0x30]`.
4. **Whether ACE sets `GRAVITY_PS (0x400)` in the broadcast `PhysicsDesc` for
   remote creatures.** Relevant only to how faithfully §5.1's item 3 should be
   implemented (construct-with-Gravity vs adopt-from-wire). cdb:
   `bp acclient!CMotionInterp::contact_allows_move` dumping
   `physics_obj->state`.