[discussion]Technical notes on how to defeat(*) oredetect

sofar
Developer
 
Posts: 1743
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: [discussion]Technical notes on how to defeat(*) oredetec

by sofar » Fri Jul 21, 2017 18:55

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.)


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.
 

sofar
Developer
 
Posts: 1743
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: [discussion]Technical notes on how to defeat(*) oredetec

by sofar » Fri Jul 21, 2017 18:57

ExeterDad wrote:
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?


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.
 

sofar
Developer
 
Posts: 1743
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: [discussion]Technical notes on how to defeat(*) oredetec

by sofar » Fri Jul 21, 2017 18:58

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.


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.
 

sofar
Developer
 
Posts: 1743
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: defeat oredetect - even more options

by sofar » Fri Jul 21, 2017 19:01

Xudo wrote:3) This should be done as a mod. Not in default game.


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
Member
 
Posts: 105
Joined: Wed Nov 09, 2016 16:43
GitHub: akryukov92
In-game: Xudo
 

User avatar
AspireMint
Member
 
Posts: 302
Joined: Mon Jul 09, 2012 12:59
GitHub: AspireMint
IRC: AspireMint
In-game: AspireMint

Re: [discussion]Technical notes on how to defeat(*) oredetec

by AspireMint » Fri Jul 21, 2017 19:44

sofar wrote:
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.


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.


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 ...
 

Xudo
Member
 
Posts: 105
Joined: Wed Nov 09, 2016 16:43
GitHub: akryukov92
In-game: Xudo

Re: [discussion]Technical notes on how to defeat(*) oredetec

by Xudo » Fri Jul 21, 2017 19:50

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 ...

From players point of view, this is same as random resources. I don't like this solution either.
 

sofar
Developer
 
Posts: 1743
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: [discussion]Technical notes on how to defeat(*) oredetec

by sofar » Fri Jul 21, 2017 20:02

Xudo wrote:Random ore from stone or oreblock is NOT good strategy.


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.

It's uncertain whether players will like it or not, sure. But until it's actually tried on a server, we won't know.
 

Xudo
Member
 
Posts: 105
Joined: Wed Nov 09, 2016 16:43
GitHub: akryukov92
In-game: Xudo

Re: [discussion]Technical notes on how to defeat(*) oredetec

by Xudo » Fri Jul 21, 2017 20:11

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?
 

sofar
Developer
 
Posts: 1743
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: [discussion]Technical notes on how to defeat(*) oredetec

by sofar » Fri Jul 21, 2017 20:20

Xudo wrote:I think that loss of gameplay from random ore out of stone is much worse than existence of players with oredetect.


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.

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.
 

sofar
Developer
 
Posts: 1743
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: [discussion]Technical notes on how to defeat(*) oredetec

by sofar » Fri Jul 21, 2017 20:29

Xudo wrote:What about showing block type only when it is adjacent to air?


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.

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.
 

Xudo
Member
 
Posts: 105
Joined: Wed Nov 09, 2016 16:43
GitHub: akryukov92
In-game: Xudo

Re: [discussion]Technical notes on how to defeat(*) oredetec

by Xudo » Fri Jul 21, 2017 21:00

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.
Last edited by Xudo on Fri Jul 21, 2017 21:07, edited 1 time in total.
 

Xudo
Member
 
Posts: 105
Joined: Wed Nov 09, 2016 16:43
GitHub: akryukov92
In-game: Xudo

Re: [discussion]Technical notes on how to defeat(*) oredetec

by Xudo » Fri Jul 21, 2017 21:05

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?
 

sofar
Developer
 
Posts: 1743
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: [discussion]Technical notes on how to defeat(*) oredetec

by sofar » Fri Jul 21, 2017 21:39

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.


stop, stop stop!

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.
 

sofar
Developer
 
Posts: 1743
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: [discussion]Technical notes on how to defeat(*) oredetec

by sofar » Fri Jul 21, 2017 21:45

Xudo wrote:Game should stick to core mechanics to be successful.


alright, this is really just diverging from the topic, but it's just ... INCORRECT.

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?
 

