ActionMap

Claims through the device rather than keeping its own set, so a claim made here is also gone from input.keyPressed and from the pad's own pressed. Two claim registers over one physical press is how a press gets acted on twice.

The larger of stick and keys, never the sum. A player holding a key while pushing the stick the same way is asking to go that way, once; adding the contributions would send them at twice the speed, which is the bug a naive merge ships with. What it costs: the two cannot be combined to exceed the rim, which is the intent. What would make it wrong: an action where two devices genuinely should add, and nothing has asked for one.

This is the reader for a direction. If the two axes are two separate controls — throttle and steering, pitch and roll — read them one at a time with axis, which does not normalise them against each other. See its note for what the joint normalisation cost one consumer.

vector is right for a direction and wrong for two controls, and the difference is not cosmetic. On foot the two axes are one direction, so a keyboard diagonal must be shortened to the rim or the player walks faster askew than straight ahead — that is what vector is for and it should stay the default. At a wheel the same two axes are throttle and steering, which are two separate controls that happen to share an action: normalising them together means a driver holding forward and left gets 0.707 of each and can never reach full lock while accelerating.

A consumer lost two weeks to this. The report was "the car does not turn and it is slow", the whole vehicle model was rewritten looking for it, and it was not in the vehicle model — it was Math.hypot three call frames away, doing exactly what it was written to do. They shipped four duplicate digital actions bound to the same keys to get around it.

The pad is unchanged either way: a stick already gives its two axes independently, so a caller driving with one reads the same numbers from both methods. The keyboard is where they part.

false where there is no pad, no actuator, or nothing to play. Never throws.

Reports rather than decides. A binding already serving another action is the interesting case in every rebinding screen there has ever been, and what to do about it is a product decision: steal it silently, warn, or refuse. A consumer that wants uniqueness enforced reads the return and rebinds back.

A diff rather than a snapshot, and this is the load-bearing decision. A snapshot freezes the map at the version that saved it: a game that later adds an action, or changes a default nobody had rebound, finds every returning player still on the old set with no way to tell a deliberate choice from a stale record. A diff means an untouched action always follows the current default and only real choices survive an update.

Through KeyValueStore because the engine calls no platform API a consumer might want to supply differently — the rule that put saves behind this seam.

An unreadable record is the defaults, reported once. A player whose stored bindings cannot be parsed should get a working game rather than a broken one, and should not have that decided silently — the same shape as every other refusal in this engine.