Keep debugging details away from player by default

[Wuzzy2]

What I still dislike about Minetest that it still mostly looks like a test (pun intended!). All the gory developer details “leak” out into the actual gameplay. This can easily happen by pressing on the various function keys. This can get irritating to non-developers.

I propose a clear seperation between “developer mode” and “player mode”. All the debugging stuff should be clearly kept away from the player by default. All the developer/debugging features can only be used while in developer mode.

Developer mode could be as simple as a minetest.conf setting. If set to true, the game is in developer mode, otherwise, the game is set to player mode.

• Setting name: developer_mode
• Default value: true in debug builds, false in release builds

Developer mode (or debugging mode) Basically what Minetest is like now. No changes neccessary. All debugging features are available without limits.

Player mode The main mode which is supposed for actual gameplay. All debugging features MUST NOT be available or accessible in player mode. However, the player could of course always opt to change the mode to developer mode by editing the config.

Specifically, the following actions can not be used in player mode:

• Camera update (F4)
• Debug screen (F5)
• Profiler (F6)
• Print stacks (P)
• RETRACTED: Autorun (keymap_autorun)
• DISPUTED: Quicktune (Page up, page down, Home, End) (I have no idea what this is for)
• Other arcane debugging features which players would/should never use

To keep things sane, the actual key binding configuration should be unaffected by this, Minetest should simply ignore the specific keys in player mode. For example, if Camera Update is set to M in minetest.conf, and the player presses M while in player mode, nothing happens. But in developer mode, pressing M has the desired effect. The current special treatment for camera update's key binding can also be removed. Its default key does no longer need to depend on the DEBUG symbol since this proposal handles this in a more generic manner.

Related issues:

• https://github.com/minetest/minetest/issues/3845 (because of the proposed removal of arcane build parameters from pause menu)
• https://github.com/minetest/minetest/pull/4537 (because it removes print stacks from key binding menu)

Note: I guess many players will instantly miss F5 because of the coordinates. Yet I think exposing the coordinates through gameplay is the only acceptalbe solution because the debug display is clearly just an “emergency solution” which also only works for PC users, by the way. I have written a mod for exposing coordinates (orienteering). Players who REALLY miss the F5 key can simply set developer_mode=true.

[red-001]

Related #3896

[paramat]

:-1: I feel it's unnecessary complexity. Players often find these very useful, for example F5 for co-ordinates, yaw, 'pointing at' etc. Players use autorun. I feel it's a non-problem, if a player accidentely presses F6 etc. then they can try pressing listed keys again to cycle back to normal.

[kwolekr]

yeah I agree, this isn't really necessary. Plenty of games have developer debug output that can get enabled by setting a variable in the debug console and plenty more use the F keys for this too. :-1:

[sfan5]

Quicktune (Page up, page down, Home, End) (I have no idea what this is for)

maybe you shouldn't be advocating disabling it if you have no idea what it is...

Generally I think that introducing a special developer mode is unnecessary, though disabling (not binding a key) stuff like Print stacks (P) if not compiled in debug mode is a good idea.

[C1ffisme]

I'd like to keep F5 available, purely because it's helpful in modding and in finding my way back home. However I do agree that some features should be unavailable by default to make Minetest feel more immersive, and less like a graphics test that resembles a game.

Also, does anyone know what Quicktune is? I'm guessing that at one point a background music system was going to be added to Minetest, but was scrapped or nobody felt like working on it.

[Fixer-007]

for non debug mode I would leave just position, block name and FPS

[C1ffisme]

@Fixer-007 Include block name as well, since that's very useful in modding. (I'd rather just see what the block is called rather than search through a hundred code files for this block.)

[Wuzzy2]

1:

I'd like to keep F5 available, purely because it's helpful in modding and in finding my way back home.

2:

Players often find these very useful, for example F5 for co-ordinates, yaw, 'pointing at' etc.

