# R4-V0 — ambiguity pins and ACE-oddity adjudications

The verbatim extraction is `r4-moveto-decomp.md` (line-anchored); the port plan
with the full ambiguity table is `r4-port-plan.md` §0. This note records the
PINNED resolutions the V1–V6 ports code against. Every pin below was produced by
an independent raw re-read of `docs/research/named-retail/acclient_2013_pseudo_c.txt`
(line numbers cited are that file's), cross-read against ACE source
(`references/ACE/Source/ACE.Server/`, MoveToManager under `Physics/Managers/`),
and P1/P3 additionally survived an adversarial refutation pass (P3 by direct
byte-level disassembly of the PDB-matched retail binary — evidence one tier
stronger than a Ghidra decompile). **No pin was refuted; none blocks on cdb or
Ghidra.** Ghidra MCP was down for the whole pass; the deferred decompile checks
are listed per-pin and in the tail section — all confirmatory, none load-bearing.

## Pinned

- **P1 — ACE's companion mt-0 echo vs retail's unpack-head cancel: PINNED — no
  adaptation needed; port the missing TAIL of retail's own gate.**
  `CPhysics::SetObjectMovement` (0x00509690) drops any movement event whose wire
  autonomous byte is set when the addressed object `IsThePlayer`, BEFORE
  `unpack_movement` is ever called — so retail's unconditional head-interrupt
  never sees an autonomous echo. Plan option (c) (suppress-when-command-matches)
  is DISCARDED. Confidence: **high** (adversarially verified; refutation failed
  on every angle).

  Port shape: in the local-player 0xF74C path, after the S1 `MotionSequenceGate`
  passes, drop the event entirely — no interrupt, no state application — when
  `update.IsAutonomous && guid == local player guid`. Verbatim (raw 271370–271431):
  `ebx = weenie_obj->vtable->IsThePlayer()` @005096a8; two wraparound sequence
  gates; then @0050972e `if ((arg7 == 0 || ebx == 0)) {
  arg2->last_move_was_autonomous = arg7; CPhysicsObj::unpack_movement(arg2,
  &arg3, arg4); if (ebx != 0) return 1; }` else fall to `return 0`. Note
  `last_move_was_autonomous` is stored ONLY on the unpack path — do not store it
  for dropped events. The `||`-vs-`&&` BN-inversion worry is refuted
  behaviorally: with `&&` the local player would never unpack ANY movement event,
  yet server MoveTos demonstrably drive retail clients against ACE. The 4-arg
  overload (0x00509790, raw 271458–271485) pins arg7 = the wire byte at offset +4
  after two u16 sequences with align-to-4 — byte-identical to ACE's writer
  (MovementData.cs:189-200: `GetNextSequence(ObjectMovement)`; autonomous ?
  `GetCurrentSequence` : `GetNextSequence(ObjectServerControl)`;
  `Convert.ToByte(motion.IsAutonomous)`; `writer.Align()`).

  With the gate in place, the verbatim `unpack_movement` head-cancel ports
  cleanly: `CPhysicsObj::interrupt_current_movement` + `unstick_from_object` on
  EVERY UM type 0/6/7/8/9 before the type switch (0x00524440, raw 300566–300573;
  jump table @300707–300719 — types 1–5 fall to return 0, head already ran).
  `interrupt_current_movement` = `if (movement_manager)
  MovementManager::CancelMoveTo(0x36)` (raw 278189–278200), a no-op when
  `moveto_manager == 0` (raw 300277–300288 @0x005241b0). mt 6/7/8/9 keep the
  retail unconditional cancel as planned (PerformMovement re-cancels anyway, §3a).

  Why the echo was never a retail problem: the "companion mt-0 echo" is NOT
  unconditional ACE behavior — it is ACE reflecting the client's OWN outbound
  MoveToState back to the sender. `BroadcastMovement` has exactly ONE caller
  (GameActionMoveToState.cs:36); `MovementData(Creature, MoveToState)` hardcodes
  `IsAutonomous = true` (MovementData.cs:162) and Player_Networking.cs:365 sends
  it to self (`EnqueueBroadcast(true, movementEvent)`; ACE's own comment
  "shouldn't need to go to originating player?"). The 2026-05-14 trace behind
  GameWindow.cs:4534-4546 was self-inflicted: the pre-#75 auto-walk synthesized
  Forward+Run input that leaked outbound as a MoveToState
  (PlayerMovementController.cs:546-557 preserves the finding); post-#75
  (:298-308) no MoveToState is built during auto-walk, so no echo exists at
  moveto start — **the GameWindow.cs:4534-4546 causal story ("ACE follows every
  mt=0x06 with an mt=0x00") is stale**. ACE's mt-6/7/8/9 senders are
  `IsAutonomous = false` (Motion.cs:18 default, copied at MovementData.cs:44;
  only two `IsAutonomous = true` sites in ACE.Server: MovementData.cs:162 and
  the Player.cs:944-951 jump hack), so they pass the gate and the auto-walk
  trigger survives. The gate also absorbs ACE's other self-addressed autonomous
  mt-0 class (the charged-jump hack) — and it is precisely why retail WASD
  against ACE (every keypress echoed back IsAutonomous=1) doesn't stutter:
  standing behavioral corroboration.

  **Register adjudication (the exact wording V5/V6 execute):** NO new AD row.
  The informal "do NOT cancel local moveto on a non-MoveTo UM" adaptation at
  GameWindow.cs:4534-4546 has no register row (verified — a row-less deviation)
  and is RETIRED by the ported retail mechanism; delete the comment block with
  the code in V5. ONE CONTINGENCY: the gate severs acdream's only live runSkill
  sync feed — GameWindow.cs:4364-4372 wires
  `ApplyServerRunRate(update.MotionState.ForwardSpeed)` and its ONLY live source
  is the autonomous mt-0 echo. V5 must re-anchor run-rate sync to retail's own
  mechanism (mt-6/7 `my_run_rate` wire read = plan item M13, plus
  PlayerDescription). If V5 instead taps the echo's ForwardSpeed BEFORE the drop,
  that tap IS an ACE-compat adaptation requiring this row in the same commit:

  > **AD-new | Local-player autonomous-echo ForwardSpeed tap** — acdream reads
  > `InterpretedMotionState.ForwardSpeed` from the self-addressed autonomous
  > mt-0 UM (ACE's MoveToState reflection, MovementData.cs:162
  > IsAutonomous=true hardcoded) before the ported retail
  > SetObjectMovement autonomous/IsThePlayer drop (0x00509690 @0050972e)
  > discards it, feeding `PlayerMovementController.ApplyServerRunRate`. Retail
  > discards the event entirely. | Risk: local/observer run-speed desync if the
  > echo changes; masks the missing my_run_rate wire feed. | Retire when M13's
  > mt-6/7 my_run_rate + PlayerDescription feed lands.

  Adjacent seam (R5 note): retail's 0xF74C dispatch calls
  `cmdinterp->vtable->LoseControlToServer()` whenever SetObjectMovement returns
  nonzero — i.e. whenever a NON-autonomous movement event is applied to the
  local player (raw 357214–357235: instance-seq gate then `if
  (CPhysics::SetObjectMovement(...) != 0) this->cmdinterp->vtable->
  LoseControlToServer();`). This is the retail autonomy-handoff hook that
  `BeginServerAutoWalk` currently approximates — R5/MovementManager scope.

  Ghidra deferred (non-blocking): decompile `0x00509690` (re-verify the
  `(arg7 == 0 || ebx == 0)` condition + which sequence stamps are written on the
  reject paths — the function has BN self-subtraction flag-test garbles at
  @005096db/@00509712, but the decisive gate is a plain integer test with the
  adjacent `last_move_was_autonomous` store); decompile the 0xF74C dispatch case
  at ~`0x00559850` (confirm LoseControlToServer fires iff SetObjectMovement != 0).

- **P2 — `get_desired_heading` (0x0052aad0) 180/0 constants: PINNED to ACE's
  shape.** `RunForward|WalkForward → movingAway ? 180 : 0`; `WalkBackwards →
  movingAway ? 0 : 180`; default 0. Confidence: **high**. The BN raw
  (308016–308033) confirms only the command GROUPING — {RunForward 0x44000007,
  WalkForward 0x45000005} vs {WalkBackwards 0x45000006} vs default — while both
  constant branches render identically (`result = arg3`) and the default renders
  as x87 flag-synthesis nonsense (`return (arg2 - 0x45000006)`), the known
  setcc-garble class. Constants + per-branch polarity are 100% ACE-sourced
  (MovementParameters.cs:186-198) but doubly corroborated: (a) caller math (raw
  307227–307233, HandleMoveToPosition @0x00529e25) adds the return to
  `Position::heading(to target)` then wraps [0,360) — a degree OFFSET; (b)
  physics: §5c pure-away picks WalkForward+movingAway=1 ("heading flips via
  get_desired_heading +180", r4-moveto-decomp.md:619-620) → away-walk faces
  away = +180; §5d towards_and_away picks WalkBackwards+movingAway=1 inside the
  min band ("backs up with WalkBackwards (no turn)", :656) → backstep faces the
  target = 0. Ghidra deferred (non-blocking): decompile `0x0052aad0`; mark the
  pseudocode doc UNVERIFIED-BY-GHIDRA until then.

- **P3 — `heading_diff` (0x00528fb0) third-arg mirror: PINNED as MIRROR
  PRESENT — port ACE's body verbatim.** `result = h1 − h2; if |result| < ε
  result = 0; if result < −ε result += 360; if (result > ε && motion !=
  TurnRight) result = 360 − result;` with ε = 0.000199999995f and TurnRight =
  0x6500000D. r4-moveto-decomp §5g's "arg3 UNUSED in the body" is a BN x87-setcc
  artifact (the W6b class); r4-ace-moveto §1's suspicion was correct.
  Confidence: **high** — sealed by direct disassembly of the PDB-matched binary
  (`C:\Turbine\Asheron's Call\acclient.exe`, CodeView GUID
  9e847e2f-777c-4bd9-886c-22256bb87f32 = MATCH), which supersedes the deferred
  Ghidra check entirely. The tail BN garbled into a fake "return flag word"
  (raw 306344–306346) disassembles as exactly the mirror guard:

  ```
  00528fec  fcom  dword [0x007c8a00]      ; result vs ε (0.00019999...)
  00528ff2  fnstsw ax
  00528ff4  test  ah, 0x41                ; C0|C3 → result <= ε
  00528ff7  jnz   0x00529009              ; skip mirror unless result > ε STRICT
  00528ff9  cmp   dword [esp+0xC], 0x6500000D   ; arg3 vs TurnRight — arg3 IS read
  00529001  je    0x00529009              ; TurnRight → skip mirror
  00529003  fsubr dword [0x0079bc60]      ; ST0 = 360.0f − result
  00529009  ret                           ; float return in ST0
  ```

  The 29 bytes BN collapsed (0x00528fec→0x00529008) fit the mirror encoding to
  the byte; `test ah,0x41 / jnz` encodes strict `>` (skip on less OR equal), so
  ACE's `>` comparison (Managers/MoveToManager.cs:825-826) is the correct port.
  Call sites: `BeginTurnToHeading` @0x00529be0 passes CONSTANT 0x6500000d
  TurnRight (mirror explicitly disabled — direction pick stays the ≤180 test);
  `HandleTurnToHeading` @0x0052a1bc (raw :307495) passes the LIVE
  `current_command`. Two refinements over the plan's P3 row: (1) the pin's
  "previous_heading update path differs" clause is FALSE — both branches of the
  progress test write `previous_heading` identically (raw @0x0052a1ef /
  @0x0052a206; ACE :611-621); (2) the mirror is behaviorally DEAD in this build —
  its only divergent effect is `fail_progress_count` reset-vs-increment, and
  that counter is write-only (6 refs in the whole raw, all writes: =0
  @0x005292b1/@0x00529f3e/@0x0052a13a/@0x0052a1e5, +=1 @0x0052a014/@0x0052a224;
  zero reads) — port it for verbatim fidelity + conformance tests, not because
  retail-visible behavior hangs on it. No deferred check remains (Ghidra + cdb
  fallback both MOOT).

- **P4 — TargetManager scope: DECISION CONFIRMED — R4 ships the minimal
  App-side `TargetTracker` adapter, not a TargetManager port.** Confidence:
  **high** (as a recorded decision; the retail feed constants and delivery
  contract are pinned from the extraction). On `set_target(0, tlid, 0.5, 0)`
  (verbatim call sites: r4-moveto-decomp.md:359 MoveToObject §3b, :423
  TurnToObject §3d; constants table :1168 — radius 0.5f, initial quantum 0)
  GameWindow's entity table delivers one immediate
  `TargetInfo{ObjectId, Ok, target_position = entity pos, interpolated_position
  = same}`, then re-delivers per tick when the target has moved > 0.5 units
  since last delivery; `clear_target` unsubscribes; target despawn/teleport
  delivers `status = ExitWorld/Teleported` so `CancelMoveTo 0x37/0x38` falls out
  of the verbatim manager (§6d @307802–307867: `!= Ok` on first callback →
  0x38 NoObject :857-858; on retarget → 0x37 ObjectGone :866-867; retarget sets
  `sought_position = interpolated`, `current_target_position = target`
  :869-870 + FLT_MAX progress reseeds :871-874). `set_target_quantum` is
  accepted and recorded but does NOT throttle (over-delivery is
  convergence-safe). TargetStatus values from ACE (r4-ace-moveto.md:654-656):
  Undefined=0, OK=1, ExitWorld=2, Teleported=3, Contained=4, Parented=5,
  TimedOut=6; ACE's HandleTargetting cadence is 0.5 s with a 10 s
  Undefined→TimedOut timeout. Wire inputs available today: mt-6 TargetGuid
  (UpdateMotion.cs:310-315, parsed-but-unused = gap M8 — the subscription key);
  wire Origin (:319-326) doubles as the first-delivery fallback when the guid
  is unresolvable, mirroring retail's own case-6 degrade to
  MoveToPosition(wire origin) (r4-moveto-decomp.md:290-292). NOT on the wire:
  target radius/height for `cylinder_distance` (from the local entity table)
  and ongoing target updates (the adapter's per-tick tracking; ACE's ~1 Hz
  MoveTo re-emit is the backstop). **Register row (AP class) lands in V4,
  replacing AP-8's "no target re-tracking" clause; full TargetManager port is
  R5 scope.** Fallback if the adapter proves too loose in V4: grep
  `TargetManager::` in the raw (~200 lines) and port verbatim.

- **P5 — Position::heading convention: PINNED — compass degrees, 0 = North
  (+Y), 90 = East (+X), CLOCKWISE, [0,360); identity quaternion faces heading
  0.** Formula: `heading(from, to) = (450 − atan2Deg(dy, dx)) % 360`. Wire
  `DesiredHeading` is in THIS convention (retail @0052a71d feeds it straight
  into `Frame::set_heading` on sought_position, §3e). Golden cardinals:
  N(0,+1)→0, E(+1,0)→90, S(0,−1)→180, W(−1,0)→270. Confidence: **high**.
  Evidence: `Position::heading` 0x005a9520 (raw 438288–438290): `450.0 −
  fpatan(...) × 57.295779513082323`, fmod tail; ACE Position.cs:200-209 pins the
  atan2 arg order (`Atan2(dir.Y, dir.X)`); `Frame::get_heading` 0x00535760 (raw
  319781) same formula on the forward basis (ACE AFrame.cs:147-152);
  `Frame::set_heading` 0x00535e40 (raw 320055–320066) round-trips — h=0 →
  forward (sin 0, cos 0) = +Y. An in-tree twin of the formula already exists at
  SceneryHelpers.cs:75.

  **⚠ CORRECTION to the plan's own pin method — the packer-reuse trap.** The
  plan says "the outbound AP packer already encodes body yaw→AC heading; REUSE
  that exact conversion". Reuse it at the **QUATERNION level ONLY**
  (`YawToAcQuaternion`/`AcQuaternionToYaw` are wire-correct end-to-end — its
  two internal errors cancel). Its internal SCALAR intermediate
  (GameWindow.cs:8083-8103: `headingDeg = 180f − yawDeg`) is **holtburger's
  convention = retail + 90°**, and its comment "AC heading: 0=West, 90=North,
  180=East, 270=South" (from holtburger math.rs:56, whose identity-quat note
  :146-148 says "Heading 90 (North)") is WRONG as a statement of the retail wire
  convention. Literal scalar reuse would face `use_final_heading` and every
  `get_desired_heading` offset 90° wrong. The correct scalar bridge from acdream
  yaw (yaw=0 faces +X per PlayerMovementController.cs:1022-1025) is
  `heading = (90 − yawDeg) mod 360`. Quaternion-level proof:
  YawToAcQuaternion(yaw=0) → (z=−0.7071, w=+0.7071), from which ACE's
  AFrame.get_heading extracts 90 = East — correct for a +X-facing body.

- **P6 — TurnToObject (mt 8) wire layout: PINNED byte-for-byte from ACE's
  writer, matching the decomp read order exactly.** After the common UM header
  (u8 movementType, u8 motionFlags, u16 currentStyle — MovementData.cs:202-205):
  `[u32 object guid][f32 standalone heading][u32 params bitfield][f32 speed]
  [f32 params desired_heading]`. mt 9 (TurnToHeading) = the 3-dword
  TurnToParameters only. Confidence: **high**. The standalone second field is
  ACE `TurnToObject.DesiredHeading` = retail's `wire_heading`, consumed ONLY in
  the unresolvable-object fallback: substituted into `params.desired_heading`,
  then degrade to TurnToHeading (decomp §2f case 8, r4-moveto-decomp.md:293-298:
  `object_id = read_dword(); wire_heading = read_dword(); UnPackNet(...); if
  (GetObjectA(object_id) == 0) { var_9c.desired_heading = wire_heading; goto
  label_524725; }`; ACE TurnToObject.cs:25-31 + field comment :10-11 "used
  instead of the DesiredHeading in the TurnToParameters"). UnPackNet 0xc-byte
  form per §2g (:311): bitfield, speed, desired_heading. Gap M7 confirmed:
  UpdateMotion.cs:252 `else if (movementType is 6 or 7)` — mt 8/9 payloads
  silently discarded today. **V3 fixture caveat:** ACE populates BOTH heading
  fields from the same source (TurnToObject.cs:17 and TurnToParameters.cs:18
  both copy `motion.DesiredHeading`), so ACE-golden fixtures always have
  field2 == field5 — distinguish the two fields by OFFSET (hand-vary one in
  synthetic fixtures), never by value.

- **P7 — remote Contact for the UseTime gate: PINNED — Contact IS live for
  grounded remotes; no state-writer fix needed.** Confidence: **high**. Remote
  bodies are BORN with `Contact | OnWalkable | Active` (GameWindow.cs:580-591)
  and BOTH remote per-tick paths re-assert `TransientState |= Contact |
  OnWalkable | Active` unconditionally every tick while `!rm.Airborne`
  (:9366-9370 player-remote pipeline; :9570-9574 NPC/legacy — the path
  RemoteMoveToDriver runs on today). The bits are cleared ONLY for the airborne
  arc (:4833-4841, `Velocity.Z > 0.5f` launch) and restored on landing by two
  independent paths (:5161-5167 UP grounded snap; :9808-9818 resolver landing —
  which already calls `rm.Motion.HitGround()`, the exact retail re-arm seam
  `MoveToManager::HitGround` §6e binds to: `if (movement_type == Invalid)
  return; BeginNextNode(this);`, r4-moveto-decomp.md:884-889). Retail UseTime
  gates on `transient_state & 1` (Contact only, @307781) — a strict SUBSET of
  the funnel's `Contact && OnWalkable` that demonstrably works for remote
  Falling dispatch today (MotionInterpreter.cs:2089-2092). A chasing grounded
  NPC passes the gate every tick; an airborne remote stalls the moveto until
  landing — retail behavior by design. The pin-method's live
  `ACDREAM_DUMP_MOTION` smoke was NOT run (read-only pass; the write is
  unconditional so the smoke is confirmatory only) — **folded into V4's
  acceptance run** (already listed there: "Live smoke: NPC chase +
  ACDREAM_DUMP_MOTION").

## Pending

None. No pin was refuted or left uncorrectable.

## Deferred non-blocking checks (Ghidra MCP down during V0)

All three are confirmatory — the textual adjudications above are decisive.

| Address | Function | What to confirm |
|---|---|---|
| `0x00509690` | `CPhysics::SetObjectMovement` (7-arg) | The `(arg7 == 0 \|\| ebx == 0)` gate condition; which sequence stamps are written on the reject paths (BN garbles @005096db/@00509712 are self-subtraction flag-test artifacts) |
| ~`0x00559850` | 0xF74C dispatch case | `LoseControlToServer()` fires iff `SetObjectMovement != 0` |
| `0x0052aad0` | `MovementParameters::get_desired_heading` | The 180/0 constants + per-branch polarity (currently ACE-sourced; grouping BN-verified) |

P3's deferred check (`0x00528fb0`) is MOOT — resolved by direct disassembly of
the PDB-matched binary (see the pin).

## Adjacent findings (load-bearing for V-commits, discovered while pinning)

- **runSkill-sync severance (V5 trap, from P1):** GameWindow.cs:4364-4372's
  `ApplyServerRunRate(ForwardSpeed)` is fed EXCLUSIVELY by the autonomous mt-0
  echo the P1 gate will drop. V5 re-anchors run-rate sync to M13 (mt-6/7
  `my_run_rate` wire read → `Motion.MyRunRate`) + PlayerDescription — or ships
  the contingent AD row quoted in P1.
  **V5 EXECUTED (2026-07-03): re-anchor taken, NO AD row needed.** Both
  retail-mechanism feeds already existed: PlayerDescription run/jump skills
  flow via `SetCharacterSkills` (K-fix7, wired since before V5 — the
  "we don't parse PD yet" comment in the controller ctor was stale) into
  `PlayerWeenie.InqRunRate`, which `apply_run_to_command`/`get_state_velocity`
  PREFER over `MyRunRate`; and V5's shared `RouteServerMoveTo` performs the
  M13 `Motion.MyRunRate = MoveToRunRate` write for the local player on
  mt-6/7. `ApplyServerRunRate` was deleted outright — its
  `InterpretedState.ForwardSpeed` overwrite was a pre-R3 mechanism that
  fought the ported machinery (any DoMotion edge recomputes ForwardSpeed
  through adjust_motion/apply_run_to_command).
- **LoseControlToServer seam (R5):** retail hands autonomy to the server at the
  0xF74C dispatch whenever a non-autonomous movement event is applied to the
  local player (raw 357214–357235). Note for R5/MovementManager — the retail
  hook `BeginServerAutoWalk` approximates today.
- **GameWindow.cs:4534-4546 comment is stale** (from P1): the "ACE follows every
  mt=0x06 with an mt=0x00" causal story described the pre-#75 build's
  self-inflicted echo; post-#75 no echo exists at moveto start. The comment
  block dies with the code in V5 — do not port against it.
- **RemoteMoveToDriver.cs:53-57 stale claim FIXED in this commit** (plan §0
  mandate): the class doc claimed "ACE swaps the chase/flee arrival predicates"
  — refuted by r4-ace-moveto §1 and by the file's own :186-199 comment; retail
  and ACE agree (chase arrives `dist <= distance_to_object`, flee arrives
  `dist >= min_distance`).

## V0 cdb capture (pending, non-blocking)

No pin above depends on it — P1/P3 were adversarially sealed textually (P3 down
to the instruction bytes). One live retail session feeds V2/V4 goldens: bp
`MoveToManager::PerformMovement` / `BeginMoveForward` / `BeginTurnToHeading` /
`HandleMoveToPosition` / `HandleUpdateTarget` /
`MovementParameters::get_command` (args+ret) while the user runs the plan §0
protocol (door-use at range, use-while-facing-away, monster chase, outrun). A
`heading_diff` arg3+ST0 log during a TurnLeft-direction TurnToHeading would
spot-check P3's mirror live — nice-to-have only.