Updating anchor links

Author: suearkinunity

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

@@ -19,7 +19,7 @@ The Input System can also send data back to the native backend in the form of [c
 
 The low-level Input System code processes and interprets the memory from the event stream that the native backend provides, and dispatches individual events.
 
-The Input System creates Device representations for any newly discovered Device in the event stream. The low-level code sees a Device as a block of raw, unmanaged memory. If it receives a state event for a Device, it writes the data from the state event into the Device's [state representation](controls.md#control-state) in memory, so that the state always contains an up-to-date representation of the Device and all its Controls.
+The Input System creates Device representations for any newly discovered Device in the event stream. The low-level code sees a Device as a block of raw, unmanaged memory. If it receives a state event for a Device, it writes the data from the state event into the Device's [state representation](control-state.md) in memory, so that the state always contains an up-to-date representation of the Device and all its Controls.
 
 The low-level system code also contains structs which describe the data layout of commonly known Devices.
 
@@ -31,4 +31,4 @@ The high-level Input System code interprets the data in a Device's state buffers
 
 Based on the information in the layouts, the Input System then creates [Control](controls.md) representations for each of the Device's controls, which let you read the state of each individual Control in a Device.
 
-As part of the high-level system, you can also build another abstraction layer to map Input Controls to your application mechanics. Use [Actions](actions.md) to [bind](bindings.md) one or more Controls to an input in your application. The Input System then monitors these Controls for state changes, and notifies your game logic using [callbacks](respond-to-input.md#responding-to-actions-using-callbacks). You can also specify more complex behaviors for your Actions using [Processors](processors.md) (which perform processing on the input data before sending it to you) and [Interactions](Interactions.md) (which let you specify patterns of input on a Control to listen to, such as multi-taps).
+As part of the high-level system, you can also build another abstraction layer to map Input Controls to your application mechanics. Use [Actions](actions.md) to [bind](bindings.md) one or more Controls to an input in your application. The Input System then monitors these Controls for state changes, and notifies your game logic using [callbacks](set-callbacks-on-actions.md). You can also specify more complex behaviors for your Actions using [Processors](processors.md) (which perform processing on the input data before sending it to you) and [Interactions](Interactions.md) (which let you specify patterns of input on a Control to listen to, such as multi-taps).

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

@@ -39,7 +39,7 @@ Use the same techniques shown for the "Jump" action in the [Workflows section](w
 
 - [make my left-hand XR controller my right-hand one?](xref:UnityEngine.InputSystem.XR.XRController)
 
-- [get all current touches from the touchscreen?](devices-touch.md#reading-all-touches)
+- [get all current touches from the touchscreen?](touch-polling.md#read-all-touches)
 
 - [deal with my gamepad data arriving in a format different from `GamepadState`?](xref:UnityEngine.InputSystem.LowLevel.GamepadState)
 
@@ -49,8 +49,8 @@ Use the same techniques shown for the "Jump" action in the [Workflows section](w
 
 - [give my head tracking an extra update before rendering?](xref:UnityEngine.InputSystem.XR.XRHMD)
 
-- [record events flowing through the system?](debugging.md#other-tips)
+- [record events flowing through the system?](see-record-input-event-flow.md)
 
-- [see events as they're processed?](debugging.md#other-tips)
+- [see events as they're processed?](see-record-input-event-flow.md)
 
 - [see what Devices I have and what state they're in?](debug-device.md)

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

@@ -4,7 +4,7 @@ uid: input-system-processors
 
 # Processors
 
-Use an input processor to apply processing to input values and return the result. For example, you can use a [clamp](built-in-processors.md#clamp) processor to clamp values to within a certain range.
+Use an input processor to apply processing to input values and return the result. For example, you can use a [clamp](built-in-processors.md) processor to clamp values to within a certain range.
 
 | **Topic** | **Description** |
 | :--- | :--- |

Packages/com.unity.inputsystem/Documentation~/about-user-management.md

@@ -9,7 +9,7 @@ The Input System supports multi-user management through the [`InputUser`](xref:U
 > [!NOTE]
 > The user management API is quite low-level in nature. The stock functionality of Player Input Manager component (refer to [Player Input Manager](player-input-manager-component.md)) provides an easier way to set up user management. The API described here is useful when you want more control over user management.
 
-In the Input System, each [`InputUser`](xref:UnityEngine.InputSystem.Users.InputUser) represents a human interacting with the application. For example, you can have multiple users playing a game together on a single computer or device (local multiplayer), where each user has one or more [paired Input Devices](#device-pairing).
+In the Input System, each [`InputUser`](xref:UnityEngine.InputSystem.Users.InputUser) represents a human interacting with the application. For example, you can have multiple users playing a game together on a single computer or device (local multiplayer), where each user has one or more [paired Input Devices](create-user-paired-with-input-device.md).
 
 The [`PlayerInputManager`](player-input-manager-component.md) class uses [`InputUser`](xref:UnityEngine.InputSystem.Users.InputUser) internally to handle users.
 

Packages/com.unity.inputsystem/Documentation~/add-layout-from-cs.md

@@ -37,14 +37,14 @@ You can then register the layout with [`InputSystem.RegisterLayout`](xref:UnityE
 InputSystem.RegisterLayout<MyDevice>();
 ```
 
-When the layout is instantiated, the system looks at every field and property defined directly in the type to potentially turn it into one or more [Control items](#control-items).
+When the layout is instantiated, the system looks at every field and property defined directly in the type to potentially turn it into one or more [Control items](control-items.md).
 
 1. If the field or property is annotated with [`InputControlAttribute`](xref:UnityEngine.InputSystem.Layouts.InputControlAttribute), the system applies the attribute's properties to the Control item. Some special defaults apply in this case:
     * If no [`offset`](xref:UnityEngine.InputSystem.Layouts.InputControlAttribute) is set, and the attribute is applied to a field, [`offset`](xref:UnityEngine.InputSystem.Layouts.InputControlAttribute) defaults to the offset of the field.
     * If no [`name`](xref:UnityEngine.InputSystem.Layouts.InputControlAttribute) is set, it defaults to the name of the property/field.
     * If no [`layout`](xref:UnityEngine.InputSystem.Layouts.InputControlAttribute) is set, the system infers it from the type of the field/property.
 2. If the field or property has a struct type which implements [`IInputStateTypeInfo`](xref:UnityEngine.InputSystem.LowLevel.IInputStateTypeInfo), the field is considered to be an embedded [state struct](#using-a-state-structure) and the system recurses into the field or property to gather Controls from it.
-3. Otherwise, if the type of the field or property is based on [`InputControl`](xref:UnityEngine.InputSystem.InputControl), the system adds a [Control item](#control-items) similar to case 1, where the member is annotated with [`InputControlAttribute`](xref:UnityEngine.InputSystem.Layouts.InputControlAttribute).
+3. Otherwise, if the type of the field or property is based on [`InputControl`](xref:UnityEngine.InputSystem.InputControl), the system adds a [Control item](control-items.md) similar to case 1, where the member is annotated with [`InputControlAttribute`](xref:UnityEngine.InputSystem.Layouts.InputControlAttribute).
 
 ## Using a state structure
 

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

@@ -8,7 +8,7 @@ You can add a processor to an action or binding in the Input Actions Editor.
 
 ## Processors on bindings
 
-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](ProcessorTypes.md#invert-vector-2) Processor to your binding.
+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:
 

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

@@ -6,9 +6,9 @@ uid: input-system-add-processors-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.
 
-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](Devices.md#creating-custom-devices). 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](ProcessorTypes.md#stick-deadzone) Processor.
+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.
 
-If you're using a layout generated by the Input System from a [state struct](Devices.md#step-1-the-state-struct) using [`InputControlAttributes`](xref:UnityEngine.InputSystem.Layouts.InputControlAttribute), you can specify the Processors you want to use with the [`processors`](xref:UnityEngine.InputSystem.Layouts.InputControlAttribute) property of the attribute, like this:
+If you're using a layout generated by the Input System from a [state struct](step-1-state-struct.md) using [`InputControlAttributes`](xref:UnityEngine.InputSystem.Layouts.InputControlAttribute), you can specify the Processors you want to use with the [`processors`](xref:UnityEngine.InputSystem.Layouts.InputControlAttribute) property of the attribute, like this:
 
 ```CSharp
 public struct MyDeviceState : IInputStateTypeInfo
@@ -23,7 +23,7 @@ public struct MyDeviceState : IInputStateTypeInfo
 }
 ```
 
-If you [create a layout from JSON](Layouts.md#layout-from-json), you can specify Processors on your Controls like this:
+If you [create a layout from JSON](add-layout-from-json.md), you can specify Processors on your Controls like this:
 
 ```CSharp
 {

Packages/com.unity.inputsystem/Documentation~/apply-interactions-bindings.md

@@ -12,7 +12,7 @@ To apply Interactions to all bindings on an Action, refer to [Apply Interactions
 
 If you're using [project-wide actions](actions-editor.md), or [Input action assets](action-assets.md), you can add any Interaction to your bindings with the Input Action editor. 
 
-1. Once you have [created some bindings](actions-editor.md#bindings), select the binding you want to add Interactions to, so that the right pane of the window displays the properties for that binding. 
+1. Once you have [created some bindings](binding-properties-panel-reference.md), select the binding you want to add Interactions to, so that the right pane of the window displays the properties for that binding. 
 1. Select the plus icon on the __Interactions__ foldout to open a list of all available Interactions types. 
 1. Select an Interaction type to add an Interaction instance of that type. The Interaction now appears in the __Interactions__ foldout. 
 1. If the Interaction has any parameters, you can edit them at this stage.

Packages/com.unity.inputsystem/Documentation~/background-behavior.md

@@ -11,7 +11,7 @@ This setting is only relevant when "Run In Background" is enabled in the [Player
 In the Editor, "Run In Background" is considered to always be enabled as the player loop is kept running regardless of whether a Game View is focused or not. Also, in development players on desktop platforms, the setting is force-enabled during the build process.
 
 > [!NOTE]
-> In the editor, `Background Behavior` is further influenced by [`Play Mode Input Behavior`](#play-mode-input-behavior). Refer to [Background and Focus Change Behavior](device-background-focus-changes.md) for a detailed breakdown. In particular, which devices are considered as [`canRunInBackground`](xref:UnityEngine.InputSystem.InputDevice) partly depends on the [`Play Mode Input Behavior`](#play-mode-input-behavior) setting.
+> In the editor, `Background Behavior` is further influenced by [`Play Mode Input Behavior`](platform-specific-settings.md#play-mode-input-behavior). Refer to [Background and Focus Change Behavior](device-background-focus-changes.md) for a detailed breakdown. In particular, which devices are considered as [`canRunInBackground`](xref:UnityEngine.InputSystem.InputDevice) partly depends on the [`Play Mode Input Behavior`](platform-specific-settings.md#play-mode-input-behavior) setting.
 
 |Setting|Description|
 |----|-----------|

Packages/com.unity.inputsystem/Documentation~/bind-touch-input.md

@@ -17,4 +17,4 @@ If you want to get input from multiple touches in the action:
 * Use bindings like `<Touchscreen>/touch3/press` to bind to individual touches.  
 * Alternatively, use a wildcard binding to bind one action to all touches. For example, `<Touchscreen>/touch*/press`.
 
-If you bind a single action to input from multiple touches, set the action type to [pass-through](respond-to-input.md#pass-through) so the action gets callbacks for each touch, instead of just one.
+If you bind a single action to input from multiple touches, set the action type to [pass-through](about-action-control-types.md#action-type) so the action gets callbacks for each touch, instead of just one.