Proposal to improve Minetest’s horrible controls

[Wuzzy]

The controls of Minetest are very confusing for newcomers and annoying for modders. I suggest to completely rework them. This post is mainly directed to the core developers and I want to know what they have say to that proposal.
First I tell you the current controls weirdness, then I tell you what I think is wrong with that and then I make a proposal to clean this mess up.

Here is what I think is wrong with the current system:

The worst keybindings are those for building, using and sneaking.
The building key is the right mouse button. Actually it is not a building key, it is a combined building and using key.

• Normally, you will build the selected node on the pointed node.
• But if the pointed node reacts on on_rightclick, this function is used instead and the node is not built.
• To actually be able to reliably build something, you have to press [Build]+[Sneak].

And sneaking has, based on the context, 3 different meanings:

• It is used to walk slower and sneak to avoid falling off edges. This only works if you stand on solid ground
• It is used to descent on ladders, in water or while in fly mode. But you only descent ladders if you you haven’t set “‘use’ = climb down”
• You have to press [Build]+[Sneak] to actually reliably build, otherwise, you may use a node accidentally

And if you have a screwdriver, you have to press [Sneak]+[Attack] to change the screwdriver mode. It works, but it is a hack. And ultra-weird, because this is neither about attacking/mining nor sneaking! xD

Even the attack key is not unambigious:

• Normally it means you punch with your current item
• But if the current item is eatable, you eat this item instead!
• If you are pointing to a dropped item, you collect it

The use key is mostly useless (funny, right?). As far I know, there are only 2 uses:

• If you hold it down, you can walk faster with it, if you are in fast mode but not in fly mode.
• If you set it in the options that way, you can alternatively descent with the use key.
• But you can’t fly faster with E if you are in fast mode and in fly mode. In this case, you are always fast. WTF? You can’t even use the Sneak key to slow down, since this would be descending, unless you flipped it with E.

Edit: Okay, another problem:
The [F4] key means “disable camera updates”. This cryptic key can be a game-breaker for the clueless. “camera updates” means that the scene is drawn if you walk throughout the world. If this is off, the world is not drawn for you anymore when you hit the border or simply turn around. This key is therefore completely useless for gameplay. It is easy to hit the F4 key accidentally and people wouldn’t understand the meaning of “camera updates”. I have seen at least one let’s play video of someone who accidentally hit the key and had no idea what happened. The scene didn’t update anymore, he was confused, restart the game and thought it was a bug …
EDIT 2: Thankfully, this has been fixed. This key works only in debug builds or by setting is explicitly in minetest.conf)


Now the problems I see with this are:

• The meaning of some keys is highly context dependent
• Many keys act in unexpectect ways and are not self-explanationary
• The so-called “use” key is a misnomer
• Minetest lacks many keys to unambigiously tell Minetest to do X: using a node, using a tool, collecting an item, ascending, descending
• A switch to change the meaning of Sneak and Use on ladders and flying does only add to the weirdness of the controls and is of no real help.
• The Lua API provides a function “on_rightclick”. This motivates modders to further abuse that key for stuff because the function does not say anything about its intended semantics. Also this does not fit together with other function names. There is “on_punch” but not a “on_leftclick”, for example.
• There is no dedicated key binding for using a certain wielded item when the use is something different than punching. This leads to weird hacks as seen in the Screwdriver mod.
• It is not possible to punch with comestibles. This is needlessly inconsistent, since you can punch with almost everything else (using hand time if it’s not a real tool).
• F4 is a game-breaker for the clueless. (fixed)

Based on these problems, I suggest to make the following changes:

• Introduce the concept of “primary tool use” and “secondary tool use”. There are a few tools where one use key may not be enough. The secondary tool use could be used to standarize that and to avoid hacky solutions as seen on the Screwdriver mod. Note that “item use” refers to any use which is not mining/attacking/punching; this is special and has its own key.
• Introduce the policiy of “one key = one meaning”. Give seperate key assignments to these actions (new assignments in bold):
  
  • Attack / Punch with the wielded item (includes mining)
  • Collect pointed_thing
  • Jump (only possible when standing on solid ground)
  • Sneak (without all its hacky extra meanings!)
  • Build (always build, even to usable nodes like furnaces)
  • Throw wielded item away.
  • Using the wielded item (meaning depends on item type to allow maximum modder flexibiliy, should be used when punching would not be appropriate)
  • Secondary use of wielded item (again the meaning depends on item type)
  • Interact with pointed node (excludes collecting and mining it)
  • Keybindings for the 6 spatial directions:
    
    • Forwards
    • Backwards
    • Left
    • Right
    • Ascent (in fly mode, on ladders or in water) (differs from jumping!)
    • Descent (in fly mode, on ladders or in water)
  • Toggle fast mode (player is always fast in fast mode, no matter if flying or not)
  • Toggle fly mode
  • Toggle noclip mode
