BC-0169 · TROUBLESHOOTING
Editorial review 2026-09-26
Roblox Build Controls Do Not Work
When game controls do not work, identify where the intended input stops producing a visible response: the action is unavailable, the control gives no acknowledgement, feedback appears without gameplay, or the action persists after release. Test a named harmless action on the actual input method before requesting a repair.
Symptom
An intended game input gives no expected action or produces an incorrect press, hold or release response.
Immediate action
Pick a named harmless action and record its control feedback separately from the game response.
Diagnostic branches
- The action is unavailable in the current round phase.
- Check the intended phase rule before describing an input defect.
- The control acknowledges input but gameplay does not react.
- Request the missing action while preserving the existing feedback and layout.
- The action continues after input is released.
- Record the release boundary and inspect the same transition around any existing menu.
- Only player movement fails while another harmless action works.
- Continue with the movement-specific investigation using the recorded context.
Least-destructive change
Repair the failing input boundary without replacing working controls or using purchases as test actions.
Retest
- The repaired action is tried in its intended phase and, if the design has one, an intentionally inactive phase.
- Feedback and actual game response agree.
- Release and return from any existing menu remain predictable on the tested input method.
Escalation
If the intended action cannot be established or safely tested, preserve the instructions/control mismatch. Report the actual input method and observed transition without asserting an undocumented key binding or internal input-system cause.
Working notes
Choose an action that the game's own instructions say should exist in the current phase. A control that is intentionally disabled before Start or after completion should not be treated as a failed active-play input. If the instructions and visible controls disagree, record that mismatch before inventing a keyboard shortcut.
Observe the control and the game separately. A pressed appearance or animation can show feedback without establishing that the intended gameplay event occurred. Conversely, gameplay may react while the button's visual state is unclear. Describe each outcome rather than using works or broken for the entire chain.
Check the boundary that matches the symptom: initial press, held input, release, or returning from a menu. Use only actions already implemented and safe in the current project. A mouse test does not validate touch, and an untested input device stays untested rather than inheriting another method's result.
Write the correction around the first missing response and the existing behavior to retain. Do not replace all controls for a defect limited to a menu transition. If only movement fails while other inputs work, hand off the action record to movement diagnosis instead of repeating the entire control matrix.
Examples
- Action chain: touch the visible Jump control during active play → pressed feedback appears → character does not jump. The desired repair concerns the missing game action, not a new button style.
- Release case: movement begins when the input is held but continues after release. A proposed request is: Stop movement on release in active play, preserving its current speed and direction while held. Verify release before and after opening the existing menu.
- Observation fields: actual input method / current game phase / instructed action / control feedback / resulting game response / release outcome. Leave another input method untested until it is used.