It will stay available, the only thing which would change is that it is off by default and you have to set developer_mode to true. Also, please read carefully. I already adressed the coordinate argument in my first post ... IMO there should be an “canon” (read: non-debug, non-developer) way to expose the coordinate (e.g. with a mod), rather than in a way which looks like a test. Also, the problem with relying on debug mode only to see the coordinates is that it conflates gameplay with developing. We should not rely on debugging/testing features for stuff like this. Making coordinates available by default is actually a bad thing. Yes, it is useful, but it also takes away challenge from all games by default, and there is nothing a subgame developer can do anything about it. What if you want to make a subgame where you do not want the player to easily access the coordinates by default but instead the player has to earn this privilege, i.e. by crafting tools first? I already developed the orienteering mod with some items which you can craft to show your coordinates. Forcing F5 to be always enabled subverts the whole premise of this mod (and mods similar like this one) because why would a player craft the tools if you could just press F5? I guess it would be hard to resist the urge. ;-) It's a bit like a minor cheat. Not all games are 100% sandbox.

Players use autorun.

OK, then maybe I / we should start considering this a regular feature and not a debug feature. Strike that one out from my list.

Quicktune (Page up, page down, Home, End) (I have no idea what this is for)

maybe you shouldn't be advocating disabling it if you have no idea what it is...

As far I know it has something to do with debug according to source code comments. If I was wrong, strike that one from my list, too.

Long story short: If you think ANY of the debugging features is also users for players (and with “player” I mean “player”, not “mod developer who tests a game” or “core developer”. Just “player”), why not propose an alternative way to make this feature available to players in a way which does make Minetest not look like a test?

Many arguments posted here come clearly from a developer-centric view. With this thinking Minetest will never look like a polished game engine for players. If Minetest will ever only be aimed at power users or developers, many potential players are excluded. Also, I do not want to take anything away from “power users”, it will just be disabled by default. Power users will only have the minor inconvenience of changing a single minetest.conf variable.

By the way: If I would post a pull request for this feature request (without disabling quicktune and autorun), would it have any chance of merging?

[paramat]

Best wait for more dev opinions. But i'm strongly opposed.

[C1ffisme]

IMO there should be an “canon” (read: non-debug, non-developer) way to expose the coordinate (e.g. with a mod), rather than in a way which looks like a test.

Ah, I see. I'm fine with this, I suppose. The details are up to MTG I guess. (Compasses, anyone?)

[stujones11]

I think that this is a perfectly reasonable request and do not understand why there is such strong opposition to something that would be entirely optional. If the debug tools are to remain enabled by default then there should at least be some mechanism to disable them via a mod.

[Wuzzy2]

Why should any game (!) aimed at actual (!) players (!) have debug mode enabled by default? It doesn't make sense. Almost no game does this.

If the debug tools are to remain enabled by default then there should at least be some mechanism to disable them via a mod.

This is just a poor compromise as this is missing the point of my request, because then players can still be exposed to the gory debug details by default. Also, it should certainly not be triggered by a mod, but by a minetest.conf setting as explained above.

The majority of players are NOT developers. And even developers won't lose anything here, really. I also proposed that debug mode stays enabled in debug mode by default, so you don't even have to edit minetest.conf. I think Minetest should sooner or later get away from that devloper-centric worldview. Sure, developers are important but please let's not forget the “Average Joe” users.

This request is NOT about taking away ANYTHING from anyone (thats why I proposed a setting), it is about making Minetest look more like a polished software and less than a test in release builds.

(Compasses, anyone?)

See my orienteering mod. :-)

[paramat]

The opposition is because it's not needed and we are trying to avoid unnecessary code.

