Skip to content
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions Packages/com.unity.inputsystem/Documentation~/Layouts.md
Original file line number Diff line number Diff line change
Expand Up @@ -240,6 +240,8 @@ You can derive a layout from an existing layout. This process is based on mergin
* For layouts defined in JSON, you can specify the base layout in the `extends` property of the root node.
* For layouts created in code using [`InputControlLayout.Builder`](xref:UnityEngine.InputSystem.Layouts.InputControlLayout.Builder), you can specify a base layout using [`InputControlLayout.Builder.Extend()`](xref:UnityEngine.InputSystem.Layouts.InputControlLayout.Builder.Extend(System.String)).

> **Note:** The layout hierarchy also determines which binding paths in Input Action Assets resolve controls on your device. When a path such as `<Gamepad>/buttonSouth` is resolved, the Input System walks the device's base layout chain upward until it finds a match. If your device class does not inherit from `Gamepad` (or whichever base layout the path references), that path will not resolves controls, no state change monitors will be created, and the corresponding actions will not fire. This also applies to custom base layouts: if you define a family of devices that share binding paths under a common layout name (e.g. `<MyBaseLayout>/...`), every device in that family must inherit from the C# class registered for that base layout.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The format for a note is

Note

The layout hierarchy....

etc

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
> **Note:** The layout hierarchy also determines which binding paths in Input Action Assets resolve controls on your device. When a path such as `<Gamepad>/buttonSouth` is resolved, the Input System walks the device's base layout chain upward until it finds a match. If your device class does not inherit from `Gamepad` (or whichever base layout the path references), that path will not resolves controls, no state change monitors will be created, and the corresponding actions will not fire. This also applies to custom base layouts: if you define a family of devices that share binding paths under a common layout name (e.g. `<MyBaseLayout>/...`), every device in that family must inherit from the C# class registered for that base layout.
> **Note:** The layout hierarchy also determines which binding paths in Input Action Assets resolve controls on your device. When a path such as `<Gamepad>/buttonSouth` is resolved, the Input System walks the device's base layout chain upward until it finds a match. If your device class doesn't inherit from `Gamepad` (or whichever base layout the path references), that path doesn't resolve controls, no state change monitors are created, and the corresponding actions don't fire. This also applies to custom base layouts: if you define a family of devices that share binding paths under a common layout name (such as`<MyBaseLayout>/...`), every device in that family must inherit from the C# class registered for that base layout.


## Control items

Each layout is comprised of zero or more Control items. Each item either describes a new Control, or modifies the properties of an existing Control. The latter can also reach down into the hierarchy and modify properties of a Control added implicitly as a child by another item.
Expand Down
Loading