[Stalled] Keyboard only input

For people working on the C++ code.
Post Reply
User avatar
karamel
Member
Posts: 47
Joined: Wed Jul 19, 2017 21:51
Contact:

[Stalled] Keyboard only input

by karamel » Post

Hello

I'm sometime modding with a laptop and I don't use the mouse in that case (I don't really need it and it is not very laptop-ish). Testing with the trackpad is still uncomfortable so I started to dig in the code to add keyboard input to run the game without mouse nor gamepad, like in the early 90's.

This is my first change is the engine. My commits are there before everything is set to create a pull request:
https://github.com/karamel59/minetest/tree/nomouse

Done:
  • Add look up/down/left/right keyboard inputs (default with the arrows)
  • Add gui entries in the keymap screen
  • Add keyboard look sensitivity in options (horizontal and vertical)
  • Add en entry in the graphical advanced configuration for look sensitivity
I'm not sure how input are handled from client to server, with prediction and stuff like that. It seems to work locally with two clients, but everything is in client/, I feel I have missed something but I don't really know where to look.

To Do:
  • What to do with the input bitmask? (look is currently added to it, but is unreliable because keyboard only)
  • Translations (I can't do them outside one or two…)
  • Add a keyboard alias for LBM and RBM in game
Stalled:

Without LBM and RBM aliases it may be usefull only for laptops to still use the buttons on the trackpad but not the trackpad itself.

But defining a keyboard alias is too much of a hassle because of conflicts in inputs with mouse and joystick and the fact that key pressed event is repeated while the key is hold down. Using a few workaround would make some ugly code. The repetition is still fine for a few inputs (like volume up and down), but not for the rest and it could be applied to the mouse too.

I feel it would be better to merge all inputs and abstract them and allow to map any mouse button to any action instead of looking directly at mouse button state + keyboard commands (not keys) + joystick button state. This is far more than the scope of the initial task but it also opens to mouse button remapping and even alternative keys (two key assignments like keypad + numbers).

I first need to write a blueprint of how inputs could be handled before diving into the code again.
Last edited by karamel on Thu Dec 19, 2019 12:17, edited 1 time in total.

micheal65536
Member
Posts: 167
Joined: Mon May 22, 2017 20:27

Re: Keyboard only input

by micheal65536 » Post

karamel wrote:I'm not sure how input are handled from client to server, with prediction and stuff like that. It seems to work locally with two clients, but everything is in client/, I feel I have missed something but I don't really know where to look.
AFAIK look direction is handled completely client-side. The client tells the server which way the player is looking (which is used so that the server can decide which map chunks to send to the player, and to set the orientation of the player's model on other clients - and possibly some other things that I'm not aware of or have forgotten about) but the server doesn't care how the client generates that information.

Also, I looked at your code and you're setting the direction in the same function as all the other input/control methods for look direction so I don't see any reason why this wouldn't correctly update the server-side look direction just like any other input/control method does.
karamel wrote:To Do:
  • Add a keyboard alias for LBM and RBM in game
This is an interesting one to mention. Minecraft allows the mouse button actions (labeled as "dig/punch" and "build/interact" or something along those lines) to be assigned to any mouse button or key. In fact, I'm pretty sure it goes a step further and allows actions that are assigned to keys by default (such as "walk") to be assigned to mouse buttons. So personally I am of the opinion that Minetest should not have an "alias" for the mouse button actions but instead group them alongside the keyboard actions ("walk", "open inventory", and so on) and allow any action to be assigned to either a key or a mouse button.

The problem with this, however, is that Minetest technically exposes four mouse button actions in the modding API (one for digging or punching, one for building, one for interacting with a block or object in the world, and one for using or eating the item in the player's hand) but only provides two actions from the player/interface perspective. In addition, some mods want to have two different actions that can be performed by interacting with a block and they use punching the block as another way of interacting with it. While this complication shouldn't affect the ability to re-assign the two mouse button actions (because you still have just two actions from the interface perspective, regardless of what keys or buttons they're assigned to) discussions about re-assigning the mouse button actions tend to digress into discussions about re-organising the interface to properly define separate "dig", "build", "interact", and "use" actions and possibly extend or re-organise the modding API to add a second "interact" action instead of leaving mods to (sometimes/always inappropriately) use the punch action for this purpose.

User avatar
Linuxdirk
Member
Posts: 2742
Joined: Wed Sep 17, 2014 11:21
In-game: Linuxdirk
Location: Germany
Contact:

Re: Keyboard only input

by Linuxdirk » Post

micheal65536 wrote:Minecraft allows the mouse button actions (labeled as "dig/punch" and "build/interact" or something along those lines) to be assigned to any mouse button or key.
This was discussed so many times and never was actually worked on by the devs and there was never a REAL reason not doing it.
micheal65536 wrote:The problem with this, however, is that Minetest technically exposes four mouse button actions in the modding API
Yes, and this is disgusting. No buttons should be in an API. Only aliases for specific actions. Input configuration is not a server API thing, but a client configuration thing.

The buttons being in the API also is the reason this won't change ever because MuH BaCkwArDs cOmPatiBiLitY.

User avatar
rubenwardy
Moderator
Posts: 6431
Joined: Tue Jun 12, 2012 18:11
GitHub: rubenwardy
IRC: rubenwardy
In-game: rubenwardy
Location: United Kingdom
Contact:

Re: Keyboard only input

by rubenwardy » Post

Damned when we break compatibility, damned when we don't

Deprecations exist to allow us to improve the API without breaking backwards compatibility. The very fact that mods and games don't break between versions is one massive benefit of minetest over minecraft

User avatar
Linuxdirk
Member
Posts: 2742
Joined: Wed Sep 17, 2014 11:21
In-game: Linuxdirk
Location: Germany
Contact:

Re: Keyboard only input

by Linuxdirk » Post

rubenwardy wrote:Damned when we break compatibility,
... when its not a "breaking changes" release.
rubenwardy wrote:damned when we don't
... on a "breaking changes" release.
rubenwardy wrote:Deprecations exist to allow us to improve the API without breaking backwards compatibility.
Deprecations should lead to removal 1-2 versions after defining them.

User avatar
rubenwardy
Moderator
Posts: 6431
Joined: Tue Jun 12, 2012 18:11
GitHub: rubenwardy
IRC: rubenwardy
In-game: rubenwardy
Location: United Kingdom
Contact:

Re: Keyboard only input

by rubenwardy » Post

Yet you're suggesting we should break this on a non breaking changes release?
Linuxdirk wrote: Deprecations should lead to removal 1-2 versions after defining them.
Deprecations should only be removed in breaking changes releases, as that's one form of breaking change

https://github.com/semver/semver/issues/508

User avatar
Linuxdirk
Member
Posts: 2742
Joined: Wed Sep 17, 2014 11:21
In-game: Linuxdirk
Location: Germany
Contact:

Re: Keyboard only input

by Linuxdirk » Post

rubenwardy wrote:Yet you're suggesting we should break this on a non breaking changes release?
I disagree removing deprecated functions 1-2 releases after deprecating them is a breaking change as much as you disagree that 5.0.0 after 0.4.17 is bogus.

User avatar
rubenwardy
Moderator
Posts: 6431
Joined: Tue Jun 12, 2012 18:11
GitHub: rubenwardy
IRC: rubenwardy
In-game: rubenwardy
Location: United Kingdom
Contact:

Re: Keyboard only input

by rubenwardy » Post

Linuxdirk wrote: I disagree removing deprecated functions 1-2 releases after deprecating them is a breaking change
We could add this as an exception in our versioning rules, it could make things much nicer and not need a major release for deprecated things

Also, whether deprecations can be removed or not doesn't matter to this issue. You'd still need to change something and have two solutions running for some time before it is removed. You shouldn't deprecate something without an alternative

User avatar
Linuxdirk
Member
Posts: 2742
Joined: Wed Sep 17, 2014 11:21
In-game: Linuxdirk
Location: Germany
Contact:

Re: Keyboard only input

by Linuxdirk » Post

rubenwardy wrote:You shouldn't deprecate something without an alternative
Having an "alternative" (or new, better, more versatile, more stable, etc.) is the main reason for deprecation.

User avatar
karamel
Member
Posts: 47
Joined: Wed Jul 19, 2017 21:51
Contact:

Re: Keyboard only input

by karamel » Post

I'm still working (slowly) on keyboard aliases for LBM and RBM, but there is a major difference between handling keyboard input and mouse inputs that prevents to do something nice and clean.

Mouse button inputs uses state (clicked or released) and a single-processing flag that is enabled only when releasing and pressing the button again.

Keyboard inputs uses state (down or up) and a single-processing-flag that is constantly set while the key is pressed (because the key event is repeated while the key is down).

I don't understand if this was unintentional and I can "fix" the keyboard input to match the mouse input or if it was intentional because of some reason.

Fixing it may prevent quickly toggling fly-mode, minimap, inventory or such while holding the key. And if I read correctly the bitmasks won't be touched so the lua triggers shouldn't be impacted for sneak and special.

User avatar
karamel
Member
Posts: 47
Joined: Wed Jul 19, 2017 21:51
Contact:

Re: Keyboard only input

by karamel » Post

Nevermind, both keyboard behaviours are fine. It would be as silly for the volume controls not to be repeated like typing as repeated toggling of a feature.

I'll make both and use one or the other depending on the key assignment.

Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests