GridKeys – “Fresh, Fast, and Not Quite a Grid” Edition
… What the heck is this?
Essentially, my aim is to imitate SC2’s grid hotkey setup, while also preserving the WASD movement that Stonehearth has. What this means is that all hotkeys should be reachable without lifting your hand off WASD (with a few obvious exceptions like escape or when you perform shift and some key).
… Okay but how does this work in Stonehearth?
My first attempt follows this simple rule: Start menu items (the main buttons you see all the time on your screen) map from keys Z to N, in order. Special menus like the town overview and bulletin are mapped to other special keys. Then when you enter a sub menu (for instance, by hitting Harvest), the buttons Z through N will now map to those items in order.The logic behind this is that you know the button’s hotkey based on their position from the left. The mechanical difference between this and default hotkeys is that Entering a sub menu changes the hotkey mappings, so the key you press will have a different action based on which menu you are in. This makes much more sense when you try it out.
… Cool, but that’s not a grid.
You’re right. But I didn’t say I was done implementing this yet.
… Alright, alright but but what do you want me to do?
Test it out! It feels a tad weird at first since you’re probably used to thinking “H for harvest,” instead of _“X for harvest menu then X for harvest tool.” Trust me, though, it won’t take long to get comfy with it. Also, you can still view all the hotkey bindings in the settings menu or by hovering over the button.
What I’d like to know about:
Any bugs of course!
How it feels! It should feel faster once you’re used to it
Possibly better hotkey bindings! Instead of Z through N, 1 through 6 might work better for menu buttons.
How the UI layout for the actual grid mappings should look!
Good thinking, cool idea!
I will not try it now - but most likely will in the future.
I just wanted to, ahem, ask about something.
This mod is set up for QWERTY keyboards - that’s great for me, as I got one of those; but, what if someone does not got a QWERTY keyboard?
Are you looking to extend the mod to non-QWERTY keyboards, too?
Perhaps “all gamers” these days got a QWERTY keyboard and you don’t even have to bother?
Again, cool idea! My curiosity just had me wondering ^^
The key binding system is tied to physical keys. So if I bind something to Q on my QWERTY keyboard, it actually binds to a keycode that is roughly equivalent to “the key that is typically to the right of Tab”, and if you use my scheme on your AZERTY keyboard, it would be bound to A. If this is not the behavior you are seeing, report it as a bug please!
Here’s an article that goes deeper into how the system we use works.
So what your saying is if someone is using, for instance, AZERTY keyboard, it will automatically work with the current mapping since “keyq” in the code will fire when they hit the A key?
GridKeys has been updated! I made it so whenever you click a menu action (one that doesn’t open a submenu), it closes back to the main start menu. This is preferable to me over leaving the submenu open after selecting an action, but let me know what yall think.
Thanks a bunch, Max. Without you I’d be bashing my head against a wall still, lol. I hope I wasn’t a nuisance. Btw, I found it most useful to add two events to start_menu.js:
start_menu_initialized, once didInsertElement finished
menu_action, in the _menuClick function (because I didn’t find a way that ‘start_menu_activated’ event could tell me if it were a menu opening or an action being clicked, it always just tells you what menu you’re in):
if (menuAction) { $(top).trigger(‘menu_action’, nodeData); menuAction(nodeData); }
So I’m wondering: Is it bad to override .JS files (like I know it is with .LUA)? Would it be possible to add these to the default start_menu.js? Is there a better way or something that I’m missing from implementation?
Also, you can still view all the hotkey bindings in the settings menu or by hovering over the button.
