Input Profiles And Keybinds

What This System Is

Input profiles are the stable contract between bindable actions, default keybinds, user preferences, editor input, gameplay controls, standalone screens, chat/dialogue focus, gamepad selection, and local persistence. They let users customize controls while keeping action names and focus scopes meaningful to code.

How Authors Use It

Authors and developers add a bindable action by defining the action, assigning it to the correct domain or focus scope, choosing sensible defaults, and making the UI surface read from the input manager instead of checking raw keys directly. Users edit profiles through the input profile UI and the result is persisted locally.

Rules And Invariants

Action names are compatibility-sensitive. Rename them only with a migration or explicit recovery path. Defaults should avoid conflicts inside the same focus scope. Gameplay actions, editor actions, chat input, dialogue selection, and UI navigation must respect focus so typing into a field does not trigger world commands.

Profile writes should be debounced and recoverable. Invalid user profiles should fall back to defaults with a visible validation issue rather than leaving input unbound.

Validation And Debugging

Use input profile validation to detect unknown actions, invalid bindings, conflicts, and malformed local persistence. Editor reports and conflict chips should name the action, domain, and competing binding. When a binding does nothing, check focus scope, profile selection, gamepad activity, and whether the UI surface consumes input before gameplay sees it.

Examples

To add a new gameplay panel toggle, define a stable action id, add a default keybind in the gameplay domain, wire the panel to the input manager, and expose it in the runtime keybind menu.

To resolve a conflict, move one action into a narrower focus scope or pick a non-overlapping default, then validate the profile and confirm local persistence reloads it.