/// The percentage of <see cref="defaultButtonPressPoint"/> at which a button that was pressed
/// is considered released again.
/// </summary>
/// <remarks>
/// This setting helps avoid flickering around the button press point by introducing something akin to a
/// "dead zone" below <see cref="defaultButtonPressPoint"/>. Once a button has been pressed to a magnitude
/// of at least <see cref="defaultButtonPressPoint"/>, it is considered pressed and keeps being considered pressed
/// until its magnitude falls back to a value of or below <see cref="buttonReleaseThreshold"/> percent of
/// <see cref="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 <see cref="Interactions.PressInteraction"/>
/// sets a custom <see cref="Interactions.PressInteraction.pressPoint"/>, the respective release point
/// can still be computed from the percentage set here.
/// </remarks>
publicfloatbuttonReleaseThreshold
{
get=>m_ButtonReleaseThreshold;
set
{
// ReSharper disable once CompareOfFloatsByEqualityOperator
if(m_ButtonReleaseThreshold==value)
return;
m_ButtonReleaseThreshold=value;
OnChange();
}
}
/// <summary>
/// Default time (in seconds) within which a press and release has to occur for it
/// to be registered as a "tap".
/// </summary>
/// <value>Default upper limit on press durations for them to register as taps.</value>
/// <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.
/// </remarks>
/// <seealso cref="Interactions.TapInteraction"/>
publicfloatdefaultTapTime
{
get=>m_DefaultTapTime;
set
{
// ReSharper disable once CompareOfFloatsByEqualityOperator
if(m_DefaultTapTime==value)
return;
m_DefaultTapTime=value;
OnChange();
}
}
/// <summary>
/// Allows you to specify the default minimum duration required of a press-and-release interaction to evaluate to a slow-tap-interaction.
/// </summary>
/// <value>The default minimum duration that the button-like input control must remain in pressed state for the interaction to evaluate to a slow-tap-interaction.</value>
/// <remarks>
/// A slow-tap-interaction is considered as a press-and-release sequence on a button-like input control.
/// This property determines the lower bound of the duration that must elapse between the button being pressed and released again.
/// If the delay between press and release is less than this duration, the input does not qualify as a slow-tap-interaction.
// ReSharper disable once CompareOfFloatsByEqualityOperator
if(m_DefaultSlowTapTime==value)
return;
m_DefaultSlowTapTime=value;
OnChange();
}
}
/// <summary>
/// Allows you to specify the default minimum duration required of a press-and-release interaction to evaluate to a hold-interaction.
/// </summary>
/// <value>The default minimum duration that the button-like input control must remain in pressed state for the interaction to evaluate to a hold-interaction.</value>
/// <remarks>
/// A hold-interaction is considered as a press-and-release sequence on a button-like input control.
/// This property determines the lower bound of the duration that must elapse between the button being pressed and released again.
/// If the delay between press and release is less than this duration, the input does not qualify as a hold-interaction.
// ReSharper disable once CompareOfFloatsByEqualityOperator
if(m_TapRadius==value)
return;
m_TapRadius=value;
OnChange();
}
}
/// <summary>
/// Allows you to specify the maximum duration that may pass between taps in order to evaluate to a multi-tap-interaction.
/// </summary>
/// <value>The default maximum duration (in seconds) that may pass between taps in order to evaluate to a multi-tap-interaction.</value>
/// <remarks>
/// A multi-tap interaction is considered as multiple press-and-release sequences.
/// This property defines the maximum duration that may pass between these press-and-release sequences.
/// If consecutive taps (press-and-release sequences) occur with a inter-sequence duration exceeding
/// this property, the interaction do not qualify as a multi-tap-interaction.
///
/// The default multi-tap delay time is 0.75 seconds.
/// </remarks>
/// <seealso cref="defaultTapTime"/>
publicfloatmultiTapDelayTime
{
get=>m_MultiTapDelayTime;
set
{
// ReSharper disable once CompareOfFloatsByEqualityOperator
if(m_MultiTapDelayTime==value)
return;
m_MultiTapDelayTime=value;
OnChange();
}
}
/// <summary>
/// When <c>Application.runInBackground</c> is true, this property determines what happens when application focus changes
/// (see <a href="https://docs.unity3d.com/ScriptReference/Application-isFocused.html">Application.isFocused</a>) changes and how we handle
/// input while running the background.
/// </summary>
/// <value>What to do with input while not having focus. Set to <see cref="BackgroundBehavior.ResetAndDisableNonBackgroundDevices"/> by default.</value>
/// <remarks>
/// If <c>Application.runInBackground</c> is false, the value of this property is ignored. In that case, nothing happens when
/// focus is lost. However, when focus is regained, <see cref="InputSystem.TrySyncDevice"/> is called on all devices.
///
/// Note that in the editor as well as in development standalone players, <c>Application.runInBackground</c> 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.
/// Determines how player focus is handled in the editor with respect to input.
/// </summary>
/// <remarks>
/// This setting only has an effect while in play mode (see <a href="https://docs.unity3d.com/ScriptReference/Application-isPlaying.html">Application.isPlaying</a>).
/// 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 <a href="https://docs.unity3d.com/ScriptReference/Application-isFocused.html">Application.isFocused</a>).
/// 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
/// <c>EditorWindow</c> 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 <a href="https://docs.unity3d.com/ScriptReference/Application-runInBackground.html">Application.runInBackground</a> 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.
/// Improves shortcut key support by making composite controls consume control input
/// </summary>
/// <remarks>
/// Actions are exclusively triggered and will consume/block other actions sharing the same input.
/// E.g. when pressing the 'Shift+B' keys, the associated action would trigger but any action bound to just the 'B' key would be prevented from triggering at the same time.
/// Please note that enabling this will cause actions with composite bindings to consume input and block any other actions which are enabled and sharing the same controls.
/// Input consumption is performed in priority order, with the action containing the greatest number of bindings checked first.
/// Therefore actions requiring fewer keypresses will not be triggered if an action using more keypresses is triggered and has overlapping controls.
/// This works for shortcut keys, however in other cases this might not give the desired result, especially where there are actions with the exact same number of composite controls, in which case it is non-deterministic which action will be triggered.
/// These conflicts may occur even between actions which belong to different Action Maps e.g. if using an UIInputModule with the Arrow Keys bound to the Navigate Action in the UI Action Map, this would interfere with other Action Maps using those keys.
/// However conflicts would not occur between actions which belong to different Action Assets.
[SerializeField]privateboolm_ShortcutKeysConsumeInputs=false;// This is the shortcut support from v1.4. Temporarily moved here as an opt-in feature, while it's issues are investigated.
/// By default, the input system will run event processing as part of the player loop. In the default configuration,
/// the processing will happens once before every every dynamic update (<a href="https://docs.unity3d.com/ScriptReference/MonoBehaviour.Update.html">Update</a>),
/// i.e. <see cref="ProcessEventsInDynamicUpdate"/> is the default behavior.
///
/// There are two types of updates not governed by UpdateMode. One is <see cref="InputUpdateType.Editor"/> which
/// will always be enabled in the editor and govern input updates for <see cref="UnityEditor.EditorWindow"/>s in
/// sync to <see cref="UnityEditor.EditorApplication.update"/>.
///
/// The other update type is <see cref="InputUpdateType.BeforeRender"/>. This type of update is enabled and disabled
/// automatically in response to whether devices are present requiring this type of update (<see
/// cref="InputDevice.updateBeforeRender"/>). This update does not consume extra state.
/// Automatically run input updates right before every <a href="https://docs.unity3d.com/ScriptReference/MonoBehaviour.Update.html">Update</a>.
///
/// In this mode, no processing happens specifically for fixed updates. Querying input state in
/// <a href="https://docs.unity3d.com/ScriptReference/MonoBehaviour.FixedUpdate.html">FixedUpdate</a> will result in errors being logged in the editor and in
/// development builds. In release player builds, the value of the dynamic update state is returned.
/// </summary>
ProcessEventsInDynamicUpdate=1,
/// <summary>
/// Automatically input run updates right before every <a href="https://docs.unity3d.com/ScriptReference/MonoBehaviour.FixedUpdate.html">FixedUpdate</a>.
///
/// In this mode, no processing happens specifically for dynamic updates. Querying input state in
/// <a href="https://docs.unity3d.com/ScriptReference/MonoBehaviour.Update.html">Update</a> will result in errors being logged in the editor and in
/// development builds. In release player builds, the value of the fixed update state is returned.
/// </summary>
ProcessEventsInFixedUpdate,
/// <summary>
/// Do not run updates automatically. In this mode, <see cref="InputSystem.Update"/> must be called
/// manually to update input.
///
/// This mode is most useful for placing input updates in the frame explicitly at an exact location.
///
/// Note that failing to call <see cref="InputSystem.Update"/> may result in a lot of events
/// accumulating or some input getting lost.
/// </summary>
ProcessEventsManually,
}
/// <summary>
/// Determines how the applications behaves when running in the background. See <see cref="backgroundBehavior"/>.
/// When the application loses focus, issue a <see cref="InputSystem.ResetDevice"/> call on every <see cref="InputDevice"/> that is
/// not marked as <see cref="InputDevice.canRunInBackground"/> and then disable the device (see <see cref="InputSystem.DisableDevice"/>
/// and <see cref="InputDevice.enabled"/>). Devices that <see cref="InputDevice.canRunInBackground"/> will not be touched and will
/// keep running as is.
///
/// In effect, this setting will "soft-reset" all devices that cannot receive input while the application does
/// not have focus. That is, it will reset all controls that are not marked as <see cref="InputControlLayout.ControlItem.dontReset"/>
/// to their default state.
///
/// When the application comes back into focus, all devices that have been reset and disabled will be re-enabled and a synchronization
/// request (see <see cref="RequestSyncCommand"/>) will be sent to each device.
///
/// Devices that are added while the application is running in the background are treated like devices that were already present
/// when losing focus. That is, if they cannot run in the background, they will be disabled until focus comes back.
///
/// Note that the resets will cancel <see cref="InputAction"/>s that are in progress from controls on devices that are being reset.
/// </summary>
ResetAndDisableNonBackgroundDevices=0,
/// <summary>
/// Like <see cref="ResetAndDisableNonBackgroundDevices"/> but instead treat all devices as having <see cref="InputDevice.canRunInBackground"/>
/// return false. This effectively means that all input is silenced while the application is running in the background.
/// </summary>
ResetAndDisableAllDevices=1,
/// <summary>
/// Ignore all changes in focus and leave devices untouched. This also disables focus checks in <see cref="UI.InputSystemUIInputModule"/>.
/// </summary>
IgnoreFocus=2,
}
/// <summary>
/// Determines how player focus is handled with respect to input when we are in play mode in the editor.
/// See <see cref="InputSettings.editorInputBehaviorInPlayMode"/>. The setting does not have an effect
/// when the editor is not in play mode.
/// </summary>
publicenumEditorInputBehaviorInPlayMode
{
/// <summary>
/// When the game view does not have focus, input from <see cref="Pointer"/> devices (such as <see cref="Mouse"/> and <see cref="Touchscreen"/>)
/// is routed to the editor and not visible in player code. Input from devices such as <see cref="Gamepad"/>s will continue to
/// go to the game regardless of which <c>EditorWindow</c> is focused.
///
/// This is the default. It makes sure that the devices that are used with the editor UI respect <c>EditorWindow</c> focus and thus
/// do not lead to accidental inputs affecting the game. While at the same time letting all other input get through to the game.
/// It does, however, mean that no other <c>EditorWindow</c> can tap input from these devices (such as <see cref="Gamepad"/>s and <see cref="HID"/>s).
/// </summary>
PointersAndKeyboardsRespectGameViewFocus,
/// <summary>
/// When the game view does not have focus, all input is routed to the editor (and thus <c>EditorWindow</c>s). No input
/// is received in the game regardless of the type of device generating it.
/// </summary>
AllDevicesRespectGameViewFocus,
/// <summary>
/// All input is going to the game at all times. This most closely aligns input behavior in the editor with that in players. <see cref="backgroundBehavior"/>
/// will be respected as in the player and devices may thus be disabled in the runtime based on Game View focus.