When i started playing MT i occasionally encountered the debug pages (i still don't understand most of it) and this didn't bother me at all, it's like being able to open the bonnet of a car even if you don't understand how an engine works, it's actually nice being able to do this. There's no harm and it avoids the complexity of installing a special 'mechanic-only' bonnet lock.

It's simply a complete non-problemm, it doesn't harm or annoy any reasonable person, there's no point bloating the code with it.

It's not debug mode, a debug build is a debug mode. This information is hidden away by default already. Does being able to access this information actually bother you? Are you perhaps imagining other players having a bad reaction to seeing this information, it's a little patronising and you have a slight tendancy to treat players as babies that have to be protected from anyhting technical and spoonfed.

[Wuzzy2]

You fail to account for these things:

1) Sometimes subgames specifically do not want players to have easy and cheap access to the coordinates for gameplay reasons (e.g. to make it more challenging). Debug screen also exposes health of pointed players/mobs which also some subgames may not want. So there you have your use case. The thing is, debug screen may expose gameplay information the player is normally not supposed to see (think of it like a minor cheat). Minetest already hides certain information under certain circumstances, like the minimap. Coordinates and health (and maybe even other infos which might “leak out” in the future) should be no exception. 2) I have offered you to help with implementation, so you won't be bothered with it. If I could offer you an implementation which is NOT bloated, would you still be opposed? 3) As I have said over and over again, interested players can just edit minetest.conf, so your “baby” argument doesn't apply. Editing a single setting is a very small step, not comparable to a “lock” 4) You completely ignored my polish argument. If Minetest looks less like a test this is also an improvement IMO.

Besides, I have just called it “debug mode” because that's the name I came up with. Call it whatever you like, I don't care, it doesn't change what I meant.

[stujones11]

Also, it should certainly not be triggered by a mod

I don't see how hiding the player coordinates is any different from hiding the mini-map and this can be done by conf setting or a mod https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L2826

If minetest is ever going to be taken seriously a 'game engine' then it really does need to give more control to game developers. Exposing the coordinates in particular, is bad for many game modes like mazes or dungeon crawlers for example.

[Wuzzy2]

Okay, I can kinda see what you are aiming for, but please keep gameplay / Lua API ideas for exposing the coordinates without resorting to debug tools out of this issue; I think creating a new issue (feature request) would make more sense to keep it clean.

Also, I'll argue that any player activating developer_mode is aware he/she is going to cheat.

[stujones11]

I agree that hiding player coordinates is possibly another topic and that there is nothing you can do to stop determined cheaters. It would be nice to be able to choose whether or not you want the debug info available. I often hit the function keys by mistake when selecting hot-bar items and it can be quite irritating. Perhaps a compromise could be a checkbox in the keyboard menu to simply disable the debug function keys?

[paramat]

Sometimes subgames specifically do not want players to have easy and cheap access to the coordinates for gameplay reasons (e.g. to make it more challenging). Debug screen also exposes health of pointed players/mobs which also some subgames may not want

Good points, these would need individual settings for each though, different request.

It doesn't matter how unbloated the implementation is, i will oppose any bad idea. Any amount of unnecessary code is bad.

Hiding information doesn't polish a game, what mainstream games do is not necessarily correct. I respect a game more when it allows access to detailed information. I think a few people here are too used to mainstream games and automatically consider anything the mainstream doesn't do a bad thing. Forget other games, just do what is right. Also forget mainstream players and worrying about what you assume they think (your assumptions are excessively negative).

This information is useful to players, they usually understand parts of it and find it useful at unexpected times during gaming, having to reset a setting instead of hitting a key would be annoying. C1ffisme, discussing which information to hide and which to not hide is pointless as you never know which information a particular player finds useful.

Accidently hitting a function key is a non-problem and your own fault, we can't start addind settings to avoid the accidental hitting of certain keys, how would you decide which keys to disable?

[C1ffisme]

@paramat

C1ffisme, discussing which information to hide and which to not hide is pointless as you never know which information a particular player finds useful.

Would you rather actually find out what information a particular player finds useful? I think that if anything, this is a question for players, not developers.

It doesn't matter how unbloated the implementation is, i will oppose any bad idea. Any amount of unnecessary code is bad.

I'm sorry for saying this, I really am, but how many little mapgens do we have? And, I'm not opposed to using Minetest's mapgen for experimenting with fractals or math, but the common player will probably just get confused when they see all this "v7","v6","singlenode" terminology.

Minecraft only has 5 mapgens, one of which is just the normal mapgen, but bigger, and the other ones are meant for a customized world. Terraria has even fewer, only a choice between Small, Medium or Large worlds, with the rest being procedurally generated. That's not a lot of customization, but it doesn't really matter when the world is 2 dimensional.,

Hiding information doesn't polish a game

Not entirely. Take for example, a subgame based on an older game where health of an enemy is not shown. Revealing this health might be helpful, but not very immersive or authentic to the original.