• Remove the option “‘use’ = climb down” because climbing down and using are now treated seperately.
• Based on the above, there have to be serveral API changes:
  
  • Deprecate the function “on_rightclick”.
  • For items, introduce the function “on_primary_item_use”. Given parameters are: itemstack (ItemStack of used tool), user (player reference to user), pointed_thing (if the player points to something; if not, is nil. The function does not have to care about the pointet_thing, it is there for convenience reasons). Minetest does not care about the return value. By default, this function is a no-op.
  • For items, introduce the function “on_secondary_item_use”. It works the same way as “on_primary_item_use”, but is only for the secondary item use.
  • For nodes, introduce the function “on_interact”. This is called when a player presses the “interact” key on the node. Given parameters are: pos (node position), node (node def.), user (player ref.), pointed_thing (the same, but as a pointed_thing), itemstack (the used tool). By default, this function is a no-op.
  • For node defintions, introduce the parameter “collectable”. If it is true, the node can be collected if the player points to it and presses the collect key. By default, it is false.
  • For entities (includes dropped items), maybe introduce the callback “on_collect(itemstack, collector)”. The function shall return an ItemStack which goes to the collector. Or nil, if the entity is not allowed to be collected. Dropped items have an obvious default function, I am unsure for other entities, but I think their default function should return nil (=not collectable).
• Make the F4 key a no-op by default; only enable it if there is a parameter set in minetest.conf. This parameter is by default off in release builds and on in debug builds. (done in Minetest 0.4.12))

Here are some examples for the key bindings I suggested:
Collect: Taking a torch from a wall, take a dropped itemstack from the floor. Note that not everything can be collected.
Primary item use: Eating comestibles, applying tool on pointed_thing (screwdriver, bucket, hoe). No-op by default.
Secondary item use: Changing tool mode (screwdriver mode, bridge tool mode). Other uses may come up later, who knows? Again, a no-op by default.
Interact pointed node: Editing sign, opening chest menu, opening furnace menu, open closed door, close open door. Excludes mining it and collecting it! If the player presses interact but nothing is pointed at, then nothing happens.




Whew, that’s it. Especially I want to hear feedback from the core developers about how realistic my proposals are. I want to hear from players wheather they think my proposal would actually improve something. I want to hear if other people around here think there is a problem with the controls and the part of the Lua API which interacts with it.


Edit: I added some stuff about F4 “disable camera updates”.
Edit 2: The F4 problem has been fixed. Finally!

[rubenwardy]

Most of these I agree with, but not the punching / right clicking.

[Casimir]

It is nice to see a problem summed up so clear that I wasn't fully aware of myself. When it comes to the solution, it seems to me you are overdoing it. When you try to find a good key for every described action you end up with a counterintuitive huge use of the keyboard. You take your mouse to point at something and then you need to switch to the keyboard, so you use both hands while doing only a simple action. The good thing about the mouse is that is is just point-and-click.
To be precise I think it is no problem to have two functions in one key when the functions don't conflict with each other.
When pointing at an object, you don't point at a node, so collect and punch/dig can be the same without problem. Also it would not separate collecting the torch from digging other things, which would be confusing.
"Secondary use" seems like the only usecase is the screwdriver. If you allow a use of an item to be the same as punching, in the case that the item interacts with nodes like the screwdriver, then would not need a secondary use key. For every normal item and eating it would be the use key, when it come to pointing at something then it is punching.
Also I see no conflict for ascent and jump being the same key.

The fastmode change "Toggle fast mode (player is always fast in fast mode, no matter if flying or not)" seems to be an important one. At the moment fastmode is misused by many as a replacement for running, and it totally blocks any other use of the use key. Personally I have "'use' = climb down" turned on, which results in instant running when reaching the end of the ladder.

[Wuzzy]

Rubenwardy, you are not helpful. Why not the punching thing?

Casimir:

When you try to find a good key for every described action you end up with a counterintuitive huge use of the keyboard.

Bullshit. Most actions I described already existed. I propose to add 6 new actions explicitly. In total, I propose to use 18 actions. Still not very much for me.
Besides, how can you even play Minetest with the mouse alone? Do you stand around all the time? As soon as you want to walk, you have to use the keyboard. I never play Minetest with mouse only.
Whatever, how about making every action user-assignable, including the mouse buttons? AFAIK you can’t assign mouse buttons to actions, and you can’t even change the bindings for attacking and interacting etc. Maybe let the user assign keys even doubly, but the user has to know what he/she/it does than. It can be useful for some if you do it right, but not if you do it wrong. Or the game simply prevents the user from making double assignments to conflicting actions.

I suggested secondary use because current usage is just made by hacking around the API. This is bad because it leads to needless incosistences. Also, screwdriver is not the only use case. There is also the bridge tool mod. But the bridge tool does it differently, bridge tool changes mode with left click. Having a secondary use action would (hopefully) standardize that. And even if there are not many use cases now, does not mean that there won’t be any use cases in the future. Maybe mod makers were demotivated to use something like “tool modes” because currently, it is very hacky or they simply had no idea how to do it. With a secondary use action, more complex tools would certainly be possible without hacking around.

I also want to point to my edit about F4:

The [F4] key means “disable camera updates”. This cryptic key can be a game-breaker for the clueless. “camera updates” means that the scene is drawn if you walk throughout the world. If this is off, the world is not drawn for you anymore when you hit the border or simply turn around. This key is therefore completely useless for gameplay. It is easy to hit the F4 key accidentally and people wouldn’t understand the meaning of “camera updates”. I have seen at least one let’s play video of someone who accidentally hit the key and had no idea what happened. The scene didn’t update anymore, he was confused, restart the game and thought it was a bug …

(…)

Make the F4 key a no-op by default; only enable it if there is a parameter set in minetest.conf. This parameter is by default off in release builds and on in debug builds.

[HeroOfTheWinds]

I share the opinion that the solutions proposed are a bit overboard. Of course, there is some truth to them, especially about F4, but I would like to point out a couple holes in your logic:
1. You say that being in fast mode while flying should require holding down the use (E) key. In my experience, when I fly, I want to go fast. Also, it isn't that hard to simply hit 'J' to turn off fast mode while flying. Accomplishes much the same goal.

2. Your criticism of the sneak key: As a person who was introduced to Minetest/Minecraft via Minecraft: Pocket Edition, I was used to hardly being able to build on objects with a formspec at all. There is no "sneak" key in MC:PE, and so I was delighted to have that second function in Minetest, even if it took me a long time to find it.

I think the more elegant solution here to maintain simplicity while addressing the problem is to meet halfway: Include some sort of help button in the pause menu to better explain the control schemes. There's not much problem with the control scheme as it is, except for in a few small areas. You just need to let people know how to play.

Also, who the heck would WANT to dig with an apple, and then eat that bruised, rotten and dirty food later?

[Casimir]

Most actions I described already existed. I propose to add 6 new actions explicitly.

When reusing the use key, then there are still five additional keys. The old control scheme is illogical and complex, you are solveing the logic part but making it more complex. I just say that you don't need to add that much.

Besides, how can you even play Minetest with the mouse alone?

What I wanted to say is, there are actions that require pointing with the mouse, and there are actions that are independent from where you are pointing at. Actions that require pointing - dig, punch, attack, place, use the screwdriver, (maybe interact) - should be done completely with the mouse. Actions that don't require the mouse - eat, sneak, open inventory, open menu, use an item, change the screwdriver mode - should be done completely without it. Mixing both keyboard and mouse for one action is not intuitive. Moving and interact are special cases here. For interact is quite similar to using the inventory (because of chest and furnace), but I don't have a good solution here.

[Calinou]

How about adding more special keys (4 is likely enough for now), so that mods can use them? Clients can configure the keys to whatever they want, preventing keyboard layout issues.

[onpon4]

Controls that depend on too much context sensitivity can be really annoying, but that doesn't mean Minetest should do the other extreme and have a different button for every different thing; that's annoying, too.

Personally:

- I don't think there are many problems with the mouse controls. Overloading the left mouse button with tool use and attacking makes sense to me. I think making the left mouse button pick up items makes sense, too. Putting both building and interacting with objects on the right mouse button is something I'm less fond of; perhaps interacting with things should be the "use" key, or perhaps the middle mouse button (or perhaps the "use" key should be the middle mouse button).

- I don't think there's any problem with the way the sneak key is used. Mods requiring holding it down to do some action is not an idea I'm particularly fond of, but I think the solution to this isn't more possible controls for mods to use, but for the mods to be redesigned so the tools can work with one key.

[Amaz]

Controls that depend on too much context sensitivity can be really annoying, but that doesn't mean Minetest should do the other extreme and have a different button for every different thing; that's annoying, too.

Personally:

- I don't think there are many problems with the mouse controls. Overloading the left mouse button with tool use and attacking makes sense to me. I think making the left mouse button pick up items makes sense, too. Putting both building and interacting with objects on the right mouse button is something I'm less fond of; perhaps interacting with things should be the "use" key, or perhaps the middle mouse button (or perhaps the "use" key should be the middle mouse button).

- I don't think there's any problem with the way the sneak key is used. Mods requiring holding it down to do some action is not an idea I'm particularly fond of, but I think the solution to this isn't more possible controls for mods to use, but for the mods to be redesigned so the tools can work with one key.

This sounds like the best idea to me. I like it.

[Kilarin]

I think some of Wuzzy's ideas are great. But I'm with what appears to be the majority here in thinking that a left click to dig, and a left click to pick up, makes sense. But it is confusing when you are trying to place something on top of a furnace with a right click, and it keeps opening the furnace instead.

I think my main complaint is that mods that need more controls can't assign any other keys. Bridgetool uses left click to change mode, and sneak left click to change the width. Those are convenient, once you get used to them, but not necessarily obvious or intuitive.

Or, lets use an example of someone who's a fairly new user in a game that includes the cart mod. If they haven't spent a lot of time reading the mod description on the forum, or going through the readme or the wiki, then they could easily end up with a cart in their inventory, and not much idea of what it does.

They are going to figure out quickly that a right click will place the cart on the track, that makes sense. And a left click punches the cart and makes it move. Again, that makes sense in terms of the game. Another right click (after placing the cart) to mount the cart makes less sense, but they will probably figure that out just because right click to use is standard in the game. But sneak-right click to dismount? They aren't likely to figure that out on their own. And in my fork I needed to bind another key for locking the user's view to the cart's direction of movement. I used jump, but a user is highly unlikely to figure that out by themselves (That's why I included a chat message explaining what all the keys do)

What would be much more intuitive would be to have a series of at least 3, possibly 4 keys for using items. And to make those keys make more sense, Minetest needs a built in help function. Every node and item should be able to have an on_help="help string" that will be displayed like a tool tip whenever the user points the cursor at that item and hits "?" It should work whether they are pointing at a node in the world, or in their inventory. For example, the bridge tool might have:
on_help="Bridge Tool: right click places the item from stack one place to the right in inventory\nuse1=change mode (forward,down,up)\nuse2=change width (1,2,3)"
And the cart could have:
on_help="use1=mount\nuse2=dismount\nuse3=lock view"
(of course, mount and dismount could be combined in the same key for further simplicity, but thats not the point here)

The on_help for the furnace could explain it's basic use. The on help for the screwdriver could explain not only how to switch the modes, but what each mode does.

We need multiple item use keys, and we need a simple built in tool tip system to explain to users how to use an item they have found or created.

[rubenwardy]

Calinou pretty much summarized it. Sorry for the vague response, I didn't have time to type a post.

I think it is counter intuitive to have anything else than left click to punch, right click to use current item, as that is what Minecraft uses, and it is simple. Minecraft shouldn't control what controls we use, though.

I agree with how placing things on top of the furnace is weird. So I think use and right click should be separate, however not sure how.

[Topywo]

I've never had much trouble with the present settings (I cross the 'use' = climb down, though more for flying down) and whenever it doesn't do what I suppose it should do, I try out all the possibilities.

Furthermore I can use the keys on my computer to ask on a server or in the forum if I don't understand something.

But I think it's good to have this discussion and especially fresh users should give their input, since the older ones are used to all the 'odd' combinations.

I'm no developer, so without knowing the difficulties to program it, I would prefer combinations of the mouse buttons with <shift>, <ctrl> and <shift + ctrl> and at least leave the 'wasd' as it is.

What I also think is important, is that tablet users should be able to assign functions from the function keys to other keys (as is already possible for the console function (F10)). I only don't know if that suggestion belongs here or in the android section. I don't use a tablet, but when meeting those on the servers they sometimes seem a bit 'lost' (no F5).


Edit: Typo

[Krock]

Here is what I think is wrong with the current system:

• Normally, you will build the selected node on the pointed node.
• But if the pointed node reacts on on_rightclick, this function is used instead and the node is not built.
• To actually be able to reliably build something, you have to press [Build]+[Sneak].

And if you have a screwdriver, you have to press [Sneak]+[Attack] to change the screwdriver mode. It works, but it is a hack. And ultra-weird, because this is neither about attacking/mining nor sneaking! xD

Even the attack key is not unambigious:

• If you are pointing to a dropped item, you collect it

The use key is mostly useless

• You can’t even use the Sneak key to slow down, since this would be descending, unless you flipped it with E.

I have seen at least one let’s play video of someone who accidentally hit the key and had no idea what happened. The scene didn’t update anymore, he was confused, restart the game and thought it was a bug …

• Also this does not fit together with other function names. There is “on_punch” but not a “on_leftclick”, for example.

I would get crazy when I always would need to have an empty slot in the inventory to open a special node!

Okay, screwdrivers use "hacky" things, "Use" could be used instead of Shift+Click, but all other things just use more keys and make it a bit messy.

Attack key??!? Whatever - how else would I collect dropped items?

The "Use" key is useful when the sneak-and-rightclick-combination is already used *refers to bitchange and currency mod*

Camera update is camera update - it updates the camera - irrlicht is the camera, so it stops adding new textures to the terrain, logic.

I do not right click on nodes (except when digging), I punch them!

My option to some of the points.

[Wuzzy]

1. You say that being in fast mode while flying should require holding down the use (E) key.

No. Actually I want this:

Toggle fast mode (player is always fast in fast mode, no matter if flying or not)

2. Your criticism of the sneak key: As a person who was introduced to Minetest/Minecraft via Minecraft: Pocket Edition, I was used to hardly being able to build on objects with a formspec at all. There is no "sneak" key in MC:PE, and so I was delighted to have that second function in Minetest, even if it took me a long time to find it.

You are basically saying “be glad that it is at least possible to build to furnaces”. This is not my point. My point is the weird and confusing overusage of it. I speak for myself, I literally had to ask the forums first before I was able to build to furnaces.

So much for my “holes” in my logic.

Also, who the heck would WANT to dig with an apple, and then eat that bruised, rotten and dirty food later

You can punch with almost everything and nobody seems to care. But it is wrong with apples, you say. I don’t understand. Punching with stuff is just a shortcut because you have the same tool capabilities as of the hand. It is a shortcut because you do not have to switch to the hand.

How about adding more special keys (4 is likely enough for now), so that mods can use them? Clients can configure the keys to whatever they want, preventing keyboard layout issues.

Your suggestion seems like a good idea but actually I do not get it. In what context should these 4 keys be used? Item-wise? Server-wide? etc. Also what would be the semantics of them? I have no idea … Please elaborate.

(…) I think the solution to this isn't more possible controls for mods to use, but for the mods to be redesigned so the tools can work with one key.

I have no idea how this is possible with the current mods. If you have any idea how to rewrite the, let’s say, screwdriver mod to work with only one key, let me know that.

Minetest needs a built in help function. (…)

This idea is great! There are some mods which are quite complex tools and stuff and. It would save players time because they don’t have to go back to the wiki or the forum all the time. ;-) Perhaps very complex things would be possible to explain in a single help text (or the help text just becomes very long xD), for example the digilines processors. But I think it would be very helpful for mods like Mesecons. Mods like Bride Tool and Screwdriver really need such a function; the simple fact that they currently exploit the chat for help messages proofs that.
The details of this idea need to be worked out (how should the GUI work? should formspecs be used or just tooltips? etc. etc.), however.

Furthermore I can use the keys on my computer to ask on a server or in the forum if I don't understand something.

True. But it costs time and is inconvenient. The better solution would be to design the game in such a way that you don’t need to because it is self-explanationary. Honestly, Minetest is anything but self-explanationary at the moment … :( It is literally impossible for people who are new to the genre to understand what’s going on without consulting the wiki or someone who knows everything already.

I'm no developer, so without knowing the difficulties to program it, I would prefer combinations of the mouse buttons with <shift>, <ctrl> and <shift + ctrl> and at least leave the 'wasd' as it is.

I am not arguing about which exact key bindings which are used. There is a reason why those can be assinged by users. Nobody is trying to argue your WASD controls away and even if I’d disagree, I can simply reconfigure the keys. I also want to have Minetest so that players can assign their own keys including mouse buttons (which is not possible yet). Also it is not possible to reconfigure the left and right mouse buttons, they are fixed for eternity on mining/punching and <whatever the current game context says>.
If that would be possible, all the mouse vs keyboard arguments which were repeated here several times are hopefully adressed, because everyone can assign however one wants to. In case someone missed it: I also propose to explicitly allow players to doubly assign keys (with the risk of conflict, but we can deal with that somehow).

I would get crazy when I always would need to have an empty slot in the inventory to open a special node!

Me, too. I never proposed that, by the way. Read again.

Camera update is camera update - it updates the camera - irrlicht is the camera, so it stops adding new textures to the terrain, logic.

There are people who don’t understand it, and that’s the point. Besides, English is an ambigious language. And the term “camera update” was probably even created ad-hoc. It is probably the second worst term in Minetest. The worst term in Minetest is “print stacks” (Ignoring the fact that this term is meaningless to non-developers: The devs were even too lazy to write out “stacktraces” lol). I can think of several ways how to interpret “camera update”:

• First, it could mean it updates the position of the camera. Makes perfectly sense, unless you realize the position of the camera is updated all the time while you move. ;-)
• It could mean there’s actually a real camera mesh in the world which gets updated somehow. Who’s filming? ;-) Yeah, I know, it sounds silly but keep in mind that Minetest is played by non-technical people.
• And yes, it could also mean that the scene which the camera sees gets updated. But it not so obvious, actually. I had to look the meaning of “camera updates” up.

And no, Irrlicht is not the camera. Irrlich is an engine which includes cameras.
It should not be a requirement to know how Irrlicht works in order to play Minetest. Besides, I generally object to adding debug functionality into release builds, it only adds to clutter. Maybe the Minetest players are all developers? XD

I do not right click on nodes (except when digging), I punch them!

Aha. Then you never build, use furnaces, use hoes, … lol

[cheapie]

Pointing and pressing a key is odd. Point-and-click is more natural. I'm thinking maybe make a left-click open formspecs (holding the left button would still dig), and right-click would just be place.

[4aiman]

I'm a seasoned Minecraft player. While I agree the inconsistence of current controls in theory, I pretty much accustomed to the way those are. The only problem I see is that by using an item with the left key you really can accidentally punch an undesired node. Otherwise I'm fine with the current controls. We have two hands but there are so many things we can do using them. I feel the same about controls.

TL;DR
Make keybindidngs configurable, so anyone will be able to revert to the original bindings (e.g. to controls as they're now). That includes multi-binding, e.g. 2 and more actions for one key.
The same goes for the mouse buttons.

[Dragonop]

Maybe instead of this discussion, can vote for more control config options:
°Checkboxes with Original Key Mode/Complex Key Mode
°Different config for the Key Modes:
-Complex shows a lot of configurations like instead of ''Use/Place Node''; ''Use Node'' AND apart form that one ''Place Node'', etc.
-Original shows the actual key config
°Config of the F1-F12 buttons
°Alternate list of all the action that can be done and the key that uses: Example
''Punch=Left Click''
''Eat=Left Click''
''Change Tool Mode= [Sneak Key] + [Left Click]''
Etc.
(All those above must be configurable)

[Dragonop]

Anybody has tink about the horrible pointing at Collectable Items that are trow to the floor?

[Casimir]

In Carbone you collect them by walking over. In Voxelgarden there are no dropped items. So that issue can/has to be solved within minetest_game.

[4aiman]

Maybe instead of this discussion, can vote for more control config options

+1

Anybody has tink about the horrible pointing at Collectable Items that are trow to the floor?

It's a feature of a game, not the engine. But you can always add a builtin mod by PilzAdam.

What SHOULD be fixed is non-rotatable collision/selection boxes. It's weird how we can click somewhere outside the entity to interact with it.

[bdjnk]

While I agree, for the most part, that some of the controls may be confusing to new-comers, I disagree with the notion that more keys is the solution. I also disagree that more flexible control configuration options is the solution, because what we're really discussing here is sane control defaults.

Let's approach this problem from the other side. Namely, what keys are conveniently placed for use, what are these keys thought to represent (in games and otherwise), and what functionality do we require. This while help us clarify both the problem and the solution.

Mouse:

• Left Click - primary interaction
• Right Click - secondary interaction, often informational or a lead-in to more options
• Middle Click - tertiary interaction, currently unused (outside the inventory)
• Scroll Wheel - flip through a finite set of items or options

Clicks are expected to be context sensitive, both in regards to what you are pointing at and what you are pointing with.

Keyboard:

• WASD - standard game movement
• Shift - standard game crouch
• Space - standard game jump
• (not convenient while moving)
  
  • Tab - flip through a finite set of items or options
  • Q - no standard, currently used to drop items
  • E - no standard, currently unused
  • 1-9 - standard quick select

Left click seems, mostly, fine to me. When I want to interact with any game (or indeed any GUI), the first thing I do is left click stuff. The fact that it destroys blocks, picks up items, and uses tools on blocks is all as it should be, because in left clicking, context sensitivity is expected. The only requirement is that I'm interacting with the interface or environment.

This leads to the one aspect that isn't fine. Eating. Left clicks are, as I said, for interacting with the environment. Thus when holding an apple, and clicking the world, I expect the apple and the world to interact in some fashion. Instead, boom, the apple disappears. The environment is not the target, the player is, which is very counter-intuitive.

Thus I propose E for eating, and indeed all item usage that isn't environment effecting.

Right click is currently a problem. A new player might even conclude that it's impossible to place a node against a furnace. One option is to let middle click be the 'use' button, and always place a node on right click. I'm ambivalent about this.

The idea that space and shift are used to jump and crouch, as well as to go up and down for flying and climbing, and that crouch prevents falling off cliffs, all seems perfectly reasonable and expected to me.

While shift is often used in applications to invoke a secondary mode for interactions, in a game this behavior might not be optimal. Because it's currently only being used to ensure we can place nodes when a right click will result in use, the above middle click proposal resolves this problem.

Lastly to address this notion of a secondary use for a tool. The screwdriver actually has four modes. Obviously four use buttons is simply not feasible. Most tools have one interaction mode. For those that need additional modes, I propose using tab to toggle between them.

Okay, I'm all done. Sorry for the novel.

[twoelk]

oh dear, I open the inventory with [E] (now guess what I played before ;-P)
and I run faster with [F]
not that that is any more logical but this way I can use the keyboard with one hand and don't need to look at it all the time to locate wide apart keys.
so I propose [Q] for eating because dropping an item has been the single most costly key for me before I moved that function out of reach.

The only key I really think is a bad choice is [F1] to toggle the hud. For me [F1] has always been one of the first keys I press if I need help. You can imagine my irritation when I pressed it in seek of some help system and instead the complete HUD disappeared. oops?

It is a little difficult to change the screwdriver mode while flying but that is not really vital I presume.

[philipbenr]

@bdjnk: Use [e] to run with fast priv.

My controls:

WASD: Normal
Q: Inventory
Z: Drop
F: enable run (fast priv)
C: enable fly priv
V: enable noclip priv
Everything else: Normal

This allows me to easily reach everything I need. Running and movement are on the right side and the other functions are on the left (except for clearsight)

I like to keep my controls in one area.

There is my input.

[Wuzzy]

While I agree that sane default controls are a good thing to have, this would not at all fix the problems with ambigous or confusing highly context- or even mod-dependent controls. Also, it would not fix at all the weird way mods have to cope with keybindings. There is no clean way to implement “tool modes”, there are just ugly mod-specific hacks and workarounds.

What I want:

• Cleanly expose all gameplay actions as potentially bindable
• Cleanly expose all actions to the Lua API
• Support for at least mouse and keyboard to bind freely to any action

What we have now:

• Some fixed keybindings which can’t be changed
• No possibility to use mouse clicks and the mouse wheel to bind an action
• Poorly designed context-dependent actions (“build” vs “interact” actions being the worst)
• Weird, confusing and tricky to use callbacks like “on_rightclick”, which does not refer to an action, but a keypress.
• Ugly hacks to work around the weird callbacks to implement something as simple as tool modes

You are missing the main point I wanted to make. I especially want that Minetest has at least support to bind a key to all basic actions. This does not neccessarily mean that each action has actually a different key on default.
Minetest should totally allow for doubly-assigned keybindings, but the player should be warned if neccessary (binding the same key to left and right would be stupid). And the player should be totally be allowed to re-arrange the keybindings at will (not just partly as we have now).

[4aiman]

Now I can fully agree with Wuzzy. "Support" is what I want too. Defaults may stay as they are.

[Wuzzy]

Small update here: The F4 problem (“disable camera updates”) has finally been fixed since a while.
https://github.com/minetest/minetest/pull/1744

Now “disabling camera update” only works if you use a debug build or explicitly add a keybinding in minetest.conf. This is exactly how I imagined it, thanks to rubenwardy! :-)

[12Me21]

How about supporting 3 button mouses? Having a scrolling wheel on your mouse is pretty much standard, so it should be an option to use. Maybe it should be to "use" items or open node inventories/menus.

How about instead of SHIFT+click, we use CTRL+click? Then you don't have to worry about sneaking and stuff.

Here's my idea:
Left click = break node/attack - R. pointer finger
Right click = place node/interact (interact takes priority) - R. ring finger
Ctrl + right click = place node (without interacting) - L. pinky finger + R. ring finger

Space = "up"(jump/fly up/climb up) - thumb
Shift = "down"(sneak/fly down/climb down) - pinky finger

WASD = move - middle, ring, middle, pointer fingers (respectively)
+Q = run - ring finger

Z = noclip
X = fast
C =fly

E = inventory (sorry, but it's just SO much easier to press than "I") -pointer finger
R = drop item - pointer finger
T = talk - pointer finger

IDK what the "use" key means, but whatever.

and look:

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

    Q W E R T         
     A S D           
SHIFT Z X C       
CTRL     SPACE

now all the keys are centered by your hand!

before:

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

    Q W E   T     I   
     A S D     H J K 
SHIFT             
         SPACE

Whose idea was this?? Just copy minecraft's controls (already not the best), and change inventory to I for no reason...
I do have to give them credit, though. The ladder controls are AWESOME! :D

[rubenwardy]

Item drop should be kept away from other keys. Also, full range (R) has been removed. I as a letter make more sense.

What do you mean by copying Minecraft controls? Wasd has always been used by first person games since like Doom.

Not everyone uses a qwerty keyboard.

[12Me21]

Item drop should be kept away from other keys.

R is farther away than Q. You can change it if you want, but I use these controls (mostly) and don't have any problems.

Also, full range (R) has been removed.

Oops, it should be F

I as a letter make more sense.

So it should be:
F: forward
B: backward
L: left
R: Right
J: jump
S: sneak
D: drop item
R: run
U: up
D: down
?
It doesn't matter what letter it is, just how easy it is to press.

What do you mean by copying Minecraft controls? Wasd has always been used by first person games since like Doom.

OK yeah you're right.
There is Q = drop and shift = sneak, though

Not everyone uses a qwerty keyboard.

It is the most widely used, though, and the one that I use.

[rubenwardy]

I missed out half of my sentence. I was chosen as it, well, stands for inventory. It's fairly intuitive (expect for MC players). But you are right, easier to reach.

I'd prefer Q and E to be swapped as it is more natural for me to run like that (mainly because I'm used to it)

As for qwerty, I was saying that a difficulty with designing controls is that some people have different keyboards. You can assume most people have qwerty though. Most games do, and have key binding.