Grid Sage Forums
Cogmind => General Discussion => Topic started by: Kyzrati on July 04, 2017, 07:29:44 PM
-
As of Beta 2, Cogmind comes with a way to use some non-QWERTY keyboards as well as rebind specific commands if necessary.
However, the system is currently considered experimental because although I've tested it pretty thoroughly, no one else has used it yet, nor does it live up to the user-friendly standards you'd expect from a Cogmind UI feature.
It's also pretty limited: 1) The settings are only accessible via external text files, 2) alternative US101 keyboard layouts work well but foreign keyboards are not fully supported, and 3) the underlying key labeling system is not 100% intuitive (I based it on the way SDL keycodes work).
As such, to prevent inexperienced players from running into too many issues (or thinking it's better than it is) and getting frustrated, even exposing the bindings requires setting a config option: open /user/advanced.cfg and set exposeKeybinds to 1.
The next time you run the game it will create two files:
- /user/keyboard.cfg lists the result of pressing each physical key on the keyboard, in terms of letters, numbers, punctuation, etc. It is referenced when entering text in game (e.g. typing hacking commands) and also used to automatically generate the next file below by converting the internal command defaults over to the alternative keyboard layout.
- /user/commands.cfg lists all commands recognized by the game, and the key combinations to trigger them. Technically the contents of this file simply override the defaults, so individual lines of unimportant commands can be freely removed to leave only the commands you care about changing.* Notice that the commands are divided into multiple groups ("domains")--a single domain cannot contain more than one command with the same definition, e.g. CMD_DOMAIN_COMMANDS cannot also assign the '5' key to access the gallery, because it already accesses the game menu (the latter would have to be changed to something else first). (*however, do not remove the domain header line for any domains which contain modified commands, otherwise the game will not know which domain they belong to)
Because you probably don't want to mess with all the little details, I've included presets for the most common use case that works nicely: switching to an alternative US101 layout. In the /rex/ directory you'll find Dvorak and Colemak presets. Delete any existing keyboard.cfg/commands.cfg in the /user/ directory, and copy the preset you want to /user/. Rename the preset file to "keyboard.cfg" and start the game, which will automatically create a commands.cfg based on that keyboard. No more configuration necessary (although again, be sure to set exposeKeybinds=1 first! otherwise it ignores these files).
Other notes:
- Changes to default commands are not currently reflected in the in-game help.
- To avoid conflicts, remember that if you bind a command to a new key, you'll want to also rebind the other command in the same domain that was originally bound to that same key (if there is one).
- Deleting both/either file will cause the game to recreate them with defaults again (QWERTY w/the usual commands).
- If you'd like to make changes in the keyboard file itself (such as describing a custom keyboard) and have those changes applied automatically to all appropriate commands, you'll want to delete the commands.cfg file and have the game generate it based on the new keyboard layout.
- This system only supports keyboard commands; mouse commands cannot be changed.
- SDL keycodes are kinda weird, so things like Shift-3 are actually represented by a single "HASH" (#), without the Shift modifier in the commands.cfg file... (this won't matter if we eventually have an in-game rebinding system, since that'll take care of these odd conversions automatically, but if you want to edit some commands you'll need to be aware of it)
- Unfortunately I don't think foreign/non-English keyboards can be perfectly supported by this system, nor would Cogmind be able to display the non-ASCII characters necessary to describe a command in the game itself (due to how its bitmap-based ASCII fonts work).
So... yeah :P. I'm glad to have finally gotten somewhere with keybinds, though having already put a lot of work into the system so far and seeing how much more would be necessary (a lot!) even though it would never be perfect, makes me unsure of whether or not it'll be revisited later. There are a number of factors suggesting it wouldn't be worth the huge amount of work required (like probably porting to a more modern engine) to go further:
- Cogmind is an English-only game, so non-US101 users are a small minority
- Lots of foreign/non-QWERTY users already have their own external keyboard solutions
- Cogmind cannot display non-ASCII characters
- All UI features are mouse-accessible, and three-quarters of players use the mouse
Anyway, we'll see what happens, but hopefully those who can already take full advantage of the system (Dvorak/Colemak users) will enjoy this new feature!
Feel free to ask any questions or leave any feedback on rebinding here in this thread.
Addendum:
- If you're looking for a WASD layout, Shadowfury333 has shared one here (http://www.gridsagegames.com/forums/index.php?topic=882.0) if you're a keyboard + mouse user.
- And I've created a WASDQEZC layout here (http://www.gridsagegames.com/forums/index.php?topic=823.msg6983#msg6983) for pure keyboard users.
-
I know this topic's a month old already, but it's a great idea and I have a question that is sort of related: is there a list of all keyboard commands available in the old 7DRL prototype?
I was actually thinking about making my own wrapper/launcher using AutoIt (https://www.autoitscript.com/site/autoit/) or AutoHotkey (https://www.autohotkey.com/) to add a key remapping ability to the prototype (with a full configuration window), and it would help to have a full list instead of having to hop back and forth between manual2.txt and the in-game commands/help screen, if such a list already exists (but if it doesn't, don't bother making one just for me; I can do that myself and don't need to tie up anyone else's time ;)).
Since those languages can also send a series of virtual keypresses, I was also considering adding the functionality to set a 'default' font/size which the wrapper/launcher would switch to on startup using the appropriate amount of Ctrl+PageUp keypresses (that would play nicely with my recent tilesets (http://www.gridsagegames.com/forums/index.php?topic=841.0), and could even be made to check the user's resolution and send an Alt+Enter command to put the game in fullscreen mode at startup -- probably a tick box in the launcher if I decide to do that)... :P
-
Nope, in the 7DRL those two places are the only way to find them all (it's just two lists! pull up the manual2 list next to a copy of the game and that's everything).
That sounds like a really cool project though!
I wonder if an external solution like that would be feasible for modern Cogmind players using non-English keyboards, since I probably won't be able to support all of them internally.
-
Ah, that's fine then. As long as those two lists contain everything, I can easily make my program without feeling like I'm missing anything. ;)
The way these languages work (one was originally a fork of the other, so they are similar), I think I can make them save to and read from a key config file that will handle remapping similar to Brogue. That is, one key will be interpreted as another when the game window is in focus. For example, if the config file contains a line that says a=b and the user presses the a key, the wrapper will interrupt the keycode and send the one for b instead. I've used these languages before for other games and know they work well (though I've only ever used hard-coded keycodes rather than configurable ones), plus I'd release the source so people could use it without any qualms, but some users may be weary of it anyway: reading and intercepting keycodes sounds an awful lot like what a keylogger does (and may even trigger a false positive in certain virus/malware scanners)... :/
And yes, an external solution like that would probably work for non-English keyboards too, but I have no way of testing that since I don't actually own a non-English keyboard. Plus, the possibility of certain scanners throwing a false-positive about it being a keylogger means it might not be the most professional solution for your commercial game either... :/
Another limitation that can be kind of annoying for certain games is that AutoIt/AutoHotkey programs usually can't distinguish between in-game dialog windows, so a "what is your name" screen would have some very strange behavior, lol. When I made a remapping program for the PC version of Phantasy Star Online (https://en.wikipedia.org/wiki/Phantasy_Star_Online), I got around this limitation by programming a key command (mapped to Ctrl+Tab IIRC) to toggle the remapping of the other keys...
-
but I have no way of testing that since I don't actually own a non-English keyboard.
On Windows at least you don't actually need a real keyboard--you can use the virtual keyboard, which can be set to any of the common ones fairly easily. Like I don't have a French keyboard, but I was able to pull up an AZERTY keyboard on screen and click keys to test out the system. It's how I tested this rebinding system (with Dvorak, too), the development of which I wrote more about here (https://www.reddit.com/r/roguelikedev/comments/6q053t/faq_fridays_revisited_18_input_handling/dktp605/).
I got around this limitation by programming a key command (mapped to Ctrl+Tab IIRC) to toggle the remapping of the other keys...
Ah yeah, that would be important :P. In Cogmind there's the manual hacking interface (and name/seed entry), which the 7DRL didn't have.
-
Oh, I forgot all about virtual keyboards! I don't actually use Windows (Cogmind works perfectly through Wine (https://www.winehq.org/) in GNU/Linux), but I've got my own virtual keyboard installed and I just checked -- it can also be configured for other layouts. :D
-
Just wanting to testify that the keyboard rebinding feature works really well for me! My F2 key (which toggles keyboard mode) doesn't work with my laptop, so I have to switch it with another key. After moving the keyboard mode to the 'P' key, I got it working! I'm pretty happy with the result. :)
-
Awesome! This is like... the first report of rebind use in the wild (aside from players I know are using the automatic keyboard layout rebinding, which is a somewhat different thing).
And yeah 'p' is a great key for anyone to replace with something they want to use frequently that may have a harder key combo, since the p key exists purely as an easy way to teach new players in the tutorial how parts need to be activated. Once the autoactivate feature is toggled, after that you never need it again :P
Now you can quickly switch between mouse and dedicated kb mode with ease like the rest of us :D
-
Now you can quickly switch between mouse and dedicated kb mode with ease like the rest of us :D
Gone with the habit of pressing Esc, 4, U, Esc just for the keyboard mode! You will not be missed. :P
-
Awesome! This is like... the first report of rebind use in the wild (aside from players I know are using the automatic keyboard layout rebinding, which is a somewhat different thing).
I suppose I should have posted my WASD stuff in this thread rather than its own, but meh.
-
Well you can link to it from your post there, but technically this thread's about Cogmind's own internal rebinding solution, whereas yours is an external one. (Which by the way, thank you for providing that :D) That and you have a dedicated discussion thread for your own in case someone has questions about it, or modifications. I imagine there will be some more users who want to take advantage of it once we have a bigger player base from Steam.
Here, I'll link it for you :)
Shadowfury333's WASD Cogmind solution! (http://www.gridsagegames.com/forums/index.php?topic=882.0)
-
I play left-handed, so any type of rebinding updates you do are very well received by me! Thanks
-
There seems to be a bug with transferring a complete commands.cfg from b2.1 to b3. It seems almost centered on a weird name sync bug when generating a new commands.cfg file in b3, starting at line 174:
171 CMD_BS_DEFAULT_WAIT "Stair/Trap Interaction (2)" - - - GREATER
172 CMD_BS_DEFAULT_WAIT_M "Wait (1)" - - - KP5
173 CMD_BS_DEFAULT_WAIT_M "Wait (2)" - - - PERIOD
174 CMD_BS_DEFAULT_GET_ATTACH "Get Item" - - - g
175 CMD_BS_DEFAULT_DETACH_ALL "Get Item and Attach" - - - a
176 CMD_BS_DEFAULT_LOOK "Go Naked" - Shift Alt p
The thing is that it still works as the descriptions would suggest, rather than the CMD_* string. I'm not even sure how the commands.cfg works anymore.
-
Ah yeah, I put info about this in the Beta 3 release announcement (http://www.gridsagegames.com/forums/index.php?topic=898.0) (as a note under the "Update ASAP" section). There was a change in code in Beta 3 that didn't account for people actually using the commands.cfg, and adjustments to some core commands at the top of the file (made for the Steam release) messed up others in the file. And yeah, you're right the underlying cause is a name syncing issue.
It seems there may still be something newly wrong with the commands.cfg, even in Beta 3 with a fresh copy--DDarkRay has encountered an unconfirmed oddity even after making a new set, though I haven't had time to look into that since the build is frozen for Steam release right now.
Either way, start with a fresh commands.cfg and try that.
(This system overall is definitely still experimental since not many people have used it and reported back, though it's possible we do have a new development here which needs to be addressed. Any more information following a reset is welcome!)
Update 171013: It seems to be working fine, although in Beta 3 it may no longer be possible to delete non-rebound commands from commands.cfg and still have it always work. I'll have to test this later and see what's up, but for now at least using a complete copy and doing rebinds seems to be working as expected.
-
Rebuilding from a fresh Beta 3 commands.cfg works (not sure if perfectly, it only modifies movement, pickup, info, and ally order keys), and I've updated the WASD github release with beta 3 compatible keybinds.
-
Thank you! I should've dropped the update message in this thread as well xD
In the future I'll definitely be more careful about updates that may affect this system.
-
As Cogmind is now on Steam, we have some more players coming in, and among them are QWERTZ users. Although Cogmind can't fully support foreign keyboards, since the partial binding I included with the game for AZERTY players seems to be useful for some, attached is a new partial QWERTZ layout.
(Again, it's only partial, but better than nothing and worth a shot for those who aren't opting to use a better external solution.)
-
By request (https://www.reddit.com/r/Cogmind/comments/7io8lz/requesting_wasdqezc_for_us_layout/) I've created a simple WASD layout, which only adjusts letter keys to enable WASDQEZC movement for all directions while taking functions originally assigned to those keys and putting them over to the right on HJKLYUBN (vi) movement keys.
This turned out to be not too problematic in terms of understanding, since half of the WASDQEZC keys are occupied by part visualization mode controls, which conveniently appear in the row of buttons at the bottom of the Parts window, so I just moved those (from CEWQ) to HJKL to keep them in the same order as the buttons appear there. Therefore:
Coverage/Vulnerability C -> H
Energy/Heat E -> J
Integrity/Mass W -> K
Info/Matter Q -> L
The remaining four commands are switched as follows:
Direct Attach A -> Y
Status S -> U
Data D -> B
Intel Mode Z -> N
Status and Intel Mode aren't used very often anyway--the most commonly used commands here are Data and Direct Attach.
I've tested it a bit and everything seems to be working as a WASD user would expect, though be aware of the following quirks:
- Cogmind's HJKLYUBN run movement modifier ('r') works with WASD as well, but was originally placed at 'r' because that key is convenient for vi users--it seems quite inconvenient players who want to use WASD. I could change the run modifier to 'p', which is an otherwise unimportant key, moving it to the other side of the keyboard for easier usage, but unfortunately the 'r' modifier is one of the very few hard-coded command modifiers in the game, so it cannot be moved via commands.cfg and I'd have to code a special advanced.cfg setting to enable that adjustment if there is interest in such a change among WASD players.
- 'd' is also normally used to activate keyboard mode's modal drop mode, so that has moved over to 'b' along with Data. Drop mode is rarely used anyway, being primarily added for a minority of Linux players who don't have access to the Alt key.
Beta 4 includes the relevant commands.cfg file in its /rex/ directory.
-
Wait, 'r' is a hardcoded function? I've been using it for player status in my 8-way WASD keybind and hadn't noticed any issues. I suppose I should consider moving self-status to another key to allow running.
-
'r' is only a hard-coded function when combined with a movement key, which is why you wouldn't have noticed it. I'm pretty sure you can continue to use it as you are if you want, without issue.
-
I mean, it doesn't have an effect if it is set to show status, it's more that because shift+w/a/s/d produces the information for the item at slot w/a/s/d I can't use that for running, so having a key that works with wasd for running would be nice.
On the other hand, it would be easier to have something like DoomRL where hitting a key (spacebar in DoomRL by default) makes the next movement action a run.
-
Ah, yeah I've added a number of modal keyboard commands since the first release but there's no such thing for running yet. The way I implemented it was to just check if 'r' is being held when a movement key is pressed, in order to support vi running.
I can see how a modifier would work... even better, eh?
Then it could become a real key in the normal system that could be reassigned, too. I guess I didn't think about that one enough and wanted to treat 'r' like modifier keys (e.g. Shift) normally behave, and how that is a run modifier, too.
I'll see about changing the implementation. (I guess on the user side the main issue there is if you want to string multiple runs together, you'd have to press the run key each time rather than now where you can just hold it down, as I like to do with the Shift key running. Is that how it works in DoomRL?)
-
Pretty much. DoomRL will automatically stop the player when getting to a doorway or staircase, and IIRC when spotting an enemy, but otherwise you just keep going.
Granted, when playing KB+M with my setup I tend to just tap the keys repeatedly to move quickly, but then again DoomRL is far more combat focused than Cogmind, so I'm usually going tap, tap, RMB (to shoot), tap, tap, tap, RMB,... the whole time, with the run command mostly for quickly getting to a staircase after clearing the level.
In Cogmind I almost always move a few spaces, look around, move a few more, look around, carefully consider what to go to, frantically run across a hall into another room, wait a bit, and so forth. If I have a Sensor Array I'm also often waiting for a bit between every few moves if I see something suspicious outside, so I'm not sure how much I'd even use a run command.
-
DoomRL will automatically stop the player when getting to a doorway or staircase, and IIRC when spotting an enemy, but otherwise you just keep going.
Yeah Cogmind already has autostopping on enemies and terrain features, that part of the behavior has been in there for a while. Was just interested in the keyboard modifier specifically.
so I'm not sure how much I'd even use a run command.
Hehe, yeah it's less useful/necessary in a lot of cases compared to other roguelikes, but I use it a fair bit as a combat bot going down hallways. Not like I usually have sensors anyway :P
-
There is an error in the Colemak configuration. The L key is incorrectly bound to "O", when it should be "I". Both the lower and upper case bindings were wrong.
Is currently:
...
76 L O
...
108 l o
...
Should be:
...
76 L I
...
108 l i
...
I have attached the corrected binding.
Cheers!
-
Excellent, thanks for the correction! Interesting it wasn't brought up before since I'm pretty sure we have at least one other Colemak user, but I guess that key's not really used much, if ever, depending on how someone plays. I'll include the updated file with the next release.
-
For AZERTY keyboard.cfg doesn't work correctly, so made a small Autohotkey script that enables complete support. Keys on screen will correspond to the AZERTY keyboard key.
How to use:
- Download and install Autohotkey 2.0+
- Download the attached script, cogmind_rebind_azerty.ahk
- Move it to your Start Menu programs folder if you want the script to always be active when you start your PC (script only rebinds keys when you use Cogmind so it's safe to have it active at all times).
Folder location: C:\Users\< your username >\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
- Double click to start it
- If you've edited keyboard.cfg and/or command.cfg delete both.
- Enjoy Cogmind in AZERTY :)
Notes:
- Kept 0-9 as default (no need to hold SHIFT)
- Use SHIFT + ALT to access supported 0-9 special characters (e.g. all 0-9 special characters except things like éè~` etc).
- ALT Gr keys work.
- [] can be accessed both with ALT Gr and the original ^$ keys, so that you can scroll your inventory without having to hold ALT Gr. Edit the marked line in the file if you want to use the dollar sign (unneeded afaik).
-
Thanks for adding this, Gokudera!
-
My pleasure! Here's hoping most AZERTY players will find this thread
-
I imagine they will since it's the main thread pointed to for info on this topic, although to be honest seeing as you have significant added value here, I think it would also make sense to also put your AZERTY info/files out there as a separate thread of its own, too.
-
I've made some bindings for Colemak users who want to keep the same finger positions as QWERTY during vi-like navigation.
This way, we can use homerow keys HNEI as well as JLBK for all vi-like movements (which correspond to QWERTY's HJKL YUBN).
I made this by first using a default keyboard.cfg to swap keys in the following manner:
Colemak -> Default Command
E -> K
K -> N
N -> J
J -> Y
Y -> E
I -> L
L -> U
U -> I
Now your can move around by using
J L
H N E I
B K
This means that 2 default commands were actually affected:
- Cycling between energy/heat info, now bound to y (think of "energY") (previously bound to e)
- Open/closing the inventory panel, now bound to u (coincidentally in the same position as QWERTY's i key, to which it was previously bound)
All other commands work as expected (as default bindings)
To install, just delete keyboard.cfg and then drop this commands.cfg file into your user/ directory
Hope this helps, it sure made the cogmind experience a lot better for me!
-
Hi, I recently started playing Cogmind (thanks DoshDoshington!) and I'm loving it so far, but the only thing that I'm really finding as a major pain point is the limitations of the key rebinding system.
I'd love to play using a WASD + mouse scheme, and while Shadowfury333's AutoHotKey script + commands.cfg file gets very close, there are still a few issues (for me):
1) The game doesn't change to reflect the hotkey changes. This isn't a problem for the information in the in-game manual, but it's very unintuitive and confusing for hotkeys displayed in the UI (such as the scan hotkeys, the inventory mode hotkeys, sort hotkey, etc.), especially if you take a break from the game and come back to it a few weeks or months later and can't remember how you had set it up. I appreciate that some keys have long names (SPACEBAR) and there might not be enough space in their UI location for them, such as the scan hotkeys, but in those situations maybe just removing the hotkey reminder from the UI would be better (and you could maybe even show the hotkey as a tooltip on hover?)
2) The mouse isn't rebindable. When using a WASD-based control scheme I'd find it more intuitive to switch the functionality of the right mouse button to the left one (left clicking on things to 'select' them is more in line with most other top-down games, such as RTS games), including for moving and setting the camera, and change the right mouse button to no longer issue movement commands, but instead enter fire mode, and then when in fire mode for RMB to shoot, while LMB cancels instead (the opposite of currently). Basically, I'd just really want the LMB and RMB functionality to also be exposed in the commands.cfg file. I'm assuming currently you've special-cased certain actions like holding RMB to set the camera to a location, but maybe that could be solved more generally by adding it as an additional modifier called Hold in the commands.cfg, alongside Ctrl, Shift, and Alt?
3) Movement key combinations for diagonals (e.g. w+d). This is great because it frees up 4 keys near where your left hand will be 99% of the time for commonly needed actions other than movement. This point actually is handled by Shadowfury333's script, but I'd love to see it included in the base game so that users don't have to install third-party programs to make this work. It's actually at this point the only thing you need the AHK script to do that you can't just do baseline. Shadowfury333's script even allows you to customize whether you want a delay for WASD input during which the script waits for a second input, or whether to simply not move on keypress, but rather on key release, which helps to prevent accidental cardinal movements when a diagonal movement was intended.
Finally, I'd just like to say that I'd be super super grateful if you could put in-game key rebinding on the roadmap. It would be so much nicer than having to mess around with advanced user options and text files. I appreciate you mentioned this would be a ton of work, but I figured I'd at least register my interest with you, if that matters.
Cheers and take care. The game you've already got is nothing short of a miracle for a 1-man project. Truly amazing :)
-
Hi matthewgdv! Thanks for the input. These points are known and noted, though an update to the system is not currently planned. Although there are theoretically technical solutions for everything, they involve a massive amount of work, and even if the system were to be updated, an external solution will always be superior to whatever would be implemented in Cogmind (due to limitations). Even the experimental solution we have now took like two full weeks to implement within the constraints of what I'm using, and it barely scratches the surface of what is needed and/or should exist in an ideal world xD
(More specifically to one of your points, the mouse commands don't always match up one-for-one in Cogmind, so exposing them in the configuration would not work.)