First and foremost, a warning: this feature description is based on initial game research, and may not be implementable the way described here, or even worthwhile at all.
Background
The current game configuration system is somewhat of a mess. There’s a global per-system settings.xml (which does not change names based on the computer name, this is fun when you’ve set OneDrive to synchronize your Documents folder), there’s also an encrypted set of cfg.dat and pc_settings.bin (renamed to fivem_set.bin in the past) as well as control override XML files if setting any controls.
On top of that, this system is not extensible for our purposes, can’t be controlled by script resources (and if it could, it’d be allowing archived settings to be overwritten), and we have a perfectly fine Quake-style console system that could be used for expanding upon this.
Configuration
A good first step would be replacing the entire configuration persistence system (settings.xml and ‘profile settings’ such as the non-graphical options in the game settings menu) with a few convars bound to the raw setting structures. These would then be saved to a Quake-style config.cfg file automatically by means of implementing the Archive flag.
For those unfamiliar with Quake, imagine a configuration file like this:
// just a snippet, not a full example
seta video_screenWidth 1920
seta video_screenHeight 1080
seta graphics_tessellation 2
seta profile_displayGps false
These would effectively be toggleable using the console on the client, the classical game settings menu, as well as a new settings menu implemented in NUI, probably.
Input
It’s the current plan to replace the game keyboard/mouse-button input system with a custom system also inspired by Quake binds. This is the part that has been researched the least, as the input system in GTA is a monstrous overcomplicated… thing.
For the time being, controllers are out of scope and would still be handled by the original GTA input code.
Basic functionality
Similar to Quake, ideally, a few commands would exist bound to specific game controls, such as +nextCamera, +interactionMenu, +reload, +vehMoveLeftOnly, with accompanying - versions as well.
These would then be bound using a bind command, which would also persist to configuration:
bind "r" "+reload"
bind "v" "+nextCamera"
# this is a good one to wonder about, should this be multiple bind commands?
# should ; splitting be implemented for +/- detection?
# should we implement +vstr?
bind "a" "+vehMoveLeftOnly; +moveLeftOnly"
A frontend for these bindings will also exist, preferably keeping the existing game binding menu in place.
Extensibility
Of course, bindings in Quake don’t necessarily have to be directly related to a specific input. See these examples of things that would be possible for users to easily do:
Automating a menu
seta openMenu "+interactionMenu; wait 5; -interactionMenu"
seta menuDown "+cellphoneDown; wait 5; -cellphoneDown"
seta menuEnter "+cellphoneSelect; wait 5; -cellphoneSelect"
bind "f5" "vstr openMenu; vstr menuDown; vstr menuDown; vstr menuEnter; vstr menuDown; vstr menuEnter"
Executing specific commands
bind w "+moveUpOnly; say I'm walking forward, watch out!"
bind numMultiply "ooc pls help me i dont like rp"
Toggle toggle there’s a toggle
# holding f3 would disable the HUD option in game settings temporarily
seta hudOn "profile_hudMode 1"
seta hudOff "profile_hudMode 0"
bind f3 "+vstr hudOff hudOn"
# or pressing, with a `toggle` command
bind f6 "toggle profile_hudMode 1 0"
Resource support
Now, we get into the hard part: resources should be able to specify a few defaults, which would either be saved in a per-server configuration (gbind for global configuration?) or a resource-specific configuration (rbind for resource-specific binds?) where if the user is on a server with that specific resource these persistent defaults will be loaded and potentially (temporarily!) override the user’s global game defaults.
However, there’s no easy way to tag a specific bind value as being specific to a resource - one option would be to always disallow bind for server scripts, and make sbind/rbind exist to create server/resource-specific overrides, both from user settings (rbind chat t "+mpTextChatAll") and resource script defaults (SetResourceBind('t', '+mpTextChatAll') from chat, for example).
This also leaves the question of “what to do with the binding UI in game settings” somewhat unanswered.
Suggestions in this regard would be welcomed! It appears MTA:SA also redoes the game input system to support binds, maybe someone can chip in about how it works there?
