When filtering for Game Processed Event, A on the gamepad is always returning true. I thought this had something to do with Jump but disabling it using Context Action Service didn’t seem to help. Any solutions out there?
EDIT:
It’s probably important to mention that I am doing this for people who want to connect their controllers in on PC.
Could it have something to do with how you can press buttons with A in the select mode?
Buddy of mine was having a similar problem, he may be able to help.
Couldn’t find anything on that, would that not fall under Context Action Service?
When you press the 2 windows button, it switches to gui mode. Then you can press a the press buttons as if you were using a mouse. I’m guessing that’s why it’s set to game processed always.
Yeah I don’t want to disable that functionality or anything but maybe I can just check for that KeyCode in particular? The issue with that is I’m letting players set their own keybinds so that seems like a weird solution.
Then just make sure to allow it game processed or not. If they are on console, they won’t really by typing anything. It’s you choice; i’m just explaining why it is game processed.
Yeah that will definitely work but unfortunately then it will be true when navigating GUIs. In this case its bound to an attack so every time you hit A to click on something in the GUI the character will just be attacking which is not ideal. Like you said this might be a gui mode issue which worries me because its that probably means I’m dealing with a core script here.
If you have say a inventory that open, you can check to see if that is open before firing the attack function. If you are worried about keybinds while windows are open, have a variable to represent it:
local windowOpen = false
local function openInventory()
windowOpen = "Inventory"
end
local function closeInventory()
windowOpen = false
end
local doAttack()
if not windowOpen then
--Do stuff
end
end
Note that is just a demo and some obvious changes will need to be mad
I’m sure that will work, was just kind of hoping I could use the UserInputService without having to create my own variables. 
Thanks for the help!
The problem I was having was that the inputs just straight up didn’t register.
He’s having a completely different issue.
I’m still having issues with buttons not registering properly and it’s killing my user base on XBOX.
I would suggest opening a separate thread if you want to talk in detail; But this seems to be a thing on your end. I just tested inputs, everything works properly. It has to be something with your implementation.
Some things on Roblox’s end are just hard-coded in, so sometimes you have to make-do with what you got.
If you can’t solve a specific problem; Sometimes it is best to move on. It’s better to spend a hour making you game have more features and cool stuff then spending a hour trying to fix a little bug that doesn’t affect many players.
Nah I looked over his implementation, and we tested it for hours with multiple different input methods.
It was a roblox issue and it eventually just fixed itself 
When something does not seem right always do the following:
Glad you found the issue, have a good day.
I don’t really see how any of that would help when this is an issue of internal input listening to GamepadButton A. None of this is related to input-based problems in Studio.
I wasn’t sure if that was the case when I posted this and I didn’t want to assume. But if so this probably belongs in Engine Bugs. I’ve also found someone who was struggling with the same issue when using R3 (clicking in the right stick) because that is tied to camera zoom. It makes sense that I wouldn’t have that issue however since I am using a custom camera.
I’m still having this issue. Any update? ButtonA is always GameProcessedEvent true.
I tried disabling the jump input from ContextActionService, with no result.
Yup, haven’t found a way to change that since. ButtonA isn’t the only one that always returns true either. The best workaround I’ve found is to define a state for having a menu open or not that way you can adjust the functionality accordingly. Depending on how you set it up that might also involve manually remapping ButtonA to jump when that state becomes false. If you want a quick fix though you can always set the JumpPower to 0 when that menu state is true so you aren’t jumping all over the place.