Commit graph

1 commit

Author SHA1 Message Date
Erik
1d2d4bb8bd docs: #317 velocity-chain audit — verdict NO RETAIL BASIS (report-only)
Report-only per CLAUDE.md's investigation rule; no fix applied and none
approved. The call at LiveEntityNetworkUpdateController.cs:2459 is
untouched.

Verdict: velocity is a SEPARATE WIRE CHANNEL in retail, and acdream's
accepted-Position path crosses it.

SmartBox::DoVectorUpdate 0x004521C0 is retail's sole velocity installer
for a remote (set_velocity 0x0045221E + set_omega 0x0045222C), gated on
update_times[3] = VECTOR_TS — not Position's update_times[0]. An
exhaustive grep of its call sites returns exactly two, and neither is the
Position path: SmartBox::HandleVectorUpdate 0x00453480 (call 0x004534E6)
and SmartBox::HandleCreateObject 0x00454C80 (call 0x00454EE9).
HandleReceivedPosition's only set_velocity is 0x004541B4, which ZEROES the
local player on the teleport arm.

Retail is not merely silent here, it is deliberate: PositionPack::UnPack
0x00516740 does decode a velocity off the Position wire (field written
0x005167E9) — retail receives the value and drops it on this path.

acdream instead commits acceptedSpawn.Physics?.Velocity on every accepted
Position, and the retail-correct mechanism ALREADY EXISTS one method away
(TryCommitAuthoritativeVector, whose doc comment describes DoVectorUpdate's
exact paired shape). The Position-path call is therefore both non-retail
and redundant with a correct sibling. Sharpening the divergence: the call
passes `?? Vector3.Zero`, so a Position without HasVelocity actively zeroes
the body — something retail never does on this path.

Recommended (NOT approved): either remove the call, or keep it and file a
register row as a deliberate adaptation in AP-135's class. Three unresolved
inputs decide which, listed in the report's section 5 — chiefly what
consumes body.Velocity for a remote (AP-80's velocity-derived animation
cycle is the specific unknown), and whether ACE sets HasVelocity at all. The
retail half of the audit is settled; those three are cheap follow-ups that
do not need the binary again.

Successor note: this function family carries Binary Ninja's dropped-flag
artifact (`-((eax_4 - eax_4))` at 0x004521F5 and 0x00452186), the same one
the C5b review hit in Gate A. Do not read a comparison here from pseudo-C.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-06 06:29:13 +02:00