Class InputSettings
Project-wide input settings.
Inherited Members
Namespace: UnityEngine.InputSystem
Syntax
public class InputSettings : ScriptableObjectRemarks
Several aspects of the input system can be customized to tailor how the system functions to the specific needs of a project. These settings are collected in this class. There is one global settings object active at any one time. It can be accessed and set through settings.
Changing a setting on the object takes effect immediately. It also triggers the onSettingsChange callback.
Properties
compensateForScreenOrientation
If true, sensors that deliver rotation values on handheld devices will automatically adjust rotations when the screen orientation changes.
Declaration
public bool compensateForScreenOrientation { get; set; }Property Value
| Type | Description |
|---|---|
| Boolean |
Remarks
This is enabled by default.
If enabled, rotation values will be rotated around Z. In Portrait, values remain unchanged. In PortraitUpsideDown, they will be rotated by 180 degrees. In LandscapeLeft by 90 degrees, and in LandscapeRight by 270 degrees.
Sensors affected by this setting are Accelerometer, Compass, and Gyroscope.
See Also
defaultButtonPressPoint
The default value threshold for when a button is considered pressed. Used if no explicit thresholds are set on parameters such as pressPoint or pressPoint.
Declaration
public float defaultButtonPressPoint { get; set; }Property Value
| Type | Description |
|---|---|
| Single | Default button press threshold. |
Remarks
In the input system, each button constitutes a full floating-point value. Pure toggle buttons, such as buttonSouth for example, will simply alternate between 0 (not pressed) and 1 (pressed). However, buttons may also have ranges, such as leftTrigger for example. When used in a context where a clear distinction between pressed and not pressed is required, we need a value beyond which we consider the button pressed.
By setting this property, the default value for this can be configured. If a button has a value equal to or greater than the button press point, it is considered pressed.
The default value is 0.5.
Lowering the button press point will make triggers feel more like hair-triggers (akin to using the hair-trigger feature on Xbox Elite controllers). However, it may make using the directional buttons (i.e. up etc) be fickle as solely moving in only one direction with sticks isn't easy. To counteract that, the button press points on the stick buttons can be raised.
Another solution is to simply lower the press points on the triggers specifically.
InputSystem.RegisterLayoutOverride(@"
{
""name"" : ""HairTriggers"",
""extend"" : ""Gamepad"",
""controls"" [
{ ""name"" : ""leftTrigger"", ""parameters"" : ""pressPoint=0.1"" },
{ ""name"" : ""rightTrigger"", ""parameters"" : ""pressPoint=0.1"" }
]
}
");See Also
defaultDeadzoneMax
Default value used when nothing is set explicitly on max or UnityEngine.InputSystem.Processors.AxisDeadzoneProcessor.max.
Declaration
public float defaultDeadzoneMax { get; set; }Property Value
| Type | Description |
|---|---|
| Single | Default upper limit for deadzones. |
Remarks
"Deadzones" refer to limits established for the range of values accepted as input on a control. If the value for the control falls outside the range, i.e. below the given minimum or above the given maximum, the value is clamped to the respective limit.
This property configures the default upper bound of the value range.
Note that deadzones will by default re-normalize values after clamping. This means that inputs at the lower and upper end are dropped and that the range in-between is re-normalized to [0..1].
Note that deadzones preserve the sign of inputs. This means that both the upper and the lower deadzone bound extend to both the positive and the negative range. For example, a deadzone max of 0.95 will clamp values of >0.95 and <-0.95.
The most common example of where deadzones are used are the sticks on gamepads, i.e. leftStick and rightStick. Sticks will usually be wobbly to some extent (just how wobbly varies greatly between different types of controllers -- which means that often deadzones need to be configured on a per-device type basis). Using deadzones, stick motion at the extreme ends of the spectrum can be filtered out and noise in these areas can effectively be eliminated this way.
The default value for this property is 0.925.
See Also
defaultDeadzoneMin
Default value used when nothing is set explicitly on min or UnityEngine.InputSystem.Processors.AxisDeadzoneProcessor.min.
Declaration
public float defaultDeadzoneMin { get; set; }Property Value
| Type | Description |
|---|---|
| Single | Default lower limit for deadzones. |
Remarks
"Deadzones" refer to limits established for the range of values accepted as input on a control. If the value for the control falls outside the range, i.e. below the given minimum or above the given maximum, the value is clamped to the respective limit.
This property configures the default lower bound of the value range.
Note that deadzones will by default re-normalize values after clamping. This means that inputs at the lower and upper end are dropped and that the range in-between is re-normalized to [0..1].
Note that deadzones preserve the sign of inputs. This means that both the upper and the lower deadzone bound extend to both the positive and the negative range. For example, a deadzone min of 0.1 will clamp values between -0.1 and +0.1.
The most common example of where deadzones are used are the sticks on gamepads, i.e. leftStick and rightStick. Sticks will usually be wobbly to some extent (just how wobbly varies greatly between different types of controllers -- which means that often deadzones need to be configured on a per-device type basis). Using deadzones, stick motion at the extreme ends of the spectrum can be filtered out and noise in these areas can effectively be eliminated this way.
The default value for this property is 0.125.
See Also
defaultHoldTime
Declaration
public float defaultHoldTime { get; set; }Property Value
| Type | Description |
|---|---|
| Single |
defaultSlowTapTime
Declaration
public float defaultSlowTapTime { get; set; }Property Value
| Type | Description |
|---|---|
| Single |
defaultTapTime
Default time (in seconds) within which a press and release has to occur for it to be registered as a "tap".
Declaration
public float defaultTapTime { get; set; }Property Value
| Type | Description |
|---|---|
| Single | Default upper limit on press durations for them to register as taps. |
Remarks
A tap is considered as a quick press-and-release on a button-like input control. This property determines just how quick the press-and-release has to be, i.e. what the maximum time is that can elapse between the button being pressed and released again. If the delay between press and release is greater than this time, the input does not qualify as a tap.
The default tap time is 0.2 seconds.
filterNoiseOnCurrent
Whether to not make a device .current (see MakeCurrent())
when there is only noise in the input.
Declaration
public bool filterNoiseOnCurrent { get; set; }Property Value
| Type | Description |
|---|---|
| Boolean | Whether to check input on devices for noise. |
Remarks
This is disabled by default.
When toggled on, this property adds extra processing every time input is received on a device that is considered noisy. These devices are those that have at least one control that is marked as noisy. A good example is the PS4 controller which has a gyroscope sensor built into the device. Whereas sticks and buttons on the device require user interaction to produce non-default values, the gyro will produce varying values even if the device just sits there without user interaction.
Without noise filtering, a PS4 controller will thus continually make itself current as it will send a continuous stream of input even when not actively used by the player. By toggling this property on, each input event will be run through a noise mask. Only if state has changed outside of memory areas marked as noise will the input be considered valid user interaction and the device will be made current. Note that in this process, the system does not determine whether non-noisy controls on the device have actually changed value. All the system establishes is whether such controls have changed state. However, processing such as for deadzones may cause values to not effectively change even though the non-noisy state of the device has changed.
See Also
multiTapDelayTime
Declaration
public float multiTapDelayTime { get; set; }Property Value
| Type | Description |
|---|---|
| Single |
supportedDevices
List of device layouts used by the project.
Declaration
public ReadOnlyArray<string> supportedDevices { get; set; }Property Value
| Type | Description |
|---|---|
| ReadOnlyArray<String> |
Remarks
This would usually be one of the high-level abstract device layouts. For example, for
a game that supports touch, gamepad, and keyboard&mouse, the list would be
{ "Touchscreen", "Gamepad", "Mouse", "Keyboard" }. However, nothing prevents the
the user from adding something a lot more specific. A game that can only be played
with a DualShock controller could make this list just be { "DualShockGamepad" },
for example.
In the editor, we use the information to filter what we display to the user by automatically filtering out irrelevant controls in the control picker and such.
The information is also used when a new device is discovered. If the device is not listed as supported by the project, it is ignored.
The list is empty by default. An empty list indicates that no restrictions are placed on what devices are supported. In this editor, this means that all possible devices and controls are shown.
See Also
tapRadius
Declaration
public float tapRadius { get; set; }Property Value
| Type | Description |
|---|---|
| Single |
updateMode
Determine how the input system updates, i.e. processes pending input events.
Declaration
public InputSettings.UpdateMode updateMode { get; set; }Property Value
| Type | Description |
|---|---|
| InputSettings.UpdateMode | When to run input updates. |
Remarks
By default, input updates will automatically be triggered as part of the player loop.
If updateMode is set to ProcessEventsInDynamicUpdate
(the default), then right at the beginning of a dynamic update (i.e. before all
MonoBehaviour.Update methods are called), input is processed. And if updateMode
is set to ProcessEventsInFixedUpdate, then right at the beginning
of each fixed update (i.e. before all MonoBehaviour.FixedUpdate methods are
called), input is processed.
Additionally, if there are devices that need updates right before rendering (see updateBeforeRender), an extra update will be run right before
rendering. This special update will only consume input on devices that have
updateBeforeRender set to true.
You can run updates manually using Update(). Doing so
outside of tests is only recommended, however, if updateMode is set to
ProcessEventsManually (in which case it is actually required
for input to be processed at all).
Note that in the editor, input updates will also run before each editor update
(i.e. as part of EditorApplication.update). Player and editor input state
are kept separate, though, so any input consumed in editor updates will not be visible
in player updates and vice versa.