Class InputSettings
Project-wide input settings.
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
backgroundBehavior
When Application.runInBackground is true, this property determines what happens when application focus changes
(see Application.isFocused) changes and how we handle
input while running the background.
Declaration
public InputSettings.BackgroundBehavior backgroundBehavior { get; set; }Property Value
| Type | Description |
|---|---|
| InputSettings.BackgroundBehavior | What to do with input while not having focus. Set to ResetAndDisableNonBackgroundDevices by default. |
Remarks
If Application.runInBackground is false, the value of this property is ignored. In that case, nothing happens when
focus is lost. However, when focus is regained, TrySyncDevice(InputDevice) is called on all devices.
Note that in the editor as well as in development standalone players, Application.runInBackground will effectively always be
turned on. The editor keeps the player loop running regardless of Game View focus for as long as the editor is active and in play mode
and development players will implicitly turn on the setting during the build process.
See Also
buttonReleaseThreshold
The percentage of defaultButtonPressPoint at which a button that was pressed is considered released again.
Declaration
public float buttonReleaseThreshold { get; set; }Property Value
| Type | Description |
|---|---|
| Single |
Remarks
This setting helps avoid flickering around the button press point by introducing something akin to a "dead zone" below defaultButtonPressPoint. Once a button has been pressed to a magnitude of at least defaultButtonPressPoint, it is considered pressed and keeps being considered pressed until its magnitude falls back to a value of or below buttonReleaseThreshold percent of defaultButtonPressPoint.
This is a percentage rather than a fixed value so it allows computing release points even when the press point has been customized. If, for example, a PressInteraction sets a custom pressPoint, the respective release point can still be computed from the percentage set here.
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
Sensors affected by this setting are Accelerometer,
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.
Any value will implicitly be clamped to 0.0001f as allowing a value of 0 would
cause all buttons in their default state to already be pressed.
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
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
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.
See Also
disableRedundantEventsMerging
Disables merging of redundant input events (at the moment, only mouse events). Disable it if you want to get all events.
Declaration
public bool disableRedundantEventsMerging { get; set; }Property Value
| Type | Description |
|---|---|
| Boolean |
Remarks
When using a high frequency mouse, the number of mouse move events in each frame can be very large, which can have a negative effect on performance. To help with this, merging events can be used which coalesces consecutive mouse move events into a single input action update.
For example, if there are one hundred mouse events, but they are all position updates with no clicks, and there is an input action callback handler for the mouse position, that callback handler will only be called one time in the current frame. Delta and scroll values for the mouse will still be accumulated across all mouse events.
editorInputBehaviorInPlayMode
Determines how player focus is handled in the editor with respect to input.
Declaration
public InputSettings.EditorInputBehaviorInPlayMode editorInputBehaviorInPlayMode { get; set; }Property Value
| Type | Description |
|---|---|
| InputSettings.EditorInputBehaviorInPlayMode |
Remarks
This setting only has an effect while in play mode (see Application.isPlaying). While not in play mode, all input is invariably routed to the editor.
The editor generally treats Game View focus as equivalent to application focus (see Application.isFocused).
In other words, as long as any Game View has focus, the player is considered to have input focus. As soon as focus is transferred to a non-Game View
EditorWindow or the editor as a whole loses focus, the player is considered to have lost input focus.
However, unlike in built players, the editor will keep running the player loop while in play mode regardless of whether a Game View is focused or not. This essentially equates to Application.runInBackground always being true in the editor.
To accommodate this behavior, this setting determines where input is routed while the player loop is running with no Game View being focused. As such, it also dictates which input reaches the editor (if any) while the game is playing.
See Also
filterNoiseOnCurrent
Currently: Option is deprecated and has no influence on the system. Filtering on noise is always enabled.
Previously: 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 |
Remarks
We add 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
iOS
iOS/tvOS-specific settings.
Declaration
public InputSettings.iOSSettings iOS { get; }Property Value
| Type | Description |
|---|---|
| InputSettings.iOSSettings |
Remarks
This is only accessible in the editor or in iOS/tvOS players.
maxEventBytesPerUpdate
Upper limit on the amount of bytes worth of InputEvents processed in a single Update().
Declaration
public int maxEventBytesPerUpdate { get; set; }Property Value
| Type | Description |
|---|---|
| Int32 |
Remarks
This setting establishes a bound on the amount of input event data processed in a single update and thus limits throughput allowed for input. This prevents long stalls from leading to long delays in input processing.
When the limit is exceeded, all events remaining in the buffer are thrown away (the InputEventBuffer is reset) and an error is logged. After that, the current update will abort and early out.
Setting this property to 0 or a negative value will disable the limit.
The default value is 5MB.
See Also
maxQueuedEventsPerUpdate
Upper limit on the number of InputEvents that can be queued within one
Update().
Note that this limit only applies while the input system is updating. There is no limit on the number of events that can be queued outside of this time, but those will be queued into the next frame where the maxEventBytesPerUpdate setting will apply.
The default value is 1000.
Declaration
public int maxQueuedEventsPerUpdate { get; set; }Property Value
| Type | Description |
|---|---|
| Int32 |
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.
See Also
Methods
SetInternalFeatureFlag(String, Boolean)
Enable or disable an internal feature by its name.
Declaration
public void SetInternalFeatureFlag(string featureName, bool enabled)Parameters
| Type | Name | Description |
|---|---|---|
| String | featureName | Name of the feature. |
| Boolean | enabled | Whether to enable or disable the feature. |
Remarks
This method is intended for experimental features. These must be enabled/disabled from code.
Setting or unsetting a feature flag will not be persisted in an .inputsettings file.