PlayerInputSystem

Remarks

Runs in Input, after InputUpdateSystem. That system advances the action assets from the device state the host submitted; this one reads the result. The ordering is an UpdateAfterAttribute rather than a phase of its own because both belong to the phase whose documented job is "devices are polled and input state is published" — and because a game that replaces InputUpdateSystem with something of its own still wants this to run after whatever it replaced it with.

The sources are a side table, not components. An InputActions asset is a managed object per player; putting it in a chunk would make every player archetype hold a reference and would put a managed field on the path a rollback copies. So a controller is registered with Bind and the system walks its own list — which is also what makes this testable with no world, no devices and no platform.

A controller that is not accepting input has its intent cleared, not frozen. A player who was sprinting when a menu opened should not still be sprinting behind it, and a held jump that survives a cutscene fires on the frame it ends. The aim is left exactly where it was, because that is the thing the controller exists to preserve.

Fields and properties (2)

• public SystemAccess Access
• public int Count

  How many controllers have a source.

Methods (4)

• public void Bind(Entity controller, IPlayerInputSource source)

  Says where one controller's intent comes from.

• public bool Unbind(Entity controller)

  Takes a controller's source away, leaving it with its last intent cleared.

• public override JobHandle Update(in SystemContext context, JobHandle dependency)

  Runs the system.

• public void Sample(World world, float deltaTime)

  Samples every bound controller.

Used by (5)

• PlayerRigThirdPersonShooter
• PlayerAllocationTestsVixen.Engine.Tests
• PlayerInputQuantizeSystemVixen.Net.Engine
• PlayerInputTestsVixen.Engine.Tests
• PossessionSystemVixen.Engine