Fixing CI issues

Author: josepmariapujol-unity

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

@@ -13,7 +13,7 @@ Learn how to investigate and troubleshoot the Input System when something isn't
 | **[Debug an action](debug-action.md)** | Verify enabled actions, bindings, and mapped controls during Play mode. |
 | **[Debug users and PlayerInput](debug-users-playerinput.md)** | Inspect InputUser and Player Input pairings, devices, and actions in the Users list. |
 | **[Debug layouts](debug-layouts.md)** | Browse registered control and device layouts in the Input Debugger. |
-| **[Trace actions](trace-actions)** | Generate a log of all activity that happened on a particular set of Actions. |
+| **[Trace actions](trace-actions.md)** | Generate a log of all activity that happened on a particular set of Actions. |
 | **[Visualizers](visualizers.md)** | Monitor controls and actions in real time with the Visualizers sample. |
 | **[Device Simulation](device-simulation.md)** | Learn how the Unity Device Simulator feeds touchscreen input into the Input System. |
 

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

@@ -16,9 +16,9 @@ The descriptions below describe these main workflows and link to more detailed d
 
 |Workflows | Description |
 |---|---|
-|[**Using Actions**](Workflow-Actions.md)|This is the **recommended** workflow for most situations. In this workflow, you use the [Actions Editor window](./ActionsEditor.md) to configure sets of actions and bindings, then set up references and read the values for those actions in your code.|
-|[**Using Actions and the PlayerInput Component**](Workflow-PlayerInput.md)|This workflow provides extra features that allow you to connect up **callbacks** directly from Actions to your own callback handler methods, removing the need to deal with Action references in your code. It also provides features that are useful in **local multiplayer** scenarios such as device assignment and split-screen functionality.|
-|[**Directly read device states**](Workflow-Direct.md)|This workflow is a simplified, script-only approach which bypasses the actions and bindings features entirely. Instead your script explicitly references specific device controls (such as "left gamepad stick") and reads the values directly. This is suitable for **fast prototyping**, or single fixed platform scenarios. It is a **less flexible** workflow because it bypasses some of the main input system features.|
+|[**Using Actions**](using-actions-workflow.md)|This is the **recommended** workflow for most situations. In this workflow, you use the [Actions Editor window](actions-editor.md) to configure sets of actions and bindings, then set up references and read the values for those actions in your code.|
+|[**Using Actions and the PlayerInput Component**](using-playerinput-workflow.md)|This workflow provides extra features that allow you to connect up **callbacks** directly from Actions to your own callback handler methods, removing the need to deal with Action references in your code. It also provides features that are useful in **local multiplayer** scenarios such as device assignment and split-screen functionality.|
+|[**Directly read device states**](using-direct-workflow.md)|This workflow is a simplified, script-only approach which bypasses the actions and bindings features entirely. Instead your script explicitly references specific device controls (such as "left gamepad stick") and reads the values directly. This is suitable for **fast prototyping**, or single fixed platform scenarios. It is a **less flexible** workflow because it bypasses some of the main input system features.|
 
 > [!NOTE]
 > Because the Input System has multiple workflows, the code samples used throughout this documentation also vary, often demonstrating techniques using various workflows. For example, some code samples may use Action references, and some may use the workflow of reading input directly from devices.

Packages/com.unity.inputsystem/Documentation~/action-properties-panel-reference.md

