Batch 50 · Owned player preparation and shared-scene preview

2026-10-27. Starting HEAD e71376d9; implementation 7054e7a1 precedes this separate evidence commit; active R2 actor preparation. The shared Gameplay scene can now prepare/render an actual production player through the existing roster/session/run lifetime. This is an inert development preview; it is not completed gameplay, movement or combat migration. The scene asset remains a data-free host and stays outside the production build list.

Runtime ownership

PlayerActorRunParticipant validates the shared host, locked roster slot/character and the existing prepared input session. It copies current value-only CharacterModifiers, creates the production prefab under its own inactive root, binds explicit camera/material dependencies, resets the existing base activation state and creates the existing character weapon. Its host-owned coroutine executes the production stat iterator, settles the existing calculation after resources fill and reports preparation completion. Actor/weapon material instances, tasks, objects and input associations have explicit lifetime boundaries. Cancellation joins the task even when disabling the host stops Unity's coroutine; failure rolls back partial creation. Release destroys only this actor/root and its instantiated materials, preserving session/player identity for retry.

Entity's normal Awake/OnEnable paths delegate to the same extracted component-binding/base-reset methods. Explicit preparation can cache components before Awake and preserve its injected camera when the root later becomes active. Player's existing audio-service ApplyCharacter adapter still starts the same setup coroutine; PrepareCharacter exposes the underlying assembly/stat iterator for a host to drive while the actor is inactive. Character setup, stat calculations and the existing Player Update/movement/damage/resource methods retain their behavior. The four-slot inspector range matches the already approved slot capacity; it does not implement four-player gameplay or menus.

Activation currently exposes sprites/animators only. Legacy MonoBehaviours remain disabled, Rigidbody2D simulation stays off and automatic particles are suppressed. It does not run Player, AbilityHolder, collector, weapon attack, ScreenBounds or circular-weapon Update/Start/OnEnable behavior. The existing input source can be read by its owner but does not move this preview. A later migrated motor/capability owner must replace this blanket legacy isolation deliberately; enabling the old manager chain is not a completed migration. Death/revive, full active actor lifecycle, targeting/attacks and physical-input equivalence remain open.

Development launcher and authoring

Open Tiny Chaos → Development → Run Lifecycle Arena. Leave Prepare player preview selected before entering Play Mode; open the shared scene, enter Play Mode, choose a Character and explicitly select one connected keyboard/gamepad for P1. Start prepares/activates the preview; Stop/Reset release the actor while retaining the intended player/input identity. Closing the preview window disposes its session. Lifecycle-only mode and the prior static launcher entry points remain for the original F0 checks. Device selection uses device IDs rather than silently transferring an ordinal to another newly connected device.

The scene-owned development controller is compiled only under UNITY_EDITOR, outside the Editor folder so Unity can attach it in Editor Play Mode. It and its runtime-created preview light are not serialized into Gameplay.unity or referenced by production catalogs. The native assembly must exclude the controller. Silent footstep feedback is explicit; it does not construct normal audio/save/online services. The light's sorting-layer data is supplied before its deferred Awake rather than relying on inactive-object initialization order.

Recipe: use the canonical player prefab with owned modifier/mount and body/animator/renderer; select a real Character/weapon definition; provide the host camera/material, copied shop values and declared feedback/view dependencies; order roster → session → actor participants, await preparation, activate only the accepted run ID, and await Stop before disposing input. Do not create another PlayerInput user or copy a GameManager hierarchy for the fixture. Full authoring/receiver/encounter recipes continue in their owning contracts.

Verification

Final GPU/Play Mode run: 13/13 groups, exit0. It verifies inactive preparation, no legacy target subscriptions, explicit camera persistence, real command-source association without fake movement, cancel/disabled-host completion, feedback-failure rollback, invalid session/selection rejection, four independent prepared actors, device loss, three retries with stable user/player IDs, material destruction, actual scene reload, development duplicate Start/reset/disposal and value-only copy assumptions. Earlier final headless 12/12 also passes. The GPU request uses the installed URP implementation and produces /tmp/tinychaos-batch50-preview.png; inspection shows the actual Soldier/gun against the shared camera background. Its temporary capture zoom/target are restored. This is an inert render, not movement or attacks.

