DOCS: cm reorg docf-6476 docf-6393 #2113
Conversation
Also added table to action types page
|
|
||
| The first of these properties is the **Action Type**. | ||
|
|
||
| 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. |
There was a problem hiding this comment.
| 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 relates 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 |
There was a problem hiding this comment.
I think this is still a mixture of task and reference - I would expect this table to be on a page that is a reference for the whole Input Actions window, called something like "Input Actions reference". That window is quite big so if the page was too long, perhaps you'd divide it into smaller pages like "Action maps reference" "Action properties reference" and so on.
Then, I think I would frame this page as something like "Configure input state changes" (make it more outcome focused than ui focused - Action Type is a thing that doesn't mean much by itself).
Then make it more task focused e.g
To configure how the input system changes state, use action types. To do this:
- Open the Input window
- Select the setting
- Choose Button if you want to do blah
- Choose Value to do other thing
For more information on these settings, refer to the Actions reference.
If available, I would also mention how you could configure this in code with APIs, but if we don't have that info it's fine.
|
|
||
| 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 at once on the same action, rather than only the most actuated from the set. |
There was a problem hiding this comment.
The content model requires we have an Additional Resources section at the end of each page.
| * [Create an empty action asset](create-empty-action-asset.md) | ||
| * [Assign a project-wide action asset](assign-project-wide-actions.md) | ||
| * [Default actions](default-actions.md) | ||
| * [Generate C# API from actions](generate-cs-api-from-actions.md) | ||
| * [Create action maps](create-edit-delete-action-maps.md) | ||
| * [Create, edit and delete actions](create-edit-delete-actions.md) | ||
| * [Configure actions](configure-actions.md) | ||
| * [Action and control types](action-and-control-types.md) | ||
| * [Configure action type](configure-action-type.md) |
There was a problem hiding this comment.
This might be a bit overkill for such a short section, but I think it's lacking a little overview explaining what action and control types are. I feel like an intro page might be useful here. I also wonder if both task pages could be combined somehow so you have something like:
- Action and control types (potentially rename this to something more outcome based like, "Configure how actions are triggered" ?)
- Action and control types overview (you can configure how actions are triggered with action types and control types...)
- Configure action and control types (to set the types, open the window and do XYZ...)
- Action and control types reference (Unsure if you need the reference here or if you have this somewhere else in an overarching window reference page)
| @@ -1 +1,15 @@ | |||
| # Configure Control 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. | |||
There was a problem hiding this comment.
I have no idea if Action should be capitalised or not, but later on this page we refer to it with a small A. Might be something to align on - I keep on seeing a mis-mash of capitals all over the place in these docs.
| * [Action and control types](action-and-control-types.md) | ||
| * [Configure action type](configure-action-type.md) | ||
| * [Configure control type](configure-control-type.md) | ||
| * [Bindings](bindings.md) |
There was a problem hiding this comment.
Again, "Bindings" is a feature based term - I'm trying to think of a good outcome-based name for this but I think it needs to be along the lines of "Configure what actions are performed." or "Connect actions to input" or similar.
These titles are absolutely terrible though and it might be better to brainstorm as a group - @siobhan-unity is usually better at these things than I am 😄
|
|
||
|  | ||
|
|
||
| A **binding** represents a connection between an [Action](actions.md) and one or more [Controls](Controls.md) identified by a [Control path](./control-paths.md). For example, the **right trigger of a gamepad** (a control) might be bound to an an action named "accelerate", so that pulling the right trigger causes a car to accelerate in your game. |
There was a problem hiding this comment.
| A **binding** represents a connection between an [Action](actions.md) and one or more [Controls](Controls.md) identified by a [Control path](./control-paths.md). For example, the **right trigger of a gamepad** (a control) might be bound to an an action named "accelerate", so that pulling the right trigger causes a car to accelerate in your game. | |
| A **binding** represents a connection between an [Action](actions.md) and one or more [Controls](Controls.md) identified by a [Control path](./control-paths.md). For example, the right trigger of a gamepad (a control) might be bound to an an action named `accelerate`, so that pulling the right trigger causes a car to accelerate in your game. |
| @@ -0,0 +1,17 @@ | |||
| # Binding types | |||
|
|
|||
| Bindings have a **type** which can be **simple** or **composite**. | |||
There was a problem hiding this comment.
I'd perhaps reformat this a little bit so it's like:
You can configure how bindings map to actions with binding types. The following binding types are available:
- Simple: A single control maps directly to an action. For example, a gamepad stick to a "move" action, or a gamepad button to a "jump" action.
- Composite: Construct a binding from multiple simple bindings.
|
|
||
| - A **four-way** composite binding, where four keyboard keys map to an action whose [control type](control-types.md) is a 2D vector, so that each of the keys maps to up, down, left, and right respectively. In this scenario, the four key bindings are simple bindings grouped together into into the composite four-way binding. | ||
|
|
||
| - You can create a **modifier** composite binding, where one control represents the main binding, and a second control represents a "modifier key" to alter the effect of the main binding - such as colding down the control key on a keyboard before also pressing a letter key. In this scenario, the two separate key bindings are simple bindings grouped together into the composite modifier binding. |
There was a problem hiding this comment.
| - You can create a **modifier** composite binding, where one control represents the main binding, and a second control represents a "modifier key" to alter the effect of the main binding - such as colding down the control key on a keyboard before also pressing a letter key. In this scenario, the two separate key bindings are simple bindings grouped together into the composite modifier binding. | |
| - A **modifier** composite binding, where one control represents the main binding, and a second control represents a modifier key which changes the effect of the main binding - such as holding down the control key on a keyboard before also pressing a letter key. In this scenario, the two separate key bindings are simple bindings grouped together into the composite modifier binding. |
|
|
||
| - You can create a **modifier** composite binding, where one control represents the main binding, and a second control represents a "modifier key" to alter the effect of the main binding - such as colding down the control key on a keyboard before also pressing a letter key. In this scenario, the two separate key bindings are simple bindings grouped together into the composite modifier binding. | ||
|
|
||
| For a full list of composite binding types, see [Composite bindings](composite-bindings.md). |
There was a problem hiding this comment.
| For a full list of composite binding types, see [Composite bindings](composite-bindings.md). | |
| For a full list of composite binding types, refer to [Composite bindings](composite-bindings.md). |
Description
Part of the Input Docs Re-org, mainly including action and control types pages, and the bindings section.
https://jira.unity3d.com/browse/DOCF-6393
https://jira.unity3d.com/browse/DOCF-6476
Testing status & QA
Built locally and checked.
Overall Product Risks
Docs only changes, no risk.
Comments to reviewers
The following pages are included in this review: