DOCATT-8743: Edited PlayerInput class for clarity, made more explicit

- Similar to DOCATT-8578, I merged some of the manual & API documentation for InputControl & PlayerInput classes as part of edits
- Also corrected some links to anchors that didn't exist in Sensors.md, HID.md, and Testing.md

Author: unitALG

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

@@ -13,7 +13,7 @@ This page introduces the basic concepts that relate to working with the Input Sy
 |[**Input Device**](SupportedDevices.html)| Often referred to just as a "**device**" within the context of input. A physical piece of hardware, such as a keyboard, gamepad, mouse, or touchscreen which allows the user to send input into Unity.|
 |[**Control**](Controls.html)|The separate individual parts of an input device which each send input values into Unity. For example, a gamepad’s **controls** comprise multiple buttons, sticks and triggers, and a mouse’s controls include the two X and Y sensors on the underside, and the various buttons and scroll wheels on the top side.|
 |[**Action**](Actions.html)| Actions are a high-level concept that describe individual things that a user might want to do in your game or app, such as "Jump" within a game, or "Select" in an on-screen UI. They are things a user can do in your game or app as a result of input, regardless of what device or control they use to perform it. Actions generally have conceptual names that you choose to suit your project, and should usually be verbs. For example "Run", "Jump" "Crouch", "Use", "Start", "Quit".|
