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
[Full source code](https://github.com/Unity-Technologies/InputSystem) for the input system is available on GitHub. This is also where most of our development happens.
6
4
7
5
>NOTE: This includes the full source code for the managed/C# part of the system. At this point, the native, platform-specific C++ backends are still closed-source and require a source code license.
8
6
9
-
## Creating PRs
10
-
11
7
## Reporting Bugs
12
8
13
-
## Feature Requests
9
+
Input System bugs should be reported through using [same mechanism as for any other Unity bugs](https://unity3d.com/unity/qa/bug-reporting). Make sure to submit a repro project, and to mention that the bug is specific to the Input System package in the description, so it can get forwarded to the correct respondents at Unity.
14
10
15
11
## Discussion
16
12
17
-
To ask questions or discuss the new input system, we have a [dedicated section on Unity's forum](https://forum.unity.com/forums/new-input-system.103/).
13
+
To ask questions or discuss the input system, we have a [dedicated section on Unity's forum](https://forum.unity.com/forums/new-input-system.103/). This is also the best place to post feature requests.
When something isn't working as expected, the best first stop is usually the "Input Debugger" in the Unity editor. This is a Unity editor window that is designed to provide access to the activity of the input system in both the editor and in connected players.
16
11
@@ -28,41 +23,45 @@ The debugger shows a tree breakdown of the state of the input system.
28
23
|Layouts|A breakdown of all registered control and device layouts. This is essentially the database of supported hardware and the knowledge of how to represent a given piece of input hardware.|
29
24
|Actions|Only visible in play mode and only if there are [actions](Actions.md) that are currently enabled.<br><br>Shows the list of all currently enabled actions and the controls they are bound to.<br><br>See [Debugging Actions](#debugging-actions).|
30
25
|Users|Only visible when there is one or more `InputUser` instances. See [documentation](UserManagement.md).<br><br>Lists all currently active uers along with their active control schemes and devices, all their associated actions as well as the controls they are bound to.<br><br>Note that `PlayerInput` uses `InputUser` underneath. This means that when using `PlayerInput` components, each player will have an entry here.<br><br>See [Debugging Users/PlayerInput](#debugging-usersplayerinput).|
31
-
|Settings||
32
-
|Metrics||
26
+
|Settings|Shows the currently active Input System [settings](Settings.md).|
27
+
|Metrics|Shows some statics about Input System resource usage.|
33
28
34
-
### Debugging Remotely
29
+
### Debugging Devices
35
30
36
-
You can connect input debugger to a player running on a device. This makes input activity from the player observable in the editor. The mechanism used by this is Unity's `PlayerConnection`, i.e. the same mechanism by which the Unity profiler can be connected to a player.
31
+
You can double-click on any [input device](Devices.md) in the `Devices` list in the debugger window to open a window showing information about the device, including real-time state information for its controls.
37
32
38
-
>NOTE: At the moment, debugging input in players is restricted to seeing devices and events from connected players. There is no support yet for seeing other input-related data from players.
33
+
IMAGE
39
34
40
-
////TODO: explain "Remote Devices"
35
+
The top of the device window shows some general information about the specific device (such as name, manufacturer, serial number, etc).
41
36
42
-
### Debugging Devices
37
+
Below that, you you see a view listing the devices controls, and their state. This is very useful when debugging input issues, as it allows you to verify if the data the input system is receiving from the input device is what you'd expect it to be in the first place. At the top of this view you will see the following buttons:
38
+
39
+
*`State`: Show the current state of the device in a new window. This is identical to the information as shown in this view, but is not updated, so you can take a slice of input state data and take the time to inspect it as needed.
40
+
41
+
*`HID Descriptor`: Only shown for devices connected using the HID protocol. This will open a window showing the detailed HID specifications for the device and each of it's logical controls.
43
42
44
-
>NOTE: For an alternative way to debug/visualize controls and/or devices, see [Visualizing Controls](#visualizing-controls).
43
+
Finally, in the bottom of the window, you can inspect the event stream coming from the device. Any [Input Event](Events.md) generated by the device will be shown here. You can double-click any event in the list to inspect the full device state at the time of the event.
45
44
46
45
### Debugging Actions
47
46
48
-
>NOTE: For an alternative way to debug/visualize actions, see [Visualizing Actions](#visualizing-actions).
47
+
Any active [actions](Actions.md) are listed in the Actions list in the debugger window (only shown if any actions are active and the editor is in play mode). If an action has actively bound controls, you can click the arrow next to the action to see them in the list. This is useful to debug whether your bindings correctly map to the controls you want them to bind to. See ["Binding Resolution"](ActionBindings.md#binding-resolution) for more info on how bindings are mapped to controls.
49
48
50
49
### Debugging Users/PlayerInput
51
50
52
-
When there are multiple `InputUser` instances – each `PlayerInput` will implicitly create one –, the debugger will list each user along with its paired devices and active actions.
51
+
When there are multiple `InputUser` instances – each `PlayerInput` will implicitly create one –, the debugger will list each user along with its paired devices and active actions. The listed devices and actions work the same way as those shown in the [devices](#debugging-devices) and [actions](#debugging-actions) lists in the debugging window.
53
52
54
53
IMAGE
55
54
56
-
##Input Visualizers
55
+
### Debugging Layouts
57
56
58
-
To debug specific problems it is often helpful to see activity over time and presented in graphical form.
57
+
The [`Layouts`](Layouts.md) list in the Debugger window shows a breakdown of all registered [control and device layouts](Layouts.md). This is essentially the database of supported hardware and the knowledge of how to represent a given piece of input hardware. This is mostly handy when you want to [create a new device mapping](HowDoI.md#-create-my-own-custom-devices), and want to see how it gets represented by the input system.
59
58
60
-
>NOTE: The input visualizer components are only available in the editor and in development players.
59
+
### Debugging Remotely
61
60
62
-
### Visualizing Controls
61
+
You can connect input debugger to a player running on a device. This makes input activity from the player observable in the editor. The mechanism used by this is Unity's `PlayerConnection`, i.e. the same mechanism by which the Unity profiler can be connected to a player.
63
62
64
-
### Visualizing Actions
63
+
>NOTE: At the moment, debugging input in players is restricted to seeing devices and events from connected players. There is no support yet for seeing other input-related data from players.
65
64
66
-
## Event Diagnostics
65
+
To see remote devices from built players, click the `Remote Devices…` pop-up button in the Debugger window. You will see a list of remote player instance you can connect to (if there are any) - this is the same list as you will see in the Profiler and Console windows, and any connections are share between those windows. If any player(s) are connected, you can enable `Show remote devices` in the same popup button. If players are connected, and `Show remote devices` is enabled, the [`Devices`](#debugging-devices) list in the debugger window will be split into a `Local` section and a `Remote` section. The `Remote` section will show any input device from any connected player, and lets you inspect device state and events in real time, just as if it were a local device.
67
66
68
-
In normal operation, the input system will silently discard any anomalous input it finds in the event stream. TODO
67
+
[//]: #(TODO: Mention ## Input Visualizers once we have decided on a location for our samples to link to)
Copy file name to clipboardExpand all lines: Packages/com.unity.inputsystem/Documentation~/Migration.md
-2Lines changed: 0 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -65,8 +65,6 @@ No corresponding API yet.
65
65
66
66
Use [`InputSystem.settings.compensateForScreenOrientation`](../api/UnityEngine.InputSystem.InputSettings.html#UnityEngine_InputSystem_InputSettings_compensateForScreenOrientation).
67
67
68
-
You will need to put a Compensate Direction processor or a Compensate Rotation processor to your actions for this to have any effect.
Use [`Keyboard.current.SetIMECursorPosition(myPosition)`](../api/UnityEngine.InputSystem.Keyboard.html#UnityEngine_InputSystem_Keyboard_SetIMECursorPosition_Vector2_).
Copy file name to clipboardExpand all lines: Packages/com.unity.inputsystem/Documentation~/Settings.md
+27-25Lines changed: 27 additions & 25 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,10 +1,10 @@
1
1
# Settings
2
2
3
-
The input system can be configured on a per-project basis by going to "Edit >> Project Settings..." and selecting "Input (NEW)".
3
+
The input system can be configured on a per-project basis by going to "Edit >> Project Settings..." and selecting "Input System Package".
4
4
5
5
6
6
7
-
Settings are stored in assets. To create a new asset, click "New" in the toolbar and choose a name and location for where to create an asset. A project may contain arbitrary many assets with input settings. To choose which asset is active, use the dropdown in the toolbar.
7
+
Settings are stored in assets. If your project does not contain an Input settings asset, you can click `Create settings asset`in the settings window to create one. If your project contains multiple settings assets, you can use the gear menu in the top right of the window to chose which one to use (or to create more of them).
8
8
9
9
>NOTE: Modifications to settings are saved when the project is saved.
10
10
@@ -18,43 +18,45 @@ There are three distinct ways in which the input system processes input.
18
18
19
19
|Type|Description|
20
20
|----|-----------|
21
-
|Fixed Update|Events are processed in intervals of fixed length. This corresponds to how [`MonoBehaviour.FixedUpdate`](https://docs.unity3d.com/ScriptReference/MonoBehaviour.FixedUpdate.html) operates. The length of each interval is determined by [`Time.fixedDeltaTime`](https://docs.unity3d.com/ScriptReference/Time-fixedDeltaTime.html).|
22
-
|Dynamic Update|Events are processed in irregular intervals governed by the current framerate.|
23
-
|Manual Update|Events are not processed automatically by instead are flushed out whenever the user calls `InputSystem.Update()`.|
21
+
|[`Fixed Update`](../api/UnityEngine.InputSystem.InputSettings.UpdateMode.html)|Events are processed in intervals of fixed length. This corresponds to how [`MonoBehaviour.FixedUpdate`](https://docs.unity3d.com/ScriptReference/MonoBehaviour.FixedUpdate.html) operates. The length of each interval is determined by [`Time.fixedDeltaTime`](https://docs.unity3d.com/ScriptReference/Time-fixedDeltaTime.html).|
22
+
|[`Dynamic Update`](../api/UnityEngine.InputSystem.InputSettings.UpdateMode.html)|Events are processed in irregular intervals governed by the current framerate.|
23
+
|[`Manual Update`](../api/UnityEngine.InputSystem.InputSettings.UpdateMode.html)|Events are not processed automatically by instead are flushed out whenever the user calls [`InputSystem.Update()`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_Update).|
24
24
25
-
>NOTE: There are two additional types of updates performed by the system in the form of `InputUpdateType.BeforeRender` (late update for XR tracking devices) and `InputUpdateType.Editor` (for EditorWindows) but these do not fundamentally alter how input is consumed in an application.
26
-
27
-
## Action Update Mode
28
-
29
-
>NOTE: This setting will only be visible if `Update Mode` is set to `Process Events In Both Fixed And Dynamic Update`.
30
-
31
-
If the system is configured to process input in both fixed and dynamic updates, `InputActions` need to know which input state to track. By default, actions will track fixed update state. By setting `Action Update Mode` to `Actions Update In Dynamic Update`, this can be changed so that actions track dynamic update state.
32
-
33
-
The key difference is that input state for dynamic updates is allowed to run ahead of input state for fixed updates.
34
-
35
-
## Timeslice Events
36
-
37
-
>NOTE: This setting is only visible if events are processed in fixed update, i.e. if `Update Mode` is either `Process Events In Both Fixed And Dynamic Update` or `Process Events In Fixed Update`.
38
-
39
-
This setting is enabled by default. ...
25
+
>NOTE: There are two additional types of updates performed by the system in the form of [`InputUpdateType.BeforeRender`](../api/UnityEngine.InputSystem.LowLevel.InputUpdateType.html) (late update for XR tracking devices) and [`InputUpdateType.Editor`](../api/UnityEngine.InputSystem.LowLevel.InputUpdateType.html) (for EditorWindows) but these do not fundamentally alter how input is consumed in an application.
40
26
41
27
## Filter Noise On Current
42
28
43
-
////REVIEW: should this be enabled by default
29
+
[//]: #(REVIEW: should this be enabled by default)
44
30
45
-
This setting is only relevant for a game that uses the various `.current` properties (like `Gamepad.current`) in the API. If these aren't used, it's recommended to leave this setting turned off (the default) as it will otherwise add needless overhead.
31
+
This setting is only relevant for a game that uses the various `.current` properties (like [`Gamepad.current`](../api/UnityEngine.InputSystem.Gamepad.html#UnityEngine_InputSystem_Gamepad_current)) in the API. If these aren't used, it's recommended to leave this setting turned off (the default) as it will otherwise add needless overhead.
46
32
47
-
Whenever there is input on a device, the system make the respective device `.current`. If, for example, a given `Gamepad` receives new input, it will assume the position of `Gamepad.current`.
33
+
Whenever there is input on a device, the system make the respective device `.current`. If, for example, a given [`Gamepad`](../api/UnityEngine.InputSystem.Gamepad.html) receives new input, it will assume the position of [`Gamepad.current`](../api/UnityEngine.InputSystem.Gamepad.html#UnityEngine_InputSystem_Gamepad_current).
48
34
49
35
However, some devices have noise in their input and thus need not be interacted with to receive input. An example is the PS4 DualShock controller which generates a constrant stream of input because of its built-in gyro. This means that if both an Xbox and a PS4 controller connected and the user is playing with the Xbox controller, the PS4 controller will still continuously push itself to the front and make itself current.
50
36
51
-
To counteract this, noise filtering can be enabled. If turned on, when input is received, the system will determine whether the input is for a device that has noisy controls (`InputDevice.noisy`). If it does, it will determine whether the given input contains any state change on a control that is __not__ marked as noisy (`InputControl.noisy`). If so, the device will become current. If not, the input will still be consumed (and visible on the device) but the device will not be made current.
37
+
To counteract this, noise filtering can be enabled. If turned on, when input is received, the system will determine whether the input is for a device that has noisy controls ([`InputControl.noisy`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_noisy)). If it does, it will determine whether the given input contains any state change on a control that is __not__ marked as noisy. If so, the device will become current. If not, the input will still be consumed (and visible on the device) but the device will not be made current.
52
38
53
39
>NOTE: The system does not currently detect other forms of noise, principally those on gamepad sticks. This means that if the sticks are wiggled a little bit (and on most gameapds this does not require actually actuating the sticks; there will be a small tolerance within which the sticks will move when the entire device is moved) but are still within deadzone limits, the device will still be made current.
54
40
55
41
## Compensate For Screen Orientation
56
42
57
-
## Tap Radius
43
+
If enabled, rotation values will be rotated around Z. In [`ScreenOrientation.Portrait`](https://docs.unity3d.com/ScriptReference/ScreenOrientation.html), values remain unchanged. In [`ScreenOrientation.PortraitUpsideDown`](https://docs.unity3d.com/ScriptReference/ScreenOrientation.html), they will be rotated by 180 degrees. In [`ScreenOrientation.LandscapeLeft`](https://docs.unity3d.com/ScriptReference/ScreenOrientation.html) by 90 degrees, and in [`ScreenOrientation.LandscapeRight`](https://docs.unity3d.com/ScriptReference/ScreenOrientation.html) by 270 degrees.
44
+
45
+
Sensors affected by this setting are [`Gyroscope`](../api/UnityEngine.InputSystem.Gyroscope.html), [`GravitySensor`](../api/UnityEngine.InputSystem.GravitySensor.html), [`AttitudeSensor`](../api/UnityEngine.InputSystem.AttitudeSensor.html), [`Accelerometer`](../api/UnityEngine.InputSystem.Accelerometer.html) and [`LinearAccelerationSensor`](../api/UnityEngine.InputSystem.LinearAccelerationSensor.html).
46
+
47
+
48
+
## Default Value Properties
49
+
50
+
|Property|Description|
51
+
|----|-----------|
52
+
|Default Deadzone Min|Default minimum value used for [Stick Deadzone](Processors.md#stick-deadzone) or [Axis Deadzone](Processors.md#axis-deadzone) processors when no min value is explicitly set on the processor|
53
+
|Default Deadzone Max|Default maximum value used for [Stick Deadzone](Processors.md#stick-deadzone) or [Axis Deadzone](Processors.md#axis-deadzone) processors when no max value is explicitly set on the processor|
54
+
|Default Button Press Point|The default [press point](../api/UnityEngine.InputSystem.Controls.ButtonControl.html#UnityEngine_InputSystem_Controls_ButtonControl_pressPointOrDefault) used for [Button controls](../api/UnityEngine.InputSystem.Controls.ButtonControl.html). For button controls which have analog physics inputs (such as triggers on a gamepad), this configures how far they need to be held down to be considered "pressed".|
55
+
|Default Tap Time|Default duration to be used for [Tap](Interactions.md#tap) and [MultiTap](Interactions.md#multitap) interactions. Also used by by Touch screen devices to distinguish taps from to new touches.|
56
+
|Default Slow Tap Time|Default duration to be used for [SlowTap](Interactions.md#tap) interactions.|
57
+
|Default Hold Time|Default duration to be used for [Hold](Interactions.md#hold) interactions.|
58
+
|Tap Radius|Maximum distance between two finger taps on a touch screen device allowed for the system to consider this a tap of the same touch (as opposed to a new touch).|
59
+
|Multi Tap Delay Time|Default delay to be allowed between taps for [MultiTap](Interactions.md#multitap) interactions. Also used by by touch devices to count multi taps (See [`TouchControl.tapCount`](../api/UnityEngine.InputSystem.Controls.TouchControl.html#UnityEngine_InputSystem_Controls_TouchControl_tapCount)).|
0 commit comments