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!
What is the advantage of this complicated key up/key down/overloading versus a separate bindable action to toggle autowalk? And what is the advantage of overloading keybinds with complicated options versus a macro system?
Heck, if you implement the GUI with some scripting language you can even let players create macros that run scripts. We’re already talking about advanced windows so just let them copy/paste their Python/Lua/whatever into a basic text field to make the macro, then assign the macro a keybind like any other.
In the simple Keybind Options you wont see the Key Up, Key Down Stuff (expert options only), but this ability is quite important, because not everyone knows how to script, and having a non-script way to do easy things like this.
And Macros are indeed something I thought about, though not in much detail.
If you do allow macros, I don’t see any advantage of having specific key up/key down binds. And regarding autowalk I think it is easier to just have an autowalk action regardless of whether you have macros.
And the macro system doesn’t necessarily require users to know how to script. You can have them drag actions into a list and save the list of actions as a macro.
Thing is this type of Feature is supposed to exist for EVERYTHING, so it is not enough to just spam dedicated Auto-Actions for those. This is not just a convenience thing, this is supposed to help people who have physical disabilities and cant hold down a Key for more than a few seconds, and I KNOW some of those people.
So wouldn’t it make sense to have an auto toggle for every action? Are you concerned about programming all that (perhaps a .autotoggle() that is inherited) or are you concerned about fitting it into the advanced controls GUI?
Maybe you could even have an auto modifier keybind, so if the user presses any keybind while holding the auto modifier key down that action is automatic? Eg: if auto-key is Alt, then by default Alt+leftclick = repeat whack.
Modifier Keybinds will work too for this kinda thing, though it is much easier if you dont have to constantly use a modifier key.
And if it did not allow for Key Up and Key Down as events, then every Modder would have to implement a separate Auto-Do-Something version of their thing instead of just having to worry about using the Up and Down Events instead. I do not want to discourage people from implementing it right, which is why I wouldn’t leave it out.
And the auto-Repeat is already part of the Keybinds stuff if you looked at the Table.
Couldn’t the auto function be inherited from your base class? Or however that works in Rust/entity-component-system.
I imagine the client backend has a list of auto actions currently enabled, then every X milliseconds it goes through that list and attempts to perform each action. So the generic auto function for any given action simply adds or removes that action from the list. Each action would have to specify a cooldown, for example the whack action might grab its cooldown by doing simple math on the held item’s encumbrance. When the client backend goes through the list of auto actions it checks if each action is on cooldown, and if not, performs the action.
That’s just one way to do it, I guess. But at least this way puts no further burden on modders.