Minetest Forums

(*) This is a discussion thread to discuss technical measures that can be taken by server operators to defeat CSM mods like oredetect, but without killing oredetect or adding "restrictions".

This is not a rant thread to discuss CSM. Discussions about CSM and other stuff are not on-topic and will be deleted.

The goal is to come up with elegant and creative solutions that are constructive, and not destructive.

Constructive solutions include solutions that result in better value for all parties: more players, happier players, happier server owners, less complaints, more game features, etc..

Destructive solutions include solutions that take away features, result in players not being able to do certain things anymore, server owners losing certain players, server owners giving up.

The problem statement:

Some players have an advantage over other players in obtaining resources

It is fairly clear that the problem isn't necessarily that CSM exists, at all. Oredetect allows players to spend less time to obtain valuable in-game resources. This advantage is often described as "cheating" since it is perceived by many players as "unfair". Whether it is unfair isn't really important in this discussion, since we are going to focus on solutions that remove this disparity.

I will post ideas and discussions in subsequent replies to this post so they can be individually discussed more easily that way. I will probably not edit the top post, since that would make the discussion hard to read, so, please follow the thread along.

The core of the problem statement is that some players are disadvantaged (those that do not have oredetect).

The obvious solution would be to remove the disadvantage by providing an in-game oredetect to all players.

There are several ways that this can already be achieved. Just like oredetect code is relatively simple, it's entire advantage could be eradicated if the server provides similar functionality to all players, and does so with a better and simpler interface that makes it easy to use for all players.

It's absolutely certain that a simpler interface than oredetect is doable, so my bet is that dedicated players would absolutely be willing to spend time e.g. crafting an in-game oredetect tool and therefore exchange play time for the ability to oredetect (e.g. a special pickaxe tool, radar etc.) and therefore consume resources and time in another way. This would actually make the game more well-rounded.

I have more thoughts on a solution like this - there are many variations that result in the removal of the inequity without the removal of the actual functionality.

Why you cant implement that if someone uses CSM, you can see it in the debug.txt?
It is not very useful to have a serverside oredetect mod, because if you do this, you should do all CSM into serverside mods and then is the problem, why are they CSMs?

oredetect functions by scanning for nearby nodes on the map. It has to search for specific nodes because there are too many different nodes and so it keeps a list of known nodes to look for.

The method that oredetect uses to select nodes to search for is very simple: the player has to enter the exact name of each node to look for. This means that it's hard for players to add new nodes, since they need to type in a very long string into the game. And it means that the nodes are in a manually maintained list.

There are many ways to make it almost impossible for players to maintain the list:

a) make the sensitive node names extremely long and contain utf8 special characters that can't be typed.
b) instead of having 1 nodedef for gold ore, have 1000 nodes for gold ore.
c) constantly change the name of gold ore nodes every server reboot (e.g. daily)
d) constantly change the name of gold ore nodes in-game real-time
...

This can be taken even further by implementing further mechanisms that decouple things:

I) remove specific ore nodes altogether and make e.g. plain stone randomly drop gold
II) have normal stone and ore stone, and ore stone randomly drops balanced distributed rare items so that players get a certain amount of iron, gold, diamonds etc.
III) decouple digging ore from obtaining rare resources: e.g. in a mining union, the player gets paid for the amount of work done, so one could reward a player working in a public mine that has mined 1000 stone equally to someone who has mined 50 ore nodes.
...

TalkLounge wrote:Why you cant implement that if someone uses CSM, you can see it in the debug.txt?

Because it would be too easy to defeat that.

TalkLounge wrote:It is not very useful to have a serverside oredetect mod, because if you do this, you should do all CSM into serverside mods and then is the problem, why are they CSMs?

This is not a discussion thread on the merit of CSM, sorry. That discussion is offtopic. If you don't understand that, and want an answer, please ask in the CSM related threads.

Look at Minecraft optifine. Today everybody has optifine. Anybody who think its unfair, should download oredetect and use it.

TalkLounge wrote: Look at Minecraft optifine. Today everybody has optifine. Anybody who think its unfair, should download oredetect and use it.

This doesn't solve the inequality, and is therefore not a solution.

A whole line of defense against oredetect is to make it painful for players to use it.

The whole point of oredetect is that it makes it easier for players to find ores they need and thus spend less time mining; Therefore an obvious counteraction would be to remove the benefit to players by:

I) detecting that players use oredetect

and subsequently take one of the following actions:

1) force the player to consume more time on other tasks, or
2) time-out the player with a temp ban, kick, lock-out or similar
3) remove the unfairly obtained resources (e.g. "tax" the player)
...

sofar wrote: and subsequently take one of the following actions:
...

I think any of these, or perhaps even a string of them (aside from mine which is meant as a joke "kinda") or set all 3 but set to be applied in a random pattern, which would cause frustration to the user

<edit> slightly OT: Many begged for CSM, now that it's here, they all be complainin' : /

TumeniNodes wrote:<edit> slightly OT: Many begged for CSM, now that it's here, they all be complainin' : /

On-topic: Since this is oredetect-specific: What about not propagating ore positions to clients unless the player had them in direct line of sight at least once?

Linuxdirk wrote: On-topic: Since this is oredetect-specific: What about not propagating ore positions to clients unless the player had them in direct line of sight at least once?

Once the nodes are on the map, it's not possible to prevent sending them to clients.

However, you could generate them only when the first player comes nearby, and when they are exposed to air. This wouldn't prevent a second player from seeing them from further away even without line of sight, but the first player most likely will mine all of the generated nodes irregardless.

So, some of this is entirely doable and likely reasonable technically as well.

TumeniNodes wrote:

sofar wrote: and subsequently take one of the following actions:
...

which would cause frustration to the user

Which wouldn't be preferential, since we want to address the inequality, not leave the inequality intact and think that enforcement could solve the problem. Good point.

A good solution is one that removes the inequality, not one that punishes players that abuse the inequality.

Well, digging around for specific nodes annoys me, so I just made different types of stone drop appropriate ores for the stone, depth, and player's dedication to digging (referred to as skill). Now I don't dig crazy shapes and my tunnels and shafts look better. I did leave ores in caves, at the surface of the rock where anyone can see them.

Making ores spawn only on the surface of rock seems to appeal to a lot of people, and a node could drop more than one ore, to make up for any scarcity. However, it's easy to drown out the look of a cave with too many ore nodes.

I like what duane has done viewtopic.php?f=9&t=18063

And definitely agree that adding some form of ore detection device, which needs to be crafted, and some form of manual entries needing to be done.
Then again, even some visual methods added to give hints to ores in an area might be interesting as well.

It would challenge kids (which is what kids need and often want), and makes mining more interesting, and adding more interesting gameplay/features is always a good way to go in my opinion.

As I sated earlier, I like what duane has done. Although the issue came up regarding a point that some people will like it, and some will not.
So, while it is a good start of a solution, it would be, as a mod.

I had mentioned this in irc yesterday, and coupled it with an idea I had regarding setting specific ores to biomes.

I think organizing ores by biomes may (somewhat) help the issue of ore-detect?
If it is known that, say for example, gold is found in the tundra biome, that is where you go to mine for gold.
This method would give an equal edge to all players, thereby potentially removing some of the thrill, or need for ore-detect?
And I think it is a reasonable "edge", because it somewhat resembles IRL methods of using signs in terrain.
and it can be done as (or part of) an embedded solution.

I mean, other than something like this, what more can be done?
Open to suggestions to improve on this idea or why it may not be a good idea

I did not read all the posts before so maybe the proposal already happens.
My idea is to solve the issue client site (client, not csm). The client lua environment is always in context of the one player, so each "get_node()" in client lua environment should check the node using line_of_sight() if visible by player and return "ignore" if not.

Maybe this additional check should be optional, set by server on connect.

Of course cheating using modified client is still possible in this way, but it is the same situation as before csm, the official client does not support cheating.

bell07 wrote:I did not read all the posts before so maybe the proposal already happens.
My idea is to solve the issue client site (client, not csm). The client lua environment is always in context of the one player, so each "get_node()" in client lua environment should check the node using line_of_sight() if visible by player and return "ignore" if not.

Maybe this additional check should be optional, set by server on connect.

Of course cheating using modified client is still possible in this way, but it is the same situation as before csm, the official client does not support cheating.

Even if we disregard hacked clients for this issue, I foresee problems with the line of sight calculations, and moreover, this would make it impossible to do things like playing sounds near nodes that are hidden, which removes a possibly useful feature.

It may also be too easy to influence the line of sight calculation client-side as well.

But, this may work well for some servers.

My proposal is not to disallow all client functionalities for "invisible" nodes but the lua-csm environment only.
The sounds triggered by server could be played as before at any place. Sounds triggered by client/csm should respect the invisibility. If not the next ore-detect mod is a "listen for ores" mod ;-/

bell07 wrote:My proposal is not to disallow all client functionalities for "invisible" nodes but the lua-csm environment only.
The sounds triggered by server could be played as before at any place. Sounds triggered by client/csm should respect the invisibility. If not the next ore-detect mod is a "listen for ores" mod ;-/

Your whole idea consists of restricting CSM, and, according to the topic, the goal of this discussion is to solve the problem without restricting CSM, since it doesn't solve hacked clients either, and essentially doesn't solve the underlying problem, and won't deter the very most determined players who desire to cheat. It certainly is a valid strategy but only if you're willing to accept that there will be a small amount of players who will cheat irregardless, and people have already said that they wouldn't.

And this is why I posted in the topic that ideas that center around restricting CSM are not going to be fruitful. Avoiding the core of the issue will only result in having to address it at a later stage.

Make statistics, and compare with players. If someone is suspected, check that mine and see if CSM was used (you can see straight tunnel to nyancats position, etc.)

sofar wrote:remove specific ore nodes altogether and make e.g. plain stone randomly drop gold

I like that simple solution.

sofar wrote:I) remove specific ore nodes altogether and make e.g. plain stone randomly drop gold

But what about mods that need the node defs to get the ores. Say TNT?
Sounds like a whole bunch of custom work to defeat something that never should of been in the first place.

AspireMint wrote:I like that simple solution.

That makes it even more random where to find ores. It already is random enough. We just need a proper way to protect them from detection without the or being in direct line of sight.

then improve script, make it "spawns" in clusters, something like real mapgen works. Only server will know where you can find these ores and with what probability.

Another solution switch to older minetest, like 0.3 /jk x)

sofar wrote:This can be taken even further by implementing further mechanisms that decouple things:

I) remove specific ore nodes altogether and make e.g. plain stone randomly drop gold
II) have normal stone and ore stone, and ore stone randomly drops balanced distributed rare items so that players get a certain amount of iron, gold, diamonds etc.
III) decouple digging ore from obtaining rare resources: e.g. in a mining union, the player gets paid for the amount of work done, so one could reward a player working in a public mine that has mined 1000 stone equally to someone who has mined 50 ore nodes.
...

As a player, I don't like those solutions.
1,2) Digging strategies is a part of gameplay. One can increase their chances of obtaining diamond (mese) by using specific tunnel layout.
3) This should be done as a mod. Not in default game.