neoh4x0r wrote:EDITED TO ADD: This problem is solvable but only without having the pre-conditions "being a non-destructive and non-restrictive solution".
EDIT: csm_restriction_flags seems to include the ability to disable calls from the client to get_item_def and get_node_def (the call is disabled on the server, not the client, to enforce the restriction).
So, a possible compromise could be to add extra flags to csm_restriction_flags to rate_limit the number of calls to those functions (like with get_node / csm_restriction_noderange).
----------
For instance, moving the ability to read the ore-data from the client to the server would allow the following scenario:
1) Client requests nodes (including the associated ore data) from the server
2) The server sends the data for (a server-side configurable number of) nodes surrounding the player (or around a specified location)
3) The client requests the same data again (either the same location or a different location)
4) The server rejects the request (and it won't send the data to the client until (a server-side configurable) amount of time has passed. Ie a cool-down period.
This doesn't defeat ore-detect, per se, or CSMs, but it does prevent the client from having an unfair advantage (ie seeing all nodes with ore-data everywhere).
This is a completely viable solution, but it would require an updated client and for ore-detect (and other CSM mods) to be modified to make a call to the server to get the ore-data.
Like I was saying before, there isn't any good way to do this ("to defeat ore-detect") without "cracking a few eggs." (and breaking those "pre-conditions")