Add Aux2 key for games to use freely, and maybe Aux3, Aux4, etc.?

[Wuzzy2]

Problem

Games don't have any key yet that they can freely use for their own purposes. Currently, most games use the Aux1 key. The most common use case is for sprinting mods.

But it's still limiting as Minetest itself already uses this key for Fast Mode and optionally also as a "climb up" key if you activated it in the settings.

So there is definitely an overlap, which is annoying.

Overloading Aux1 for sprinting doesn't seem to be that bad, it's been in use for years now and it's acceptable. But if you want to use Aux1 for something else, that might be more annoying, especially if you use Fast Mode a lot. Like, for example, if you overload Aux1 to be used to change some custom movement mode like jump height.

Solutions

Add a new key Aux2. This key does absolutely nothing by default, but it can be detected by the game (e.g. with player:get_player_control()) to do some custom stuff. Games can then detect keys with player:get_player_control().

Since this key does nothing by default, there are also no side-effects, giving full control to the game.

And MAYBE also add Aux3, Aux4, etc. I don't know how many new "Auxes" there should be in total, but at least one.

[hecktest]

It appears that the bitfield representing controls is already a u32, we might as well start using all of its bits as it will cost nothing.

But it will look ugly.

Imagine you have a dozen arbitrary AUX keys, up to "aux12" in the keymap or so. Since games are going to use them for different things, you'll have to redo your entire keymap whenever you play a different game.

When a game tells you to press "aux9" to do something, you might have a hard time remembering which key on the keyboard it was!

Conversely, when you're on the keymap screen, you don't exactly see what you're binding to what - you may bind Q to aux3 but you don't see what aux3 actually does in the game, it could even be context sensitive and perform many different functions. So you have to know in advance what aux3 actually is.

Solution to the naming problem

Allow the server to "allocate" aux keys out of the remaining bitfield space. An allocation would provide a short name and a tooltip description, which would be used by the keymap screen.

Solution to the display problem

Parse strings client side for a custom escape sequence followed by the ID of a specific virtual key. Replace it with a visual representation of the real key or joystick button that the virtual key is bound to, displaying it inline in text. Provide APIs to generate the escapes and to strip them from strings. (we might want to strip them from incoming chat)

The sprites representing the keys and buttons ought to live in a single spritesheet in the textures folder, allowing mods and texturepacks to override their look. Use squares for small keys and joy buttons, and 2:1 rectangles to represent wide keys like shift, backspace, return. Lastly, use a composite of an analog stick or d-pad graphic and an arrow blended over it to represent a bound stick or hat direction.

Solution to the shared config problem

Aux key assignments would probably need some sort of config local to each game. Servers could provide a string containing the game ID being used, it's not foolproof but I can't think of anything better at the moment.

[anon55555]

Solution to the display problem

Parse strings client side for a custom escape sequence followed by the ID of a specific virtual key. Replace it with a visual representation of the real key or joystick button that the virtual key is bound to, displaying it inline in text. Provide APIs to generate the escapes and to strip them from strings. (we might want to strip them from incoming chat)

This wouldn't work when nothing is bound to the virtual key, here are some options for what to do about this:

1. Always display the virtual key name instead of the key.
2. Only display the virtual key name instead of the key when nothing is bound to it.
3. Always display the virtual key name and display the key bound to it when a key is bound to it.

I think the best option would be to either not add these escape sequences, which would make option 1 the only option for mods, or to use a fallback string in the escape sequence when nothing is bound to the key, which would allow games to choose any of the options.

[Wuzzy2]

The problem is the virtual on-screen keys. This restricts us from adding infinitely many keys. I think it is simplest to just add a single key for now (Aux2 only).
The tricky question is, where would you put all the other Auxes on the touchscreen?

If it's only a single new Aux2, that won't be a huge issue.

[hecktest]

Ah, the Android port kills yet another good idea. What if we just take some touchscreen positioning and display info when registering aux keys?

Always display the virtual key name instead of the key.

Worst of all worlds and it's something you can already do. The very point of this is that whenever you see "press AUX13 to do thing", you shouldn't have to stop and remember what AUX13 even was.
I recall this being a huge problem with joystick controls in PC games where they'd tell you to press some generic "button 9", which was different for every controller, and sometimes the index was 0 based, sometimes 1 based. Utterly awful.

