This doesn't defeat oredetect, it merely tries to detect it's use after the fact. A good solution makes oredetect useless to players before the crime, not after.AspireMint wrote: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.)
[discussion]Technical notes on how to defeat(*) oredetect
Re: [discussion]Technical notes on how to defeat(*) oredetec
Re: [discussion]Technical notes on how to defeat(*) oredetec
A solution like that would pretty much replace most of the base game code, and thus redoing the TNT code shouldn't be an issue.ExeterDad wrote:But what about mods that need the node defs to get the ores. Say TNT?sofar wrote:I) remove specific ore nodes altogether and make e.g. plain stone randomly drop gold
Re: [discussion]Technical notes on how to defeat(*) oredetec
Well, as soon as the player gets near the clusters, their client would still receive the block data and therefore you're not defeating the concept of oredetect.AspireMint wrote: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.
Re: defeat oredetect - even more options
The idea of the discussion is to discover (hopefully) good strategies. Implementation is not the goal here. Once we have good ideas, those who develop games or minetest_game can decide for themselves whether the strategies are acceptable or not. So whether it should be a mod or not is not yet relevant for the discussion.Xudo wrote:3) This should be done as a mod. Not in default game.
-
- Member
- Posts: 162
- Joined: Wed Nov 09, 2016 16:43
- GitHub: akryukov92
- In-game: Xudo
Re: [discussion]Technical notes on how to defeat(*) oredetec
Random ore from stone or oreblock is NOT good strategy.
- AspireMint
- Member
- Posts: 415
- Joined: Mon Jul 09, 2012 12:59
- GitHub: AspireMint
- IRC: AspireMint
- In-game: AspireMint
- Location: Stuck at spawn
Re: [discussion]Technical notes on how to defeat(*) oredetec
No, i meant something else. Everything will be stone.sofar wrote:Well, as soon as the player gets near the clusters, their client would still receive the block data and therefore you're not defeating the concept of oredetect.AspireMint wrote: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.
Dummy example:
on_dig_stone(pos, player) if ( super_secret_calculation_on_server_side(pos) not null) add_to_inv(ore_type, player:inv) else add_stone(player:inv)
... nvm ...
-
- Member
- Posts: 162
- Joined: Wed Nov 09, 2016 16:43
- GitHub: akryukov92
- In-game: Xudo
Re: [discussion]Technical notes on how to defeat(*) oredetec
From players point of view, this is same as random resources. I don't like this solution either.AspireMint wrote:No, i meant something else. Everything will be stone.
Dummy example:
on_dig_stone(pos, player) if ( super_secret_calculation_on_server_side(pos) not null) add_to_inv(ore_type, player:inv) else add_stone(player:inv)
... nvm ...
Re: [discussion]Technical notes on how to defeat(*) oredetec
It is a solution that 100% defeats oredetect. You may not like it, but it's a valid solution to the problem that is being discussed.Xudo wrote:Random ore from stone or oreblock is NOT good strategy.
It's uncertain whether players will like it or not, sure. But until it's actually tried on a server, we won't know.
-
- Member
- Posts: 162
- Joined: Wed Nov 09, 2016 16:43
- GitHub: akryukov92
- In-game: Xudo
Re: [discussion]Technical notes on how to defeat(*) oredetec
I think that loss of gameplay from random ore out of stone is much worse than existence of players with oredetect.
What about showing block type only when it is adjacent to air?
What about showing block type only when it is adjacent to air?
Re: [discussion]Technical notes on how to defeat(*) oredetec
This discussion thread is about discovering methods and designs that defeat oredetect. Disregarding solutions based on a person's personal opinion isn't good science/engineering.Xudo wrote:I think that loss of gameplay from random ore out of stone is much worse than existence of players with oredetect.
Try to keep an open mind. There could be many ways that such a mechanism could be enjoyable to the player that you would otherwise throw out with the bathwater.
For instance, let's hypothesize about a world where underground mining is entirely absent: All resources are gained from the surface only. This could be a highly enjoyable game - many games have setups like this, take for instance mining in WoW - it's all at the surface of the world. You may dislike it, but at one point there were over 10 million active players playing this game, so who says that a game needs to have underground mining at all to be successful?
So, please don't focus on the "I hate it" part, but try and think about solutions that solve the problem in ways that I haven't come up with yet.
Re: [discussion]Technical notes on how to defeat(*) oredetec
This may be very expensive to do. First of all, to do it properly (defeating oredetect) one should send normal stone blocks to the client. This means that the server needs to maintain an actual secondary version of the map block that indicates which nodes are ore nodes and which are not. Then the server needs to continuously scan those blocks together with the real map block data and compare to see which blocks were exposed to air and can therefore be changed and sent to the client as ore nodes.Xudo wrote:What about showing block type only when it is adjacent to air?
This isn't an appetizing solution - it's neither simple, nor is it efficient. It would be a very difficult solution at best, and it would suffer from lots of lag problems.
-
- Member
- Posts: 162
- Joined: Wed Nov 09, 2016 16:43
- GitHub: akryukov92
- In-game: Xudo
Re: [discussion]Technical notes on how to defeat(*) oredetec
It is very possible that my opinion is shared by part of silent community, which may not be present at forums and don't want such major changes in gameplay. Please keep open mind looking other solutions, but random resources from stone. It is ok to create mod like this, but don't force all players on all servers to play it.
Gameplay in Wow is not based on mining. 10 millions of players play with thousands of spells, abilities, NPCs and quests since 2004 or 2005 year. This is not the case of minetest. Game should stick to core mechanics to be successful.
There are two activities, which are based on visibility of ores:
* exploring caves and digging only resources from walls
* digging strategies - player digs specific layout of tunnels to increase the amount of ores per stone
This is what minetest and minecraft are about. Don't break it.
Gameplay in Wow is not based on mining. 10 millions of players play with thousands of spells, abilities, NPCs and quests since 2004 or 2005 year. This is not the case of minetest. Game should stick to core mechanics to be successful.
There are two activities, which are based on visibility of ores:
* exploring caves and digging only resources from walls
* digging strategies - player digs specific layout of tunnels to increase the amount of ores per stone
This is what minetest and minecraft are about. Don't break it.
Last edited by Xudo on Fri Jul 21, 2017 21:07, edited 1 time in total.
-
- Member
- Posts: 162
- Joined: Wed Nov 09, 2016 16:43
- GitHub: akryukov92
- In-game: Xudo
Re: [discussion]Technical notes on how to defeat(*) oredetec
What about rule: player can see ore only if it is adjacent to air and lit by torch (at least).
I suppose, that recomputation of light requires updates of all adjacent blocks anyway. Why not to expand this functionality?
I suppose, that recomputation of light requires updates of all adjacent blocks anyway. Why not to expand this functionality?
Re: [discussion]Technical notes on how to defeat(*) oredetec
stop, stop stop!Xudo wrote:It is very possible that my opinion is shared by part of silent community, which may not be present at forums and don't want such major changes in gameplay. Please keep open mind looking other solutions, but random resources from stone. It is ok to create mod like this, but don't force all players on all servers to play it.
this discussion thread exists to explore ideas, nothing more. I am not going to implement any code or change minetest_game.
So, let's get back to discussing the most ridiculous ideas. Don't fret, we're not going to force you or anyone to accept anything.
Re: [discussion]Technical notes on how to defeat(*) oredetec
alright, this is really just diverging from the topic, but it's just ... INCORRECT.Xudo wrote:Game should stick to core mechanics to be successful.
You can't even prove this. It's entirely stupid, too. Games change, sometimes even daily to adjust for the needs of the players, or the needs of the community, or the needs of the publisher.
WoW has changed over and over again. Sometimes for the worse, a lot of times for the better. Final Fantasy keeps adding new "chapters" that have drastic mechanism changes, but players still come back because if the mechanisms wouldn't change, it would just suck. Many games are changed after release, sometimes with major impact.
So, for the sake of *this* discussion, can you entertain ideas that do change the core mechanism, please?
Re: [discussion]Technical notes on how to defeat(*) oredetec
Does not solve the fact that the server would have to keep a completely separate copy of the map and incur a large overhead when mapblocks change to update the new map. Adding light into the mix makes it more complex (slow) and not more efficient.Xudo wrote:What about rule: player can see ore only if it is adjacent to air and lit by torch (at least).
I suppose, that recomputation of light requires updates of all adjacent blocks anyway. Why not to expand this functionality?
This is still an interesting idea, though, even at the cost (it may be acceptable, although implementing it would require quite a lot of effort) of it.
One problem is that once an area is exposed, other players nowhere near the exposed ore nodes will still be able to see the ore with oredetect from an unfairly far distance.
- TumeniNodes
- Member
- Posts: 2943
- Joined: Fri Feb 26, 2016 19:49
- GitHub: TumeniNodes
- IRC: tumeninodes
- In-game: TumeniNodes
- Location: in the dark recesses of the mind
- Contact:
Re: [discussion]Technical notes on how to defeat(*) oredetec
So, perhaps the plain stone which uses a random ore drop method... additionally setting the randomization per biome.
In tundra, it would be more likely to to obtain gold as the highest probability, other ores with lower prob.
In desert, more likely to obtain diamond as highest, other ores lower chance, etc..
The most challenging part, would be determining the probability of each ore and in which location
In this manner the usefulness is defeated in two stages, while adding some actual geological type game play
I am, somewhat, repeating myself but it seems a decent system. Personal preferences have come into this idea already so, that will happen with any solutions.
In tundra, it would be more likely to to obtain gold as the highest probability, other ores with lower prob.
In desert, more likely to obtain diamond as highest, other ores lower chance, etc..
The most challenging part, would be determining the probability of each ore and in which location
In this manner the usefulness is defeated in two stages, while adding some actual geological type game play
I am, somewhat, repeating myself but it seems a decent system. Personal preferences have come into this idea already so, that will happen with any solutions.
A Wonderful World
- duane
- Member
- Posts: 1715
- Joined: Wed Aug 19, 2015 19:11
- GitHub: duane-r
- Location: Oklahoma City
- Contact:
Re: [discussion]Technical notes on how to defeat(*) oredetec
It doesn't take much to do this, as I've already done it. There's no need to bother with gravel, since it's as common as dirt these days (much to my annoyance). It's also fairly easy (and efficient) to only put ores in the walls of caves and on the surface.sofar wrote:A solution like that would pretty much replace most of the base game code, and thus redoing the TNT code shouldn't be an issue.ExeterDad wrote:But what about mods that need the node defs to get the ores. Say TNT?sofar wrote:I) remove specific ore nodes altogether and make e.g. plain stone randomly drop gold
Personally, I don't think random drops take much away from the game. I'd much rather explore a cave than mine, and when I do mine, I want to dig nice, straight tunnels, not be forced to detour every time I strike a node, looking for more ore. However, it would be trivial to make it an option.
I do like the idea of making certain ores more common in certain areas. Diamonds could be found near lava or in deserts, etc. The problem with this is that biomes cease to have any meaning deep underground. And there's no reason to go only with one solution. If you leave a few decorative ores where they can easily be seen, no one will bother with cheats.
An ideal solution would actually give you incentive to dig deep. Nothing in the default game provides that. The deepest most people get is a few hundred meters down, strictly to get mese and diamond. After that, it's too boring (pun intended) to bother with.
I couldn't disagree more. Building is what minetest and minecraft are about. Digging is only incidental.Xudo wrote:There are two activities, which are based on visibility of ores:
* exploring caves and digging only resources from walls
* digging strategies - player digs specific layout of tunnels to increase the amount of ores per stone
This is what minetest and minecraft are about. Don't break it.
Believe in people and you don't need to believe anything else.
-
- Member
- Posts: 162
- Joined: Wed Nov 09, 2016 16:43
- GitHub: akryukov92
- In-game: Xudo
Re: [discussion]Technical notes on how to defeat(*) oredetec
Why do you need to keep separate copy of world? I think that flag "exposed" to node would be enough.sofar wrote:Does not solve the fact that the server would have to keep a completely separate copy of the map and incur a large overhead when mapblocks change to update the new map. Adding light into the mix makes it more complex (slow) and not more efficient.Xudo wrote:What about rule: player can see ore only if it is adjacent to air and lit by torch (at least).
I suppose, that recomputation of light requires updates of all adjacent blocks anyway. Why not to expand this functionality?
If ore block is "exposed" then send player "ore", otherwise "stone". Once block is exposed, you don't need to revert its visibility.
You can add access from lua API to allow customisation of exposing rules. It doesn't have to be light. One can introduce "mine detector". You click with mine detector on node and it will show ores around.
Does player receives updates about world on arbitrary distance?sofar wrote:One problem is that once an area is exposed, other players nowhere near the exposed ore nodes will still be able to see the ore with oredetect from an unfairly far distance.
In that case, server shouldn't send data when player is too far.
-
- Member
- Posts: 162
- Joined: Wed Nov 09, 2016 16:43
- GitHub: akryukov92
- In-game: Xudo
Re: [discussion]Technical notes on how to defeat(*) oredetec
Digging is important as a building. If you like building, then it is your playstyle. Developers of core game should keep in mind both playstyles. I think you wouldn't like the idea of placing random block instead of one you want to place.duane wrote:Personally, I don't think random drops take much away from the game. I'd much rather explore a cave than mine, and when I do mine, I want to dig nice, straight tunnels, not be forced to detour every time I strike a node, looking for more ore. However, it would be trivial to make it an option.
Player should know what he will get before digging, not after.
I'd also add one bullet to that list.
There are three interesting activities, which are about digging:
* exploring caves and digging only resources from walls
* digging strategies - player digs specific layout of tunnels to increase the amount of ores per stone
* digging stone blocks adjacent to ores usually expose additional nodes of ore
Those things makes digging interesting.
-
- Member
- Posts: 4290
- Joined: Sun Sep 09, 2012 17:31
- GitHub: Sokomine
- IRC: Sokomine
- In-game: Sokomine
Re: [discussion]Technical notes on how to defeat(*) oredetec
It's not that easy. The whole reason why people mine is because something *was* taken away from them - namely the creative priv (because they play on a server that isn't creative). Some subgames and servers add strong mobs which make survival more difficult, gameplay more challenging and thus more worthwile for some players. I personally value it a lot if the server has sensible rules and forbids (technically plus socially) griefing. That's also a restriction of freedom that greatly increases the joy in playing (for me - not for griefers).sofar wrote: 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.
That sums it up well.sofar wrote: The problem statement:
Some players have an advantage over other players in obtaining resources
You can't discard this aspect. It kind of even is the core of the entire argument. There are few situations where beeing able to obtain more ressources would even matter to other players - why bother if the other one has chests over chests with stacks of diamonds and nyan cats? Who - really - cares? As long as it's not put to good use (and diamonds and nyan cats in quantities make a very poor looking building), it might as well not be there for all it matters. It's not entirely unkown for people who prefer building to eventually get creative privs or otherwise unlimited ressources on an otherwise survival server. Pure PvP servers where quick availability of good armor and weapons matter might be slightly diffrent. I don't have experience with these. Still, you can only turn so many diamonds into weapons and armors.sofar wrote: 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.
Economy on servers usually doesn't work. If you play long enough you have enough of all you might need. Granted, there can be some exchange of items, and players might be happily using stores to buy and sell items. But to call that an economy would be stretching the word too far.
Players and server owners complain about the abilities of oredetect because they feel that other players can "cheat" which they experience as unjust. It does become unjust when comparing achievements and not mentionning that the conditions under which those achievements where reached where not the same. If it is known that a player has creative priv or uses oredetect, players can view achievements ("found a nyancat!") in the right light. Even the player who isn't using oredetect or other means was just lucky - or helped his luck by searching a lot.
Might be quite costy for the server. Crafting a complex, expensive tool in order to find very rare blocks might enhance gameplay a lot. The value would lie in the path to the tool - with the block that it finds just beeing thrown in as a nice addon.sofar wrote: The obvious solution would be to remove the disadvantage by providing an in-game oredetect to all players.
Sounds like security by obscurity. It would create a significant overhead as well.sofar wrote: 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
That would be a good technical solution. Except that it wouldn't be good for gameplay. Digging around, seeing the sought-for ore glimmer in the tunnel, finding one block and searching around for more, or exploring a cave and seeing the ore there - all that would be lost. Players mining ores could almost stop looking at the screen and put their cup on the keyboard. Caves would look pretty boring.sofar wrote: 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.
I usually don't build underground and do not care about the shapes of mines. They're one-time-dig-ores-and-never-come-back-places. I sometimes find mining pretty relaxing - it does not require much brain activity (good to do while watching a film) and is still fun when finding rare ores.duane wrote: 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.
Colorful caves are nice :-) To some degree. As long as there's enough stone between the ores...duane wrote: 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.
Players often seem to like caves a lot and report excitedly in chat that they've found a nice cave rich with ores and are now exploring. I don't like caves much as they're large and require more concentration to navigate.
Sounds like a good idea. Places with a higher ore probability could consist of a diffrent type of stone, with the field beeing large enough so that a player without oredetect is likely to find it as well.TumeniNodes wrote: 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.
Gold seems to be mentionned here a lot. What value does gold have ingame? Not much. You can craft blocks from it - which look acceptable in some few situations - and perhaps craft a few things with it (more with technic). Some servers use it as a currency. Gold might not be what players using oredetect are after.
Coal, iron and copper are relatively common ores and easy to find once you got a mine. Any effort to hide them from the client might be a waste of time. I don't think that using oredetect for those is efficient. Tin, silver, gold - those have too few uses to really matter. It's diamonds, mese blocks, mese crystals, mithril and nyan cats, infinium and the like player's are after - *rare* ressources.
My idea would be to leave normal ore generation as it is (coal, iron, copper, tin, even gold), but not to generate mese crystals, mese blocks, diamonds etc. at mapgen time. Those rare ores would be generated randomly when the player diggs stone like already suggested by others. If a stone is digged and the function returns "ore found", the stone behind the just digged stone turns into the ore so that it looks to the player as if he's just revealed that ore block. Other stoneblocks around could be turned into the desired ore at this time as well, simulating a cluster-like distribution. Making the ore emit some light and/or sound could help human players in times of lag. Digging strategies could be rewarded by not "jumping" over corridors and placing the ores closer together, with only stone and never air between two blocks.
A list of my mods can be found here.
-
- Member
- Posts: 162
- Joined: Wed Nov 09, 2016 16:43
- GitHub: akryukov92
- In-game: Xudo
Re: [discussion]Technical notes on how to defeat(*) oredetec
I completely agree with Sokomine.
I think that solution "leave simple ore as it is, make rare ore random" is very simple and efficient.
It is even possible to make "ore detector" tool, which will set apart digging and searching actions.
It can actually change stone to diamond, depending on coordinates of target block. It will prevent clicking on same stone until diamond appear.
I think that solution "leave simple ore as it is, make rare ore random" is very simple and efficient.
It is even possible to make "ore detector" tool, which will set apart digging and searching actions.
It can actually change stone to diamond, depending on coordinates of target block. It will prevent clicking on same stone until diamond appear.
Re: [discussion]Technical notes on how to defeat(*) oredetec
I didn't say "copy of world", I said:Xudo wrote:Why do you need to keep separate copy of world? I think that flag "exposed" to node would be enough.
If ore block is "exposed" then send player "ore", otherwise "stone". Once block is exposed, you don't need to revert its visibility.
You can add access from lua API to allow customisation of exposing rules. It doesn't have to be light. One can introduce "mine detector". You click with mine detector on node and it will show ores around.
There is no way that the server can send "ore" otherwise "stone" to a client. If there is ore, it sends ore, if there is stone, it sends stone, period. The only way around this would be to create a secret map that flags "this stone is actually ore" for each block and that secret map is never sent to the player. However, once exposed, the actual map would change when the block would be exposed by a player.sofar wrote:server needs to maintain an actual secondary version of the map block that indicates which nodes are ore nodes and which are not
Only nearby blocks are sent, but, nonetheless players further away from the exposed blocks will still receive it even if they haven't ever seen the block. That is unpreventable.Xudo wrote:Does player receives updates about world on arbitrary distance?sofar wrote:One problem is that once an area is exposed, other players nowhere near the exposed ore nodes will still be able to see the ore with oredetect from an unfairly far distance.
In that case, server shouldn't send data when player is too far.
-
- Member
- Posts: 162
- Joined: Wed Nov 09, 2016 16:43
- GitHub: akryukov92
- In-game: Xudo
Re: [discussion]Technical notes on how to defeat(*) oredetec
Sofar, you said before:
Assuming this, your answer is confusing:
What do you think about proposal of Sokomine?
And I have proposed you an idea what do change core mechanism.sofar wrote:So, for the sake of *this* discussion, can you entertain ideas that do change the core mechanism, please?
Assuming this, your answer is confusing:
Why are you asking for core-changing ideas and refuse them without reasons?sofar wrote:There is no way that the server can send "ore" otherwise "stone" to a client. If there is ore, it sends ore, if there is stone, it sends stone, period.
...
Only nearby blocks are sent, but, nonetheless players further away from the exposed blocks will still receive it even if they haven't ever seen the block. That is unpreventable.
What do you think about proposal of Sokomine?
Re: [discussion]Technical notes on how to defeat(*) oredetec
I'm not refusing the idea, actually. On the contrary.Xudo wrote:Why are you asking for core-changing ideas and refuse them without reasons
This thread is a technical discussion about all the ideas, and my replies are not a refusal, but a criticism. The idea is certainly possible, it just comes at a high cost and I do not know if you understand the implications, hence my attempts to explain the cost.
For the sake of the discussion, I've stated that any solution that reduces to "just disable CSM" is not acceptable for this thread (since it will make people stop thinking about the underlying problems, and therefore ignore more creative solutions). But, in the same way, that doesn't make it necessarily unacceptable to minetest - that is a discussion that will be had on any PR on github.
Forum -> ideas
github -> implementation
Who is online
Users browsing this forum: No registered users and 1 guest