-|[**Action Map**](ActionsEditor.html#configure-action-maps) | Action Maps allow you to organise Actions into groups which represent specific situations where a set of actions make sense together. You can simultaneously enable or disable all Actions in an action map, so it is useful to group Actions in Action Maps by the context in which they are relevant. For example, you might have one action map for controlling a player, and another for interacting with your game's UI.|
-|[**Binding**](ActionBindings.html)| A connection defined between an **Action** and specific device controls. For example, your "Move" action might have bindings to the arrow keys and WSAD keys on the keyboard, and the left stick on a joypad, and the primary 2D axis on a VR controller. Multiple bindings like this means your game can accept cross-platform input. |
+|[**Action Map**](ActionsEditor.html#configure-action-maps) | Action Maps allow you to organize Actions into groups which represent specific situations where a set of actions make sense together. You can simultaneously enable or disable all Actions in an action map, so it is useful to group Actions in Action Maps by the context in which they are relevant. For example, you might have one action map for controlling a player, and another for interacting with your game's UI.|
+|[**Binding**](ActionBindings.html)| A connection defined between an **Action** and specific device controls. There are two main types of bindings:<ul><li>**Normal** bindings directly bind to control(s) by means of a [control path](xref:input-system-controls#control-paths). At runtime, any path that matches one or multiple controls will feed input into the binding.</li><li>**Composite** bindings don't bind to controls themselves. Instead, they receive their input from their **Part** bindings and then return a value representing a composition of those inputs. For example, the right trigger on the gamepad can act as a strength multiplier on the value of the left stick.</li></ul> |
 |[**Your Action Code**](xref:input-system-responding)| The part of your script which is executed based on the actions you have configured. In your code, you can use references to actions to either read the current value or state of the action (also known as "polling"), or set up a callback to call your own method when actions are performed.|
 |[**Action Asset**](xref:input-system-action-assets) | An asset type which contains a saved configuration of Action Maps, Actions and Bindings. You can specify one Action Asset in your project as the [project-wide actions](xref:project-wide-actions), which allows you to easily reference those actions in code by using [`InputSystem.actions`](xref:UnityEngine.InputSystem.InputSystem). |

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

@@ -9,7 +9,7 @@ To query the set of all currently present Devices, you can use [`InputSystem.dev
 
 ## Device descriptions
 
-An [`InputDeviceDescription`](xref:UnityEngine.InputSystem.Layouts.InputDeviceDescription) describes a Device. The Input System uses this primarily during the Device discovery process. When a new Device is reported (by the runtime or by the user), the report contains a Device description. Based on the description, the system then attempts to find a Device [layout](xref:input-system-layouts) that matches the description. This process is based on [Device matchers](#matching).
+The Input System uses the device description defined as a [`InputDeviceDescription`](xref:UnityEngine.InputSystem.Layouts.InputDeviceDescription) primarily during the Device discovery process. When a new Device is reported (by the runtime or by the user), the system then attempts to find a Device [layout](xref:input-system-layouts) that matches the Device description contained in the report. This process is based on [Device matching](#matching).
 
 After a Device has been created, you can retrieve the description it was created from through the [`InputDevice.description`](xref:UnityEngine.InputSystem.InputDevice.description) property.
 
@@ -50,7 +50,7 @@ InputSystem.RegisterLayoutMatcher<MyDevice>(
 
 ```
 
-If multiple matchers are matching the same [`InputDeviceDescription`](xref:UnityEngine.InputSystem.Layouts.InputDeviceDescription), the Input System chooses the matcher that has the larger number of properties to match against.
+If multiple matchers identifies the same [`InputDeviceDescription`](xref:UnityEngine.InputSystem.Layouts.InputDeviceDescription), the Input System chooses the matcher that has the larger number of properties to match against.
 
 #### Hijacking the matching process
 
@@ -106,12 +106,12 @@ Resetting a Device resets its Controls to their default state. You can do this m
 
 There are two types of resets as determined by the second parameter to [`InputSystem.ResetDevice`](xref:UnityEngine.InputSystem.InputSystem.ResetDevice(UnityEngine.InputSystem.InputDevice,System.Boolean)):
 
-|Type|Description|
+|Reset Type|Description|
 |----|-----------|
-|"Soft" Resets|This is the default. With this type, only controls that are *not* marked as [`dontReset`](xref:input-system-layouts#control-items) are reset to their default value. This excludes controls such as [`Pointer.position`](xref:UnityEngine.InputSystem.Pointer.position) from resets and thus prevents mouse positions resetting to `(0,0)`.|
-|"Hard" Resets|In this type, *all* controls are reset to their default value regardless of whether they have [`dontReset`](xref:input-system-layouts#control-items) set or not.|
+|**Soft** Resets|This is the default. With this type, only controls that are not marked as [`dontReset`](xref:input-system-layouts#control-items) are reset to their default value. This excludes controls such as [`Pointer.position`](xref:UnityEngine.InputSystem.Pointer.position) from resets and thus prevents mouse positions resetting to `(0,0)`.|
+|**Hard** Resets|In this type, all controls are reset to their default value regardless of whether they have [`dontReset`](xref:input-system-layouts#control-items) set or not.|
 
-Resetting Controls this way is visible on [Actions](xref:input-system-actions). If you reset a Device that is currently driving one or more Action, the Actions are cancelled. This cancellation is different from sending an event with default state. Whereas the latter may inadvertently [perform](xref:UnityEngine.InputSystem.InputAction.performed) Actions (e.g. a button that was pressed would not appear to have been released), a reset will force clean cancellation.
+Resetting Controls this way is visible on [Actions](xref:input-system-actions). If you reset a Device that is currently driving one or more Action, the Actions are cancelled. This cancellation is different from sending an event with default state. Whereas the latter may inadvertently [perform](xref:UnityEngine.InputSystem.InputAction.performed) Actions (for example, a button that was pressed would not appear to have been released), a reset will force clean cancellation.
 
 Resets may be triggered automatically by the Input System depending on [application focus](#background-and-focus-change-behavior).
 
@@ -148,11 +148,14 @@ If the application is configured to run while in the background (that is, not ha
 
 If the application is configured this way to keep running while in the background, the player loop and thus the Input System, too, will keep running even when the application does not have focus. What happens with respect to input then depends on two factors:
 
-1. On the ability of individual devices to receive input while the application is not running in the foreground. This is only supported by a small subset of devices and platforms. VR devices ([`TrackedDevice`](xref:UnityEngine.InputSystem.TrackedDevice)) such as HMDs and VR controllers generally support this.<br><br>To find out whether a specific device supports this, you can query the [`InputDevice.canRunInBackground`](xref:UnityEngine.InputSystem.InputDevice.canRunInBackground) property. This property can also be forced to true or false via a Device's [layout](xref:input-system-layouts#control-items).
-2. On two settings you can find in the project-wide [Input Settings](xref:input-system-settings). Specifically, [`InputSettings.backgroundBehavior`](xref:UnityEngine.InputSystem.InputSettings.backgroundBehavior) and [`InputSettings.editorInputBehaviorInPlayMode`](xref:UnityEngine.InputSystem.InputSettings.editorInputBehaviorInPlayMode). The table below shows a detailed breakdown of how input behaviors vary based on these two settings and in relation to the `Run In Background` player setting in Unity.
+1. On the ability of individual devices to receive input while the application is not running in the foreground. This is only supported by a small subset of devices and platforms. VR devices ([`TrackedDevice`](xref:UnityEngine.InputSystem.TrackedDevice)) such as HMDs and VR controllers generally support this.
 
-> [!NOTE]
-> [`InputDevice.canRunInBackground`](xref:UnityEngine.InputSystem.InputDevice.canRunInBackground) is overridden by the editor in certain situations (see table below). In general, the value of the property does not have to be the same between the editor and the player and depends on the specific platform and device.
+    To find out whether a specific device supports this, you can query the [`InputDevice.canRunInBackground`](xref:UnityEngine.InputSystem.InputDevice.canRunInBackground) property. This property can also be forced to true or false via a Device's [layout](xref:input-system-layouts#control-items).
+
+    > [!NOTE]
+    > [`InputDevice.canRunInBackground`](xref:UnityEngine.InputSystem.InputDevice.canRunInBackground) is overridden by the editor in certain situations (see table below). In general, the value of the property does not have to be the same between the editor and the player and depends on the specific platform and device.
+
+2. On two settings you can find in the project-wide [Input Settings](xref:input-system-settings): [`InputSettings.backgroundBehavior`](xref:UnityEngine.InputSystem.InputSettings.backgroundBehavior) and [`InputSettings.editorInputBehaviorInPlayMode`](xref:UnityEngine.InputSystem.InputSettings.editorInputBehaviorInPlayMode). The table below shows a detailed breakdown of how input behaviors vary based on these two settings and in relation to the `Run In Background` player setting in Unity.
 
 The following table shows the full matrix of behaviors according to the [Input Settings](xref:input-system-settings) and whether the game is running in the editor or in the player.
 

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

@@ -28,7 +28,7 @@ The best way to resolve the situation of HIDs not working as expected is to add
 
 ## HID output
 
-HIDs can support output (for example, to toggle lights or force feedback motors on a gamepad). Unity controls output by sending HID Output Report commands to a Device. Output reports use Device-specific data formats. To use HID Output Reports, call [`InputDevice.ExecuteCommand`](xref:UnityEngine.InputSystem.InputDevice.ExecuteCommand``1(``0@)) to send a command struct with the [`typeStatic`](../api/UnityEngine.InputSystem.LowLevel.IInputDeviceCommandInfo.html#properties) property set as `"HIDO"` to a Device. The command struct contains the Device-specific data sent out to the HID.
+HIDs can support output (for example, to toggle lights or force feedback motors on a gamepad). Unity controls output by sending HID Output Report commands to a Device. Output reports use Device-specific data formats. To use HID Output Reports, call [`InputDevice.ExecuteCommand`](xref:UnityEngine.InputSystem.InputDevice.ExecuteCommand``1(``0@)) to send a command struct with the [`typeStatic`](xref:UnityEngine.InputSystem.LowLevel.IInputDeviceCommandInfo.typeStatic) property set as `"HIDO"` to a Device. The command struct contains the Device-specific data sent out to the HID.
 
 ## Creating a custom device layout
 

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

@@ -90,9 +90,25 @@ 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. Once you [created some Bindings](xref:input-system-configuring-input#bindings), select the Binding you want to add Interactions to, so that the right pane of the window shows the properties for that Binding. Next, click on the plus icon on the __Interactions__ foldout to open a list of all available Interactions types. 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.
+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 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.
+To add an Interaction:
+
+1. [Create some Bindings](xref:input-system-configuring-input#bindings).
+
+2. Select the Binding you want to add Interactions to. 
+
+    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. 
+
+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 change the [order of Interactions](#multiple-interactions-on-a-binding), click the up and down arrows.
 
 If you create your Bindings in code, you can add Interactions like this:
 
@@ -106,7 +122,7 @@ action.AddBinding("<Gamepad>/leftStick")
 
 Applying Interactions directly to an Action is equivalent to applying them to all Bindings for the Action. It is thus more or less a shortcut that avoids manually adding the same Interaction(s) to each of the Bindings.
 
-If Interactions are applied __both__ to an Action and to its Bindings, then the effect is the same as if the Action's Interactions are *appended* to the list of Interactions on each of the Bindings. This means that the Binding's Interactions are applied *first*, and then the Action's Interactions are applied *after*.
+If Interactions are applied __both__ to an Action and to its Bindings, then the effect is the same as if the Action's Interactions are appended to the list of Interactions on each of the Bindings. This means that the Binding's Interactions are applied first, and then the Action's Interactions are applied after.
 
 You can add and edit Interactions on Actions in the [Input Action Assets](xref:input-system-action-assets) editor window the [same way](#interactions-applied-to-bindings) as you would do for Bindings: select an Action to Edit, then add the Interactions in the right window pane.
 
@@ -243,7 +259,9 @@ 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. Add a class implementing the [`IInputInteraction`](xref:UnityEngine.InputSystem.IInputInteraction) interface, like this:
+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:
 
 ```CSharp
 // Interaction which performs when you quickly move an
@@ -287,13 +305,15 @@ public class MyWiggleInteraction : IInputInteraction
 }
 ```
 
-Now, you need to tell the Input System about your Interaction. Call this method in your initialization code:
+Register your interaction with the Input System in your initialization code:
 
 ```CSharp
 InputSystem.RegisterInteraction<MyWiggleInteraction>();
 ```
 
-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 like this:
+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:
 
 ```CSharp
 var Action = new InputAction(Interactions: "MyWiggle(duration=0.5)");