public sealed class InputUpdateSystemReads the frame's input into every registered action asset.
No guide page documents this yet — the page shows what the code says about itself.
As a system
- Phase
- Input
Remarks
Runs in Input, which exists for this. SystemPhase's own documentation gives the reason the phase is named rather than derived: "input must be read before anything reacts to it", and that ordering is not something a dependency graph over component types can see. So this system is the phase's only occupant in a default engine, and everything that reads an action runs in a later one.
It reads no components and writes none. An action asset is not world state — it is one object per player, read by whatever wants it — so there is nothing here for the runner's conflict analysis to serialise on, and a game's own systems parallelise freely around it.
What it does not do is pump the platform. The host drains the OS event queue and submits what it found to the InputService before the frame's phases run; this turns the state that arrived into actions. Splitting it there is what lets a determinism test replay a recorded input log through the same system with no platform underneath it at all.
Methods (2)
public InputUpdateSystem(InputService input)Reads the frame's input into every registered action asset.
public override JobHandle Update(in SystemContext context, JobHandle dependency)Runs the system.
Used by (3)
- MouseCaptureSystemThirdPersonShooter
- AppBuilderVixen.App.Hosting
- PlayerInputSystemVixen.Engine