Batch 52 · Shared player motor and session-owned movement input¶
2026-10-27. Starting HEAD d71649e6. Implementation 7df4717f precedes its separate documentation checkpoint. The existing game's Player facade and the shared-scene actor now use one PlayerMotor. The development character moves through the assigned Input System session, with physics, walking animation and existing empty-target facing. This is walking integration, not completed Player/AbilityHolder/combat or full F2.
Responsibilities¶
PlayerMotor owns observed input, Speed and LastHorizontalInput. It computes the same normalized walking velocity, walking-update/dash-intent result and stunned/dashing zero/preserve decisions. It has no input polling, scene lookup, resource mutation or target selection. Player forwards its existing public Speed/LastHorizontalInput API and retains its legacy InputManager adapter for production callers. Its existing Update order, targeting/facing, NoPassing callback, vitals/damage/status and feedback remain. ApplyMovementInput is the new facade entry for the driver; the original Movement uses the same motor. No prefab/meta identity or authored Rigidbody settings change, and motion remains in Update rather than FixedUpdate.
PlayerInputSession now owns one keyboard sampling history, independent of actor/run admission. Its existing SDK after-update hook advances that history once per Unity frame on dynamic updates, including Blocked contexts and intervals with no actor. ReadFrame may fill a not-yet-sampled frame but cannot advance the keyboard twice. Pause uses scaled delta; retry, context changes and scene reload do not reset the history. Device replacement/loss starts a neutral timeline. Public Blocked/Reward output still gates gameplay motion. A new read-only Movement field carries the filtered actor input alongside existing raw/pressure/button fields. Rebinding-history/focus behavior and held keys predating creation of a brand-new input owner remain acceptance questions, distinct from the verified held input within a continuing session.
GamepadMovementFilter applies the authored .19 dead zone and rescales each axis separately. The measured Linux SDL signed-16 endpoint is corrected before that rescale, only for the actual SDL interface on Linux. Non-SDL/other-platform values use the standard normalized domain; physical devices and Windows still require their own comparisons. This does not use the SDK's default radial stick processor or proportional walking. Analog input changes remain observable with timeScale 0, unlike the frozen keyboard smoothing.
PlayerMovementDriver owns one command-frame read per Update, passes its Movement through Player's motor facade, and retains LastCommands for later capability consumers. It does not execute Dash/Stats/Pause buttons. Actor preparation can explicitly add this module while inactive; activation enables only this driver and the root Rigidbody2D, keeping Player/AbilityHolder/weapon/collector/ScreenBounds behaviours quarantined. The prepared character's dash-speed primitive supplies the existing dash-intent output; no dash admission, spending or ability execution is enabled. Release disables movement and clears body velocity before destroying owned objects/materials. Disabling MonoBehaviours does not guarantee suppression of Unity physics callbacks; collision/collectible ownership is still an integration gate. The development launcher opts into movement; the existing inert participant mode remains for lifecycle-only checks. It does not turn the runtime Scene asset into serialized development content.
Original and live input evidence¶
Before editing Player movement, a guarded Linux graphical Editor process creates one owned uinput virtual Xbox-layout pad, records actual legacy joystick/GetAxis and unprocessed SDK axes, and removes the device afterward. All 48 controlled phases complete: 6,506 observations, exit0 in 92.883s. The earlier keyboard reference remains byte-preserved. New LegacyGamepadReference.json retains 34 distinct original analog pairs and original source/Player hashes, SHA256 68e0e6e94ba715b1c7ca4f79cb387fd8c19698e5a213c263c8c34c1f01e1fa50. Sweeps include positive/negative X/Y, dead-zone edge, diagonals, endpoints and paused changes. Character inactivity/held reactivation confirms that engine axes advance without Player.Movement calls.
The first session-wired trial exposed a wrong backend selector: the actual pad reports SDL rather than Linux. Its 6,440 samples contain 3, 691 analog differences and are excluded from passing evidence. Selecting the observed Linux SDL path repairs it. The final identical 48-phase comparison records 6,379 observations with zero differences between actual session and legacy keyboard/joystick axes, including inactive actors and pause; exit0 in 59.138s. This is OS-backed virtual-input evidence, not physical-controller or Windows qualification. All owned virtual-device handles close and no joystick node remains.
Checks¶
MotorRunChecks passes 10/10 headless groups, exit0 in 45.554s. It compares every original 2,967 keyboard/motor state boundary exactly against both the pure motor and actual Player facade; compares all 34 original analog pairs; and exercises real shared-scene physics, animation/facing, isolated scripts, pre-activation input, held retry, paused/released resume, independent keyboard/pad actors, loss neutrality, context gating and actual scene reload with retained external session identity. The development launcher remains scene-owned and disposes its session when unloaded; persistent production session composition is not completed by that fixture. Original stun/dash flags/velocities are supplied for the comparison; this is not executed dash-ability or collision acceptance.
GPU run passes 11/11, exit0 in 36.163s, including real before/after render requests. Inspected private PNGs show the actual Soldier/gun moving right, with an observed position change; no test-only player implementation. The fixed capture delta in these deterministic scene checks is not performance or real movement-feel evidence. The original keyboard/input/character regressions pass 9/9 + 8/8 + 22/22, exits0 in 35.759s/29.360s/35.113s. The GPU run predates the SDL selector correction but its synthetic-device path and motor are unchanged; the later actual SDL comparison and regression compilations verify the corrected current branch. Accepted logs contain no exception heading. The build retains the same CS8785 generator warning seen in batch50; graphical Editor checks retain the unavailable Windows BuildProfile type warning. No warning-free claim. Earlier endpoint-selector trial is retained privately and is not a shipped-game defect claim.
Linux x64 IL2CPP build exits0 in 828.133s, reviewed dirty source d71649e6, Editor 6000.2.8f1, target StandaloneLinux64. DevelopmentPlayerRun and the capture/check classes are absent from its managed assembly. The new shared actor's assigned-input path is Editor-verified; the native probe uses production scenes' legacy input adapter plus the new common motor.
A guarded 1280×720 native process reaches Soldier/Knight Meadow/Normal with original 100/150 HP, 100 stamina, damage 10/16 and movement 2.80/2.60. Timer advances 00:04→00:37 with enemies/shots/drops and score 1→33, then natural level-up pauses the game at 00:37 across repeated inspected frames. The first D/Up attempt landed in reward selection and is explicitly excluded from movement evidence. Actual Space/Slash confirm distinct Reload Speed/Skill Amplification picks; Soldier reload display changes 2.50→2.00s and Knight skill amplification 10→35. Play resumes 00:39→00:42→00:45, score 35→38→41. A fresh held D moves Soldier relative to Knight, then Up moves Knight upward relative to Soldier; inspected screenshots show both independent moves. This is a compatibility smoke, not a movement-feel/performance measurement or full co-op/reward acceptance.
Pause → actual Main Menu Yes returns; actual Quit Yes exits normally, exit0 after 320.740s. That lifetime includes inspection and a long paused reward interval; it is not startup/freeze evidence. One Arena-start and two menu-initialized markers, no exception heading, zero traced config-write begins and byte-identical temporary config. The player used a child-only XDG profile copied from the earlier isolated test profile, not normal game data. Full runs/death/revive, new combat, physical pads and Windows remain unverified.
Preservation and remaining work¶
Private capture /tmp/tinychaos-batch52-preserve-1613012ec9/ retains 7,763 pre-existing project files and 8,181 profile hashes with recoverable bytes. All 7,755 captured project files outside the eight intended source edits match exactly; ten added source/reference/metadata files match the manifest. Of 105 prior rebuild paths, 97 stay byte-identical. The immutable selected baseline stays 600/608 with the same eight earlier exceptions. All scenes, prefabs, build lists, authored definitions, other settings and old metadata remain unchanged.
Attributed Linux-toolchain package changes, generated Addressables link/meta and Editor layout were archived and their original absence/bytes restored. Shared prefs changed five existing session/GameView keys and added 36 graphical-Editor defaults; normal game prefs changed only four Unity session/connection keys. After all owned Editors/player exited, exact original preferences were restored; normal game's one prefs file/membership is unchanged. Other external engine logs/licensing/cache/layout bookkeeping has 7 changed, 6 added, 0 removed files; the whole profile tree is not claimed unchanged. Unresolved audio deletions and untracked Linux.meta are preserved. Raw traces, logs, images, virtual-device helpers, profiles and build artifacts remain private/outside Git.
Inventory now covers 270 scripts, preserving 258 prior rows, updating eight and adding four. Six MI gates append to 158 prior rows; all 27 workstream follow-ups remain open. Original authored/source CSVs and legacy input-consumer membership remain unchanged. Documentation validation resolves all 888 local links and routes each of 53 issues once. Implementation and evidence are separate commits.
No source baseline is repinned. Full movement/collision/bounds/camera integration, active vitals/stats, dash resources/hooks, AbilityHolder, attack/target receivers, enemies/stages/rewards, full content and UI/services remain open. New setup/rebinding/four-player layouts, Tutorial and dedicated GAME-01 work remain deferred. Continue through the R3 capability owners without enabling the old manager chain inside the shared scene. Finish current motion consumers and health/stamina/stat ownership before concrete abilities. Existing native scenes still use their legacy input adapter; full production Input System rollout is not claimed from this development actor.