Unbound keys should be displayed in some conspicuous fashion, it's fine to write "Aux3" on them but it should be in red for example. Also warn the user that they have unbound keys.

By default nothing should be unbound; if the game's desired default for an aux key is already bound, heuristics could be used to find something that's close enough.

[anon55555]

Always display the virtual key name instead of the key.

Worst of all worlds and it's something you can already do. The very point of this is that whenever you see "press AUX13 to do thing", you shouldn't have to stop and remember what AUX13 even was.

By virtual key name I meant the name used in the key binding menu, so it would be "press Climb to climb", not "press AUX13 to climb".

[rubenwardy]

My preferred API for a fully comprehensive mod keybindings would be something like this:

minetest.register_action("mymod:spell1", {
	description = S("Cast spell"),
	default_binding = {
		"KEY_Z",
		"JS_LT", -- joystick left trigger
	},
	icon = "mymod_spell_icon.png", -- shown on Android
	
	on_down = function(player)
		
    end,
	
	on_up = function(player)
		
    end,
})

if player:has_action_pressed("mymod:spell1") then

end

I've named it action as it may not be a key, but could be multiple keys, a touchscreen button, or something else. It can also only be a keybinding, and be hidden on Android

The user can then use Keybindings in the pause menu to change the bindings

[Wuzzy2]

I don't think we can let games define infinitely many keys. There are practical limits and you only have so many keys on a keyboard. And on Android you only have so much screen space.

The real challenge is the question how it will all be made accessible and usable. If this is just going to be yet another setting that is deeply hidden in the minetest.conf settings tree, not much is won.

I think even adding only 3 new "auxes" would be a lot and is already more than most games ever need.

Maybe adding just Aux2 and nothing else for now would be a reasonable start. Even for Android I think it would be managable. Could be done in a way that is forwards-compatible, i.e. by making the change as minimal as possible yet still functional.

[ghost]

I don't think we can let games define infinitely many keys. There are practical limits and you only have so many keys on a keyboard. And on Android you only have so much screen space.

I don't see how this is a problem, frankly. No-one is saying "I want to register 10,000 keybinds" or w/e, they're proposing a system where we don't make assumptions about a game's needs and present the user with real, understandable names instead of arbitrary numbers. It's easy to propose 3 bonus aux keys (and believe me, I could use far more than that given the option), but then remember that keybinds are neither mod nor game-specific so the default value of each will necessarily limit what games can actually do with them.

If mods/games define the actions they need instead, the actions will be separate by nature and this issue disappears entirely. It's also a massively better option for UX, since users get to know what they're actually binding keys for, an issue that your proposal completely ignores. Minetest's UX is bad enough today, we shouldn't actively make it worse for the sake a band-aid fix.

Of course, I'm not a coredev and I don't presently have time to make a PR so my voice may not count for much... but I think input is in a position where it hasn't been built up as heavily as other parts of the engine, and we should take advantage of that to do things the right way. It's not the engine's place to decide what actions a game can take, and "Let games define named actions with default mappings" is a tried-and-tested pattern used by most modern game engines. We should follow suit.

[srutzky]

@rubenwardy Question about your suggestion:

My preferred API for a fully comprehensive mod keybindings would be something like this:

minetest.register_action("mymod:spell1", {
	description = S("Cast spell"),
	default_binding = { "KEY_Z", "JS_LT" },
	on_down = function(player)
	end,
	on_up = function(player)
	end,
})

I assume that this would be a global callback event handler, similar to the other minetest.register_on_* functions? If so, that's perfect! For the past two weeks I have been trying to figure out the best way to request exactly that (i.e. how would it work? does a globalstep function that constantly cycles through get_connected_players(), checking get_player_control() suffice? — it does not), and this is even better than what I was going to request 😺 .

Now, whether the bindings are direct to keys / buttons (e.g. "KEY_Z"), or abstracted to "Aux2", etc, is probably a separate issue. I see value in binding the action to a stable "AuxX", or even to "AuxX" plus "AuxY" combination (from the mod perspective), and then letting the users determine their own mappings for "AuxX" = "KEY_Z" and "AuxY" = "JS_LT" (as in your example).

[farooqkz]

What's the status of this?

[Zughy]

Now that R has been freed (#12632), it can be used as AUX2. It's just one key but it means twice the customisations for us modders

[Lazerbeak12345]

could be effected by #10738 (linking all the things)