I think a few people here are too used to mainstream games and automatically consider anything the mainstream doesn't do a bad thing.

I have to half-agree with you here. The majority or popular group don't always do very smart things. We call out their mistakes by saying that it was a "bad update" or a "filler episode".

But, at the end of the day, they are still far more known then the people who do it right.

Summary: Our game still looks like a graphical test. I wish it weren't so, but I still can't look at it the same when debug details are on the screen.

To be fair, though, I do turn the debug screen on while playing, so call me a hypocrite if you like. :P

[Wuzzy2]

I have noticed that recently debug has become a privilege.

So my suggestion is to simply require the player to have the debug priv for accessing the debug, profiler and related functions (see 1st post).

[paramat]

Indeed this priv could be expanded to cover more things. The problem would be deciding about F5 as it may be desired for F5 to be available but F5 wireframe not.

[paramat]

So my suggestion is to simply require the player to have the debug priv for accessing the debug [...]

We may need another level of debug that allows seeing the first F5 page (co-ords, node pointing at) without seeing the wireframe page (see through the world) as the wireframe view is a very different level of information. I think the profiler and technical pages are harmless for players and even useful for them, so i would not limit those, just the seeing of coordinates.

[sfan5]

Maybe (probably) this was discussed previously but...

Is there really any good reason to hide coordinates from players? IMO they don't do any harm and can't be considered cheats that require locking down.

[paramat]

A few people have requested this, including a server owner, but i don't see it as high priority.

[C1ffisme]

Just so you all know, there are people in the Minecraft community as well that think that hiding the coordinates can improve gameplay. The Better Than Wolves mod removes coordinates from the debug screen in order to make gameplay harder.

To quote part of the forum page:

The "F3 debug info" screen has had a very unfortunate effect on gameplay in Minecraft. Despite the game having been "released" for some odd reason Mojang decided to leave an easily accessible debugging tool in the end product, and leave information displayed in it that provides the player with a distinct in-game advantage. In particular, the player co-ordinates provided effectively makes compasses and maps useless, while demotivating players with regards to building roads, rail networks, tunnels, and other infrastructure to connect their various building projects.

One of my main troubles with Minecraft, and yes, even I have some troubles, is that Nether Portals allow for fast transportation, because of the fact that building a portal in the Nether to the Overworld will form a portal in the Overworld relative to the coordinates of the recently built portal in the Nether times 8. This makes things like Minecarts redundant seeing as they just require extreme amounts of materials to go the same distance in a much longer time.

