Key binding (N button) problem

FiveM Discussion Bug Reports
1

Hey, I found a problem with the key binding to the button N. Doing so will activate the command even in undesired situations, such as when the console is displayed or if you have NUI focus.

  1. Client (production/canary) and FXServer version - Client is Canary, FXServer version is 5591 Linux (unrelated to the issue)
  2. What you expected to happen - Pressing N will trigger all its binds only when you have access to the gameplay, just as it works with any other keys.
  3. What actually happens - When you press N with the console opened or NUI focus, it will trigger all the binds you have with it.
  4. Category of bug (eg. client, server, weapons, peds, native) - client
  5. Reproducible steps, preferably with example script(s):

Script:
Just an example script that registers N, and K buttons to print something in the console

RegisterCommand("testCommand", function(source, args, rawcommand)
	print("testCommand", "N")
end)

RegisterCommand("testCommand1", function(source, args, rawcommand)
	print("testCommand", "K")
end)

RegisterKeyMapping("testCommand", "test", "KEYBOARD", "N")
RegisterKeyMapping("testCommand1", "test1", "KEYBOARD", "K")
  1. Try to press N and K, and see that it is working normally, and print “testCommand {KEY}”.
  2. Open the console and press K and N (even in the input box) and see that it will print “testCommand N” when you press N, but won’t do the same to the K key.
  3. Try it even with NUI focus, with this line of code in the crun (runcode resource):
crun SetNuiFocus(true, true)

I have seen that vMenu shows that you talk when you press N with the console opened (which is working by when you talk and not when you press N), so I guess this is the origin of the problem (now on second thought, maybe it is intended with bad side effects?)
image

2

This issue originates from the GTA Online “Push to Talk” keybinding.

image
image1131×48 52.4 KB

If you change this keybinding to some other key the mentioned behaviour will stop.

Also, if you map the “Push to Talk” keybinding to another key (for example ‘U’) and register a command key mapping on the same key, you will see this issue on that keymapping too.

So this probably has something to do with the “Push to Talk” overwrite that is implemented, so you can talk when the game is out of focus or a NUI is in front.

1 Like
3

And then we’d be back to square one with people who want push to talk with any UI open… seriously, this one feature only ever led to people reporting that every single way it could be is a bug.

Not working? Bug. Working? Bug. Working, but not in some edge case? Bug. Not working in this edge case? Bug.

1 Like
4

Would it be technically possible that only the “Push to talk” interaction gets passed through and every other interaction that has a keymapping registered on the same key gets blocked like other keys when the game is not in focus? (NUI, out of focus, etc.)

If possible, that would solve both scenarios.

5

I get it why it should be doing that when you actually try to talk, but not with RegisterKeyMapping, as IS_CONTROL_* natives are supposed to get when you try to talk, or doing anything that related to the actual controls; and RegisterKeyMapping is supposed to be for non control binds, as you can just change it to other keys and it will still working, and have 0 meaning to the actual control you press.

For example:
You won’t do RegisterKeyMapping for left mouse click to achieve a command that works when you shoot, instead you will check IsControlPressed with INPUT_ATTACK.

(Binds to actual controls can be a nice suggestion to the platform actually, but it’s not related to this thread and I may be creating a different one for that, as you can only achieve it by checking every frame if this control is pressed)

6

Both are handled the same way and the ‘bypass’ logic to allow the push-to-talk key to be processed by game code is at an earlier stage than actual game code deciding which input to route the raw key to. I agree the behavior can be seen as illogical, but implementation-wise it is explainable fine.

Implementing this any other way would be extremely risky and make for a lot of potential edge cases (I think the first iteration of this implementation was actually directly setting the control, but that led to other issues) as a result of a partial understanding of R* game code or not being aware of some other weird edge case in said code.

7

Also, yeah, but a lot of servers do the stupid way anyway so any fix to this could break stuff for other cases where people rely on the ‘broken’/illogical behavior.

This particular feature is already picky every single time it gets touched so it just won’t get anything done to it anymore any time soon: too risky a component to make a change to, so it’s way down the priority list.

Want anything changed in such a component - do it yourself and preferably test it on every server ever (the latter thing is impossible which is why I won’t do it either) or at least be aware enough of the code so you can also fix any further regression report. :confused:

8

@nta Hey, just figured out that the same goes to the Left Alt button, is this intended?

9

What do you mean, ‘the same’? If it’s bound to anything?

10

Yes, I tried to register a key mapping to left alt, but it keeps functioning even when I’m focused to another NUI, just like the N key does; for N I can see the reason, as talking is essential, but to left alt I can’t see why…

11

No idea what could cause this if it isn’t bound to voice or similar - can’t check code right now at all. I recall there being some weird special cases involving the Alt button at times though (for one as Windows handles these differently, but maybe something weird about the global input stuff as well, I remember a user request somewhere).