Custom/generalized keybindings

[taikedz]

Hello

I wanted to know if it would be of interest to add the possibility to register custom key bindings to Minetest for mods purposes?

I see there's this already

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

player:get_player_control().up

I was wondering if it would be of interest to add these:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

minetest.register_control("j") -- defined by letter
minetest.register_control("k","cust1") -- custom table entry name
minetest.register_control(17,"ctrl1") -- defined by code

-- return error if custom key already defined so as to avoid mod conflicts?

-- Usage examples:

player:get_player_control().keyj -- automatically generated name
player:get_player_control().cust1
player:get_player_control().ctrl1


I am presuming the W3C's codes are general-purpose and not just for the web?

https://www.w3.org/2002/09/tests/keys.html

My own intention is to be able to add a mod that would allow the use of I,J,K,L keys as well as U,O,P to set yaw, pitch and usage, for full keyboard control.

[Krock]

And how, do you think, can these keys be configured individually for players who already use them for another function?

[taikedz]

Are you talking about conflicts where 2 mods use the same keys for different functions?

I'd expect that would be an admin task when introducing two overlapping mods - they would have to configure these appropriately, just as if two different mods were to try to redefine the same block.

+++

Alternatively, providing a key assignment interface as part of the engine. So a mod make woudl be able to do something like this:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

minetest.registerkey("secondpunch")

-- .... to be used like this ...

if player:get_player_control().secondpunch then
-- ...


and add to the Minetest application interface a key configuration panel accessible during gameplay.

Would that make sense?

[Wuzzy]

I also strongly object to the idea of hardcoding any keys via the Lua API. It wouldn't even work as soon anyone is using custom controls. In other words, it simply can't work.

However, adding a small set of abstract “Lua keys” to be used for special actions is a pretty good idea.
The mods simply use something like “Lua key #1” without knowing the actual key binding. The clients then have bindings to the “Lua keys” which can in turn be configured freely.

I think such an approach would work and it would make sense. I have seen such an approach being used in a different game for 3 keys and it worked just fine.

What could be still tricky is to make sure that no 2 mods want to use the same key for completely different reasons.

[Byakuren]

Are you talking about conflicts where 2 mods use the same keys for different functions?

I'd expect that would be an admin task when introducing two overlapping mods - they would have to configure these appropriately, just as if two different mods were to try to redefine the same block.

+++

Alternatively, providing a key assignment interface as part of the engine. So a mod make woudl be able to do something like this:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

minetest.registerkey("secondpunch")

-- .... to be used like this ...

if player:get_player_control().secondpunch then
-- ...


and add to the Minetest application interface a key configuration panel accessible during gameplay.

Would that make sense?

I like this reassignment idea, except I think key registrations should have their id modname-prefixed to prevent collisions, and also include a description meant for humans, so the player knows what the mapping is for. The key settings between a player and a particular key id should be saved also, on the client.

This avoids the problem Wuzzy mentioned about different mods wanting the same abstract key, since there would be as many keys possible as there are strings, and they would be unique across all mods as long as prefixes are enforced.

It creates another problem though, where players might have the same physical key for different abstract keys in different worlds, because there was no conflict in the individual worlds. If the player then plays in a world with both mods, they will have a key conflict. Maybe this should be resolved manually by the player (and have the game alert them), or settings should be saved per-world rather than globally.

[Byakuren]

Rethinking, I think the best option would be to have a large number of lua keys as Wuzzy suggested, in the C++ part of the engine. A way to parcel out and configure the mapping to lua keys could be implemented in lua engine code or as part of a framework mod. This would make the C++ portion simpler and still allow unambiguous configurable key mappings.

[taikedz]

After sitting on it, I'm still thinking it would be nice for a mod to be able to say "hey I expose an extra key, please configure me", and for the UI to have a responsive thing - once loged in to server, user can bring up a "key bindings" window and see what extra keys can be configured, for each mod, on that server.

It leaves it up to the player to configure it, and the mod just registers a handler by name/ID

[kaadmy]

There should at least be some "user" keys, such as userbind0, userbind1, ...
And have mods use those instead, like @taikedz suggested.