But removing coordinates means that players now have to focus on more realistic ways of keeping track of locations. Roads, landmarks, maps, and more are suddenly a lot more useful than just decoration or safety. (And safe roads aren't that useful in a game that has no hostile mobs by default.)

[Wuzzy2]

In particular, the player co-ordinates provided effectively makes compasses and maps useless, while demotivating players with regards to building roads, rail networks, tunnels, and other infrastructure to connect their various building projects.

This greatly sums up why I brought up this issue in the first place.

It is not that I want to make it impossible for players to view the coordinates (this could be done in a different, non-debug related way). My point is, you can't really make mods or subgames specifically made for orienteering purposes. Debug mode makes orienteering tools worthless. The point of these mods is that you have to earn the information instead getting it for free. The best example for this is my orienteering mod which includes items to expose your coordinates. The mod currently relies on the player resisting the urge to just press F5.

[paramat]

There is good reason for a server to be able to stop players seeing position / direction (some challenges need these hidden) and pointed node (you can then see which nodes are disguised traps or dangers).

I suggest HUD flags that can control what information players can access. We already have a priv for wireframe but this should perhaps be a HUD flag instead.

Much information is harmless to know: MT version, seed, FPS, view_range, range_all, profiler graphs etc. I see no harm in allowing players to access those, they are very useful for players and are not dev-only information, and being able to access these does not give a bad impression at all.

Perhaps a new HUD flag should control accessing position / direction / pointed nodename.

[LazyJ]

I don't like the idea of having to install a mod or edit source code to replace/revert yet another, long established, useful feature of the engine that has been either hidden (singlenode mapgen - made visible again and now this discussion about the debug info) or removed (sneak glitch) for the sake of one person's mod, sub-game, or ideal of numeric uniformity (PR/merged #5774 and PR/partial fix #6159).

I realise Wuzzy is not requesting that the debug info be removed but the underlying current of thought in this discussion is similar to that which was present in the issues I mentioned above.

There is good reason for a server to be able to stop players seeing position / direction (some challenges need these hidden) and pointed node (you can then see which nodes are disguised traps or dangers).

Over the years I have toured and kept a journal of quite a few MT servers. I have only encountered one server where the debug info would ruin the game play and that was one of Shara's/Ezzh's private, WIP, servers (still under development and still private as far as I know). In the future there may be more servers where the game play is dependent on players not knowing any of the info reported in the debug display. However; for now and the foreseeable future, such servers are in the tiny minority. Better to create a customizable setup to hide the info that would negatively affect those few servers' game play than add an unnecessary problem for the rest of the servers where such info may be helpful to both players and visiting testers (Fixer's visits to my server, comes to mind).

I suggest HUD flags that can control what information players can access. We already have a priv for wireframe but this should perhaps be a HUD flag instead.

HUD flags to control what information players can access, with my current understanding of the matter, sounds like a good compromise. Fixer proposed such an idea in PR #6225.

Much information is harmless to know: MT version, seed, FPS, view_range, range_all, profiler graphs etc. I see no harm in allowing players to access those, they are very useful for players and are not dev-only information, and being able to access these does not give a bad impression at all.

Bad impression? No. Minecraft, right out of the box: click on F3 and the screen is filled with coords, a compass of sorts, the name of the targeted node, the light level, and a lot of other info that has little to do with digging holes and stacking blocks. It's even more congested and obtrusive than Minetest's.

Harmless yet helpful. A couple years ago I enabled the display of debug info on my server because it is helpful to players (but not so helpful that it is cheating) for the way the game play is done on my server. Coords, cardinal direction, modname:nodename, are the most useful. FPS and viewrange are secondary. The rest of the debug info is ignored (though I would like to be able to comprehend what it is telling me well enough to be able to use it to tweak settings or diagnose problems)_. Being able to toggle through various stages of debug detail levels is ideal for a quick glance at the graphs and metrics and then back to the normal, less detailed info.

This will probably cross-over into the discussion on PR #6225 but here are some actual use cases from my own server, LinuxGaming2:

FPS If the lag seems to have built up after teleporting to a few places or after gathering and mining for a while, a quick glance at the FPS will provide a clue as to whether the lag is real or because the "R" key was unknowingly pressed, toggling on the full-view range causing the FPS to drop like a stone and motion to be very choppy.

View_Range When flying or setting up for scenery screenshots, increasing the view_range on the fly is done. When walking on the ground or mining, decreasing the view range improves performance for those who have weaker systems. For planning builds and landscaping - create a look-out tower, increase the viewrange and work on your plan (and take screenshots for reference)_.

Modname:nodename LinuxGaming2 uses several custom nodes. For new comers (new to the server but familiar with MT) it is handy to target a custom node they find while exploring to learn what it is. Then they can run a search for it in the craft guide to learn how to craft it.

I use the modname:nodename on a regular basis in conjunction with WorldEdit when cleaning up messes on the server; there are too many nodes to remember to enter into WE's commands. The most common use is clearing floating trees, particularly MoreTrees. Some of those trees are made up of 3 to 4 different node types. I set the WE region, target a leaf node and enter the modname:nodename to be replaced by air. Then repeat the process for the other leaf type, fruit/nut, and trunk. Inspector mods are nice but they get in the way of the work-flow for this particular use case.

Minetest is very geeky and, eventually, new comers will run into situations where they will need to know what the name of a mod is and what the name of a node is. A quick way to teach them is to tell them how to turn on the debug display, point at the ground, and report back what they see in the debug display.

Cardinal Direction This was more helpful before the mini-map was added. These days it is more of a nicety for us old timers who still prefer analog clocks and mercury thermometers. Otherwise, promoting MT as educational can be demonstrated by teaching kids the cardinal directions, learning what "N", "S", "E", and "W" indicate and how they relate in the min-map and how the kid's position in the map relates to other places and landmarks.

Coords For years I have recommended to players to keep pen and paper next to their computer and to jot down notes, doodle ideas, and chiefly to write down the coords to places important to them. Even with the teleporter mods we have these days, keeping note of coords still proves handy for places players have scouted but don't have a teleport too so as not to be found to easily by others or, as is more common, they mistakenly clicked on the sethome button instead of the returnhome button and need an admin or moderator to manually teleport them home.

LinuxGaming2 uses ShadowNinja's Areas protection mod. Players are able to set protection on their own stuff using chat commands. Those chat command depend on knowing the coords of two, cubically opposite corners. Another "MT is educational" example, use simple math to calculate where the second position is based on the coords of the first position.

Using coords to calculate the number of blocks required to build a wall is helpful; especially when using expensive nodes to build with.

Another common thing players have used coords for is to tell me the location of something they want me to see or check into. They pass the coords on to me and then I teleport to those coords.

When I see something suspicious in the logs, I teleport to the coords recorded in the logs to see first hand what has happened. On more than a few occasions I enter a typo, forget a number or a negative sign and wind up in the wrong place. A comparison of the coords in the debug display to the coords in the logs shows me what I entered incorrectly.

It was suggested that infrastructure (roads, teleports) should be the alternative to having coords displayed. Such things are indeed nice to have on a server but as my tours have shown me, that is rarely the case. Spawns and surrounding, developed areas will have some infrastructure but beyond that most places have none. It is not uncommon for a player to purposely avoid roads and other forms of public travel because they want to reduce the chances of being griefed. Also, such infrastructure takes a very, very long time to develop for both players and staff.

[paramat]

Better to create a customizable setup to hide the info that would negatively affect those few servers' game play than add an unnecessary problem for the rest of the servers where such info may be helpful

Yes, if such information becomes controllable i would want to be default enabled.

Cardinal directions can be known from cloud drift, sun / moon / star motion, or texture orientation.

[C1ffisme]

@rubenwardy

It was suggested that infrastructure (roads, teleports) should be the alternative to having coords displayed. Such things are indeed nice to have on a server but as my tours have shown me, that is rarely the case. Spawns and surrounding, developed areas will have some infrastructure but beyond that most places have none. It is not uncommon for a player to purposely avoid roads and other forms of public travel because they want to reduce the chances of being griefed. Also, such infrastructure takes a very, very long time to develop for both players and staff.

Griefing is a problem with servers, but it's likely that singleplayer games could benefit from the loss of coords.

You also mentioned protection mods. The solution to problems with those is to make them easier to use: make a graphical display that shows where protection is.

@paramat

Much information is harmless to know: MT version, seed, FPS, view_range, range_all, profiler graphs etc. I see no harm in allowing players to access those, they are very useful for players and are not dev-only information, and being able to access these does not give a bad impression at all.

Most of those are things that would be very good to give players (Although, view_range should appear as View Range in non-debug situations) except for seed. If someone has the seed of a world, it's likely that they can replicate a server's world for themselves, and then you could write your own mod for spotting ores or other useful things.

[paramat]

Good point about seed.

[C1ffisme]

@paramat I've actually done that before with my own singleplayer worlds in Minecraft, so not giving the player the seed of the world is a good safeguard to stop someone from doing this.

[nybble41]

@LazyJ

"I don't like the idea of having to install a mod or edit source code to replace/revert yet another, long established, useful feature of the engine ... for the sake of one person's mod, sub-game, or ideal of numeric uniformity (PR/merged #5774 and PR/partial fix #6159)."

5774 was not about some crusade for "numeric uniformity". Neither was it for the sake of any one mod or sub-game. The function was designed and documented to add only as many items as will fit in the stack, subject to the configured stack limit, and return the remainder. The fact that it did not do this /only when the destination stack was originally empty/ was an obvious bug. The fact that some users would prefer to ignore the stack limits does not imply that the original implementation was correct, even for that use case.

[paramat]

3 disapprovals above for the original suggestion. So closing.

However, it does seem possibly useful to add further stages to debug to control what information can be seen. A new issue for this could be opened if there isn't one already.