erik/acdream
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1

docs: R5-V5 facade pickup prompt for the next session

Browse source 
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-07-05 10:32:52 +02:00
parent 6fd60b4e66
commit 6feaab91e3
1 changed files with 57 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

57
docs/research/2026-07-04-r5v5-facade-pickup-prompt.md Normal file
View file

@ -0,0 +1,57 @@
# Pickup prompt — R5-V5: MovementManager facade (paste into a fresh session)
Read `docs/research/2026-07-03-r5-managers/r5-wiring-handoff.md` first (the
§V4 status note + the facade paragraph are the SSOT), then
`docs/research/2026-07-03-r5-managers/r5-movementmanager-decomp.md` (the
retail struct + method inventory is already decompiled — do NOT re-decompile).
Then implement R5-V5.
**Context:** the R5 arc is one slice from done. Shipped + user-gated
2026-07-04: V3 sticky melee (#171, three slices `5bd2b8bc`/`7a823176`/
`69966950` — TS-39 retired, TS-43/TS-44/AP-82 added) and the V4 behavioral
items (`f423884b` — head style-on-change for all movement types, #164
action-replay Autonomous bit, mt-0 wire flags 0x1 stick_to_object / 0x2
StandingLongJump). Worktree `vigorous-joliot-f0c3ad`, branch
`claude/vigorous-joliot-f0c3ad`.
**The slice (STRUCTURAL — zero behavior change):** retail gives every
entity ONE `MovementManager` (acclient.h; decomp 0x00524xxx) that owns the
`motion_interpreter` + `moveto_manager` the R4/R5 work ported. acdream
carries them as loose per-entity objects (`RemoteMotion.Motion`/`.MoveTo`,
`PlayerMovementController.Motion`/`.MoveTo`) wired by hand at three sites
(`EnsureRemoteMotionBindings`, `EnterPlayerModeNow`, the harness). Build the
owner class in `src/AcDream.Core/Physics/Motion/MovementManager.cs`:
1. Owns MotionInterpreter + MoveToManager (lazy `MakeMoveToManager` per
retail 0x005245b3) + the relay methods whose call shapes are already in
the decomp doc: `UseTime` (minterp → moveto order), `HitGround` (minterp
FIRST then moveto — 0x00524300, already wired inline at 3 sites),
`HandleExitWorld`, `CancelMoveTo`, `HandleUpdateTarget` (→ moveto).
2. Repoint the three wiring sites to construct/hold ONE MovementManager per
entity; the existing seam bindings (sinks, StickTo/Unstick,
UnstickFromObject, PositionManager handoff) move onto/through it
unchanged. GameWindow keeps the wire unpack (Core.Net types stay out of
Core.Physics).
3. Do NOT reshuffle the per-tick order (TS-42's documented inversion is R6
scope, not this slice), do NOT touch the #170/#171 gate-passed machinery,
do NOT absorb RouteServerMoveTo/the routing heads into Core.
**Acceptance:** `dotnet build` + full `dotnet test` green with the
183-case/funnel/moveto/chase/sticky suites UNMODIFIED (a structural slice
that needs a test edit is a red flag — stop and reassess). Register: no new
rows expected; update row source columns that name the old wiring shape.
No visual gate needed (zero behavior change) — but launch once and confirm
a creature still chases + a door still opens before calling it done.
**After this slice:** the R5 arc is DONE — update the roadmap/milestones
line, write the arc close-out in the wiring handoff, then return to M1.5's
critical path (#137 dungeon collision, #138 teleport-OUT, A7 lighting).
**Gotchas:** revert-prone area — structural moves only, no "while I'm
here" improvements; the three wiring sites are load-bearing and
comment-dense (keep the retail-anchor comments with the code they
describe); the harness (`RemoteChaseEndToEndHarnessTests`) mirrors
GameWindow's wiring field-for-field — update its construction to the
facade in the SAME commit or the mirror lies; PowerShell Tee logs are
UTF-16 (`tr -d '\000'` before grep); the user manages client lifecycle
(graceful close; if a rebuild is locked by a running client, ask).