InputSystem Changelog

1.1.0 #

Changed

• Modified the fix that landed in 1.1-preview.3 for any given control being added to an action only once.
  • This caused a regression with some setups that, for example, bound the same control multiple times in a composite using processors to alter the value of the control.
  • Internally, a control is now again allowed to feed into the same action through more than one binding.
  • However, externally the control will be mentioned on the action's InputAction.controls list only once.
• Adding InputSystemUIInputModule from code now installs DefaultInputActions. This is equivalent to the default setup when adding the component in the editor (case 1259306).

  var go = new GameObject();
  go.AddComponent<EventSystem>();
  var uiModule = go.AddComponent<InputSystemUIInputModule>();
  // uiModule.actionsAsset now has a DefaultInputActions() asset assigned to it and the various
  // action references point to its actions.
  

  • InputSystemUIInputModule.UnassignActions has been added to remove all actions from the module en bloc.

  uiModule.UnassignActions();
  

Fixed

• Fixed an issue where mixing test cases based on InputTestFixture (using mocked InputSystem) and regular test cases (using real InputSystem) would lead to static state leaking between test cases causing random failures and unexpected/undefined behavior (case 1329015).
• Fixed InputSystemUIInputModule.AssignDefaultActions not assigning trackedDeviceOrientation and trackedDevicePosition.
• Fixed regression introduced by previous change where InputSystemUIInputModule would not disable actions correctly.
• Fixed InputAction.canceled not getting triggered reliably for InputActionType.PassThrough actions when InputSystem.ResetDevice was called.
• Fixed device resets (e.g. happening as part of focus changes) leading to only some actions bound to these devices getting cancelled instead of all of them.