I) remove specific ore nodes altogether and make e.g. plain stone randomly drop gold
This solution would completely defeat oredetect, but it's destructive.
This would be universally hated. This reduces mining to totally mindless and aimless grinding and would be quite boring. It's common sense.
We can do better than this.
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.
Useless since oredetect just needs to detect the ore stone.
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.
This has the same problem as II) because oredetect just detects the ore nodes.
I also think ideas I-III are destructive because you lose the classic ore blocks and get replaced by something boring. They restrict a lot of creative freedom of the subgame author. If you
really do want the classic ore nodes in your subgame, these ideas are not helping.
The problem with oredetect is pretty simple: Oredetect works because the Minetest client
already knows where the ores are. The server happily gives you this valuable information. You just need some code to extract this information from YOUR client. This code does not even need to be CSM. A modified client works just fine.
The current ideas seem to completely ignore this, and I think they all fall flat. We need ideas based on this premise. That we should not give clients all crucial information on a silver platter.
I came up with a few ideas on my own.
Idea 1:
- Reduce the block send distance
Pros:
- Already possible and simple
- Reduces server load
Cons:
- Does not defeat ore detect at all, only limits it
- Reduces view distance
- Useless if oredetect takes the seed into account
Idea 2:
- Allow modders to add a “disguise” for certain nodes. This is a node attribute which sets another node as the disguise of itself. E.g. a gold ore can be disguised as stone
- This is NOT a texture change!
- Example: The Minetest server will pretend that gold ore is actually stone as long the node is enclosed by stone and/or is far away from the player.
- There are no changes to the map format, or the network protocol required. The server still knows perfectly well where the ores are, it just lies about the itemstring
- For the client, enclosed ores are internally stored as node Y, so oredetect is useless
- When any of the sides has been made visible (e.g. air), the server tells the client that the node at position P is actually a gold ore (or whatever)
Pro:
- Guaranteed to defeat oredetect. There's nothing to detect
- No gameplay changes required
- Completely transparent to the client
Con:
- Requires a round-trip when an ore is revealed
- After an ore is revealed, it will first briefly look like a normal stone. This messes with client predictions
- Useless if oredetect takes the seed into account
Idea 3:
- Only send in “visible” nodes. These are nodes NOT enclosed by fully opaque nodes
- Internally, the client stores hidden (enclosed by a solid block) nodes as a special node type “hidden”
- When the player digs out a block and other blocks get revealed, the server sends an update for the new, revealed blocks
Pros:
- Oredetect can only detect ores which are visible anyway
- No gameplay changes required
Cons:
- Does not defeat oredetect 100%. It can detect ores in a neighbor cave which the player doesn't see
- Complex
- Requires a round-trip for each dig
- There's a delay before you see the revealed node after a dig
- Useless if oredetect takes the seed into account
Idea 4:
- Same as idea 3, but send more nodes: Not only the visible nodes themselves, but also all the nodes directly behind them
Pros:
- Oredetect is made (mostly) useless
- No gameplay changes required
- The dig prediction is a bit better than in idea 3
Cons:
- Visible ores and ores hidden directly behind stone can be detected
- Complex
- Useless if oredetect takes the seed into account
All ideas so far are vulnerable to using the world seed and using it to (pre-)calculate the positions of ore spawns. This can be very powerful as you can find lots of ores long before the server even generated them.
I have 2 ideas to defeat this:
Idea A: Keep the world seed secret from clients
Idea B: Make ore spawns independent from the world seed
Idea 5:
- Generate only stone, but keep the ore nodes (as definitions)
- After digging stone, randomly decide to add an ore cluster in a patch of hidden stone close to the player. If the algorithm decided to
not add stone, mark a patch of stone as “tried”
- The randomness and ore types are based on height. Existing ore definitions can be recycled.
- Stone needs a distinction between naturally generated and player-placed (like leaves)
- This algorithm is only allowed to add ores in naturally generated stone and stone which has not been marked as “tried”.
Pros:
- Pretty much destroys oredetect
Cons:
- Additional round-trips required (but you might be clever about it to hide it from the player)
- No ores at cave walls. You have to dig in order to reveal ores
- Hard to implement advanced ore distribution stuff. The actual ore distribution (as seen by players) will be very different
Note: This is similar to idea I, but without the frustration of having no visible ores.
Sadly, none of my ideas are without problems. But maybe you have an idea on how to improve on them.