When a button does nothing, the failure may be in device detection, action mapping, notification delivery, or the game rule that decides whether the action is allowed. Adding another listener before tracing that route can turn a missing input into a duplicated one.
This checklist uses a fictional dash action that stops working after closing the pause menu. It focuses on projects using Unity’s Input System package. Record the installed package version and consult its matching documentation; changing input systems is a separate decision from repairing one action.
/01
Reproduce one control and one transition
Record the device, control, scene, current game state, and exact steps. Does dash fail immediately, only after pause, or only after reconnecting a controller? Compare a short press with a held press, and keep keyboard and controller results separate. The goal is a small sequence that another person can run without guessing the timing.
Use a test scene or disposable session where the action’s result is obvious. Preserve the existing binding and sensitivity values while collecting evidence. In the example, first prove that dash works before pause and fails afterward with the same device. That comparison narrows the investigation to what the menu transition changes.
/02
Inspect the device before the gameplay callback
The Input System’s Input Debugger can show devices and control state. Confirm that the relevant control changes when operated. If the device event is absent, investigate focus, connection, or device support before editing the dash code. Preserve the distinction between receiving physical input and interpreting it as a game action.
Unity’s action model separates an action’s purpose from its bound controls. Inspect the configured binding, active control scheme, and relevant action map for this player. Compare these states before and after pause. A correct binding on an inactive map is a different problem from an active map whose binding points at the wrong control.
/03
Follow the action to its current owner
Determine which object receives the action and how its notification path is configured. Check that the intended player owns the paired device and that a recreated player has not left an older listener behind. Inspect the actual action phase or polling condition used by the project instead of assuming every press produces the same callback sequence.
Add focused diagnostics at the action receiver and at the dash request boundary. If the receiver runs twice, count subscriptions and object instances before adding a debounce. If it never runs, inspect action enablement and routing. Keep diagnostic logging out of performance conclusions because the extra work can change timing.
/04
Check the game rule after the input arrives
Once the request reaches gameplay, inspect the conditions that permit dash: pause state, cooldown, movement mode, current animation, and any menu ownership flag. Record why a request is rejected. In the fictional case, closing the menu might restore the visual HUD while leaving the session’s paused flag set.
Fix the state transition that owns the stale condition. Bypassing the cooldown or pause gate globally may make this example work while allowing actions in menus or during transitions. Specify whether a held button should trigger on resume, wait for release, or be discarded, then implement and test that intended behavior consistently.
/05
Verify reconnect, focus, and the built player
Repeat the original sequence, then test a controller reconnect and a focus change where the target supports them. Confirm that one intended press produces one permitted dash and that menu input does not accidentally control the character. Test another supported input method to catch a fix that hardcodes one device.
Verify the built player as well as the Editor. The documented remote Input Debugger exposes device events but has limitations compared with local action inspection, so supplement it with bounded application diagnostics where needed. Report the package version, tested controls, and remaining device gaps. A passing keyboard test is not evidence that every controller configuration works.
Keep this in mind
Key takeaways
- Trace device input, action mapping, notification ownership, and gameplay rejection as separate stages.
- Use the failing transition to narrow the investigation instead of replacing the control scheme.
- Verify one action per intended press across pause, focus, reconnect, and the actual player build.
Sources & further reading
Consult the source documentation for the version and platform you are working with.