# Input System
**Target:** Unity **6000.5+** with package **`com.unity.inputsystem` 1.20.x** (Unity Manual lists **1.20.0** as released for Editor **6000.5**). Quest-specific XR notes that need a patched runtime may use **Unity 6.3 LTS (6000.3.27f2+)** — see [[Meta Quest 2]].
This is the deep dive. For a lighter upgrade path on an existing movement project, start with [[Unity New Input System Upgrade Tutorial]], then come back here for control schemes, rebinding, UI wiring, and XR.
Related: [[Surface-Walking with an Omnidirectional Player Movement]] · [[UI Toolkit and Diegetic UI]] · [[8.UI Toolkit for VR]] · [[6.Quest 2 Input Hands and Passthrough]] · [[Architecture and Code Patterns]] · [[Game Programming Patterns (Review)]] · [[Level Up! (Review)]] · [[Car Controller]] · [[Multiplayer with Netcode for GameObjects]]
> [!warning] Verification status
> **None of the C# in this tutorial set was compiled in a Unity Editor.** APIs and workflows below were checked against the Input System **1.20.1** package docs on docs.unity3d.com (installation, actions, action types, composites, control schemes, rebinding, save/load overrides, UI Input Module, tracked UI, devices/domain reloads, device loss) and the Unity Manual package page for **6000.5**. Unverified items: exact Inspector label wording across minor package patches, generated C# class field names for your asset (they follow your map/action names), XR Interaction Toolkit preset names beyond what XRI docs describe, and any Quest OpenXR binding path strings you paste from device profiles. Prefer the Package Manager sample **Rebinding UI** when you want a known-good reference UI.
## Why this matters (Level Up! Three Cs)
Scott Rogers' **Controls** chapter (see [[Level Up! (Review)]], Level 7) treats input as part of the **Three Cs** — Character, Camera, Control. The Input System's job is to keep *intent* (Jump, Interact, Look) separate from *hardware* (Space, South button, XR primary). That separation is what makes remapping, multiplayer device pairing, and VR/desktop dual support tractable. Treat actions like **Command** objects ([[Game Programming Patterns (Review)]]) that your gameplay code can invoke without caring which device fired them.
## Reading order
1. **[[1. Package Setup and Action Foundations]]** — Active Input Handling, `.inputactions` assets, maps, Button/Value/PassThrough, bindings, composites, processors, interactions.
2. **[[2. Control Schemes Devices and Consumption Patterns]]** — control schemes, device pairing, generated C# class vs `PlayerInput` vs `InputActionReference`.
3. **[[3. Runtime Rebinding]]** — `PerformInteractiveRebinding`, display strings, save/load overrides, restore defaults.
4. **[[4. UI Input and XR Input]]** — `InputSystemUIInputModule`, EventSystem, tracked-device UI, Quest/XRI pointers without duplicating the Quest notes.
5. **[[5. Worked Example Remappable Player]]** — Move / Look / Jump / Interact with saveable rebinds.
6. **[[6. Pitfalls]]** — domain reload, dual backends, lost devices, map enable mistakes.
## Package and docs (bookmark these)
| Topic | Doc |
|---|---|
| Package for Unity 6000.5 | https://docs.unity3d.com/Manual/com.unity.inputsystem.html |
| Install / Active Input Handling | https://docs.unity3d.com/Packages/
[email protected]/manual/Installation.html |
| Actions overview | https://docs.unity3d.com/Packages/
[email protected]/manual/Actions.html |
| Action types | https://docs.unity3d.com/Packages/
[email protected]/manual/action-type-reference.html |
| Composites | https://docs.unity3d.com/Packages/
[email protected]/manual/composite-bindings.html |
| Control schemes | https://docs.unity3d.com/Packages/
[email protected]/manual/group-binding-to-control-scheme.html |
| Runtime rebinding | https://docs.unity3d.com/Packages/
[email protected]/manual/rebind-action-runtime.html |
| Save / load rebinds | https://docs.unity3d.com/Packages/
[email protected]/manual/save-load-rebinds.html |
| UI Input Module | https://docs.unity3d.com/Packages/
[email protected]/manual/introduction-ui-input-module.html |
| Tracked UI | https://docs.unity3d.com/Packages/
[email protected]/manual/supported-ui-input-types-tracked.html |
| Domain reloads | https://docs.unity3d.com/Packages/
[email protected]/manual/devices-domain-reloads.html |
| Device loss | https://docs.unity3d.com/Packages/
[email protected]/manual/handle-loss-of-device.html |
## Mental model
```
Device control → Binding (+ processors / interactions / scheme)
→ Action (Button | Value | PassThrough)
→ Action Map (Player, UI, Vehicle, …)
→ Input Action Asset (.inputactions)
→ Your code (generated class | PlayerInput | InputActionReference)
```
Gameplay scripts should almost never hard-code `<Keyboard>/space`. Bind once in the asset, consume the **action**.
## Setup checklist (do once per project)
1. Confirm **Window > Package Manager > Unity Registry > Input System** is installed (1.20.x on 6000.5).
2. Set **Edit > Project Settings > Player > Active Input Handling** to **Input System Package (New)** unless you are mid-migration (then **Both** briefly). Editor restarts.
3. Create or assign project-wide actions (**Edit > Project Settings > Input System Package**) *or* create `Assets/.../PlayerInputActions.inputactions`.
4. Add control schemes **Keyboard&Mouse** and **Gamepad** (and **XR** when you need them).
5. Decide your consumption pattern early (part 2) and stick to it for the player pawn.
When you finish part 5 you will have a remappable desktop player you can later extend toward [[Car Controller]] vehicle maps or Netcode player objects in [[Multiplayer with Netcode for GameObjects]].