acdream/docs/research/2026-08-04-bug-b-remote-slide-diagnosis.md

# 2026-08-04 — Bug B (remote ledge/roof slide) diagnosis

**Status:** REPORT-ONLY. No source or test edits made. HEAD `7f1c1f5a`.
**Companion:** `docs/research/2026-08-04-remote-landing-investigation.md` (Bug A),
`docs/ISSUES.md` #32 (2026-08-04 addendum), divergence register rows **AP-87**,
**AP-81**, **AD-10**.

**Relationship to the prior same-day investigation.** ISSUES.md #32 already
carries a 2026-08-04 root-cause addendum naming the landing block's
unconditional `Contact | OnWalkable`. That addendum is **correct but
incomplete**: it names one of *four* independent links in the chain, and the
one it names is not the dominant one. Fixing only the landing block cannot
produce a slide. §1 below establishes the full chain; §6 states what that means
for the fix. Everything here is re-verified against source and against the
pseudo-C directly — nothing is carried over on trust.

---

## 1. Does acdream locally simulate remote bodies, and would it slide one off a steep roof?

**It simulates them, and it cannot slide them. Four independent links each
block the slide on their own.**

The per-tick remote owner is
`src/AcDream.Runtime/Physics/RuntimeRemotePhysicsUpdater.cs`, `Tick(...)`
(`:61-650`). It runs once per eligible remote per retail object quantum and
*does* call `PhysicsEngine.ResolveWithTransition` (`:370-418`) — the same sweep
the local player uses. So the naive framing ("acdream only applies wire
positions") is **wrong**: there is a real per-tick sweep. The problem is that
everything fed into that sweep has been pre-flattened.

### Link 1 — the grounded branch force-sets `Contact | OnWalkable` every tick, unconditionally

`RuntimeRemotePhysicsUpdater.cs:150-154`:

```csharp
if (!rm.Airborne)
{
    rm.Body.TransientState |= TransientStateFlags.Contact
                            | TransientStateFlags.OnWalkable
                            | TransientStateFlags.Active;
```

The gate is `rm.Airborne` — an acdream client-side bool — **not** the contact
plane and not the wire bit. This is the dominant site: it runs *before every
sweep, on every tick*, so it re-asserts the walkable lie even if some other
site cleared it. The landing block that ISSUES.md #32 names
(`LiveEntityNetworkUpdateController.cs:2023-2024`) and its per-tick twin
(`RuntimeRemotePhysicsUpdater.cs:503-504`) fire once each per landing; this one
fires ~30 times a second forever.

### Link 2 — a grounded remote's velocity is zeroed every tick

`RuntimeRemotePhysicsUpdater.cs:169`:

```csharp
rm.Body.Velocity = System.Numerics.Vector3.Zero;
```

There is nothing left to slide *with*. This also silently discards any
authoritative velocity ACE delivered: `OnVector` (0xF74E) writes
`update.Velocity` into the body via `TryCommitAuthoritativeVector`
(`LiveEntityNetworkUpdateController.cs:1250-1258`), but a downhill slide has
`Velocity.Z < 0`, so the `update.Velocity.Z > 0.5f` test at `:1265` leaves
`rm.Airborne == false`, and the next tick's `:169` erases the vector.

### Link 3 — the Gravity state bit is cleared at landing and never restored

`RuntimeRemotePhysicsUpdater.cs:571-576` and
`LiveEntityNetworkUpdateController.cs:2110-2116` both do
`rm.Body.State &= ~PhysicsStateFlags.Gravity` after `HitGround()`.
`PhysicsBody.calc_acceleration()` (`PhysicsBody.cs:503-518`) returns
`Acceleration = Vector3.Zero` when the Gravity bit is clear. The bit is only
ever *set* by the jump VectorUpdate (`:1273`) and once at body construction
(`RuntimeRemoteBodyDescription.cs:221` / `RuntimePhysicsState.InitializeNewPhysicsBody`,
`RuntimePhysicsState.cs:2617`), and that initializer runs **once per
incarnation** ("Later SetState never replays them",
`RuntimePhysicsState.cs:2608-2612`). So after the first landing the remote has
no gravity for the rest of its life.

Retail does the opposite: GRAVITY_PS is a persistent object property and
gravity *acceleration* is gated on the CONTACT/ON_WALKABLE transients inside
`calc_acceleration`, not on the state bit being toggled. This is already filed
as register row **AP-81** — but AP-81's file:line column lists only the
VectorUpdate handler and the landing blocks, not `:150-154` (Link 1).

### Link 4 — the visible remote tick never commits the sweep's own contact classification

The engine *does* compute the retail answer. `PhysicsEngine.cs:2653-2676`:

```csharp
bool inContact  = ci.ContactPlaneValid;
bool onWalkable = PhysicsObjUpdate.IsWalkableContact(inContact, ci.ContactPlane.Normal);
bool onGround   = inContact || (transition.ObjectInfo.State & ObjectInfoState.OnWalkable) != 0;
```

and `IsWalkableContact` (`PhysicsObjUpdate.cs:20-21`) is
`inContact && contactNormal.Z >= PhysicsGlobals.FloorZ` — retail-shaped. Both
`InContact` and `OnWalkable` are carried out on `ResolveResult`
(`ResolveResult.cs:46-53`).

`Tick` reads **only** `resolveResult.Position`, `.CellId`, `.IsOnGround`,
`.CollisionNormalValid`, `.CollisionNormal` (`:420-477`). It never reads
`.InContact` or `.OnWalkable`, and — unlike `TickHidden`, which calls
`PhysicsObjUpdate.CommitSetPositionTransition` at `:778-795` — it never commits
them to the body. `PhysicsEngine` itself writes `ContactPlane*`,
`WaterContact`, `Sliding`, and the Stationary bits back onto the body, but
**not** `Contact`/`OnWalkable` (grep of `PhysicsEngine.cs` for
`body.TransientState`: `:2488-2540` only).

Worse, `IsOnGround` is `inContact || …` — so a **steep-roof contact reports
`IsOnGround == true`**. That is the value the airborne→grounded landing
detection at `:493-495` tests. The remote therefore "lands" on a surface retail
would classify as contact-but-not-walkable, and the landing block then forces
`OnWalkable` and clears Gravity.

**Conclusion for §1:** a remote resting on a steep roof is held there by
acdream's own physics, not merely parked at a wire position. The sweep runs
every tick and returns "no movement" because the mover has zero velocity, zero
acceleration, and a forged walkable contact.

---

## 2. What produces the blip

**Two candidates, both live, and they are distinguishable only by capture.**
The first is the one AP-87 predicted; the second is a retail-faithful mechanism
firing correctly on a body that has been frozen by §1 — and it fits the user's
timing description ("stay there *briefly*, then blip") better.

### Candidate 1 — AP-87's `bodyToTarget > 4 m` snap

`src/AcDream.Runtime/Physics/RuntimeRemoteSteadyStatePosition.cs:129-137`:

```csharp
bool  firstUp       = remote.LastServerPosTime <= 0.0;
float bodyToTarget  = Vector3.Distance(remote.Body.Position, worldPosition);
if (firstUp || !willBeDrTicked || bodyToTarget > BodySnapThreshold)   // BodySnapThreshold = 4f, :42
{
    remote.Interp.Clear();
    remote.Body.Position    = worldPosition;
    remote.Body.Orientation = orientation;
    return Action.Snapped;
}
```

This requires the server position to have descended more than 4 m from the
parked body. It only fires on a packet that classifies `Interpolate`.

### Candidate 2 — the InterpolationManager's own stall blip (`node_fail_counter > 3`)

`src/AcDream.Core/Physics/InterpolationManager.cs:405-467` ports retail's
5-frame stall window and its snap-to-tail:

```csharp
if (_frameCounter >= StallCheckFrameInterval)          // 5 frames
{
    float cumulative = _originalDistance - dist;        // progress made
    …
    if (!primaryPass && !secondaryPass) _failCount++;   // no progress -> fail
    else                                _failCount = 0;
}
…
if (_failCount > StallFailCountThreshold)              // > 3, :458
{
    InterpolationNode tail = _queue.Last!.Value;
    Vector3 tailDelta = tail.TargetPosition - currentBodyPosition;
    Clear();
    return new InterpolationStep(true, tailDelta, tail.TargetOrientation);
}
```

This is a faithful port of retail `InterpolationManager::UseTime` **@0x00555f20**
(pseudo-C :353261): `if (node_fail_counter > 3)` → `SetPositionSimple(physics_obj,
<tail or blipto_position>, 1)` @0x0055605D / @0x00556021, then
`StopInterpolating` @0x00556061. Verified directly.

A body frozen by §1 makes **zero** progress every window, so `_failCount`
increments on every 5th frame and crosses 3 after ~20 frames — **about 0.33 s at
60 Hz**. That is "stay there briefly, then blip", and the blip lands exactly at
the tail waypoint, i.e. the server's already-slid-down position.

The code is not wrong. Retail's own remote would never trip this, because
retail's remote is genuinely sliding and therefore genuinely making progress.
**This is a downstream symptom of §1, not an independent defect — do not touch
`InterpolationManager`.**

### Elimination of the remaining candidates

| Candidate | Site | Verdict |
|---|---|---|
| Far snap (≥96 m) — route 4b-2, just landed at `7f1c1f5a` | `RuntimeRemoteFarSnapPosition.ResolveArm`; classifier `RuntimeAuthoritativePositionRouteClassifier.cs:454-459` (`nearby = PlayerDistance < 96f`) | **Ruled out.** The observer is watching the house; `player_distance` is far under 96 m, so the classification is `Interpolate`, never `SetPositionSimple`. |
| `RemoteContactArm.AirborneSnap` | `LiveEntityNetworkUpdateController.cs:1031-1049` | Ruled out for the *post-plant* blip: it requires `remote.Airborne`, which is false once the body has planted (cleared at `:2021` / `:497`). It *is* the mechanism for the initial plant-onto-the-roof snap. |
| Airborne no-op branch | `LiveEntityNetworkUpdateController.cs:1994-1998` / `:2273-2280` | Not a writer at all — it writes nothing but `CellId` + `LastServerPos` (AP-135). It is a *contributor* (see below), not the blip. |
| Teleport / `ForcePosition` | `RemoteTeleportController` | Ruled out: requires a bumped teleport/force-position sequence, which ACE does not emit for ordinary sliding movement. |
| `InterpolationManager` 100 m autonomy blip | — | Ruled out at this distance. |

### The un-established half: what the wire says during the slide

There are **two** shapes of the same symptom, and code alone cannot tell them
apart:

- **Shape A** — ACE reports `IsGrounded == false` throughout the retail
  sender's slide. ACE derives that flag from its *own* server-side physics:
  `references/ACE/Source/ACE.Server/Network/Structure/PositionPack.cs:72-73`,
  `if ((PhysicsObj.TransientState & TransientStateFlags.OnWalkable) != 0) flags |= PositionFlags.IsGrounded;`.
  A steep roof is not walkable, so if ACE's server physics classifies it the
  same way retail does, the whole slide arrives with the bit clear. Every one of
  those packets classifies `NoPositionOperation`
  (`RuntimeAuthoritativePositionRouteClassifier.cs:422-443`) and acdream writes
  **nothing** — not even the interpolation queue. The remote is frozen for the
  entire slide, and the first `IsGrounded == true` packet after the sender
  reaches walkable ground fires the 4 m snap. Visible as: *land, total
  stillness, one large blip.*
- **Shape B** — ACE reports `IsGrounded == true` throughout. Each packet
  classifies `Interpolate` and feeds the queue. The body still cannot move (§1),
  so **Candidate 2 fires first**, at ~0.33 s, snapping to the tail waypoint;
  Candidate 1 would only get its turn if the queue were empty. Visible as:
  *land, ~third of a second, blip.*

Note that in **Shape A** the queue is never fed at all (the `NoPositionOperation`
branch writes nothing), so Candidate 2 cannot fire — the blip must be
Candidate 1, on the first grounded packet after the sender reaches walkable
ground. **The two shapes therefore have different blip producers**, which is
precisely why the capture is worth taking. This is **NOT ESTABLISHED**.

One further §1 consequence worth naming here: retail's
`InterpolationManager::adjust_offset` **@0x00555d30** gates its entire body on
`physics_obj->transient_state & 1` (CONTACT_TS) at 0x00555D52 — a remote in free
fall gets no interpolation correction at all. acdream ports that gate
(`InterpolationManager.cs:319-321`, `:346-349`) and the remote tick passes
`inContact: rm.Body.InContact` (`RuntimeRemotePhysicsUpdater.cs:269`, `:306`) —
but Link 1 forces `Contact` true unconditionally, so the gate never engages.
Another correct port defeated by the same forged input.

### Do existing probes distinguish them? No.

- `ACDREAM_PROBE_REMOTE_LANDING` (`PhysicsDiagnostics.cs:218-265`) fires only at
  the two landing *edges*. It logs `contact`, `onWalkable`, `gravitySet`,
  `resolveIsOnGround` — genuinely useful for confirming Links 3 and 4 at the
  landing instant, but it emits nothing during the slide window and nothing at
  the snap. It cannot see the wire bit or the classification.
- `ACDREAM_PROBE_RESOLVE` (`PhysicsEngine.cs:2640`) logs
  `groundedIn / cp / hit / walkable` per resolve for every entity. It shows the
  contact-plane state but not the *result's* `OnWalkable`, not the plane's
  `Normal.Z`, and not the wire/classification side. It is also ~30 Hz × every
  entity — impractical for a two-client session.
- `ACDREAM_REMOTE_VEL_DIAG` gives `[VEL_DIAG]` pace but no contact or
  classification data.

### The probe that would settle it

One new per-accepted-Position line for remote GUIDs, emitted at the routing
site in `LiveEntityNetworkUpdateController` (both arms), plus one per-tick line
for the same GUID:

**`[remote-slide-up]`** — guid, `update.IsGrounded` (the raw wire bit),
`earlyRemoteRoute?.Disposition`, `request.PlayerDistance`, `bodyToTarget`,
`willBeDrTicked`, `firstUp`, the `ApplyInterpolate` `Action` result
(`Snapped`/`Enqueued`), `rm.Airborne`, `Body.TransientState` Contact/OnWalkable,
`Body.State & Gravity`, `Body.Velocity`, `Body.ContactPlaneValid`,
`Body.ContactPlane.Normal.Z`, wire `worldPos`, `Body.Position`, plus
`Interp` queue depth and `_failCount` (needed to tell Candidate 1 from
Candidate 2).

**`[remote-slide-tick]`** — guid, `resolveResult.InContact`,
`resolveResult.OnWalkable`, `resolveResult.IsOnGround`,
`Body.ContactPlane.Normal.Z`, `Body.Velocity`, `Body.Acceleration`, the
pre/post-integrate positions, and whether the body actually moved this tick.
Rate-limit to remotes whose `ContactPlaneValid && ContactPlane.Normal.Z <
PhysicsGlobals.FloorZ` (i.e. only while standing on something steep) so the
volume stays usable in a live two-client run.

That single capture answers: which shape, which snap site, and whether the
contact plane the sweep finds on the roof is actually steep.

---

## 3. What retail does — verified directly against the pseudo-C

All citations independently read out of
`docs/research/named-retail/acclient_2013_pseudo_c.txt` for this report.

### 3.1 Retail's observer runs full physics for *every* object — no player fork

`CPhysics::UseTime` **@0x00509950** (pseudo-C :271481) iterates a
`LongHashIter<CPhysicsObj>` over the whole physics-object hash and calls
`update_object` on each entry (pseudo-C :271639-271650):

```
005099e0    class HashBaseData<unsigned long>* curPtr_ = iter->curPtr_;
005099e5    CPhysicsObj::update_object(curPtr_);
005099ed    if (curPtr_ == this->player)
005099f2        SmartBox::PlayerPhysicsUpdatedCallback(this->smartbox);
005099fa    HashBaseIter<unsigned long>::Next(this->iter);
```

The `curPtr_ == this->player` test only fires an extra callback. There is **no
local-vs-remote fork on the update itself**.

`CPhysicsObj::update_object` **@0x00515d10** (pseudo-C :283950-284055) has
exactly one early-return gate (:283957):

```
00515d40    if ((this_3->parent != 0 || (this_3->cell == 0 || (this_3->state & 0x1000000) != 0)))
00515eeb        this_3->transient_state &= 0xffffff7f;   // clear ACTIVE
00515ef5        return;
```

`0x01000000` is `FROZEN_PS` (ACE `PhysicsState.Frozen = 0x01000000`,
`references/ACE/Source/ACE.Entity/Enum/PhysicsState.cs:32`). **There is no
`is_player`, `autonomous`, `server_controlled`, or `MOVEMENT_LOCKED` gate.**

`0x01000000` is `FROZEN_PS` (retail header `acclient.h:2841`, `enum
PhysicsState`; cross-checked against ACE
`references/ACE/Source/ACE.Entity/Enum/PhysicsState.cs:32`).

The rest is the object clock: `player_distance` is computed (:283963-283976,
this is retail's own `player_distance` field, the one
`MoveOrTeleport` later reads); `set_active(1)` when within 96 m or when the
object has no part array (:283983-283988); then dt gates — `< 0.0002` return,
`> 2.0` discard, then the MaxQuantum subdivision loop into
`UpdateObjectInternal` (:284035-284053). The 96 m test is a **distance LOD that
applies to the local player identically**, not an identity fork.

The only autonomy-flavoured field on `CPhysicsObj` is
`last_move_was_autonomous`, written at 0x00514FE9 in `set_description` from
`PhysicsDesc::get_autonomous_movement` and read by
`CPhysicsObj::movement_is_autonomous` **@0x0050eb30** — whose only four callers
are in `CMotionInterp::apply_raw_movement`/`apply_current_movement`
(@0x0052888D, @0x005288ED, @0x0052894D, @0x00528991), i.e. deciding whether to
*send* movement upstream. **It is never read by the physics tick.**

`UpdateObjectInternal` **@0x005156B0** (pseudo-C :283611) and
`UpdatePositionInternal` **@0x00512C30** (:280817) likewise contain no identity
fork. `UpdatePositionInternal`'s only state-dependent branch of interest is
`transient_state & 2` (ON_WALKABLE_TS, :280836), which decides whether the
animation root-frame delta is scaled by `m_scale` or by zero — the branch
acdream mirrors at `RuntimeRemotePhysicsUpdater.cs:133-135`, except that
acdream keys it on the client `rm.Airborne` bool instead of the transient.

**Answer: a retail observer runs the complete transition/slide for a remote,
identically to the local player.**

### 3.2 `MoveOrTeleport` returning 0 does not suspend that simulation

`CPhysicsObj::MoveOrTeleport` **@0x00516330** (pseudo-C :284304-284366) —
verified verbatim:

- `0x0051638E` — `if (arg4 != 0)` guards the entire near/far branch.
- `0x0051636D` — `return 0` when it does not. Nothing is written.
- `0x005163AF` — `InterpolateTo(this_1, arg2, IsMovingTo(this_1))` then
  `return 1` @0x005163BE, on `player_distance < 96f`.
- `0x00516386` — cell-0/teleport branch, `teleport_hook` + flags-`0x1012`
  `SetPosition`, `return 1` @0x00516438.

Nothing on the `return 0` path touches `update_time`, `FROZEN_PS`, `parent`,
or `cell` — the three things `update_object` gates on. **The object keeps being
ticked by `CPhysics::UseTime` at full rate.** This is the single most important
retail fact for Bug B: retail's airborne no-op is safe *because* retail is
simulating the object locally. acdream copied the no-op without the simulation.

The caller confirms the same: `SmartBox::HandleReceivedPosition` **@0x00453FD0**,
remote branch (pseudo-C :92995), is
`if (MoveOrTeleport(...) != 0) { …ConstrainTo @0x00454272 }` and then returns.
On the zero return it has done nothing but `unset_parent` @0x00454129 and the
`!HasAnims`-gated `SetPlacementFrame` @0x00454142 — neither of which touches
position, velocity, `FROZEN_PS`, or `ACTIVE_TS`.

Incidental but worth recording: **`MoveOrTeleport` never references `arg5`**,
the wire velocity vector. Retail discards the broadcast velocity for remotes
entirely and relies on its own simulation — which is exactly the load acdream's
`RuntimeRemotePhysicsUpdater.cs:169` cannot carry.

### 3.3 Retail derives `on_walkable` from the contact plane

`CPhysicsObj::SetPositionInternal` **@0x00515330**, pseudo-C :283481-283509
(read out directly):

```
00515430    if (arg2->collision_info.contact_plane_valid == 0)
00515437        eax_7 = (transient_state_1 & 0xfffffffe);   // clear CONTACT_TS (0x1)
00515430    else
00515432        eax_7 = (transient_state_1 | 1);            // set CONTACT_TS
0051543c    this->transient_state = eax_7;
00515442    CPhysicsObj::calc_acceleration(this);
...
00515465    if ((eax_9 & 1) == 0)                            // not in contact
0051549f        this->transient_state = (eax_9 & 0xfffffffd);   // clear ON_WALKABLE (0x2)
005154a5        if ((eax_9 & 2) != 0) MovementManager::LeaveGround(...)
00515465    else
00515467        long double x87_r7_1 = this->contact_plane.N.z;
0051546d        long double temp1_1 = PhysicsGlobals::floor_z;
00515478        if (contact_plane.N.z < floor_z)
0051548e            CPhysicsObj::set_on_walkable(this, 0);
00515478        else
00515482            CPhysicsObj::set_on_walkable(this, 1);
```

Contact and on-walkable are **two independent facts**. A steep roof is Contact
and not on-walkable. acdream ports this correctly in
`PhysicsObjUpdate.ApplySetPositionContact` (`:30-56`) and
`IsWalkableContact` (`:20-21`) — it simply never calls them on the visible
remote path (Link 4).

### 3.4 What actually makes retail slide on a steep contact

Three pieces, all present and correct in acdream's Core — none of them reachable
by a grounded remote:

1. **Gravity survives.** `CPhysicsObj::calc_acceleration` **@0x00510950**
   (pseudo-C :278533; acdream's port is `PhysicsBody.cs:503-518`) zeroes
   acceleration only when `CONTACT && ON_WALKABLE && !SLEDDING` (0x0051096B). On
   a steep contact `ON_WALKABLE` is clear, so it falls through to the
   `state & GRAVITY_PS (0x400)` test at 0x005109F4 →
   `acceleration = (0, 0, PhysicsGlobals::gravity = -9.80000019)`.
   **`GRAVITY_PS` is on in the `CPhysicsObj` constructor** — `state = 0x400C08`
   at 0x00512508 (EDGE_SLIDE | LIGHTING_ON | GRAVITY | REPORT_COLLISIONS) — and
   is thereafter set wholesale from the wire by `set_description`'s
   `set_state(this, desc->state, 1)` @0x00514F40. `set_state` @0x00514DD0
   post-processes only lighting / nodraw / hidden; **it never masks GRAVITY**.
   Retail never toggles the bit on a landing.
2. **Friction does not engage.** `CPhysicsObj::calc_friction` **@0x0050ee70**
   (pseudo-C :276694) opens with `if ((this->transient_state & 2) != 0)` at
   0x0050EE7D — the *entire* function body, including the
   `v -= (v·N)N` into-plane removal and the `pow(1-friction, dt)` damping, is
   inside that `if`. On a non-walkable contact it returns immediately: no
   friction, and the into-surface component is never projected out. acdream's
   port has the identical gate (`PhysicsBody.cs:693-696`).
3. **The sweep projects the motion along the plane** — `CTransition` /
   `SlideSphere` @0x00537440 and the `SetPositionInternal` sliding-normal tail
   at 0x005154c2-0x005154e8.

`UpdatePhysicsInternal` then integrates: `Velocity += Acceleration * dt`
unconditionally (acdream `PhysicsBody.cs:771`). That is the slide.

### 3.5 Retail's interpolation is a per-frame *offset*, not the motion

`PositionManager::adjust_offset` **@0x00555190** (pseudo-C :352090-352115)
chains `InterpolationManager::adjust_offset` → `StickyManager::adjust_offset`
→ `ConstraintManager::adjust_offset` into the same `Frame` that
`UpdatePositionInternal` then sends through the transition sweep. In retail the
interpolation nudges an object that is *already* moving under its own physics.
In acdream the interpolation catch-up is the object's *entire* motion
(`RemoteMotionCombiner.ComposeOffset`, `:40-76`), because Links 1-3 removed
everything else.

---

## 4. Is the roof even walkable? — the classification agrees; the consumer does not

**acdream's classifier agrees with retail.** `PhysicsObjUpdate.IsWalkableContact`
(`:20-21`) is `inContact && contactNormal.Z >= PhysicsGlobals.FloorZ` — the same
predicate as retail's `contact_plane.N.z < floor_z` test above, and the same as
retail's standalone `CPhysicsObj::is_valid_walkable` **@0x0050f530** (pseudo-C
:277180), which is literally `return N.z < floor_z ? 0 : 1`.

**Constant check — with a caveat.** acdream `TransitionTypes.cs:1255` carries
`FloorZ = 0.6642f`, while `src/AcDream.Core/Rendering/Wb/TerrainUtils.cs:20`
carries `0.66417414618662751f`. Two copies of the same constant in our own tree,
differing by 2.6e-5 (about 0.002° of slope). Not load-bearing for Bug B, but it
is an unexplained internal divergence and should be unified on the longer value.

**The literal 0.66417414 does NOT appear anywhere in the pseudo-C** — grep
returns nothing. `PhysicsGlobals::floor_z` lives at 0x008EDE5C and is computed
at static-init in `$E73` **@0x0070d920** (pseudo-C :805181), which Binary Ninja
renders as `floor_z = __fcos(3437.7467707849391)`. That rendering is a BN
artifact of the classic elided-numerator kind (`3437.74677` is
arcminutes-per-radian, so the real source is `cos(<arcmin> / 3437.7467…)`; BN
dropped the numerator, exactly the class of defect
`claude-memory/feedback_bn_decomp_field_names.md` warns about). The *value* is
corroborated by WorldBuilder and ACE agreeing on 0.66417414618662751, but a
byte decode of 0x0070D920 would be needed to pin it from the binary — see
NOT ESTABLISHED #6.

So the "acdream thinks it's walkable, retail doesn't" hypothesis is **half
true, and its cause is not the threshold**. acdream's *sweep* would classify
the roof exactly as retail does. The forged `OnWalkable` at
`RuntimeRemotePhysicsUpdater.cs:150-154` overwrites that answer before the
sweep ever runs, and `Tick` discards the answer the sweep returns anyway
(Link 4). This is a plumbing defect, not a geometry or threshold defect.

**NOT ESTABLISHED:** whether the specific house roof in the user's test
actually produces a contact plane with `Normal.Z < 0.6642` in acdream's
collision data. Buildings are GfxObj/Setup collision, and no capture of the
contact plane on that roof exists. The `[remote-slide-tick]` probe's
`ContactPlane.Normal.Z` field settles it.

---

## 5. Is it in the register / ISSUES already?

**Yes, partially — three rows and one issue, none of them complete.**

| Record | What it covers | Gap |
|---|---|---|
| `docs/ISSUES.md` **#32** (2026-08-04 addendum, ~:9562) | Bug B named, root-caused to the *landing block's* unconditional `OnWalkable`; cites `SetPositionInternal` @0x00515330 :283501-283509 correctly | Does not name `RuntimeRemotePhysicsUpdater.cs:150-154` (the dominant per-tick force), does not name `:169` (velocity zeroing), and treats Link 3 (Gravity) as a Bug A concern only. The stated fix target is therefore insufficient. |
| register **AP-87** (`:242`) | The 4 m snap; its risk column *already predicted this exact symptom* and was updated 2026-08-04 with the live observation | Correct and current. AP-87 is the blip's mechanism, not its cause — do not "fix" AP-87. |
| register **AP-81** (`:235`) | Remote VectorUpdate's non-retail Airborne/Gravity dance; risk column literally says "grounded remotes carry a non-retail state word" | Its file:line column lists only the VectorUpdate handler and the landing blocks. It does **not** list `RuntimeRemotePhysicsUpdater.cs:150-154`/`:169` — the per-tick unconditional force and velocity zeroing have **no register row of their own** and are not covered by AP-81's cited sites. Register rule 1 violation; the row needs extending in whichever commit next touches that file. |
| register **AD-10** (`:122`) | Remote slope projection is terrain-normal-only (`RemoteMotionCombiner.ComposeOffset :65-73`, `ComputeOffset :163-168`), cannot see building/EnvCell geometry; already amended 2026-08-04 to name Bug B | Correct. Confirms that even a corrected `OnWalkable` gets no help from this path on a house roof. |

**Verified `#32` is NOT a route-4a regression, independently:** the landing
block's `TransientState |= Contact | OnWalkable` and the per-tick force at
`:150-154` both predate C4. The per-tick force carries the comment "Forces
OnWalkable + Contact so the gate in `apply_current_movement` always succeeds"
(`:138-140`) — a #184-Slice-2b-era construct, unrelated to route 4a. Do not
revert `44830a0e` or `7f1c1f5a`.

**DO-NOT-RETRY check** (`claude-memory/project_physics_collision_digest.md`):
the proposal in §6 does not appear in any DO-NOT-RETRY table. Closest
neighbours, all distinct: the AD-25 landing `Velocity.Z = 0` hand-zero
(:145-151) — this proposal *removes* a velocity zeroing rather than adding one,
and does not touch the landing reflect; "do not seed transition contact from a
caller's `isOnGround` bool when a body is present" (:149-150) — this proposal
moves the remote *toward* body-derived contact, which is the same direction;
#269's slope-slide residual (:152-160) — a *local-player* decay-curve question
whose code is byte-exonerated, unrelated to the remote plumbing here.

---

## 6. Proposed fix

### The one-line summary

The remote tick already runs retail's sweep and the sweep already computes
retail's answer. **Stop forging the inputs and start consuming the outputs** —
i.e. make the visible remote path use the same
`PhysicsObjUpdate.CommitSetPositionTransition` seam that `TickHidden` and every
other body in the codebase already use.

### Concrete targets

1. **`src/AcDream.Runtime/Physics/RuntimeRemotePhysicsUpdater.cs:150-154`** —
   delete the unconditional `Contact | OnWalkable` force from the grounded
   branch. Keep `Active`. Retail's equivalent state is written only by
   `SetPositionInternal` from the contact plane
   (`@0x00515330`, 0x00515430 / 0x00515465-0x0051548e).
2. **`RuntimeRemotePhysicsUpdater.cs:420-477`** — replace the bare
   `HandleAllCollisions` call with `PhysicsObjUpdate.CommitSetPositionTransition
   (body, resolveResult.InContact, resolveResult.OnWalkable, …, previousContact,
   previousOnWalkable, rm.Movement.HitGround, rm.Motion.LeaveGround, isCurrent)`
   — byte-identical in shape to `TickHidden.cs:778-795`, which already does
   exactly this. `CommitSetPositionTransition` calls `HandleAllCollisions`
   itself (`PhysicsObjUpdate.cs:104-110`), so this is a substitution, not an
   addition. Retail order is `SetPositionInternal` contact/walkable →
   `HitGround`/`LeaveGround` → `handle_all_collisions` @0x005154FE.
3. **`RuntimeRemotePhysicsUpdater.cs:493-495`** — the landing test currently
   uses `resolveResult.IsOnGround`, which is `inContact || …`
   (`PhysicsEngine.cs:2660`) and therefore true on a steep roof. It must be
   `resolveResult.OnWalkable`. Retail's ground edge is `set_on_walkable`, not
   contact.
4. **`RuntimeRemotePhysicsUpdater.cs:169`** — the `Velocity = Zero` must become
   conditional on the body actually being on walkable ground, or be deleted in
   favour of letting `calc_friction` (which retail gates on `OnWalkable`,
   `PhysicsBody.cs:693-696`) do the decay. Deleting it outright is the
   retail-faithful shape; making it conditional is the smaller step.
5. **`RuntimeRemotePhysicsUpdater.cs:571-576` and
   `LiveEntityNetworkUpdateController.cs:2110-2116`** — stop clearing
   `PhysicsStateFlags.Gravity`. Retail keeps GRAVITY_PS for the object's whole
   life and gates gravity acceleration on the Contact transient inside
   `calc_acceleration` (already correct in `PhysicsBody.cs:505-517`). This
   retires the bulk of register row **AP-81** and is shared with **Bug A**'s H1.
6. **`LiveEntityNetworkUpdateController.cs:2023-2024`** — the landing block's
   force, the site ISSUES.md #32 names. Necessary but, alone, useless: `:150-154`
   re-asserts it on the next tick.

7. **Register bookkeeping, same commit.** `AP-81`'s file:line column must gain
   `RuntimeRemotePhysicsUpdater.cs:150-154` and `:169` (§5). If items 1-5 land,
   AP-81 is largely retired and the row should be deleted or narrowed in the
   same commit per the register's rule 1. `AP-87` stays — it is the backstop,
   not the bug.

**Explicitly NOT in scope:** `src/AcDream.Core/Physics/InterpolationManager.cs`.
Its stall blip (§2 Candidate 2) is a faithful port of retail
`InterpolationManager::UseTime` @0x00555f20 and is behaving correctly on a
frozen body. Touching it would be a symptom-site guard.

### Ordering and prerequisites

Items 1-4 are one coherent change and must land together — any subset leaves
either a forged input or a discarded output. Item 5 is separable and is shared
with Bug A. Item 6 falls out of item 1 (both sites express the same wrong idea).
Item 7 is bookkeeping and rides whichever commit lands 1-4.

### Blast radius

- **Every remote — players and NPCs alike.** Slice 2b deliberately collapsed the
  player/NPC fork (`RuntimeRemotePhysicsUpdater.cs:110-117`); there is one path.
  A remote will now genuinely fall, slide, and be subject to friction. This is
  the intent, and it is what makes it risky: **the #184 invisible-but-solid
  monster lived in this neighbourhood.** AP-87's 4 m snap stays as the backstop
  and must not be weakened in the same change (AP-137 explicitly warns that
  weakening it turns the leftover arm into a silent-freeze path).
- **NPC free-fall / knockback** — the route 4a acceptance criterion "push a
  monster off a ledge, confirm it falls and lands without hovering"
  (`2026-08-03-c4-route-4a-contract.md:174-183`) is directly exercised by items
  3 and 5 and must be re-run.
- **Local player** — untouched. `PlayerMovementController` constructs its body
  with `State = Gravity | ReportCollisions` permanently
  (`PlayerMovementController.cs:689`) and already commits contact from the
  sweep. No shared code changes.
- **Projectiles** — untouched. `RuntimeProjectilePhysicsUpdater` has its own
  stepper and its own state handling.
- **Hidden remotes** — untouched; `TickHidden` already does the right thing and
  is the template.
- **Sticky melee (TS-44) and de-overlap (#184/AP-86)** — the shadow-follows-
  resolved sync at `:618-630` reads `rm.Body.Position` after the resolve; a body
  that now genuinely moves under gravity will re-flood its shadow more often.
  Perf note, not correctness, but worth measuring in a packed town.
- **The interpolation contact gate goes live.** `InterpolationManager.AdjustOffset`'s
  `inContact` early-return (`:319-321`, `:346-349` — retail's @0x00555D52
  CONTACT_TS gate) currently never engages because Link 1 forges the bit. After
  item 1 it will, and an out-of-contact remote will stop receiving interpolation
  corrections mid-fall — which is retail-correct, and which also means Candidate 2
  can no longer accumulate fail counts against a falling body. Expect the
  observable timing of any residual blip to change.

### Does it need live cdb evidence rather than a code change?

**The retail side does not** — §3 establishes retail's behaviour from the
pseudo-C conclusively, with no ambiguity requiring a runtime trace. `CPhysics::UseTime`
iterating every object, `update_object`'s three-condition gate, `MoveOrTeleport`'s
bare `return 0`, and `SetPositionInternal`'s floor_z comparison are all read
directly and are unambiguous.

**The acdream side does**, for one thing only: **which of Shape A / Shape B is
happening on the wire**, and whether the roof's contact plane in acdream's own
collision data is actually steep (§4's NOT ESTABLISHED). That is an *acdream*
capture — the `[remote-slide-up]` / `[remote-slide-tick]` probe of §2 — not a
retail cdb attach. Retail cdb is not the right tool here and would not answer
either question.

The honest recommendation: **land the probe, take one two-client capture, then
implement items 1-4 together.** Implementing before the capture is defensible
given how complete the code-side chain is, but the capture costs one session
and tells us whether the wire is *also* starving the path (Shape A), which
changes whether the `NoPositionOperation` branch needs its own follow-up.

---

## Shared root with Bug A?

**Partially — one of three links is shared; the rest are not.**

Shared: **Link 3, the Gravity clear.** Bug A's H1
(`2026-08-04-remote-landing-investigation.md:55-88`) is that the Gravity bit is
already clear when `HitGround()` runs, so `CMotionInterp::HitGround`'s
`state & 0x400` gate silently no-ops and the Falling pose never exits. Bug B's
Link 3 is that the same clear removes the gravity acceleration that would drive
the slide. **Item 5 of the fix addresses both.**

Also shared: the **misclassified landing edge** (item 3). If the remote "lands"
on a steep roof because `IsOnGround` is contact-derived, it runs the whole
landing block — `HitGround`, Gravity clear, pose transition — on a surface
retail is still sliding it down. That is a plausible amplifier for Bug A's
symptom *specifically in the roof scenario*, though Bug A also occurs on flat
ground, where it must have another cause.

Not shared: Links 1, 2, and 4 (the per-tick force, the velocity zeroing, and
the uncommitted sweep result) are pure position/physics and have no animation
consequence. Bug A's H2 (no `DefaultSink` bound) and H3 (scheduler-side) have no
Bug B analogue.

---

## NOT ESTABLISHED

1. **Which shape (A or B) the wire produces during a retail sender's roof
   slide** — i.e. whether ACE emits `IsGrounded == false` for the whole slide.
   Requires the `[remote-slide-up]` capture. Depends on whether ACE's *server-side*
   physics classifies a house roof as non-walkable, which was not traced.
2. **Whether the specific roof produces a contact plane with `Normal.Z <
   0.6642` in acdream's collision data.** Requires the `[remote-slide-tick]`
   capture's `ContactPlane.Normal.Z` field.
3. **Whether items 1-4 are sufficient** to reproduce retail's slide, or whether
   the `#173` remote collision-velocity reflect (shipped but its gate folded
   into the never-run Campaign P matrix scenario 8) and AD-10's terrain-only
   projection also need work. ISSUES.md #32 already flags both as open
   dependencies and that assessment is confirmed here.
4. **Whether ACE relays a `0xF74E` VectorUpdate at all during a slide.** If it
   does not, the sender's slide velocity never reaches acdream even in
   principle, and the local simulation is the only possible source — which
   strengthens the fix but was not verified against ACE's broadcast conditions.
5. **Whether ACE's server-side physics classifies a house roof as
   non-walkable.** ACE emits `IsGrounded` from its own
   `PhysicsObj.TransientState & OnWalkable` (`PositionPack.cs:72-73`), so
   Shape A requires ACE's server physics to agree with retail's `floor_z` test
   on building geometry. Not traced.
6. **`PhysicsGlobals::floor_z`'s exact value from the binary.** The literal is
   absent from the pseudo-C and its static-init is a BN-mangled `fcos`
   (§4). The value is corroborated by two independent references but not by a
   primary byte decode of 0x0070D920.
7. **The polarity of `MoveOrTeleport`'s `player_distance` vs `96.0f` compare**
   at 0x00516393 — BN emits `bool p = unimplemented {test ah, 0x5}` and its
   synthesized `fcom` operand ordering is inconsistent across this dump. Nothing
   in this diagnosis depends on it: both arms `return 1` and both leave the
   object in the simulation set, and the observer in the user's test is far
   inside 96 m either way.