PR 2253 note formatting

Author: suearkinunity

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

@@ -5,7 +5,8 @@ uid: input-system-contributing
 
 The [full source code](https://github.com/Unity-Technologies/InputSystem) for the Input System is available on GitHub. This is also where most of the Input System's development happens.
 
->__Note__: This includes the full source code for the managed/C# part of the system. At this point, the native, platform-specific C++ backends are still closed-source and require a source code license.
+> [!NOTE]
+> This includes the full source code for the managed/C# part of the system. At this point, the native, platform-specific C++ backends are still closed-source and require a source code license.
 
 ## Reporting bugs
 

Packages/com.unity.inputsystem/Documentation~/about-layouts.md

@@ -6,7 +6,8 @@ uid: input-system-about-layouts
 
 Layouts are the central mechanism by which the Input System learns about types of Input Devices and Input Controls. Each layout represents a specific composition of Input Controls. By matching the description of a Device to a layout, the Input System is able to create the correct type of Device and interpret the incoming input data correctly.
 
->__Note__: Layouts are an advanced, mostly internal feature of the Input System. Knowledge of the layout system is mostly useful if you want to support custom Devices or change the behavior of existing Devices.
+> [!NOTE]
+> Layouts are an advanced, mostly internal feature of the Input System. Knowledge of the layout system is mostly useful if you want to support custom Devices or change the behavior of existing Devices.
 
 A layout describes a memory format for input, and the Input Controls to build in order to read and write data to or from that memory.
 

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

@@ -6,10 +6,12 @@ uid: input-system-user-management-about
 
 The Input System supports multi-user management through the [`InputUser`](xref:UnityEngine.InputSystem.Users.InputUser) class. This comprises both user account management features on platforms that have these capabilities built into them (such as Xbox and PS4), as well as features to manage Device allocations to one or more local users.
 
->__Note__: The user management API is quite low-level in nature. The stock functionality of Player Input Manager component (see [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.
+> [!NOTE]
+> The user management API is quite low-level in nature. The stock functionality of Player Input Manager component (see [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).
 
 The [`PlayerInputManager`](player-input-manager-component.md) class uses [`InputUser`](xref:UnityEngine.InputSystem.Users.InputUser) internally to handle users.
 
->__Note__: In the editor, all `InputUser` instances are automatically removed when exiting play mode thus also removing any device pairings. In essence, `InputUser` is considered a player-only API.
+> [!NOTE]
+> In the editor, all `InputUser` instances are automatically removed when exiting play mode thus also removing any device pairings. In essence, `InputUser` is considered a player-only API.

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

@@ -10,7 +10,8 @@ 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). See [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.
+> [!NOTE]
+> In the editor, `Background Behavior` is further influenced by [`Play Mode Input Behavior`](#play-mode-input-behavior). See [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.
 
 |Setting|Description|
 |----|-----------|

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

@@ -34,7 +34,8 @@ For [composite bindings](./composite-bindings.md), magnitudes of the composite a
 
 ## Multiple input sequences (such as keyboard shortcuts)
 
->__Note__: 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]
+> 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).
 
 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~/composite-bindings.md

@@ -23,4 +23,5 @@ The **Add binding (+)** menu contains the following options.
 | **Add Binding With One Modifier** | Adds a composite with two sub-bindings, named **Binding** and **Modifier**, which requires the user to hold down the **modifier** button in addition to another control from which the actual value of the binding is determined. This can be used, for example, for bindings such as "SHIFT+1". Implemented in the [`OneModifierComposite`](xref:UnityEngine.InputSystem.Composites.OneModifierComposite) class. The buttons can be on any Device, and can be toggle buttons or full-range buttons such as gamepad triggers.<br/><br/>The output is a [value of the same type](control-types-reference.md) as the control bound to the sub-binding named **Binding**. |
 | **Add Binding With Two Modifiers** | Adds a composite with three sub-bindings, named **Binding**, **Modifier 1** and **Modifier 2**, which requires the user to hold down two modifier buttons in addition to another control from which the actual value of the binding is determined. This can be used, for example, for bindings such as "SHIFT+CTRL+1". Implemented in the [`TwoModifiersComposite`](xref:UnityEngine.InputSystem.Composites.TwoModifiersComposite) class. The buttons can be on any Device, and can be toggle buttons or full-range buttons such as gamepad triggers.<br/><br/>The output is a [value of the same type](control-types-reference.md) as the control bound to the sub-binding named **Binding**. |
 
-> **Note**: You can also [create custom composite bindings from code](./create-custom-composite-binding.md)
+> [!NOTE]
+> You can also [create custom composite bindings from code](./create-custom-composite-binding.md)

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

@@ -236,7 +236,8 @@ If Controls from both the `positive` and the `negative` side are actuated, then
 |(1) `Positive`|The positive side has precedence and the Composite returns `maxValue`.|
 |(2) `Negative`|The negative side has precedence and the Composite returns `minValue`.|
 
->__Note__: There is no support yet for interpolating between the positive and negative over time.
+> [!NOTE]
+> There is no support yet for interpolating between the positive and negative over time.
 
 ### 2D vector
 
@@ -274,7 +275,8 @@ In addition, you can set the following parameters on a 2D vector Composite:
 |---------|-----------|
 |[`mode`](xref:UnityEngine.InputSystem.Composites.Vector2Composite)|Whether to treat the inputs as digital or as analog controls.<br><br>If this is set to [`Mode.DigitalNormalized`](xref:UnityEngine.InputSystem.Composites.Vector2Composite.Mode), inputs are treated as buttons (off if below [`defaultButtonPressPoint`](xref:UnityEngine.InputSystem.InputSettings) and on if equal to or greater). Each input is 0 or 1 depending on whether the button is pressed or not. The vector resulting from the up/down/left/right parts is normalized. The result is a diamond-shaped 2D input range.<br><br>If this is set to [`Mode.Digital`](xref:UnityEngine.InputSystem.Composites.Vector2Composite.Mode), the behavior is essentially the same as [`Mode.DigitalNormalized`](xref:UnityEngine.InputSystem.Composites.Vector2Composite.Mode) except that the resulting vector is not normalized.<br><br>Finally, if this is set to [`Mode.Analog`](xref:UnityEngine.InputSystem.Composites.Vector2Composite.Mode), inputs are treated as analog (i.e. full floating-point values) and, other than [`down`](xref:UnityEngine.InputSystem.Composites.Vector2Composite) and [`left`](xref:UnityEngine.InputSystem.Composites.Vector2Composite) being inverted, values will be passed through as is.<br><br>The default is [`Mode.DigitalNormalized`](xref:UnityEngine.InputSystem.Composites.Vector2Composite.Mode).|
 
->__Note__: There is no support yet for interpolating between the up/down/left/right over time.
+> [!NOTE]
+> There is no support yet for interpolating between the up/down/left/right over time.
 
 ### 3D vector
 
@@ -371,7 +373,8 @@ 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, see [interactions](write-custom-interactions.md).
+> [!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, see [interactions](write-custom-interactions.md).
 
 ```CSharp
 // Use InputBindingComposite<TValue> as a base class for a composite that returns

Packages/com.unity.inputsystem/Documentation~/configure-player-input-manager-component.md

@@ -4,7 +4,7 @@ uid: input-system-configure-player-input-manager
 
 # Configure the Player Input Manager component
 
-![PlayerInputManager](Images/PlayerInputManager.png)
+![On the PlayerInputManager component, the Notification Behavior value displays Send Messages, the Join Behavior value displays Join Players When Button Is Pressed, and the Joining Enabled By Default value is checked.](Images/PlayerInputManager.png)
 
 |Property|Description|
 |--------|-----------|

Packages/com.unity.inputsystem/Documentation~/configure-unity-events.md

@@ -6,13 +6,13 @@ uid: input-system-configure-unity-events
 
 You can use the following properties to configure `PlayerInput`:
 
-|Property|Description|
-|--------|-----------|
-|[`Actions`](xref:UnityEngine.InputSystem.PlayerInput)|The set of [Input Actions](actions.md) associated with the player. Typically you would set this to Project-Wide Actions, however you can assign an [ActionAsset](action-assets.md) reference here). To receive input, each player must have an associated set of Actions. See documentation on [Actions](#actions) for details.|
-|[`Default Control Scheme`](xref:UnityEngine.InputSystem.PlayerInput)|Which [Control Scheme](control-schemes.md) (from what is defined in [`Actions`](xref:UnityEngine.InputSystem.PlayerInput)) to enable by default.|
-|[`Default Action Map`](xref:UnityEngine.InputSystem.PlayerInput)|Which [Action Map](actions.md) in [`Actions`](xref:UnityEngine.InputSystem.PlayerInput) to enable by default. If set to `None`, then the player starts with no Actions being enabled.|
-|[`Camera`](xref:UnityEngine.InputSystem.PlayerInput)|The individual camera associated with the player. This is only required when employing [split-screen](player-input-manager-component.md#split-screen) setups and has no effect otherwise.|
-|[`Behavior`](xref:UnityEngine.InputSystem.PlayerInput)|How the `PlayerInput` component notifies game code about things that happen with the player. See documentation on [notification behaviors](#notification-behaviors).|
+| Component (UI) property | Description | Matching property |
+| -- | -- | -- |
+| **Actions** | The set of [Input Actions](xref:input-system-actions) associated with the player. Typically you would set this to Project-Wide Actions, however you can also assign an [ActionAsset](xref:input-system-action-assets) reference instead. To receive input, each player must have an associated set of [Actions](#actions). | [`actions`](xref:UnityEngine.InputSystem.PlayerInput.actions) |
+| **Default Scheme** | The [Control Scheme](xref:input-system-action-bindings#control-schemes) to enable by default, as defined in the [`PlayerInput.actions`](xref:UnityEngine.InputSystem.PlayerInput.actions) property. | [`defaultControlScheme`](xref:UnityEngine.InputSystem.PlayerInput.defaultControlScheme) |
+| **Default Map** | The [Action Map](xref:input-system-actions#scripting-access) in the [`PlayerInput.actions`](xref:UnityEngine.InputSystem.PlayerInput.actions) property to enable by default. If set to `None`, then the player starts with no Actions being enabled. | [`defaultActionMap`](xref:UnityEngine.InputSystem.PlayerInput.defaultActionMap) |
+| **Camera** | The individual camera associated with the player. This is only required when employing [split-screen](xref:input-system-player-input-manager#split-screen) setups and has no effect otherwise. | [`camera`](xref:UnityEngine.InputSystem.PlayerInput.camera) |
+| **Behavior** | How the `PlayerInput` component [notifies](#notification-behaviors) game code about input actions and other input-related events happening to the player or that the player initiates. | [`notificationBehavior`](xref:UnityEngine.InputSystem.PlayerInput.notificationBehavior) |
 
 ## Actions