That’s a silly alternative. I may as well not use C# either, because it’s difficult to deal with the Client/Server event invocations. Whether you think so or not, having specific input states is sometimes required. I don’t care if someone mapped their move forward key to “scroll down”, I only care that they pressed “W” on the keyboard, because it’s how I want something mapped. There are times where being able to rebind a key is useful, and there are times where rebinding it doesn’t make sense. Unfortunately, we don’t have the ability currently to add our own control mappings, so we have to make due with what the game exposes.
FiveM already has a WndProc hook that can be used to keep an input state. Alternatively, you can just throw in XInput/DirectInput, and tada, you have all the input mechanisms you could ever want. (Including controllers, wheels, etc)
Do you mean where the “W” key is on a QWERTY keyboard? (i.e. by scan code?)
What if they’re using an AZERTY keyboard?
Dvorak?
Colemak?
Russian layout?
This may not apply to the base letter keys, but there are many keys imaginable where the user may not have them, and we’re not going to allow you to read those keys without allowing the user to re-bind them to a key/combination they do have.
Why would you want the user to not be able to re-bind a key?
That’s exactly what the above design document is meant to resolve.
… and that wouldn’t integrate with the existing game systems whatsoever. The point here is not to provide half-assed solutions that have to remain compatible for all of eternity with nobody moving on to a newer system, we’ve gotten burned too many times doing exactly that.
In addition, with the features from said design document implemented, you’ll be able to set up your own random custom ‘4 scan codes next to one another’ segment or whatever with custom controls and some defaults, but the user will be able to rebind it away from there anyway, but if they’d do so they’d probably be hurting their own fingers but you shouldn’t care about that.
Keyboard localization is a “solved” problem. I purposely wasn’t mentioning it to keep the conversation simpler. But if you must make it so verbose, so be it.
Lets take an example (admittedly bad, but it’ll get my point across). I want to make a “snake” game. 4 keys on QWERTY; WASD. AZERTY; ZQSD, Dvorak; <AQE, etc. Those 4 keys map to the same keyboard location (again, solved problem…) no matter what keyboard layout is being used. (Purposely ignoring “novelty” layouts for simplicity here)
User 1: Default layout, has zero issues playing my “snake” game.
User 2: Rebound “move left” to scroll wheel down, and “move forward” to scroll wheel up. This makes the usual gameplay easier on them, but now “snake” is unplayable. (Not entirely unplayable, just really unbearable)
Second example; I want to bind to “i” on QWERTY to say, open an inventory. Nope. Can’t do that, because there’s no default mapping to “i”, and forcing users to remap their keys is out of the question.
I’m also not sure how the WndProc hook, nor XInput/DirectInput wouldn’t integrate? It’s not like it’s some black-box system that hasn’t been used before. WndProc is still (unfortunately) used for input state mappings in a lot of games. XI/DI makes it simpler still.
Lets be clear, I’m not saying don’t do what’s in the design doc. They are good ideas. But there are quite a few use-cases for getting raw inputs, whether or not you believe so. Are they usually a “hack” to make something work? Yes. Absolutely. But there are cases where it makes sense to use.
Nowhere are we arguing the current system is a permanent nor ideal solution. In the proposed system, you’d make some sort of ‘snakeUp’ control/command/whatever of your own to bind to.
If the user binds this to a random mouse input, it’ll only affect them in the Snake game, and they wouldn’t be so stupid as to do this.
Imagine your default is bound to the numpad. Now, people with any keyboard without a numpad will be screwed out of the snake game as they won’t be able to re-bind the keys.
Again, it seems you’re misinterpreting our position here - there’s no argument that this is a permanent solution, it’s just that ‘just exposing raw keys’ won’t be done for reasons we’ll mention below.
If using scan codes and you’re still hard-codedly printing the scan code as ‘W’ even if it might be ‘<’ due to lack of an API for such, that’s still not considered ‘solved’. Most people will do that if the API leads them to think in keys instead of actions.
Potential inconsistencies with places the game itself resets/overwrites the raw input arrays. Using the game’s ‘raw’ input arrays directly would be a way to implement this in a slightly less hacky fashion, but it’d still be an interface that’d have to remain compatible for all eternity.
And, once the actual API is implemented, these can practically all be implemented using a set of rebindable control bindings as well.
Again, nowhere are we arguing that having ‘key input’ is a bad idea, or that the limited set of game controls is an ideal solution.
It’s just that, since there’s a better solution on the horizon whenever it is a priority (it is absolutely not at this time, there’s a number of more important features that need to be worked on first that lead to postslikethese - 3 links, by the way), having an API to return raw keys, while solving certain problems now, will have to be retained to not break user scripts in the future, which will lead to people, both those running older unmodified scripts, and those learning by reference while writing newer scripts (since they’re potentially ‘too lazy’ to learn to properly use the new input system), using the un-rebindable raw key-based system.
This new system would’ve been implemented a lot sooner, however the game’s input handling is insanely convoluted and hard to dissect from disassembly, so most attempts to analyze the way input travels through key bindings have led to a dead end, and with other features being a priority, this hasn’t been worked on since.
If there were a way to provide raw keys without the likelihood of script developers binding keys to buttons that aren’t present on user devices (imagine the horrors if someone’d bind an important command to F24…) or having a means to make this incompatible for authors of newer scripts past the point where it’d be removed (forced timestamping comes to mind, but discounting social aspects it’d have way too many technical problems with feasibility as well), we’d have done so already, but as we see it now this’ll lead to support questions of the class ‘how do I change my FiveM account’ when FiveM doesn’t have any account bindings just because a particular resource developer used SC license tokens for saving user data instead of Steam accounts despite checking for Steam accounts in the same resource and not allowing connection without a Steam account.
Here’s another slightly more realistic example than the numpad one:
What if someone accidentally binds a control to the ‘102’ key, that appears on non-ANSI layouts between ‘left Shift’ and where the US layout has ‘Z’, and users with ANSI keyboards can’t rebind this?
I think the FiveM community has shown that a half-assed solution will never be deprecated properly. Take anything from the C# server days, I bet the keys table is still floating around out there.
Your explanation is much better than the design doc, which only uses already-available binding commands. (mpTextChatAll, cellphoneDown, etc) It reads as if you can only change bindings to already available commands in the game. That said, you can ignore my points about that.
Again, see above.
My example was just that, an example. Obviously using raw VKEY or scan codes without proper mapping isn’t a valid solution. But as I said, keyboard localization is a “solved” problem. Most games (and most people who end up writing their own input system) will end up creating a “Key to command” type system (such as GTAV’s limited one). I just didn’t mention all the implementation details for the sake of clarity. Even the “new” input system you guys propose will have to do the same thing in the end, unless you put the bulk of keyboard localization on the resource developer to ensure any given key is available on the user’s keyboard. (Probably a bad idea, as you can easily imagine)
Feel free to shoot me a PM of what you know, or some place to start looking, I’ll happily spend some time on it. (That’s what I do for a living, literally) I haven’t bothered to tear apart GTAV for the most part because I haven’t had a proper reason to do so yet.
So you mean I can’t have a “SuperScreenshot” keybind?
If there is raw support, I could port my already existing code-base from Garry’s Mod over - I wrote a custom bind system to handle vehicle Emergency Lights, Sirens, horn, cruise, and more… for players I added lock / unlock vehicle and more… For weapons I have change weapon firemode, aiming, etc… all bindable and working.
I also wrote a networking system in Lua which supports data-type and / or value restrictions so you can register input from clients… so if a user sends a networked message when they turn a siren on - if they aren’t the driver or front-seat passenger then it is automatically denied, if they are then it authorizes specific values… For lights I have 0 off, 1 on, 2 high… fog true / false, etc… brake lights, reverse lights, and all of that with a lot controlled through scripts and some through binds.
So the more back-end support for certain things, the more I can introduce… I am looking at moving my game-mode to GTA because of the large map, etc… I could do something similar in Garry’s Mod but I’d need to create the map and make everything a lot smaller which then makes it look worse so I’d rather go with a newer engine.
