Fixing formatting

Author: suearkinunity

Packages/com.unity.inputsystem/Documentation~/compensate-orientation.md

@@ -14,6 +14,7 @@ If this setting is enabled, rotation values reported by [sensors](devices-sensor
 |[`ScreenOrientation.LandscapeRight`](https://docs.unity3d.com/ScriptReference/ScreenOrientation.html)|Values rotate by 270 degrees.|
 
 This setting affects the following sensors:
+
 * [`Gyroscope`](xref:UnityEngine.InputSystem.Gyroscope)
 * [`GravitySensor`](xref:UnityEngine.InputSystem.GravitySensor)
 * [`AttitudeSensor`](xref:UnityEngine.InputSystem.AttitudeSensor)

Packages/com.unity.inputsystem/Documentation~/configure-virtual-mouse-input.md

@@ -26,7 +26,6 @@ To configure the input to drive the virtual mouse, do one of the following:
 
 ## Control the system mouse cursor with the virtual mouse
 
-To set the virtual mouse to control the system mouse cursor:
-1. Set [Cursor Mode](xref:UnityEngine.InputSystem.UI.VirtualMouseInput) to **Hardware Cursor If Available**. 
+To set the virtual mouse to control the system mouse cursor, set [Cursor Mode](xref:UnityEngine.InputSystem.UI.VirtualMouseInput) to **Hardware Cursor If Available**. 
 
 In this mode, the **Cursor Graphic** is hidden when a system mouse is present, and you use [Mouse.WarpCursorPosition](xref:UnityEngine.InputSystem.Mouse) to move the system mouse cursor instead of the software cursor. The transform linked through **Cursor Transform** is not updated.

Packages/com.unity.inputsystem/Documentation~/corresponding-old-new-api.md

@@ -19,6 +19,7 @@ Action-based input refers to reading pre-configured named axes, buttons, or othe
 __Note:__ In some cases for named axes and buttons, the new Input System requires slightly more code than the old Input Manager, but this results in better performance. This is because in the new Input System, the logic is separated into two parts: the first is to find and store a reference to the action (usually done once, for example in your `Start` method), and the second is to read the action (usually done every frame, for example in your `Update` method). In contrast, the old Input Manager used a string-based API to "find" and "read" the value at the same time, because it was not possible to store a reference to a button or axis. This results in worse performance, because the axis or button is looked up each time the value is read.
 
 To find and store references to actions, which can be axes or buttons use [`FindAction`](xref:UnityEngine.InputSystem.InputActionAsset). For example:
+
 ```
  // A 2D axis action named "Move"
 InputAction moveAction = InputSystem.actions.FindAction("Move");

Packages/com.unity.inputsystem/Documentation~/event-merging.md

@@ -36,10 +36,12 @@ and it's important to keep the exact timestamp of such transition.
 Later we combine no5, no6, no7 together into no7 because it is the last event in the update.
 
 Currently this approach is implemented for:
+
 - `FastMouse`, combines events unless `buttons` or `clickCount` differ in `MouseState`.
 - `Touchscreen`, combines events unless `touchId`, `phaseId` or `flags` differ in `TouchState`.
 
 You can disable merging of events by:
+
 ```
 InputSystem.settings.disableRedundantEventsMerging = true;
 ```

Packages/com.unity.inputsystem/Documentation~/get-started-player-input-component.md

@@ -8,6 +8,5 @@ To get started using the Player Input component, use the following steps:
 
 1. [Add](https://docs.unity3d.com/Manual/UsingComponents.html) a **Player Input** component to a GameObject. This would usually be the GameObject that represents the player in your game.
 2. Assign your [Action Asset](ActionAssets.md) to the **Actions** field. This is usually the default project-wide action asset named "InputSystem_Actions"
-    > [!NOTE]
-    > Currently, when using project-wide actions all the action maps are enabled by default. It is advisible to manually disable them and manually enable the default map that **Player Input** during `Start()`.
+    Currently, when using project-wide actions all the action maps are enabled by default. It is advisible to manually disable them and manually enable the default map that **Player Input** during `Start()`.
 3. Set up Action responses, by selecting a **Behavior** type from the Behavior menu. The Behavior type you select affects how you should implement the methods that handle your Action responses. See the  [notification behaviors](#notification-behaviors) section further down for details.<br/><br/>![PlayerInput Notification Behavior](Images/PlayerInputNotificationBehaviors.png)<br/><br/>

Packages/com.unity.inputsystem/Documentation~/introduction-to-processors.md

@@ -28,21 +28,23 @@ Processors can have parameters which can be booleans, integers, or floating-poin
     "invert,normalize(min=0,max=10)"
 ``` 
 
-## Choose the right ProcessorCollapse commentComment on line R29jfreire-unity commented on Jun 12, 2025 jfreire-unityon Jun 12, 2025CollaboratorMore actionsGreat section 👏ReactWrite a replyResolve comment
+## Choose the right ProcessorCollapse comment
 
 The following sections contain a brief explanation and various example scenarios for the different Processor types. Note that there are additional cases where Processors may apply; the scenarios described here illustrate only some of them. In some situations, it might be useful to combine multiple Processors to achieve a specific goal.
 Refer to the [Processor Types](ProcessorTypes.md) for a comprehensive list and information on how to write your own custom Processors.
 
 ### Invert
 
-The [Invert Processor](ProcessorTypes.md#invert) inverts input values of any type (e.g. float, Vector2, or Vector3) by multiplying them by -1. This results in effects such as reversing player navigation, for example, the left arrow would be interpreted as a right arrow, and vice versa.
+The [Invert Processor](ProcessorTypes.md#invert) inverts input values of any type (e.g. float, Vector2, or Vector3) by multiplying them by `-1`. This results in effects such as reversing player navigation, for example, the left arrow would be interpreted as a right arrow, and vice versa.
 
 #### Example: Ship navigation
 
 To use an axis control to mimic a ship's rudder, inverting the input produces the desired effect. Pulling left steers the ship right, and vice versa.
 
 ![This picture shows a ship in a neutral position](./Images/Processors-Ship-Neutral.png)
+
 ![This picture shows a ship rotated to the left while the On-Screen control stick was moved to the right](./Images/Processors-Ship-Left.png)
+
 ![This picture shows a ship rotated to the right while the On-Screen control stick was moved to the left](./Images/Processors-Ship-Right.png)
 
 You can achieve this by using an Invert Processor on the Action or the Binding. In this scenario, the Processor is applied to the Binding. Note that inversion is enabled for the X axis but not for the Y axis. Inverting the Y axis would cause the ship to move backward when the joystick is pulled upward. The following image shows the setup in the Action Asset Editor.
@@ -81,6 +83,7 @@ Normalized input is particularly useful in scenarios where the specific magnitud
 To ensure the player always moves at a constant speed where the input simply triggers the action and controls the direction, the Normalize Processor is a suitable choice. This is achieved by retrieving the input vector while ignoring its magnitude and focusing solely on its direction.
 
 ![A player moves forward while the on-screen control stick is slightly pushed up.](./Images/Processors-Normalize-Slow.png)
+
 ![A player moves forward while the on-screen control stick is moved all the way up](./Images/Processors-Normalize-Fast.png)
 
 In the images shown above, the player moves forward at a constant speed, regardless of how far the joystick is pushed upward.
@@ -97,7 +100,7 @@ To apply the Processor, add it to the Binding, as shown in the image below.
 The [Scale Processor](ProcessorTypes.md#scale) multiplies the input value by a given factor X. This applies to float values as well as vectors, where each axis is multiplied by the corresponding factor specified for that axis.
 This allows you to assign weight to input values, which can, for example, make a particular type of control easier to use.
 
-#### Example: Horizontally aligned CameraCollapse commentComment on line R97jfreire-unity commented on Jun 12, 2025 jfreire-unityon Jun 12, 2025CollaboratorMore actionsI don't think it makes sense to add now but I feel it can be mentioned. This example would be a great shout out to another package users might not be aware of, such as Cinemachine!ReactWrite a replyResolve comment
+#### Example: Horizontally aligned CameraCollapse comment
 
 To make the look-around movement smoother and improve ease of use, it may be helpful to reduce the vertical rotation and scale the input values for horizontal rotation. For in-game landscapes that are primarily horizontally aligned, this is a useful feature to prevent the camera from rotating vertically too quickly or in unintended ways.
 To apply this effect to all bindings, you can add the Processor to the Action itself (Look in this scenario). The following image shows the setup using the Starter Assets example:
@@ -107,6 +110,7 @@ To apply this effect to all bindings, you can add the Processor to the Action it
 There are two Bindings attached to the Action. The input value ranges of the two bindings are very different. To mitigate this difference, it helps to use a Scale Processor on each of the Bindings. See how the Scale Processor normalizes the input data values for a joystick and a pointer (e.g., a mouse) in the images below.
 
 ![An example of a Scale Vector 2 Processor setup in the Input Action Asset Editor](./Images/Processors-Scale-Look-Pointer.png)
+
 ![An example of a Scale Vector 2 Processor setup in the Input Action Asset Editor](./Images/Processors-Scale-Look-Stick.png)
 
 > [!NOTE]

Packages/com.unity.inputsystem/Documentation~/optimize-controls.md

@@ -13,20 +13,25 @@ Use [`InputControl<T>.value`](xref:UnityEngine.InputSystem.InputControl-1) inste
 ## Control Value Caching
 
 When the `'USE_READ_VALUE_CACHING'` internal feature flag is set, the Input System will switch to an optimized path for reading control values. This path efficiently marks controls as 'stale' when they have been actuated. Subsequent calls to [`InputControl<T>.ReadValue`](xref:UnityEngine.InputSystem.InputControl-1) will only apply control processing when there have been changes to that control or in case of control processing. Control processing in this case can mean any hard-coded processing that might exist on the control, such as with [`AxisControl`](xref:UnityEngine.InputSystem.Controls.AxisControl) which has built-in inversion, normalisation, scaling etc, or any processors that have been applied to the controls' [processor stack](add-processors-controls.md).
-> Note: Performance improvements **are currently not guaranteed** for all use cases. Even though this performance path marks controls as "stale" in an efficient way, it still has an overhead which can degrade performance in some cases.
+
+> [!NOTE] 
+> Performance improvements **are currently not guaranteed** for all use cases. Even though this performance path marks controls as "stale" in an efficient way, it still has an overhead which can degrade performance in some cases.
 
 A positive performance impact has been seen when:
+
 - Reading from controls that do not change frequently.
 - In case the controls change every frame, are being read and have actions bound to them as well, e.g. on a Gamepad, reading `leftStick`, `leftStick.x` and `leftStick.left` for example when there's a action with composite bindings setup.
 
 On the other hand, it is likely to have a negative performance impact when:
+
 - No control reads are performed for a control, and there are a lot of changes for that particular control.
 - Reading from controls that change frequently that have no actions bound to those controls.
 
 Moreover, this feature is not enabled by default as it can result in the following minor behavioural changes:
- * Some control processors use global state. Without cached value optimizations, it is possible to 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. With cached value optimizations, reading the control value will only ever return a new value if the physical control has been actuated. Changing the global state of a control processor will have no effect otherwise.
- * Writing to device state using low-level APIs like [`InputControl<T>.WriteValueIntoState`](xref:UnityEngine.InputSystem.InputControl-1) does not set the stale flag and subsequent calls to [`InputControl<T>.value`](xref:UnityEngine.InputSystem.InputControl-1) will not reflect those changes.
- * After changing properties on [`AxisControl`](xref:UnityEngine.InputSystem.Controls.AxisControl) the [`ApplyParameterChanges`](xref:UnityEngine.InputSystem.InputControl) has to be called to invalidate cached value.
+
+* Some control processors use global state. Without cached value optimizations, it is possible to 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. With cached value optimizations, reading the control value will only ever return a new value if the physical control has been actuated. Changing the global state of a control processor will have no effect otherwise.
+* Writing to device state using low-level APIs like [`InputControl<T>.WriteValueIntoState`](xref:UnityEngine.InputSystem.InputControl-1) does not set the stale flag and subsequent calls to [`InputControl<T>.value`](xref:UnityEngine.InputSystem.InputControl-1) will not reflect those changes.
+* After changing properties on [`AxisControl`](xref:UnityEngine.InputSystem.Controls.AxisControl) the [`ApplyParameterChanges`](xref:UnityEngine.InputSystem.InputControl) has to be called to invalidate cached value.
 
 Processors that need to run on every read can set their respective caching policy to EvaluateOnEveryRead. That will disable caching on controls that are using such processor.
 
@@ -37,18 +42,22 @@ If there are any non-obvious inconsistencies, 'PARANOID_READ_VALUE_CACHING_CHECK
 When the `'USE_OPTIMIZED_CONTROLS'` internal feature flag is set, the Input System will use faster way to use state memory for some controls instances. This is very specific optimization and should be used with caution.
 
 Most controls are flexible with regards to memory representation, like [`AxisControl`](xref:UnityEngine.InputSystem.Controls.AxisControl) can be one bit, multiple bits, a float, etc, or in [`Vector2Control`](xref:UnityEngine.InputSystem.Controls.Vector2Control) where x and y can have different memory representation.
+
 Yet for most controls there are common memory representation patterns, for example [`AxisControl`](xref:UnityEngine.InputSystem.Controls.AxisControl) are floats or single bytes. Or some [`Vector2Control`](xref:UnityEngine.InputSystem.Controls.Vector2Control) are two consequitive floats in memory.
+
 If a control matches a common representation we can bypass reading its children control and cast the memory directly to the common representation. For example if [`Vector2Control`](xref:UnityEngine.InputSystem.Controls.Vector2Control) is two consecutive floats in memory we can bypass reading `x` and `y` separately and just cast the state memory to `Vector2`.
 
 This optimization has a performance impact on `PlayMode` as we do extra checks to ensure that the controls have the correct memory representation during development. Don't be alarmed if you see a performance drop in `PlayMode` when using this optimization as it's expected at this stage.
 
 This optimization only works if the controls don't need any processing applied to them, such as `invert`, `clamp`, `normalize`, `scale` or any other processor. If any of these are applied to the control, **there won't be any optimization applied** and the control will be read as usual.
 
 Also, [`InputControl.ApplyParameterChanges()`](xref:UnityEngine.InputSystem.InputControl) **must be explicitly called** in specific changes to ensure [`InputControl.optimizedControlDataType`](xref:UnityEngine.InputSystem.InputControl) is updated to the correct memory representation. Make sure to call it when:
+
 * Configuration changes after [`InputControl.FinishSetup()`](xref:UnityEngine.InputSystem.InputControl) is called.
 * Changing parameters such [`AxisControl.invert`](xref:UnityEngine.InputSystem.Controls.AxisControl), [`AxisControl.clamp`](xref:UnityEngine.InputSystem.Controls.AxisControl), [`AxisControl.normalize`](xref:UnityEngine.InputSystem.Controls.AxisControl), [`AxisControl.scale`](xref:UnityEngine.InputSystem.Controls.AxisControl) or changing processors. The memory representation needs to be recalculated after these changes so that we know that the control is not optimized anymore. Otherwise, the control will be read with wrong values.
 
 The optimized controls work as follows:
+
 * A potential memory representation is set using [`InputControl.CalculateOptimizedControlDataType()`](xref:UnityEngine.InputSystem.InputControl)
 * Its memory representation is stored in [`InputControl.optimizedControlDataType`](xref:UnityEngine.InputSystem.InputControl)
-* Finally,  [`ReadUnprocessedValueFromState`](xref:UnityEngine.InputSystem.InputControl-1) uses the optimized memory representation to decide if it should cast to memory directly instead of reading every children control on it's own to reconstruct the controls state.
+* Finally, [`ReadUnprocessedValueFromState`](xref:UnityEngine.InputSystem.InputControl-1) uses the optimized memory representation to decide if it should cast to memory directly instead of reading every children control on it's own to reconstruct the controls state.

Packages/com.unity.inputsystem/Documentation~/read-devices-directly.md

@@ -24,6 +24,7 @@ To get a reference to a device, you can either:
 You can get references to any supported device currently connected by using one of the [InputDevice classes](xref:UnityEngine.InputSystem.InputDevice) and using the `.current` property to get the currently active device of that type. For example, [`Gamepad.current`](xref:UnityEngine.InputSystem.Gamepad) returns the most recently active connected gamepad.
 
 You can browse the available device types from the [InputDevice classes API documentation](xref:UnityEngine.InputSystem.InputDevice). 
+
 - Some types listed are usable directly, such as `Gamepad` or `Joystick`.
 - Some are abstract parent classes that have usable child classes. For example, `Pointer` is not directly usable, but has usable child classes of `Mouse`, `Pen`, and `Touch`.
 - Some usable types also have more specialized child classes. For example `Gamepad` also has child classes such as `AndroidGamepad` as well as other Gampad types.

Packages/com.unity.inputsystem/Documentation~/set-up-test-assemblies.md

@@ -7,12 +7,14 @@ uid: input-system-set-up-test-assemblies
 To set up a test assembly that uses the Input System's automation framework, follow these steps:
 
 1. In the `Packages/manifest.json` file of your project, `com.unity.inputsystem` must be listed in `testables`. This is necessary for test code that comes with the package to be included with test builds of your project.<br><br>You can, for example, add this after the `dependencies` property like so:
+    
     ```
     },
     "testables" : [
         "com.unity.inputsystem"
     ]
     ```
+
 2. Create a new assembly definition (menu: __Create > Assembly Definition__) or go to an assembly definition for a test assembly that you have already created.
 3. Add references to `nunit.framework.dll`, `UnityEngine.TestRunner`, and `UnityEditor.TestRunner` (as described in [How to create a new test assembly](https://docs.unity3d.com/Packages/com.unity.test-framework@1.0/manual/workflow-create-test-assembly.html)), as well as `Unity.InputSystem` and `Unity.InputSystem.TestFramework` for the Input System.