You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: Assets/Tests/InputSystem/CoreTests_Devices.cs
+2Lines changed: 2 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -24,6 +24,8 @@
24
24
usingVector2=UnityEngine.Vector2;
25
25
usingVector3=UnityEngine.Vector3;
26
26
27
+
////TODO: set display name from product string only for layout builders (and give them control); for other layouts, let the layout dictate the display name
28
+
27
29
////TODO: test that device re-creation doesn't lose flags and such
Copy file name to clipboardExpand all lines: Packages/com.unity.inputsystem/CHANGELOG.md
+15Lines changed: 15 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,6 +11,21 @@ however, it has to be formatted properly to pass verification tests.
11
11
12
12
### Changed
13
13
14
+
- We've changed the rules that govern how action phases have to progress:
15
+
*__This is a breaking change!__
16
+
- The primary effect is additional callbacks getting triggered.
17
+
*__Before__:
18
+
- There were no enforced rules about how an action would go through `InputAction.started`, `InputAction.performed`, and `InputAction.canceled`. Which of the callbacks were triggered and in what order depended on a number of factors, the biggest influencer of which were the different interactions that could be applied to actions (like `Press` or `Hold`).
19
+
- This made for unpredictable and frequently surprising results. In addition, it led to bugs where, for [example](https://issuetracker.unity3d.com/issues/input-system-ui-becomes-unresponsive-after-the-first-ui-button-press), adding a `Press` interaction to the `Click` action of `InputSystemUIInputModule` would cause the click state to get stuck because the click action would never cancel.
20
+
*__Now__:
21
+
- The system will now *always* trigger `InputAction.started` first. If this is not done explicitly, it happens implicitly.
22
+
- Likewise, the system will now *always* trigger `InputAction.canceled` before going back to waiting state. Like with `InputAction.started`, if this isn't done explicitly, it will happen implicitly. This implies that `InputAction.canceled` no longer signifies an action getting aborted because it stopped after it started but before it performed. It now simply means "the action has ended" whether it actually got performed or not.
23
+
- In-between `InputAction.started` and `InputAction.canceled`, `InputAction.performed` may be triggered arbitrary many times (including not at all).
24
+
* While late in the cycle for 1.0, we've opted to make this change now in order to fix a range of bugs and problems we've observed that people encountered because of the previous behavior of the system.
25
+
- Related to the change above, the behavior of `PressInteraction` has been tweaked and now is the following:
26
+
*`Press Only`: Starts and immediately performs when pressed, then stays performed and cancels when button is released.
27
+
*`Release Only`: Starts when button is pressed and then performs and immediately cancels when the button is released.
28
+
*`Press And Release`: Starts and immediately performs when button is pressed, then stays performed and performs again and immediately cancels when button is released.
14
29
-`Vector2Composite` now has a `mode` parameter which can be used to choose between `DigitalNormalized` (the default), `Digital` (same as `DigitalNormalized` but does not normalize the resulting vector), and `Analog` (uses float input values as is).
15
30
*`Vector2Composite.normalize` has been deprecated. Note that it will not work together with `Analog`. The parameter will be removed in the future.
0 commit comments