KeyCode.ButtonA is constantly sunk by the PlayerModule

Bug Reports Engine Bugs
#1

Reproduction Steps

Open an empty baseplate, paste this into a local script.

game.UserInputService.InputBegan:Connect(function(Input, GameProcessedEvent)
	if GameProcessedEvent then return end
	warn(Input.KeyCode)
end)

Try pressing the A button on a gamepad, it will never show up. The other buttons will work.

Expected Behavior

That the ButtonA will be processed properly and not be sunk by the PlayerModule script.

Actual Behavior

The Button A gets ignored by the GameProcessedEvent

Workaround

I could technically ignore GameProcessedEvent, but then it wouldn’t ignore other key systems like the chat window. I would have to write lots of janky workarounds against the playermodule.

Issue Area: Engine
Issue Type: Other
Impact: High
Frequency: Constantly

3 Likes
PlayerModule : ButtonA is sinked to jumping
#2

The issue is because GameProcessedEvent is true for ButtonA. I believe this is because Jump is bound to A by default. You can use the Developer Console to view the currently active bindings.

1 Like
#3

While that might be true, it would be better if it wasn’t sunk.

The space bar also makes you jump and it’s not sunk (doesn’t trigger game processed event). Ideally there would be some consistency here.

1 Like
#4

Can’t you just do something like this?

local UserInputService = game:GetService("UserInputService")

UserInputService.InputBegan:Connect(function(Input, GameProcessedEvent)
	if UserInputService:GetFocusedTextBox() ~= nil then return end
	warn(Input.KeyCode)
end)
#5

Yes, this is a somewhat valid workaround (depending on context), But I would much rather just have the ButtonA always being sunk by the Control Module to be fixed instead. It adds unnecessary friction in coding

#6

I’ve already gone to the developers about the same issue with the right joystick click, it was working before and then after an update, Roblox took control of it and could no longer use as exclusive button without it always switching between 1st and 3rd person view on top of the function I had setup for it. The short answer is, they will tell you the same thing they told me. They aren’t going to change it. :face_exhaling:

3 Likes
#7

Well, this is depressing to read :confused: I appreciate the answer though

#8

Well, don’t give up. I’m just one person complaining at that time, but when enough of us get together and complain, they do listen sometimes. It’s merely asking to change it back to the way it was before or at least offer an option to override this behavior because it only affects the Xbox controller for the most part, the PC and tablet have many other ways to work around the buttons, but the controller has limited space and Roblox having dominion over certain buttons doesn’t really make sense in the grand scheme of things. :grinning:

1 Like
#9

Thanks for the report! We’ll follow up when we have an update for you.

4 Likes
#10

I know that this issue has been noted of, but if ButtonA was sunk into the player module, it would literally destroy 1000’s of gamepad compatible games, which of course is not an option.

#11

Unfortunately we’ve decided not to fix this :frowning: thank you for the report.

#12

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