Add API to get user input mechanisms (ie: touchscreen? gamepad? keyboard?)

[rubenwardy]

Problem

Currently, mods need to create user interfaces for all devices without being able to customise for an input method. Knowing whether the client has a touchscreen for controls/gui is useful for scaling up GUIs.

This will also be required by #8679

Solutions

In the future, it's likely to be possible for a laptop to use touchscreen controls, and a phone to use a bluetooth keyboard.

I'd like to design the API well. I suggest something like the following information:

{
    has_touchscreen_controls = false, -- whether the touchscreen joystick / in-game controls are enabled
    has_touchscreen_gui = true, -- whether formspecs should be optimised for touchscreen use
    has_keyboard = true, -- whether they have a physical keyboard
    has_mouse = true, -- whether they have a physical mouse / touchpad
    has_gamepad = false, -- whether they have a gamepad / controller
    active = "gamepad", -- which did they use most recently?
}

This could be a new API

The only unambiguous value here is has_touchscreen_controls: the touchscreen controls are either enabled or not. The rest could be problematic - it's possible to have both a keyboard/mouse and gamepad connected, but only the former used.

Alternatives

...

Additional context

Related: #10632

[SmallJoker]

Suggestion: Split the input methods into two to introduce priorities.

primary = {
	-- Example 1: Laptop
	mouse = true,
	keyboard = true,

	-- Example 2: Mobile
	touchscreen_gui = true,
},
secondary = {
	-- Example 1: Laptop
	touchscreen = true, -- might have a touchscreen?
	joystick = true, -- connected but yet unused

	-- Example 2: Mobile
	keyboard = true, -- connected but yet unused
}

[rubenwardy]

I was thinking about having active_controls_method = "keyboard_mouse" | "touchscreen" | "gamepad",. We don't really have a way of tracking this currently

[FatalistError]

The addition of expanded keyboard and touch information would be a relevant addition to a PR to fix this

(Like full keyboard, and touch location)

[MisterE123]

Some games that I have played show help info for the last input method touched. So if you touch a gamepad, then your currently-used input method is a gamepad. If you touch a keyboard, then you are now using a keyboard input method.

[swagtoy]

I think the "has" X/Y/Z thing could be a bitwise now that Lua supports these, much like how keyboard input controls offers a bitwise variant of a function (plus, it'd be easier in the C++ code to use bitwise for that). Or just indexed into a child table like has = { ... }

EDIT: Now that I think about it, a bitwise might not be preferred since this is kind of a C/++-ism. Maybe though for consistancy we can offer a bitwise-specific function like player:get_player_control_bits() is done.

That, and active should be a number of some sort, like 1 = gamepad, 2 = touchscreen... we've used something like this in the code several times, so for consistency it would be preferred over comparing to a string (which is probably O(1) in Lua anyway so not a huge deal I suppose)

[swagtoy]

I also think that moving these options into another minetest.get_input_method() function could be nice. For privacy reasons, a player might not want to expose their screen width, DPI, etc etc, like how those paranoid Firefox/Operating system extensions do it. Or we can just add an option to make these values random/offsetted.

It might feel weird to have player input methods in a function called get_player_window_information, given that it took me a bit to even realize we had functions to see if i.e. a touchscreen is available. We might want to provide other info like the Window manager and stuff to that, or renderer (i.e., to bypass a bug with OpenGL in 5.8.0)

[rubenwardy]

Yeah the intention was for this to be a new method rather than part of get_player_window_information

[sfan5]

Done by #14092, no?