Ran reformatting tool

Author: unitALG

Packages/com.unity.inputsystem/Documentation~/ActionBindings.md

@@ -28,7 +28,7 @@ Each `InputBinding` has the following properties:
 |[`isComposite`](xref:UnityEngine.InputSystem.InputBinding.isComposite)|Whether the Binding acts as a [Composite](#composite-bindings).|
 |[`isPartOfComposite`](xref:UnityEngine.InputSystem.InputBinding.isPartOfComposite)|Whether the Binding is part of a [Composite](#composite-bindings).|
 
-To query the Bindings for a specific Action, use [`InputAction.bindings`](xref:UnityEngine.InputSystem.InputAction.bindings). 
+To query the Bindings for a specific Action, use [`InputAction.bindings`](xref:UnityEngine.InputSystem.InputAction.bindings).
 
 To query a flat list of Bindings for all Actions in an Action Map, use [`InputActionMap.bindings`](xref:UnityEngine.InputSystem.InputActionMap.bindings).
 
@@ -69,13 +69,13 @@ Composites can have parameters, just like [Interactions](xref:input-system-inter
 myAction.AddCompositeBinding("Axis(whichSideWins=1)");
 ```
 
-There are currently five Composite types that come with the system out of the box: 
+There are currently five Composite types that come with the system out of the box:
 
 - [1D-Axis](#1d-axis): two buttons that pull a 1D axis in the negative and positive direction.
 - [2D-Vector](#2d-vector): represents a 4-way button setup where each button represents a cardinal direction, for example a WASD keyboard input (up-down-left-right controls).
 - [3D-Vector](#3d-vector): represents a 6-way button where two combinations each control one axis of a 3D Vector.
-- [One Modifier](#one-modifier): requires the user to hold down a "modifier" button in addition to another control, for example, "SHIFT+1". 
-- [Two Modifiers](#two-modifiers): requires the user to hold down two "modifier" buttons in addition to another control, for example, "SHIFT+CTRL+1". 
+- [One Modifier](#one-modifier): requires the user to hold down a "modifier" button in addition to another control, for example, "SHIFT+1".
+- [Two Modifiers](#two-modifiers): requires the user to hold down two "modifier" buttons in addition to another control, for example, "SHIFT+CTRL+1".
 
 You can also [add your own](#writing-custom-composites) types of Composites.
 
@@ -939,7 +939,7 @@ Press(keyboard.bKey);
 
 ### Initial state check
 
-After an Action is [enabled](xref:UnityEngine.InputSystem.InputAction.enabled), it will start reacting to input as it comes in. However, at the time the Action is enabled, one or more of the Controls that are [bound](xref:UnityEngine.InputSystem.InputAction.controls) to an action may already have a non-default state at that point. 
+After an Action is [enabled](xref:UnityEngine.InputSystem.InputAction.enabled), it will start reacting to input as it comes in. However, at the time the Action is enabled, one or more of the Controls that are [bound](xref:UnityEngine.InputSystem.InputAction.controls) to an action may already have a non-default state at that point.
 
 Using what is referred to as an "initial state check", an Action can be made to respond to such a non-default state as if the state change happened *after* the Action was enabled. The way this works is that in the first input [update](xref:UnityEngine.InputSystem.InputSystem.Update*) after the Action was enabled, all its bound controls are checked in turn. If any of them has a non-default state, the Action responds right away.
 

Packages/com.unity.inputsystem/Documentation~/Controls.md

@@ -51,7 +51,7 @@ A control can have one or more associated usages. A usage is a string that denot
 
 You can access a control's usages using the [`InputControl.usages`](xref:UnityEngine.InputSystem.InputControl.usages) property.
 
-Usages can be arbitrary strings. However, a certain set of usages is very commonly used and comes predefined in the API in the [`CommonUsages`](xref:UnityEngine.InputSystem.CommonUsages) static class. 
+Usages can be arbitrary strings. However, a certain set of usages is very commonly used and comes predefined in the API in the [`CommonUsages`](xref:UnityEngine.InputSystem.CommonUsages) static class.
 
 ## Control paths
 
@@ -224,19 +224,19 @@ These two mechanisms use control actuation:
 
 The Input System can label a control as "noisy", meaning that they can change value without needing any actual or intentional user interaction, such as a gravity [sensor](xref:UnityEngine.InputSystem.Sensor) in a cellphone, or taking orientation readings from an [XR head-mounted display](xref:UnityEngine.InputSystem.XR.XRHMD).
 
-For example, the PS4 controller has a gyroscope sensor built into the device which constantly feeds data about the angular velocity of the device, even if the device just sits there without user interaction. Conversely, the controller's sticks and buttons require user interaction to produce non-default values. 
+For example, the PS4 controller has a gyroscope sensor built into the device which constantly feeds data about the angular velocity of the device, even if the device just sits there without user interaction. Conversely, the controller's sticks and buttons require user interaction to produce non-default values.
 
 If a control is marked as noisy, it means that:
 
 - The control is not considered for [interactive rebinding](xref:input-system-action-bindings#interactive-rebinding). The [`InputActionRebindingExceptions.RebindingOperation`](xref:UnityEngine.InputSystem.InputActionRebindingExtensions.RebindingOperation) ignores the control by default (although you can bypass this using [`WithoutIgnoringNoisyControls`](xref:UnityEngine.InputSystem.InputActionRebindingExtensions.RebindingOperation.WithoutIgnoringNoisyControls)).
 
 - If enabled in the Project Settings, the system performs additional event filtering, then calls [`InputDevice.MakeCurrent`](xref:UnityEngine.InputSystem.InputDevice.MakeCurrent). If an input event for a device contains no state change on a control that is not marked noisy, then the device will not be made current based on the event. This avoids, for example, a plugged in PS4 controller constantly making itself the current gamepad ([`Gamepad.current`](xref:UnityEngine.InputSystem.Gamepad.current)) due to its sensors constantly feeding data into the system.
 
-- When the application loses focus and devices are [reset](xref:input-system-devices#device-resets) as a result, the state of noisy controls will be preserved as is. This ensures that sensor readings will remain at their last value rather than being reset to default values. However, while other controls are reset to their default value, noisy controls will not be reset but rather remain at their current value (unless the device is [running in the background](xref:input-system-devices#background-and-focus-change-behavior)). This is based on the assumption that noisy controls most often represent sensor values and snapping the last sampling value back to default will usually have undesirable effects on an application's simulation logic. 
+- When the application loses focus and devices are [reset](xref:input-system-devices#device-resets) as a result, the state of noisy controls will be preserved as is. This ensures that sensor readings will remain at their last value rather than being reset to default values. However, while other controls are reset to their default value, noisy controls will not be reset but rather remain at their current value (unless the device is [running in the background](xref:input-system-devices#background-and-focus-change-behavior)). This is based on the assumption that noisy controls most often represent sensor values and snapping the last sampling value back to default will usually have undesirable effects on an application's simulation logic.
 
 > [!NOTE]
 > To query whether a control is noisy, use the [`InputControl.noisy`](xref:UnityEngine.InputSystem.InputControl.noisy) property.
-> 
+>
 > If any control on a device is noisy, the device itself is flagged as noisy.
 
 ### Noise masks
@@ -257,7 +257,7 @@ The system considers synthetic controls for [interactive rebinding](xref:input-s
 
 ### Avoiding defensive copies
 
-Use [`InputControl<T>.value`](xref:UnityEngine.InputSystem.InputControl`1.value) instead of [`InputControl<T>.ReadValue`](xref:UnityEngine.InputSystem.InputControl`1.ReadValue) to avoid creating a copy of the control state on every call. This is because `InputControl<T>.value` returns the value as `ref readonly` while `InputControl<T>.ReadValue` always makes a copy. Note that this optimization only applies if the call site assigns the return value to a variable that has been declared `ref readonly`. Otherwise, a copy is made as before. 
+Use [`InputControl<T>.value`](xref:UnityEngine.InputSystem.InputControl`1.value) instead of [`InputControl<T>.ReadValue`](xref:UnityEngine.InputSystem.InputControl`1.ReadValue) to avoid creating a copy of the control state on every call. This is because `InputControl<T>.value` returns the value as `ref readonly` while `InputControl<T>.ReadValue` always makes a copy. Note that this optimization only applies if the call site assigns the return value to a variable that has been declared `ref readonly`. Otherwise, a copy is made as before.
 
 Additionally, be aware of defensive copies that the compiler can allocate when it is unable to determine that it can safely use the read-only reference. This means that if the compiler can't determine that the reference won't be changed, it will create a defensive copy. For more details, refer to the [.NET guidance on reducing memory allocations](https://learn.microsoft.com/en-us/dotnet/csharp/write-safe-efficient-code#use-ref-readonly-return-statements).
 
@@ -278,15 +278,15 @@ Negative performance impact can occur when:
 - No readings from controls that change frequently.
 
 `USE_READ_VALUE_CACHING` is not enabled by default because it can result in the following minor behavioral changes:
-- For control processors that use a global state with cached value optimization, changing the global state of a control processor will have no effect. Reading the control value will only ever return a new value if the physical control has been actuated. 
+- For control processors that use a global state with cached value optimization, changing the global state of a control processor will have no effect. Reading the control value will only ever return a new value if the physical control has been actuated.
 
     This behavior differs from using global states without cached value optimizations, in which you can read the control value, change the global state, read the control value again, and get a new value due to the fact that the control processor runs on every call.
 - Writing to device state using low-level APIs like [`InputControl<T>.WriteValueIntoState`](xref:UnityEngine.InputSystem.InputControl`1.WriteValueIntoState(`0,System.Void*)) doesn't set the stale flag and subsequent calls to [`InputControl<T>.value`](xref:UnityEngine.InputSystem.InputControl`1.value) won't reflect those changes.
 - After changing properties on [`AxisControl`](xref:UnityEngine.InputSystem.Controls.AxisControl) the [`ApplyParameterChanges`](xref:UnityEngine.InputSystem.InputControl.ApplyParameterChanges) method has to be called to invalidate cached values.
 
 Processors that must run on every read can set their caching policy to [EvaluateOnEveryRead](xref:UnityEngine.InputSystem.InputProcessor.CachingPolicy.EvaluateOnEveryRead), which disables caching on controls that are using such processors.
 
-You can enable the `PARANOID_READ_VALUE_CACHING_CHECKS` internal feature flag to compare cached and uncached values on every read. If they don't match, the check logs an error. 
+You can enable the `PARANOID_READ_VALUE_CACHING_CHECKS` internal feature flag to compare cached and uncached values on every read. If they don't match, the check logs an error.
 
 ### Optimized control read value
 

Packages/com.unity.inputsystem/Documentation~/Gamepad.md

@@ -11,7 +11,7 @@ Gamepad support guarantees the correct location and functioning of Controls acro
 
 > [!NOTE]
 > Generic [HID](xref:input-system-hid) gamepads will __not__ be surfaced as [`Gamepad`](xref:UnityEngine.InputSystem.Gamepad) devices but rather be created as generic [joysticks](xref:input-system-joystick). This is because the Input System cannot guarantee correct mapping of buttons and axes on the controller (the information is simply not available at the HID level). Only HID gamepads that are explicitly supported by the Input System (like the PS4 controller) will come out as gamepads. Note that you can set up the same kind of support for specific HID gamepads yourself (see ["Overriding the HID Fallback"](xref:input-system-hid#creating-a-custom-device-layout)).
-> 
+>
 > In case you want to use the gamepad for driving mouse input, there is a sample called `Gamepad Mouse Cursor` you can install from the package manager UI when selecting the Input System package. The sample demonstrates how to set up gamepad input to drive a virtual mouse cursor.
 
 ## Controls

Packages/com.unity.inputsystem/Documentation~/Installation.md

@@ -6,15 +6,15 @@ uid: input-system-installation
 This page describes how to install and activate the Input System package for your Unity Project.
 
 > [!NOTE]
-> This version of the new Input System requires the .NET 4 runtime. It doesn't work in projects using the old .NET 3.5 runtime. 
+> This version of the new Input System requires the .NET 4 runtime. It doesn't work in projects using the old .NET 3.5 runtime.
 >
 > This package is only compatible with Unity Editor release versions 2021.3 and later. If you are working in a release version of the Editor prior to 2021.3, you need to use the package version that works with that version of the Editor, indicated by the **Release** tag in the [Unity Package Manager](https://docs.unity3d.com/Manual/upm-ui.html) window.
 
 ## Install the package
 
-To install the new Input System: 
+To install the new Input System:
 
-1. In the main menu of the Unity Editor, go to __Window__ > __Package Manager__ to open the Unity Package Manager. 
+1. In the main menu of the Unity Editor, go to __Window__ > __Package Manager__ to open the Unity Package Manager.
 
 2. Select **Unity Registry** from the navigation panel.
 

Packages/com.unity.inputsystem/Documentation~/Interactions.md

@@ -90,23 +90,23 @@ You can install Interactions on [Bindings](xref:input-system-action-bindings) or
 
 When you create Bindings for your [Actions](xref:input-system-actions), you can choose to add Interactions to the Bindings.
 
-If you're using [project-wide actions](xref:input-system-configuring-input), or [Input Action Assets](xref:input-system-action-assets), you can add any Interaction to your Bindings in the Input Action editor. 
+If you're using [project-wide actions](xref:input-system-configuring-input), or [Input Action Assets](xref:input-system-action-assets), you can add any Interaction to your Bindings in the Input Action editor.
 
 To add an Interaction:
 
 1. [Create some Bindings](xref:input-system-configuring-input#bindings).
 
-2. Select the Binding you want to add Interactions to. 
+2. Select the Binding you want to add Interactions to.
 
-    The right pane of the window shows the properties for that Binding. 
+    The right pane of the window shows the properties for that Binding.
 
-3. Click on the plus icon on the __Interactions__ foldout to open a list of all available Interactions types. 
+3. Click on the plus icon on the __Interactions__ foldout to open a list of all available Interactions types.
 
-4. Choose an Interaction type to add an Interaction instance of that type. 
+4. Choose an Interaction type to add an Interaction instance of that type.
 
     The Interaction now appears in the __Interactions__ foldout. If the Interaction has any parameters, you can edit them, as well.
 
-To remove an Interaction, click the minus button next to it. 
+To remove an Interaction, click the minus button next to it.
 
 To change the [order of Interactions](#multiple-interactions-on-a-binding), click the up and down arrows.
 
@@ -259,7 +259,7 @@ A [`MultiTapInteraction`](xref:UnityEngine.InputSystem.Interactions.MultiTapInte
 
 ## Writing custom Interactions
 
-You can also write a custom Interaction to use in your project. You can use custom Interactions in the UI and code the same way you use built-in Interactions. 
+You can also write a custom Interaction to use in your project. You can use custom Interactions in the UI and code the same way you use built-in Interactions.
 
 Add a class implementing the [`IInputInteraction`](xref:UnityEngine.InputSystem.IInputInteraction) interface, like this:
 
@@ -311,7 +311,7 @@ Register your interaction with the Input System in your initialization code:
 InputSystem.RegisterInteraction<MyWiggleInteraction>();
 ```
 
-Your new Interaction is now available in the [Input Action Asset Editor window](xref:input-system-action-assets). 
+Your new Interaction is now available in the [Input Action Asset Editor window](xref:input-system-action-assets).
 
 You can also add it in code using this call:
 

Packages/com.unity.inputsystem/Documentation~/Layouts.md

@@ -308,7 +308,7 @@ You can speed up this process up by "baking" the final form of a layout into a "
 
 ### Creating a precompiled layout
 
-The first step in setting up a precompiled layout is to generate it. 
+The first step in setting up a precompiled layout is to generate it.
 
 To generate a layout:
 

Packages/com.unity.inputsystem/Documentation~/PlayerInput.md

@@ -184,4 +184,3 @@ If you use [`MultiplayerEventSystem`](xref:input-system-ui-support#multiplayer-u
 > - As a general rule, if you are using the PlayerInput workflow, you should read input through callbacks as described above, however if you need to access the input actions asset directly while using the PlayerInput component, you should access the [PlayerInput component's copy of the actions](xref:UnityEngine.InputSystem.PlayerInput.actions), not `InputSystem.actions`. This is because the PlayerInput component performs device filtering to automatically assign devices to multiple players, so each instance has its own copy of the actions filtered for each player. If you bypass this by reading `InputSystem.actions` directly, the automatic device assignment won't work.
 >
 > - This component is built on top of the public Input System API. As such, they don't do anything that you can't program yourself. They are meant primarily as an easy, out-of-the-box setup that eliminates much of the need for custom scripting.
-

Packages/com.unity.inputsystem/Documentation~/Sensors.md

@@ -109,12 +109,12 @@ Use the gravity sensor to determine the direction of the gravity vector relative
 
 Use the attitude sensor to determine the orientation of a device. This is useful to control content by rotating a device. Values are affected by the [__Compensate Orientation__](xref:input-system-settings#compensate-orientation) setting.
 
-On Android devices, there are two types of attitude sensors: 
+On Android devices, there are two types of attitude sensors:
 
 - [**RotationVector**](https://developer.android.com/reference/android/hardware/Sensor#TYPE_ROTATION_VECTOR)
 - [**GameRotationVector**](https://developer.android.com/reference/android/hardware/Sensor#TYPE_GAME_ROTATION_VECTOR)
 
-Some Android devices have both types of sensor, while other devices may only have one or the other type available. These two types of attitude sensor behave slightly differently to each other. You can [read about the differences between them here](https://developer.android.com/guide/topics/sensors/sensors_position#sensors-pos-gamerot). 
+Some Android devices have both types of sensor, while other devices may only have one or the other type available. These two types of attitude sensor behave slightly differently to each other. You can [read about the differences between them here](https://developer.android.com/guide/topics/sensors/sensors_position#sensors-pos-gamerot).
 
 Because of this variety in what type of rotation sensors are available across devices, when you require input from a rotation sensor on Android devices, you should include code that checks for your preferred type of rotation sensor with a fallback to the alternative type of rotation sensor if it is not present. For example: