More work on bindings pages

Also added table to action types page

Author: duckets

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

@@ -1,98 +1,53 @@
 
-## Binding conflict resolution
+# Binding conflicts
 
-For Value type actions, the Input System continuously monitors all the Controls which are bound to the Action, and then chooses the one which is the most actuated to be the Control driving the Action, and report the values from that Control in callbacks, triggered whenever the value changes. If a different bound Control actuated more, then that Control becomes the Control driving the Action, and the Action starts reporting values from that Control. This process is called conflict resolution. This is useful if you want to allow different Controls to control an Action in the game, but only take input from one Control at the same time.
+A binding conflict is when an [action](./actions.md) with more than one [control](./controls.md) [bound](./bindings.md) to it recieves values from multiple controls. 
 
-For more information, see: [Dealing with binding conflicts](./dealing-with-binding-conflicts.md). 
+For example, if the left and right triggers of a gamepad are both bound to an "accelerate" action in your game, each trigger could be pressed in to different amounts. This conflict of recieving two different values for the same action is resolved by the Input System.
 
+## Conflict Resolution
 
+For [value type actions](./action-and-control-types.md), the Input System continuously monitors all the controls bound to the action, and then chooses the one which is the **most actuated** to be the control driving the action. Most actuated means the largest absolute value is being reported, whether positive or negative in the case of a 1D axis, and regardless of direction in the case of 2D and 3D axes. The value of the most actuated control is reported in callbacks, and triggered whenever the value changes.
 
-There are two situations where a given input may lead to ambiguity:
+If a different bound control is actuated more, that control becomes the control driving the action. This process is called **conflict resolution**. This is useful if you want to allow different Controls to control an Action in the game, but only take input from one Control at the same time.
 
-1. Several Controls are bound to the same Action and more than one is feeding input into the Action at the same time. Example: an Action that is bound to both the left and right trigger on a Gamepad and both triggers are pressed.
-2. The input is part of a sequence of inputs and there are several possible such sequences. Example: one Action is bound to the `B` key and another Action is bound to `Shift-B`.
-
-#### Multiple, concurrently used Controls
-
->__Note:__ This section does not apply to [`PassThrough`](RespondingToActions.md#pass-through) Actions as they are by design meant to allow multiple concurrent inputs.
-
-For a [`Button`](RespondingToActions.md#button) or [`Value`](RespondingToActions.md#value) Action, there can only be one Control at any time that is "driving" the Action. This Control is considered the [`activeControl`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_activeControl).
+## Ambiguous situations
 
-When an Action is bound to multiple Controls, the [`activeControl`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_activeControl) at any point is the one with the greatest level of ["actuation"](Controls.md#control-actuation), that is, the largest value returned from [`EvaluateMagnitude`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_EvaluateMagnitude_). If a Control exceeds the actuation level of the current [`activeControl`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_activeControl), it will itself become the active Control.
-
-The following example demonstrates this mechanism with a [`Button`](RespondingToActions.md#button) Action and also demonstrates the difference to a [`PassThrough`](RespondingToActions.md#pass-through) Action.
-
-```CSharp
-// Create a button and a pass-through action and bind each of them
-// to both triggers on the gamepad.
-var buttonAction = new InputAction(type: InputActionType.Button,
-    binding: "<Gamepad>/*Trigger");
-var passThroughAction = new InputAction(type: InputActionType.PassThrough,
-    binding: "<Gamepad>/*Trigger");
+There are two situations where a given input might lead to ambiguity:
 
-buttonAction.performed += c => Debug.Log("${c.control.name} pressed (Button)");
-passThroughAction.performed += c => Debug.Log("${c.control.name} changed (Pass-Through)");
-
-buttonAction.Enable();
-passThroughAction.Enable();
-
-// Press the left trigger all the way down.
-// This will trigger both buttonAction and passThroughAction. Both will
-// see leftTrigger becoming the activeControl.
-Set(gamepad.leftTrigger, 1f);
-
-// Will log
-//   "leftTrigger pressed (Button)" and
-//   "leftTrigger changed (Pass-Through)"
-
-// Press the right trigger halfway down.
-// This will *not* trigger or otherwise change buttonAction as the right trigger
-// is actuated *less* than the left one that is already driving action.
-// However, passThrough action is not performing such tracking and will thus respond
-// directly to the value change. It will perform and make rightTrigger its activeControl.
-Set(gamepad.rightTrigger, 0.5f);
+1. Several controls are bound to the same action and more than one is feeding input into the Action at the same time. Example: an Action that is bound to both the left and right trigger on a Gamepad and both triggers are pressed.
+2. The input is part of a sequence of inputs and there are several possible such sequences. Example: one Action is bound to the `B` key and another Action is bound to `Shift-B`.
 
-// Will log
-//   "rightTrigger changed (Pass-Through)"
+## Multiple concurrently used controls
 
-// Release the left trigger.
-// For buttonAction, this will mean that now all controls feeding into the action have
-// been released and thus the button releases. activeControl will go back to null.
-// For passThrough action, this is just another value change. So, the action performs
-// and its active control changes to leftTrigger.
-Set(gamepad.leftTrigger,  0f);
+>__Note:__ This section does not apply to [pass-through](./configure-action-type.md) actions, which do not perform conflict resolution, and are intended allow multiple concurrent inputs.
 
-// Will log
-//   "leftTrigger changed (Pass-Through)"
-```
+For a **Button** or **Value** [action type](./configure-action-type.md), there can only be one control at any time that is "driving" the action. This control is considered the [`activeControl`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_activeControl).
 
-For [composite bindings](#composite-bindings), magnitudes of the composite as a whole rather than for individual Controls are tracked. However, [`activeControl`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_activeControl) will stick track individual Controls from the composite.
+When an action is bound to multiple controls, the active control at any point is the one with the greatest level of ["actuation"](./control-actuation.md) (the one with the largest value returned from [`EvaluateMagnitude`](../api/UnityEngine.InputSystem.InputControl.html#UnityEngine_InputSystem_InputControl_EvaluateMagnitude_)). If a different control exceeds the actuation level of the current active control, it becomes the active control.
 
-##### Disabling Conflict Resolution
+For [composite bindings](./composite-bindings.md), magnitudes of the composite as a whole rather than for individual controls are tracked. However, [`activeControl`](../api/UnityEngine.InputSystem.InputAction.html#UnityEngine_InputSystem_InputAction_activeControl) will still track individual Controls from the composite.
 
-Conflict resolution is always applied to [Button](RespondingToActions.md#button) and [Value](RespondingToActions.md#value) type Actions. However, it can be undesirable in situations when an Action is simply used to gather any and all inputs from bound Controls. For example, the following Action would monitor the A button of all available gamepads:
+## Disabling Conflict Resolution
 
-```CSharp
-var action = new InputAction(type: InputActionType.PassThrough, binding: "<Gamepad>/buttonSouth");
-action.Enable();
-```
+Conflict resolution is always applied to **Button** or **Value** [action types](./configure-action-type.md). However, it can be undesirable in situations when an action is simply used to gather all inputs from bound Controls. For example, if you have a **Button** type action bound to the **A** button on all gamepads, a user holding down **A** on one gamepad means that the **A** button on other gamepads is ignored.
 
-By using the [Pass-Through](RespondingToActions.md#pass-through) Action type, conflict resolution is bypassed and thus, pressing the A button on one gamepad will not result in a press on a different gamepad being ignored.
+By using the **Pass Through** action type, conflict resolution is bypassed, which means pressing the **A** button on one gamepad will not result in presses on other gamepads being ignored.
 
-#### Multiple input sequences (such as keyboard shortcuts)
+## Multiple input sequences (such as keyboard shortcuts)
 
->__Note__: The mechanism described here only applies to Actions that are part of the same [`InputActionMap`](../api/UnityEngine.InputSystem.InputActionMap.html) or [`InputActionAsset`](../api/UnityEngine.InputSystem.InputActionAsset.html).
+>__Note__: The mechanism described here only applies to Actions that are part of the same [action map](./action-maps-panel.md) or [action assets](./action-assets.md).
 
-Inputs that are used in combinations with other inputs may 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.
+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.
 
-The way this is handled is that Bindings will be processed in the order of decreasing "complexity". This metric is derived automatically from the Binding:
+The way the Input System handles this, is that Bindings are processed in the order of decreasing complexity. This metric is derived automatically from the Binding:
 
-* A binding that is *not* part of a [composite](#composite-bindings) is assigned a complexity of 1.
-* A binding that *is* part of a [composite](#composite-bindings) is assigned a complexity equal to the number of part bindings in the composite.
+* A binding that is *not* part of a [composite](composite-bindings.md) is assigned a complexity of 1.
+* A binding that *is* part of a [composite](composite-bindings.md) is assigned a complexity equal to the number of part bindings in the composite.
 
-In our example, this means that a [`OneModifier`](#one-modifier) composite Binding to `Shift+B` has a higher "complexity" than a Binding to `B` and thus is processed first.
+In our example, this means that a **one-modifier composite** binding to **Shift** + **B** has a higher complexity than a Binding to  **B** and gets processed first.
 
-Additionally, the first Binding that results in the Action changing [phase](RespondingToActions.md#action-callbacks) will "consume" the input. This consuming will result in other Bindings to the same input not being processed. So in our example, when `Shift+B` "consumes" the `B` input, the Binding to `B` will be skipped.
+Additionally, the first Binding that results in the Action changing [phase](./set-callbacks-on-actions.md) will consume the input. This results in other Bindings to the same input not being processed. This means in our example, when the **Shift** + **B** binding consumes the **B** input, the Binding to **B** is skipped.
 
 The following example illustrates how this works at the API level.
 

Packages/com.unity.inputsystem/Documentation~/configure-action-type.md

@@ -1,21 +1,23 @@
 # Configure Action type
 
-When you select an Action in the [Actions Editor Window](./actions-editor.md), you can edit its properties in the right-hand pane of the window.
+When you select an action in the [actions panel](./actions-panel.md) of the [Actions Editor window](./actions-editor.md), you can edit its properties in the right-hand [action properties panel](./action-properties-panel.md).
 
-The first of these properties is the Action Type.
+The first of these properties is the **Action Type**.
 
-![Action Properties](Images/ActionProperties.png)
+The action type influences how the Input System processes state changes for the action, and relate to whether this action represents a discrete on/off button-style interaction or a value that can change gradually over time.
 
- The Action type influences how the Input System processes state changes for the Action, and relate to whether this action represents a discrete on/off button-style interaction or a value that can change gradually over time.
+## Action types
 
-The Action Type setting allows you to choose between **Button**, **Value** or **Pass Through**. The default Action type is Value.
+The **Action Type** setting allows you to choose between **Button**, **Value** or **Pass Through**. The default Action type is Value.
 
-For device controls such as keyboard keys, mouse clicks, or gamepad buttons, which have only an on/off state, and no gradual value changes, select **Button**.
+| Value                         | Description                    |
+| :---------------------------- | :----------------------------- |
+| **Button**                    | Use this for device controls such as keyboard keys, mouse clicks, or gamepad buttons, which have only an on/off state, and no gradual value changes. |
+| **Value**                     | Use this for device controls such as mouse movement, a joystick or gamepad stick, or device orientation that provides gradually changing input over a range of values. |
+| **Pass Through**              | Use this for the same types as **Value**, but this type provides no **phase** information or **conflict resolution** (see below). |
 
-For device controls such as mouse movement, a joystick or gamepad stick, or device orientation that provides gradually changing input over a range of values, select **Value**.
-
-If you select **Button** or **Value* as your Action Type, the Input System also provides data about the action such as whether it has started and stopped (known as the **Phase** of the action), and [conflict resolution](./binding-conflicts.md) in situations where you have mapped multiple bindings to the same action.
+If you select **Button** or **Value** as your Action Type, the Input System also provides data about the action such as whether it has started and stopped (known as the **Phase** of the action), and [conflict resolution](./binding-conflicts.md) in situations where you have mapped multiple bindings to the same action.
 
 The third option, **Pass Through**, is also a value type, and as such is suitable for the same types of device controls as described for **Value**. The difference is that if your action is set to PassThrough, the Input System only provides basic information about the values incoming from the device controls bound to it, and does not provide the extra data relating to the phase of the action, nor does it perform [conflict resolution](./binding-conflicts.md).
 
-Because pass-through actions don't perform conflict resolution, it means they don't use concept of a specific control driving the action. Instead, any change to any of the controls bound to the action triggers a callback with that Control's value. This is useful if you want to process all input from a set of controls, rather than only the most actuated from the set.
+Because pass-through actions don't perform conflict resolution, it means they don't use concept of a specific control driving the action. Instead, any change to any of the controls bound to the action triggers a callback with that Control's value. This is useful if you want to process all input from a set of controls at once on the same action, rather than only the most actuated from the set.

Packages/com.unity.inputsystem/Documentation~/restrict-binding-specific-device.md

@@ -1,11 +1,10 @@
 # Restrict bindings to specific devices
 
-By default, Actions resolve their Bindings against all Devices present in the Input System (that is, [`InputSystem.devices`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_devices)). For example, if there are two gamepads present in the system, a Binding to `<Gamepad>/buttonSouth` picks up both gamepads and allows the Action to be used from either.
+By default, actions [resolve their bindings](./binding-resolution.md) against all devices present that the Input System is aware of (that is, those listed in [`InputSystem.devices`](../api/UnityEngine.InputSystem.InputSystem.html#UnityEngine_InputSystem_InputSystem_devices)). For example, if there are two gamepads connected, a binding to `<Gamepad>/buttonSouth` picks up both gamepads and allows the action to be performed from either gamepad.
 
-You can override this behavior by restricting [`InputActionAssets`](../api/UnityEngine.InputSystem.InputActionAsset.html) or individual [`InputActionMaps`](../api/UnityEngine.InputSystem.InputActionMap.html) to a specific set of Devices. If you do this, Binding resolution only takes the Controls of the given Devices into account.
-
->__Note__: [`InputUser`](user-management.md) and [`PlayerInput`](player-input-component.md) make use of this facility automatically. They set [`InputActionMap.devices`](../api/UnityEngine.InputSystem.InputActionMap.html#UnityEngine_InputSystem_InputActionMap_devices) automatically based on the Devices that are paired to the user.
+You can override this behavior by restricting an [action asset](./action-assets.md) or individual [action maps](./create-edit-delete-action-maps.md) to a specific set of Devices. If you do this, binding resolution only takes the controls of the specified devices into account.
 
+>__Note__: The Input System's [user management](user-management.md) feature and [Player Input component](player-input-component.md) make use of this automatically. They set the [`InputActionMap.devices`](../api/UnityEngine.InputSystem.InputActionMap.html#UnityEngine_InputSystem_InputActionMap_devices) for each player automatically, based on the device that is paired to each user.
 
 To restrict an action map to just the first gamepad: