The touch_interaction introduced in 404a063fdfbbddcba32d22dd1c34dd73922bc12a needs a setting to override it

[j-r]

Problem

The idea is nice and the code looks fine, too, but it just doesn't work well in a lot of games including minetest_game.

Even the default is bad, because one can easily punch a chest boat by accident (which is more than annoying). It will only get worse when mods actually start using it, because the player has to remember which thing has overriden the default in what way.

Solutions

I can easily imagine the feature to be a big win for more tightly controlled scenarios, but it needs accompanying settings to

i) change the defaults, so players can customize them to their preference (e.g. a peaceful game is served perfectly well with long_dig_short_place for everything)
ii) disable override by node/entity definition, so players can manage the surprises they'll get

Alternatives

Revert it, but why waste a good idea

Additional context

No response

[grorp]

Thank you for giving feedback. I'll spend some time thinking about your points and I'll write an answer in a week or so.

[grorp]

Even the default is bad, because one can easily punch a chest boat by accident (which is more than annoying).

I think this is mostly a matter of getting used to the new controls. When I started using the new controls, I also had problems like this, but they went away once I had memorized that short tap = punch. The exact same short/long-tap control scheme is also used by Minecraft.

It will only get worse when mods actually start using it, because the player has to remember which thing has overriden the default in what way.

Games and mods are responsible for using this feature in a way that makes sense and doesn't confuse the player. They can of course use it badly, but that's possible with any feature and it's not Minetest's fault when they do.

I recommend game and mod authors to leave the touch_interaction field at its default value whenever possible. It should only be used in cases where the default simply doesn't work, like for bows.

These cases are easy to remember because there's a simple rule behind them: If you need to hold down a mouse button for more than a few milliseconds, its touchscreen equivalent is a long tap.

I can easily imagine the feature to be a big win for more tightly controlled scenarios, but it needs accompanying settings to
i) change the defaults, so players can customize them to their preference (e.g. a peaceful game is served perfectly well with long_dig_short_place for everything)

Peaceful games can already set "long_dig_short_place" for everything if they want (but I suspect you used the term "game" to mean something different).

A client-side setting for changing the default touch_interaction.pointed_object value could make sense, but I don't currently see any actual benefits of "long tap to punch" over "short tap to punch" (except Minetest players being used to it). However, "long tap to punch" could become quite interesting if we automatically disabled 94feb62 along with it.

The "default default value" must stay "short tap to punch" IMO, for the reasons I've described in #14087.

ii) disable override by node/entity definition, so players can manage the surprises they'll get

I can't understand why you would want this. Currently, the touch_interaction value doesn't depend on what node or entity is pointed, it just depends on whether a node or an entity is pointed.

Making the touch_interaction value dependent on what node or entity is pointed would add a lot more for players to remember. It would result in more suprises, not fewer.

Also, adding a client-side setting to override the game's control choices would violate Minetest's design principle that games should be in control of the experience.

[j-r]

The exact same short/long-tap control scheme is also used by Minecraft.

That is not necessarily an argument either way, because Minetest is not a Minecraft clone. With minetest_game based experiences usually being some kind of mod soup, I'd rather say the goal should be to be more flexible than Minecraft.

Games and mods are responsible for using this feature in a way that makes sense and doesn't confuse the player. They can of course use it badly, but that's possible with any feature and it's not Minetest's fault when they do.

I recommend game and mod authors to leave the touch_interaction field at its default value whenever possible. It should only be used in cases where the default simply doesn't work, like for bows.

Looking at the ContentDB I can assume with some confidence it will not work out that way. Mods are not games, the user compiles the game from them. Individual authors code to their preferences. Users obviously can change the touch_interaction themselves, but even a simple override setting could probably save them the work in most cases.

These cases are easy to remember because there's a simple rule behind them: If you need to hold down a mouse button for more than a few milliseconds, its touchscreen equivalent is a long tap.

Not all touch users have played the game using a mouse. But more importantly in several games/mods it is not always easy for the user to tell an entity from a node. And there are valid reasons to have entities that look like nodes.

I can easily imagine the feature to be a big win for more tightly controlled scenarios, but it needs accompanying settings to
i) change the defaults, so players can customize them to their preference (e.g. a peaceful game is served perfectly well with long_dig_short_place for everything)

Peaceful games can already set "long_dig_short_place" for everything if they want (but I suspect you used the term "game" to mean something different).

With most games the user actually decides whether the game is peaceful. E.g. Mineclonia has a peaceful setting. Therefore not providing a user facing setting for touch_interaction control is just increasing the workload of game/mod authors.

A client-side setting for changing the default touch_interaction.pointed_object value could make sense, but I don't currently see any actual benefits of "long tap to punch" over "short tap to punch" (except Minetest players being used to it). However, "long tap to punch" could become quite interesting if we automatically disabled 94feb62 along with it.

I agree.

ii) disable override by node/entity definition, so players can manage the surprises they'll get

I can't understand why you would want this. Currently, the touch_interaction value doesn't depend on what node or entity is pointed, it just depends on whether a node or an entity is pointed.

I misread the code. I think this makes it even more annoying. Just because I'm wielding a sword doesn't mean I want to punch my bag carrying horse or my chest minecart that looks like a node or my digtron storage that actually is a node. I can know if I closely check the information presented on the screen, even better when I activate debug info, but that breaks immersion.

Making the touch_interaction value dependent on what node or entity is pointed would add a lot more for players to remember. It would result in more suprises, not fewer.

I actually agree, but for tightly controlled scenarios like Mineclonia it could still be great. And for the mod soup it has to be easily overridable by the user. It would be enough to have a setting to just ignore touch_interaction from item_def and a way to override the default.

Also, adding a client-side setting to override the game's control choices would violate Minetest's design principle that games should be in control of the experience.

Then why are there mods? I mean, really why? But that is effectively the main point of the discussion. If that is a core design principle than you are obviously right, but that also explains why the minetest game experience is often mediocre. How could a mod soup where quite a lot of authors aren't even active any longer even try provide a consistent experience?

Don't get me wrong, Minetest is great and I think this is a nice feature. And more user settings are not always better, but since the touch UI is quite different there should be more knobs for the user to somehow coerce the currently existing and future mod soup to be playable. Thank you:-)

[grorp]

That is not necessarily an argument either way, because Minetest is not a Minecraft clone. With minetest_game based experiences usually being some kind of mod soup, I'd rather say the goal should be to be more flexible than Minecraft.

Yes, sure. I just mentioned Minecraft to support my "it will get better if you get used to the new controls" point above. If the controls are used in Minecraft, it must be possible to get used to them and use them well.

Looking at the ContentDB I can assume with some confidence it will not work out that way. Mods are not games, the user compiles the game from them. Individual authors code to their preferences. Users obviously can change the touch_interaction themselves, but even a simple override setting could probably save them the work in most cases.

there should be more knobs for the user to somehow coerce the currently existing and future mod soup to be playable

IMO there is no sense in adding settings for users to override mod behavior just because you think that future mods will behave badly.

There are no mods using the touch_interaction feature yet. If it turns out to be abused by mods (which I think is unlikely), we can still consider solutions. However, I will open a documentation PR to add a little usage guidance for mod authors to lua_api.md.

Not all touch users have played the game using a mouse.

For these users, it should be even easier because they don't need mouse analogies to understand the controls. For them, the rule is as simple as "if you want to do a long action, do a long tap".

But more importantly in several games/mods it is not always easy for the user to tell an entity from a node. And there are valid reasons to have entities that look like nodes.

I misread the code. I think this makes it even more annoying. Just because I'm wielding a sword doesn't mean I want to punch my bag carrying horse or my chest minecart that looks like a node or my digtron storage that actually is a node. I can know if I closely check the information presented on the screen, even better when I activate debug info, but that breaks immersion.

If the feature is used like it is supposed to be used, wielding a sword doesn't change anything because swords can and should use the default touch_interaction value.

While a client-side setting to override touch_interaction per node/entity is out of question IMO, one could consider adding an API for games/mods to override touch_interaction per node/entity.

While this would allows games/mods to solve potential problems with node-like entities and entity-like nodes, it would lead to another problem I've already mentioned above: "Making the touch_interaction value dependent on what node or entity is pointed would add a lot more for players to remember. It would result in more suprises, not fewer."

With most games the user actually decides whether the game is peaceful. E.g. Mineclonia has a peaceful setting. Therefore not providing a user facing setting for touch_interaction control is just increasing the workload of game/mod authors.

It's also decreasing the workload for Minetest while at the same time giving more control to games/mods.

Then why are there mods? I mean, really why? But that is effectively the main point of the discussion. If that is a core design principle than you are obviously right, but that also explains why the minetest game experience is often mediocre. How could a mod soup where quite a lot of authors aren't even active any longer even try provide a consistent experience?

I guess I said this wrong. Let me rephrase it so it includes mods:

"Also, adding a client-side setting to override the server's control choices would violate Minetest's design principle that the server should be in control of the experience."

[Oriebugg]

I think button controls like the new one implemented in pocket edition would be best. I know minetest is not supposed to be a minecraft clone but in terms of controls, it might actually be the best one a game like this can have. Two buttons, one for breaking/attacking and the other for using/interacting. Once again, I know this isn't supposed to be a minecraft clone but there's also no denying that It's the control scheme the majority of mobile players are comfortable with.

[grorp]

@Oriebugg that's a different feature request, see #13229. I plan to add support for controls with onscreen dig/place buttons, but only as an alternative to the current controls.

(I'm not sure why that issue was renamed, the new title seems misleading.)

[j-r]

I published https://content.minetest.net/packages/j-r/touch_config/ which addresses my use-cases, but it is a crappy solution (another mod iterating all item definitions) and not suitable for multi-user servers. So a client side configuration would be much preferred.

After some more experiments I think the utility of touch_interaction is much more limited than I thought before, it's only useful for items that have two distinct actions of which exactly one requires 'holding'. Like the pickax mod that also places items on use. But most items I looked at have effectively just one action (e.g. shoot) and if this requires 'holding' the easiest way out for mod authors is actually to bind this action to both punch and use to be independent of client version and configuration.

I'll probably just roll out a custom apk to my family that hard-codes long punch, short place for everything, which is adequate for the servers we play on.

[grorp]

1. "Long tap to punch" has been brought back as a setting, resolving the first half of this issue.

2. The second half of this issue ("add a setting to disable touch_interaction per node/entity definition") should IMO be rejected. It makes touch_interaction dependent on which node/entity is being pointed. This isn't bad per se, but it's bad that it's only available as a client-side setting, making a client-side setting more powerful than the modding API once again.

   What could make sense instead is to extend the (server-side) mod API to allow this (should be opened as another issue if desired)