Controllers, Keybindings, Mice and such. Second Part

Controllers, Keybindings, Mice and such. Second Part

First of all this tiny addition to the Multiplayer Section:

Local Multiplayer is also possible thanks to the way I’m going to implement Controls, so that multiple Mice and Keyboards could be detected. The Mice will probably be the largest Issue for that, but I will see how that is gonna be solved! ;D

The Part that was already there but for reading convenience:

Default Controls

As for Keybindings, there will be defaults for WASD and for Arrow Keys. Both won’t overlap and will work at once, so you don’t need to adjust Controls all that much. The Arrow Keys variant will work with the Keyboard Layout that I have myself, so it might not be the best considering that this Area is not Universal.
The F-Keys (F1 to F12 and so on, not the actual F-Key) are not going to be used for anything in the Default Keybinds, not even Debug Stuff. I don’t even want Mods to Default any Keybinds to those, with the reason being that people using Fraps, OBS or other Screen Capture things, have the ON/OFF Buttons and similar Recording Options mapped to the F-Keys by Default. Also apparently there is Keyboards without ANY of the F-Keys or an ESC Key…​ Yay for Apple! (Not that I would add support for Apple Stuffs, but still)
In the Default Keybind Config, the Z-Key and the Y-Key must be mapped to the same Function, in order to give less reason for Users to change Keybinds if they have a common QWERTZ Keyboard.
Generally, I do not want Users to end up changing their Keybinds (I will ofcourse give the Options for that in an actually proper fashion), this has the simple Reason, that when Players communicate Keybinds to each other, they usually mention the Letter corresponding to the Default binding, and that can be very confusing in some cases, when the recipient of the Message already reconfigured it.
Keybindings that are opening non-Inventory GUIs or for Debug purposes, always have to default to the Area to the right of the U, H and B Keys (including those 3 Keys themselves). They have to be between the WASD Area and the Arrow Keys Area by default.
In regards of Dvorak Users, there should definitely be an option that auto-remaps all Keybinds from QWERTY to Dvorak.

And the new Part:

Advanced Controls

There is gonna be more than just simple Default bindings ofcourse. Ever thought how Keybinds usually work? Normally there is a Key-Pressed and a Key-Unpressed Event, there is no “Holding Key” Event, the holding needs to be implemented by the Game itself.
So if you want to set Keybinds differently, you could map “Press W” to “Start Walking Forward”, and then map “Press W” to “Stop Walking Forward”, this would result in you starting to walk when you press W once, and then stopping the walking when you press W a second time without you needing to hold W at all.
Or map “Stop Walking Forward” to “S” as well as “Start Walking Backward” to “S”, but without pass through so that “S” is being cought by the “Stop” Keybind before it can reach the “Start Walking Backwards” Keybind, so Priorities and sortable Execution Orders will be a thing too!
But even better, this could be combined with mapping multiple Keybinds to one function, so map “Press and Unpress W” like you normally do to Walking and stop Walking, but then map lets say “Press K” to “Start Walking Forward” too, meaning you can walk with WASD like normal but press K to Autowalk!
Want to get even more advanced and make things even more confusing yet awesome? How about using multiple Keyboards at the same time and change Keybinds per Keyboard! So instead of K you map the Autowalking to W on the second Keyboard! That way its more intuitive for remembering Stuff, even if the second Keyboard might be a bit away!
This Functionality will be able to detect Keyboards not only by “first plugged in and second plugged in” but also with the UUID set by the Manufacturer with possible fallbacks if the Keyboard isn’t found properly.
This can also be used for Controllers so one of them is always “Player 1” and the other “Player 2” no matter which order or which USB Slot you decide to choose! Ofcourse with the possible fallback that if only one Controller is detected it will use it for Player 1 if you wanted to, even if you happen to plug in the Player 2 Controller.
In general the Fallback by default will be for “Devices that havent been specifically assigned yet”, which will mean that if you buy a new Keyboard and plug it in, it will mirror the Keybinds of whatever the Primary Keyboard is. This is especially needed for USB Stick installs of the Game, where you just Plug and Play at some foreign Computer, while you also have additional Home Settings for specific Keyboards.
One thing of note is, by principle, I will not allow the “Reset All Bindings” Button to reset any Device that is not plugged in at that moment. It will however create a new Keyboard and similar Profile with the actual Default bindings and set that Profile as the Primary Profile, keeping the old Profiles intact and moving them to the “Old” Tab in the Options as well as moving the corresponding Device Settings File to the “old” Sub Folder.
There is going to be a lot and I really mean A LOT of customization options, to the point that Macro Keyboards are pretty much gonna be useless except for very specific timed tasks or a turbo button maybe, and even that I might obsoletify later on!
Oh and in case you are afraid of the huge GUI that this would cause, all of this is the Advanced Settings not the Normal Settings, so don’t worry too much about it, if you are just playing casually. :wink:


On Windows this is near impossible without getting Admin access (and who wants to give that for a game) because Windows sucks for input handling.

On Linux it’s doable, but have to take into account X11 vs wayland for it.

No clue on mac. ^.^;

Multiple gamepads are trivial though.



Just run it in the new Linux Subsystem for Windows then. XD

Is it doable in both at least?

No one cares about Apple, I’m not gonna add intentional Support for that garbage.


Won’t help, it doesn’t get raw hardware access, it goes through the windows kernel, which is what batches the event calls together.


Lol, so it should incidentally work then. ^.^


Considering I plan on BSD support, probably, if that works right too that is.


Mac’s may use a BSD kernel, but the rendering systems are entirely different. BSD uses X11, Mac’s use… Cocoa or whatever it was called…