sofar
Developer
 
Posts: 1743
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: [discussion]Technical notes on how to defeat(*) oredetec

by sofar » Fri Jul 21, 2017 21:50

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?


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.

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.
 

User avatar
TumeniNodes
Member
 
Posts: 2506
Joined: Fri Feb 26, 2016 19:49
Location: in the dark recesses of the mind
GitHub: TumeniNodes
IRC: tumeninodes
In-game: TumeniNodes

Re: [discussion]Technical notes on how to defeat(*) oredetec

by TumeniNodes » Fri Jul 21, 2017 22:48

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.
I'm not your buddy, guy...
 

User avatar
duane
Member
 
Posts: 1273
Joined: Wed Aug 19, 2015 19:11
Location: Oklahoma City
GitHub: duane-r

Re: [discussion]Technical notes on how to defeat(*) oredetec

by duane » Sat Jul 22, 2017 01:04

sofar wrote:
ExeterDad wrote:
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?


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.


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.

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.

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.


I couldn't disagree more. Building is what minetest and minecraft are about. Digging is only incidental.
Believe in people and you don't need to believe anything else.
 

Xudo
Member
 
Posts: 105
Joined: Wed Nov 09, 2016 16:43
GitHub: akryukov92
In-game: Xudo

Re: [discussion]Technical notes on how to defeat(*) oredetec

by Xudo » Sat Jul 22, 2017 05:18

sofar wrote:
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?


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.

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.

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.

Does player receives updates about world on arbitrary distance?
In that case, server shouldn't send data when player is too far.
 

Xudo
Member
 
Posts: 105
Joined: Wed Nov 09, 2016 16:43
GitHub: akryukov92
In-game: Xudo

Re: [discussion]Technical notes on how to defeat(*) oredetec

by Xudo » Sat Jul 22, 2017 05:28

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.

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.
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.
 

Sokomine
Member
 
Posts: 3616
Joined: Sun Sep 09, 2012 17:31
GitHub: Sokomine

Re: [discussion]Technical notes on how to defeat(*) oredetec

by Sokomine » Tue Jul 25, 2017 03:52

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.

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:The problem statement:
Some players have an advantage over other players in obtaining resources

That sums it up well.

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.

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.

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.

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

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: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

Sounds like security by obscurity. It would create a significant overhead as well.

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.

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.

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.

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: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.

Colorful caves are nice :-) To some degree. As long as there's enough stone between the ores...

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.

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.

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.

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.
 

Xudo
Member
 
Posts: 105
Joined: Wed Nov 09, 2016 16:43
GitHub: akryukov92
In-game: Xudo

Re: [discussion]Technical notes on how to defeat(*) oredetec

by Xudo » Tue Jul 25, 2017 10:55

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.
 

sofar
Developer
 
Posts: 1743
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: [discussion]Technical notes on how to defeat(*) oredetec

by sofar » Tue Jul 25, 2017 19:12

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.


I didn't say "copy of world", I said:

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


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.

Xudo wrote:
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.

Does player receives updates about world on arbitrary distance?
In that case, server shouldn't send data when player is too far.


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
Member
 
Posts: 105
Joined: Wed Nov 09, 2016 16:43
GitHub: akryukov92
In-game: Xudo

Re: [discussion]Technical notes on how to defeat(*) oredetec

by Xudo » Tue Jul 25, 2017 20:27

Sofar, you said before:
sofar wrote:So, for the sake of *this* discussion, can you entertain ideas that do change the core mechanism, please?

And I have proposed you an idea what do change core mechanism.
Assuming this, your answer is confusing:
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.

Why are you asking for core-changing ideas and refuse them without reasons?

What do you think about proposal of Sokomine?
 

sofar
Developer
 
Posts: 1743
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: [discussion]Technical notes on how to defeat(*) oredetec

by sofar » Wed Jul 26, 2017 17:24

Xudo wrote:Why are you asking for core-changing ideas and refuse them without reasons


I'm not refusing the idea, actually. On the contrary.

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
 

PreviousNext

Return to Client-side modding



Who is online

Users browsing this forum: No registered users and 1 guest