InputSystem Changelog

1.0.0-preview.4 #

This release includes a number of Quality-of-Life improvements for a range of common problems that users have reported.

Added

• To aid in debugging issues, we've extended the system's event tracing and replay functionality to allow persisting and replaying arbitrary input event streams.
  • InputEventTrace now has APIs to persist the events to disk and to load them back in from previously persisted event streams. The same API can be used to persist in arbitrary C# Stream instances, not just in file streams.

    // Write.
    myTrace.WriteTo("file.inputtrace");
    
    // Read.
    InputEventTrace.LoadFrom("file.inputtrace");
    

  • InputEventTrace now has built-in replay functionality.

    myTrace.Replay().PlayAllFramesOneByOne();
    

  • The event trace in device windows of the Input Debugger has been extended with controls to save and load traces.
• We've added a new InputRecording sample which has a reusable MonoBehaviour component that can be used to capture and replay device activity.
• Keyboard now has a FindKeyOnCurrentKeyboardLayout method to look up key controls by their display names.
• Keyboards now have synthetic controls that combine left and right variants of modifier keys.
  • This means that you can bind to just "shift" now, for example, instead of having to bind to both "left shift" and "right shift".

    new InputAction(binding: "<Keyboard>/shift");
    

  • The controls are also available as properties on Keyboard.

    if (Keyboard.current.shiftKey.isPressed) /* ... */;
    
    // Is equivalent to:
    if (Keyboard.current.leftShiftKey.isPressed ||
        Keyboard.current.rightShiftKey.isPressed) /* ... */;
    

Actions

• PlayerInput now has a new Controls Changed event/message which is triggered when the control setup of the player changes (e.g. when switching control schemes).

      public void OnControlsChanged()
      {
          // Update UI display hints, for example...
      }
  

• We've added APIs to simplify turning bindings into strings suitable for display in UIs.

  // Takes things such as currently bound controls and active binding masks into account
  // and can handle composites.
  action.GetBindingDisplayString();
  

  • Related to this, custom binding composites can now be annotated with the new DisplayStringFormat attribute to control how composites as a whole are turned into display strings.

    [DisplayStringFormat("{button}+{stick}")]
    public class MyComposite : InputBindingComposite<Vector2>
    {
        [InputControl(layout = "Button")] public int button;
        [InputControl(layout = "Stick")] public int stick;
    }
    

• InputActionRebindingExtension.RebindingOperation has a new configuration method WithMatchingEventsBeingSuppressed which allows suitable input events to automatically be swallowed while a rebind is ongoing. This greatly helps with not having something else respond to input while a rebind is in progress.
• We've added two new samples:
  • Rebinding UI: Demonstrates how to create a rebinding screen using the Input System's APIs. The sample also includes a reusable prefab you can use directly in your projects to quickly put rebinding screens together.
  • In-Game Hints: Demonstrates how to show context-sensitive help that respects the current control scheme.

Changed

• The logic for resetting devices on focus loss has changed somewhat:
  • When focus is lost, all devices are forcibly reset to their default state. As before, a RequestResetCommand for each device is also sent to the backend but regardless of whether the device responds or not, the input state for the device will be overwritten to default.
  • Noisy controls are exempted from resets. The assumption here is that noisy controls most often represent sensor readings of some kind (e.g. tracking data) and snapping the values back to their default will usually
  • If Application.runInBackground is true, all devices that return true from InputDevice.canRunInBackground are exempted from resets entirely. This, for example, allows XR devices to continue running regardless of focus change.
  • This fixes problems such as keyboard keys getting stuck when alt-tabbing between applications (case 1206199).
• InputControlExtensions.GetStatePtrFromStateEvent no longer throws InvalidOperationException when the state format for the event does not match that of the device. It simply returns null instead (same as when control is found in the event's state).
• InputEventTrace instances are no longer disposed automatically from their finalizer but MUST be disposed of explicitly using Dispose().
  • This is to allow event traces to survive domain reloads. If they are disposed of automatically during finalizers, even if they survive the reload, the next GC will cause traces to be deallocated.

Actions

• InputActionRebindingExtensions.PerformInteractiveRebinding has been greatly enhanced to apply a wide range of default configurations to the rebind. This greatly reduces the need to manually configure the resulting rebind.

  // Start a rebind with the default configuration.
  myAction.PerformInteractiveRebinding().Start();
  

  • Pointer position input will be ignored by default.
  • If not a suitable binding target itself, <Keyboard>/escape will automatically be made to quit the rebind.
  • Events with control input not explicitly matching exclusions will now get suppressed. This prevents input actions from getting triggered while a rebind is in progress.
  • The expected control type is automatically adjusted if a part binding of a composite is targeted by the rebind (e.g. if the action expects a Vector2 but the part binding expects a Button, the rebind switches automatically to Button).
  • If the targeted binding is part of a control scheme, controls will automatically be restricted to match the device requirements of the control scheme. For example, if the binding belongs to a "Keyboard&Mouse" scheme that has <Keyboard> and a <Mouse> requirement, the rebind will ignore input on gamepads.
  • As before, you can always create a RebindingOperation from scratch yourself or wipe/alter the configuration returned by PerformInteractiveRebinding however you see fit.

• Control schemes can now handle ambiguity.
  • This means that, for example, you can now have one control scheme for generic gamepads and another control scheme specifically for PS4 controllers and the system will reliably pick the PS4 scheme when a PS4 controller is used and fall back to the generic gamepad scheme otherwise.
  • While this is exposed as a new score property on InputControlScheme.MatchResult, no code changes are necessary to take advantage of this feature.
• PlayerInput.active has been renamed to PlayerInput.inputIsActive to avoid ambiguities with GameObject activation.

Fixed

• InputUser in combination with touchscreens no longer throws InvalidOperationException complaining about incorrect state format.

• In a related change, InputControlExtensions.GetStatePtrFromStateEvent now works with touch events, too.

• Stack overflow in InputTestFixture.currentTime getter.
• Input that occurs in-between pressing the play button and the game starting no longer leaks into the game (case 1191342).
  • This usually manifested itself as large accumulated mouse deltas leading to such effects as the camera immediately jerking around on game start.
• Removing a device no longer has the potential of corrupting state change monitors (and thus actions getting triggered) from other devices.
  • This bug led to input being missed on a device once another device had been removed.
• TrackedDevice layout is no longer incorrectly registered as Tracked Device.
• Event traces in the input debugger are no longer lost on domain reloads.
• IndexOutOfRangeException being thrown when looking up controls on XR devices.

Actions

• Clicking the "Replace with InputSystemUIInputModule" button in the inspector when looking at StandaloneInputModule, the resulting operation is now undoable and will properly dirty the scene.