RunBatch49 passes 22/22 original-output/import/coroutine groups and the existing scene runner passes 7/7, both exit0. Player's Update-and-later code and Entity's damage/status code remain byte-preserved; the original base OnEnable reset body is unchanged inside its new callable method. The selected source baseline and authored CSVs are not regenerated.

Linux x64 IL2CPP build exits0 in 683.280 seconds, reviewed dirty source e71376d9, required Editor 6000.2.8f1, Standalone backend1. Its managed Assembly-CSharp contains neither DevelopmentPlayerRun nor ActorRunChecks, confirming fixture-controller exclusion. A guarded 1280×720 native process selects Soldier/Knight and reaches Meadow/Normal: health100/150, stamina100/100, damage10/16, movement2.80/2.60, separate gun/sword/HUD, ammo4/10 then8/10, timer00:05→00:11 and score3→5. A brief held D sample shows the existing movement/animation. Pause, actual Yes return and actual Yes application quit complete, exit0. One Arena-start and two menu-initialized markers, no exception heading and zero traced config-write begins; the temporary config remains byte-identical. Its 150.130-second lifetime includes focus/inspection time and is not startup/freeze or movement-feel evidence. Batch49 retains the earlier one-player/native setup scope. No stage completion, new actor-factory use in a shipping scene, reward/revive, physical gamepad or Windows validation is claimed. Logs, client screenshots, provenance and hashes remain private.

Initial fixture compilation tried to inspect an internal user field from the separate Editor assembly; it was corrected to query the SDK's public paired users. An early development controller in an Editor folder could not be attached; it moved to an Editor-guarded runtime file. A launcher failure then exposed Light2D's uninitialized sorting-layer array under an inactive environment; explicit sorting-layer assignment repairs the actual entry path. A headless-only Localization package toolbar exception is excluded from product evidence: the harness scopes its GameView toolbar preference off and restores both the previous value and key absence/existence, without patching the package. Earlier failing/setup trials remain private and are not counted as passing gameplay.

Preservation and remaining work

Private capture /tmp/tinychaos-batch50-preserve-a99299683a/ retains 7,749 pre-existing project files and 8,172 Unity/profile hashes with recoverable preferences. All 7,744 captured files outside the five intended source edits match exactly; six added source/metadata files match the candidate manifest. Of 89 prior rebuild paths, 86 remain byte-identical and only Player, input session and development window are intentionally updated. The immutable selected baseline stays at 600/608 matches with the same eight previously documented exceptions; new Entity/data seams are outside those selected pins. All scenes, build lists, other settings, authored definitions and old metadata remain as captured.

Reviewed Linux-toolchain package additions were archived and exact pre-run package bytes restored. No new Addressables link files remain or needed manual deletion. Shared prefs changed only two Editor session keys plus three GameView geometry keys from the GPU Editor; normal game prefs changed only four Unity session/connection keys. Generated copies were archived and exact captured preferences restored after all owned processes exited. The scoped Localization toolbar key/value also restores its original existence/value. The normal game's one prefs file is byte-identical and no normal game data files were added. External engine bookkeeping retains 5 changed, 6 added and 0 removed files; the full profile tree is not claimed unchanged. Audio deletions and the untracked Linux.meta are preserved. No owned Editor or candidate remains running.

Inventory now covers 263 scripts, preserves 255 earlier rows, updates five and adds three. Seven PA gates append to 148 prior rows (155 total); all 27 workstream follow-ups stay open. Input consumer membership and prior authored/source contracts remain unchanged. Documentation validation resolves all 871 local links, keeps all 53 issues routed once and confirms the implementation commit contains exactly the 11 reviewed source/metadata paths. Implementation and evidence are committed separately; raw logs/profiles and the rendered PNG are excluded from Git.

Next prove legacy-equivalent input sampling and give the prepared actor a real migrated motor/capability activation path, then vitals/stats and AbilityHolder. Passive target/combat receivers follow their real runtime contract. New rebinding/four-player menus and UI/UX remain deferred. GAME-01, complete released-content integration, physical devices and Windows qualification are not closed by the preview.