@@ -14,6 +14,6 @@ The Action Properties panel changes depending on the **Action Type** of the sele
 |**Control Type**| Define the control type for the selected action. Refer to [Action and control types](action-and-control-types.md) for detailed information on control types. <br/><br/>This property is only available when **Action Type** is set to **Value** or **Pass Through**.  |
 |**Initial State Check**| Perform an initial state check when the Action is first enabled, to check the current state of any bound Control. <br/><br/>This setting is only available when Action Type is set to **Button** or **Pass Through**. It is always enabled for **Value**-type actions. Refer to [binding initial state checks|(binding-initial-state-checks.md) for detailed information.
 
-[!include[Interactions reference](include-interactions-reference)]
+[!include[Interactions reference](include-interactions-reference.md)]
 
-[!include[Processors reference](include-processors-reference)]
+[!include[Processors reference](include-processors-reference.md)]

Packages/com.unity.inputsystem/Documentation~/add-processors-bindings-actions.md

@@ -10,7 +10,7 @@ You can add a processor to an action or binding in the Input Actions Editor.
 
 When you create bindings for your [actions](Actions.md), you can choose to add Processors to the bindings. These process the values from the controls they bind to, before the system applies them to the Action value. For instance, you might want to invert the `Vector2` values from the controls along the Y-axis before passing these values to the Action that drives the input logic for your application. To do this, you can add an [Invert Vector2](built-in-processors.md) Processor to your binding.
 
-If you're using Actions defined in the [Input Actions Editor](ActionsEditor.md), or in an [action asset](ActionAssets.md), you can add any Processor to your bindings in the Input Action editor:
+If you're using Actions defined in the [Input Actions Editor](actions-editor.md), or in an [action asset](action-assets.md), you can add any Processor to your bindings in the Input Action editor:
 
 1. Select the binding you want to add Processors to so that the Binding Properties panel shows up on the right side.
 2. Select the **Add (+)** icon on the __Processors__ foldout to open a list of all available Processors that match your control type.
@@ -33,7 +33,7 @@ action.AddBinding("<Gamepad>/leftStick")
 
 Processors on Actions work in the same way as Processors on bindings, but they affect all controls bound to an Action, rather than just the controls from a specific binding. If there are Processors on both the binding and the Action, the system processes the ones from the binding first.
 
-You can add and edit Processors on Actions in the [Input Actions Editor](ActionsEditor.md), or in an  [action asset](ActionAssets.md) the [same way](#processors-on-bindings) as you would for bindings: select an Action to edit, then add one or more Processors in the right window pane.
+You can add and edit Processors on Actions in the [Input Actions Editor](actions-editor.md), or in an  [action asset](action-assets.md) the [same way](#processors-on-bindings) as you would for bindings: select an Action to edit, then add one or more Processors in the right window pane.
 
 If you create your Actions in code, you can add Processors like this:
 

Packages/com.unity.inputsystem/Documentation~/add-processors-controls.md

@@ -4,7 +4,7 @@ uid: input-system-add-processors-controls
 
 # Add processors to controls
 
-You can have any number of Processors directly on an [`InputControl`](xref:UnityEngine.InputSystem.InputControl), which then process the values read from the Control. Whenever you call [`ReadValue`](xref:UnityEngine.InputSystem.InputControl-1) on a Control, all Processors on that Control process the value before it gets returned to you. You can use [`ReadUnprocessedValue`](xref:UnityEngine.InputSystem.InputControl-1) on a Control to bypass the Processors.
+You can have any number of Processors directly on an [`InputControl`](xref:UnityEngine.InputSystem.InputControl), which then process the values read from the Control. Whenever you call [`ReadValue`](xref:UnityEngine.InputSystem.InputControl`1) on a Control, all Processors on that Control process the value before it gets returned to you. You can use [`ReadUnprocessedValue`](xref:UnityEngine.InputSystem.InputControl`1) on a Control to bypass the Processors.
 
 The Input System adds Processors to a Control during device creation, if they're specified in the Control's [layout](Layouts.md). You can't add Processors to existing Controls after they've been created, so you can only add Processors to Controls when you're [creating custom devices](custom-devices.md). The devices that the Input System supports out of the box already have some useful Processors added on their Controls. For instance, sticks on gamepads have a [Stick Deadzone](built-in-processors.md) Processor.
 

Packages/com.unity.inputsystem/Documentation~/binding-conflicts.md

@@ -38,7 +38,7 @@ For [composite bindings](./composite-bindings.md), magnitudes of the composite a
 > The mechanism described here only applies to Actions that are part of the same [action map](./input-actions-editor-window-reference.md#action-maps-panel-reference) or [action assets](./action-assets.md).
 
 > [!NOTE]
-> To use automatic composite complexity as described below, in **Project Settings** > **Input System Package**, enable __Complexity-Based Shortcut Resolution__ ([`InputSettings.shortcutKeysConsumeInput`](xref:UnityEngine.InputSystem.InputSettings.shortcutKeysConsumeInput)) and leave __Action Priority Shortcut Resolution__ ([`InputSettings.shortcutKeysUseActionPriority`](xref:UnityEngine.InputSystem.InputSettings.shortcutKeysUseActionPriority)) disabled. If __Action Priority Shortcut Resolution__ is enabled, overlaps are resolved using each action's [`InputAction.Priority`](xref:UnityEngine.InputSystem.InputAction.Priority) instead. Refer to [Input settings](xref:input-system-settings#improved-shortcut-support) for details.
+> To use automatic composite complexity as described below, in **Project Settings** > **Input System Package**, enable __Complexity-Based Shortcut Resolution__ ([`InputSettings.shortcutKeysConsumeInput`](xref:UnityEngine.InputSystem.InputSettings.shortcutKeysConsumeInput)) and leave __Action Priority Shortcut Resolution__ ([`InputSettings.shortcutKeysUseActionPriority`](xref:UnityEngine.InputSystem.InputSettings.shortcutKeysUseActionPriority)) disabled. If __Action Priority Shortcut Resolution__ is enabled, overlaps are resolved using each action's [`InputAction.Priority`](xref:UnityEngine.InputSystem.InputAction.Priority) instead. Refer to [Input settings](xref:input-system-settings) for details.
 
 Inputs used in combinations with other inputs can also lead to ambiguities. If, for example, the **B** key on the Keyboard is bound both on its own as well as in combination with the **Shift** key, then if you first press **Shift** and then **B**, the latter key press would be a valid input for either of the Actions.
 

Packages/com.unity.inputsystem/Documentation~/binding-properties-panel-reference.md

@@ -26,7 +26,7 @@ When you create a [composite binding](composite-bindings.md), the Binding Proper
 |-|-|
 |**Composite Type**|Select the [composite type](composite-bindings.md) of the selected binding. The options are: <br/>- **1D Axis**: Create a composite binding made of two buttons: one that pulls a 1D axis in its negative direction, and another that pulls it in its positive direction. <br/>- **2D Vector**: Create a composite binding that represents a 4-way button setup like the D-pad on gamepads. <br/>- **3D Vector**: Create a composite binding that represents a 6-way button where two combinations each control one axis of a 3D vector. <br/>- **One Modifier**: Create a composite binding that requires the user to hold down a "modifier" button in addition to another control from which the actual value of the binding is determined. <br/>- **Two Modifiers**: Create a composite binding that requires the user to hold down a "modifier" button in addition to another control from which the actual value of the binding is determined. |
 
-For more information on the composite types that are available by default, refer to scripting documentation on [`InputSystem.Composites`](../api/UnityEngine.InputSystem.Composites). Others might also be available if your project contains custom composite binding types.
+For more information on the composite types that are available by default, refer to scripting documentation on [`InputSystem.Composites`](../api/UnityEngine.InputSystem.Composites.html). Others might also be available if your project contains custom composite binding types.
 
 ### Axis binding reference
 
@@ -36,7 +36,7 @@ When **Composite Type** is set to **1D Axis**, the Binding Properties panel disp
 |-|-|
 |**Which Side Wins**|Define what happens when both buttons are triggered at the same time. <br/>- **Positive**: Prioritize the Positive binding. <br/>- **Negative**: Prioritize the Negative binding. <br/>- **Neither**: Do nothing when both bindings are triggered at the same time. |
 
-For more details, refer to scripting reference documentation on [`Composites.AxisComposite`](..api/UnityEngine.InputSystem.Composites.AxisComposite.html).
+For more details, refer to scripting reference documentation on [`Composites.AxisComposite`](../api/UnityEngine.InputSystem.Composites.AxisComposite.html).
 
 ### Vector binding reference
 
@@ -46,7 +46,7 @@ When **Composite Type** is set to **2D Vector** or **3D Vector**, the Binding Pr
 |-|-|
 |**Mode**| Select the process that the Input System uses to calculate a Vector2 or Vector3 from the input values provided. <br/>- **Analog**: Accept and use the floating-point values from controls. <br/>- **Digital**: Treat control values as on/off, and do not normalize the resulting vector. <br/>- **Digital Normalized**: Treat control values as on/off, and normalize the resulting vector. |
 
-For more details on each mode, refer to scripting reference documentation on  [`Vector2Composite.Mode`](../api/UnityEngine.InputSystem.Composites.Vector2Composite.Mode) and [`Vector3Composite.Mode`](../api/UnityEngine.InputSystem.Composites.Vector3Composite.Mode).
+For more details on each mode, refer to scripting reference documentation on  [`Vector2Composite.Mode`](../api/UnityEngine.InputSystem.Composites.Vector2Composite.Mode.html) and [`Vector3Composite.Mode`](../api/UnityEngine.InputSystem.Composites.Vector3Composite.Mode.html).
 
 ### Binding with modifier reference
 
@@ -57,8 +57,8 @@ When **Composite Type** is set to **One Modifier**, **Two Modifiers**, **Button
 |**Override Modifiers Need To Be Pressed First**| **Note**: This property is obsolete. Use the **Modifiers Order** property instead.<br/><br/>Override the Input Consumption setting, so that the composite binding still triggers if the modifiers are pressed after the button. |
 |**Modifiers order**| Define the order in which buttons and modifiers must be pressed in order to trigger the composite binding. <br/>- **Default**: Apply the Input Consumption setting.  <br/>- **Ordered**: Only trigger the binding if the modifiers are in a pressed state before the button enters a pressed state.   <br/>- **Unordered**: Allow the binding to trigger regardless of the order in which the buttons and modifiers enter a pressed state. |
 
-For more details, refer to scripting reference documentation on [`OneModifierComposite`](..api/UnityEngine.InputSystem.Composites.OneModifierComposite.html), [`TwoModifiersComposite`](..api/UnityEngine.InputSystem.Composites.TwoModifiersComposite.html), [`ButtonWithOneModifier`](..api/UnityEngine.InputSystem.Composites.ButtonWithOneModifier.html), and [`ButtonWithTwoModifiers`](..api/UnityEngine.InputSystem.Composites.ButtonWithTwoModifiers.html).
+For more details, refer to scripting reference documentation on [`OneModifierComposite`](../api/UnityEngine.InputSystem.Composites.OneModifierComposite.html), [`TwoModifiersComposite`](../api/UnityEngine.InputSystem.Composites.TwoModifiersComposite.html), [`ButtonWithOneModifier`](../api/UnityEngine.InputSystem.Composites.ButtonWithOneModifier.html), and [`ButtonWithTwoModifiers`](../api/UnityEngine.InputSystem.Composites.ButtonWithTwoModifiers.html).
 
-[!include[Interactions reference](include-interactions-reference)]
+[!include[Interactions reference](include-interactions-reference.md)]
 
-[!include[Processors reference](include-processors-reference)]
+[!include[Processors reference](include-processors-reference.md)]

Packages/com.unity.inputsystem/Documentation~/configure-bindings-from-code.md

@@ -377,7 +377,7 @@ You can define new types of Composites, and register them with the API. Unity tr
 To define a new type of Composite, create a class based on [`InputBindingComposite<TValue>`](xref:UnityEngine.InputSystem.InputBindingComposite`1).
 
 > [!IMPORTANT]
-> Composites must be __stateless__. This means that you cannot store local state that changes depending on the input being processed. For __stateful__ processing on bindings, refer to [interactions](xref:input-system-interactions#writing-custom-interactions).
+> Composites must be __stateless__. This means that you cannot store local state that changes depending on the input being processed. For __stateful__ processing on bindings, refer to [interactions](xref:input-system-custom-interactions).
 
 ```CSharp
 // Use InputBindingComposite<TValue> as a base class for a composite that returns
@@ -455,7 +455,7 @@ The Composite should now appear in the editor UI when you add a binding, and you
         .With("secondpart", "<Gamepad>/buttonNorth");
 ```
 
-To define a custom parameter editor for the Composite, you can derive from  [`InputParameterEditor<TObject>`](xref:UnityEngine.InputSystem.Editor.InputParameterEditor-1).
+To define a custom parameter editor for the Composite, you can derive from  [`InputParameterEditor<TObject>`](xref:UnityEngine.InputSystem.Editor.InputParameterEditor`1).
 
 ```CSharp
 #if UNITY_EDITOR

Packages/com.unity.inputsystem/Documentation~/configure-ui-input-action-map.md

@@ -23,7 +23,7 @@ You can modify, add, or remove bindings to the named actions in the UI action ma
 * The names of the actions it contains
 * Their respective **Action Types**.
 
-To see the specific actions and types that the [UI Input Module](xref:UnityEngine.InputSystem.UI.InputSystemUIInputModule) class expects, refer to the [UI action map reference](ui-action-map-reference).
+To see the specific actions and types that the [UI Input Module](xref:UnityEngine.InputSystem.UI.InputSystemUIInputModule) class expects, refer to the [UI action map reference](ui-action-map-reference.md).
 
 ## Reset the UI action map