Batch 58 · Assigned dash through player-owned ability work¶
2026-10-28 checkpoint. Starting HEAD 633304d0; implementation 56f764c9, separate from this documentation commit. Partial R3 composition, preserving gameplay rules rather than adding a new attack or input action.
Change¶
PlayerMovementDriver reads its command source once, applies movement, ticks the existing stamina/immunity rules and passes the same frame to PlayerDashController. Assigned dash uses the selected character and private ability owner, with explicit pause/effect/feedback dependencies. It retains active-dash, zero-direction, pause, cooldown and stamina admission. PlayerDashHooks shares the old ordered cost/perk/impulse/feedback rules; LegacyPlayerDashHooks supplies production's existing global adapters. The old production input path remains in use.
Opted-in preparation binds one scoped executor while the actor is inactive. Owned iterator cleanup completes only its own dash generation; an older cancelled action cannot clear a newer dash. Weapon-hide work uses the ability scope and restores its own weapon on cancellation. Actor disable clears phase and velocity and retires the owner's work. Device loss neutralizes future commands while retaining the player; it does not invent pause or cancellation of an already admitted timed effect. Life/revive retains its existing acquired-state/cooldown reset policy.
The development launcher enables dash, supplies a selected Character, scaled-pause read, preview AudioSource and transient dash count. Reload feedback uses the existing authored audio clip GUID. It does not create global game/session/audio/ability managers or publish progression counts. These are development adapters, not complete production audio/settings/progression integration. Other factory modes remain opt-in.
Only the resource clocks required by dash are activated: stamina recovery/delay and immunity countdown. Full health recovery, status/damage/life/run participation, stat mutation callers, targeting, attacks and concrete perk workers remain to compose. The shared actor keeps Player/AbilityHolder/weapon/collector legacy Update disabled. Existing concrete dash perks may still require global services; this batch does not qualify upgraded combinations or automatic character attacks there.
Lightweight evidence¶
Unity 6000.2.8f1, Linux64 headless. The final assigned-dash run exits 0 in 30.090 seconds, passing 15 new groups:
- Scoped completion/cancellation cannot clear a newer dash.
- All seven characters consume assigned keyboard dash with the original cost, checked impulse, completion, weapon restoration, stamina recovery and immunity expiry.
- Two assigned keyboard/gamepad players dash independently; held buttons do not repeat, and scaled pause holds active dash/cooldown work.
- Zero direction, insufficient stamina, reward context and paused input retain their gates; held confirmation/pause edges do not replay as dash.
- Actor disable retires work and restores weapon presentation; later device loss neutralizes input without transferring ownership.
That run also passes the prior 16 original cooldown cases, 14 ability ownership groups, shared-scene release/failure checks, seven character definition/weapon handoffs and launcher retry/disposal regression. Character attack effects are unexecuted: Wu Ran/Tiamra weapons and Zenova's special output remain preservation requirements, not qualified combat.
A separate regression exits 0 in 33.855 seconds, matching all 70 original dash + 14 shared status cases, plus eight dash ownership groups, actual death/revive retirement and stale-freeze-reset protection. Original references and their hashes remain unchanged. The new driver explicitly orders movement/resource/dash work; the old cross-component Update order was not certified. These controlled-delta/simulated-device checks establish state, arithmetic and lifecycle results, not wall-clock performance, physical input feel or native playthrough equivalence.
Earlier iterations corrected parameterless effect delegates and an Editor/runtime assembly access in the fixture. A recovery assertion initially sampled before the unchanged two-second stamina delay; it now awaits the actual condition within a bound. An intermediate passing run predates the added scoped-generation/pause/device checks; the final run above is authoritative. These development/check iterations do not establish new shipped-game bugs. Existing CS8785 generator warnings remain; accepted runs contain no C# errors or exception headings.
Preservation and continuation¶
All 7,815 original project files outside eight intended edits match captured bytes; eight source/metadata paths are added. Scenes, prefabs, authored data, existing metadata/settings/build lists and original comparison references remain unchanged. Auto-added Linux toolchain package entries and attributed session preferences were reviewed, archived and restored to original bytes. Normal game profile membership/hashes match the baseline. Six Unity service/tooling/license artifacts changed and were retained, including logs and licensing renewal; no claim is made that all Unity tooling state is unchanged. Unresolved audio deletions and generated Addressables Linux.meta remain excluded. Private logs/backups stay outside Git.
All 27 workstream follow-ups remain open. Continue remaining R3 simulation/lifecycle composition: health recovery, stat mutation callers, status/damage dependencies and explicit joined-player death/revive/run participation. Then use those owners for targeting/weapon/attack execution and concrete skills. No new native build or complete gameplay, physical-controller or Windows IL2CPP qualification was performed; batch 52 remains the latest native smoke. Dedicated main-menu freeze work, new menu/remap/four-player layouts and unrelated features remain deferred.