Sometimes UserInputService ignores specifically Enum.Keycode.F

Help and Feedback Scripting Support
, , ,
1

Sometimes UIS just flat out ignores the F input. My keyboard works fine, I have tested this.
Printing to the console, UIS detects other inputs. Every other input. Typing F in the command bar, moving back to the game, and still no input being detected. (Proving the F key still works) This happens 1/10 times I start the game, and sometimes even outside of studio. I am at a loss of ideas.


local char = game.Players.LocalPlayer.Character or game.Players.LocalPlayer.CharacterAdded:Wait()

local UIS = game:GetService("UserInputService")

local rp = RaycastParams.new()
rp.CollisionGroup = "Look"
rp.RespectCanCollide = true

script.Parent.FlashlightPrimary.WeldConstraint.Enabled = false
script.Parent.Parent:WaitForChild("RopeConstraint").Visible = false
game:GetService("RunService").RenderStepped:Connect(function()
	local mpos = game:GetService("UserInputService"):GetMouseLocation()
	local unitRay = workspace.CurrentCamera:ViewportPointToRay(mpos.X, mpos.Y)

	local ray = workspace:Raycast(unitRay.Origin, unitRay.Direction * 10000, rp)

	if ray then
		script.Parent.Flashlight:PivotTo(CFrame.lookAt(char.Head.Position, ray.Position))
	end
end)


--start of the bugged code. the rest of this page is irrelevant but included for the sake of this article
print("listening") --always prints.
UIS.InputBegan:Connect(function(key, gpe)
	print("button", key.KeyCode, gpe) --always prints, unless F is pressed while the bug is occuring.
	if gpe then return true end
	if key.KeyCode == Enum.KeyCode.F or key.KeyCode == Enum.KeyCode.ButtonY then
		script.Toggle:FireServer()
	end
end)

game.Players.LocalPlayer.PlayerGui:WaitForChild("General").Hotbar.Flashlight.Keybind.ImageLabel.TouchTap:Connect(function()
	script.Toggle:FireServer()
end)

The console ALWAYS prints “listening”, and ALWAYS prints the other inputs. Nothing prints when F is pressed if the bug occurs.

2 Likes
2

Try to isolate your issue, create a new empty place with that part of the script that’s having problems. This could be an engine bug, or it could be caused by something else in your game.

1 Like
3

I’m not totally sure, but this may be happening because GameProcessedEvent (which I have no idea what that even is lol) may be true, causing your if gpe then return true end to trigger.

1 Like
4

This is because your character isn’t fully loaded, and the F key specifically is revealing that.

local player = game:GetService("Players").LocalPlayer
local character = player.Character or player.CharacterAdded:Wait()
local humanoid = character:WaitForChild("Humanoid")  --magic pause
--
--
1 Like
5

I’ve noticed this happening in studio whenever you have something selected in the explorer while running the studio test.

Try clearing that and see what happens

3 Likes
6

GameProcessedEvent is when you press that input while being ‘focus’ on something else, such as typing in the chat or a textbox.

7

You don’t need the character and its humanoid to be loaded for input detection to work, unless it’s a local script under the character, but in that case, the script won’t run until the character spawns, and there’s still no need to wait for the humanoid.

That just seems to be a weird issue on their device’s end or Roblox API rather than a problem with the script. There’s no logical reason why only the F key not work when all the other keys work perfectly fine.

@VintageDegenerate This issue could be caused by a studio shortcut that prevents UIS from working. The F key is, by default, bound to the “Zoom To” shortcut function.
Try going to File > Studio Settings > Studio > Advanced and unchecking “Respect Studio shortcuts when the game has focus.” This should resolve the issue.

8

Roblox can miss keyboard input, specifically the F key and possibly other keys, if the character isn’t fully loaded yet. This mostly happens due to the timing mismatch between input binding and the character’s load state. If you’re using something like local char = player.Character, and it’s nil when the F key is pressed, your handler might silently fail or skip logic. Using WaitForChild(“Humanoid”) can prevent that completely. Even adding a task.wait() after that helps ensure stability.

Did you think that was a wild guess? I’ve run into this, and this was the outcome of some serious research. Go look for yourself… you’re assuming.

9

If that were the case, input detection would not work without the character being spawned, but yet all input keys work without the character.

I have never encountered such an issue on the live server, regardless of the character’s state.

10

Well, that would explain the assuming. This is not a debate. Take it or leave it…
I can’t say for sure this is his problem, but it sure sounds familiar.

11

I cannot believe it until you show me proof that it can happen on the live server, or provide an official documentation page stating that UserInputService requires the character to be fully loaded to function correctly.

For now, this issue only occurs in Studio and has been encountered multiple times in the past with the keys F, I, and O, which are all bound to Studio shortcuts for zooming to, zooming in, and zooming out.

12

Well I fixed it before I went past that.. Sound like you know this is real, what proof do you need other than “encountered multiple times in the past with the keys F” :zany_face:

13

Can you at least read the entire phrase?
Also, if it were true, it would be specified in the documentation, as it is a major issue.

14

This is for trying to answer questions, not baiting. Now you’re assuming I didn’t read all that. :rofl::rofl:
I did say and possibly other keys. “Also, if it were true, it would be specified in the documentation”
Ya, I found that and more… Again, go research for yourself. You’re being rude, sir. I’m done, save the reply.

1 Like
15

The thing is, when the bug occurs and F is pressed, not even that prints. The entire connection does not fire

16

Uh. You are right. Thank you so much
That is such a weird bug-

17

Thank you so much. This issue has been draining my sanity for weeks now.

18

If this problem occurs again, I’ll reply here. I am not sure what caused the occurrence in-game, though that was a little while ago so I presume it was fixed by me at some point.

19

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.