How to configure Orebfuscator to fit your needs

Functional point of view

Ore X-RAY

This plugin's main goal is to prevent ore x-ray. It does so by sending stone or fake ore in their place. This makes sure that players can only see ore when they are exposed to them.

Both engine mode 1 and 2 can be used to prevent this kind of hacking.

Texture-pack/see-through X-RAY

Setting AntiTexturePackAndFreecam to true will now protect against x-ray texturepacks and freecam.

DarknessObfuscate

This feature obfuscates blocks that are in complete darkness (light level 0). By default, MossyCobblestone and Spawner blocks are obfuscated.

ProximityHider

ProximityHider works by hiding chests, furnaces and any block of your choice until players move around it.

ProximityHider now hides all non-obfuscated blocks that is exposed to caves. Useful against cave-finder to find ores.

Resource point of view

CPU

Obfuscating blocks is a CPU intensive work. There are many many blocks to be checked before a chunk is successfully obfuscated and sent to the client. A few variables play key roles in the calculation of the chunks(these are sorted from the most influential to the least):

• View Distance: This is in the configuration of the server (server.properties), option "view-distance". The default value 10 means each player will receive d = 10 x 2 + 1 = 21, chunks = d x d = 21 x 21 = 441 chunks around him/her. This means that each player will need that many chunks to be processed when he logs in or gets teleported. Reducing view-distance can dramatically decrease the number of chunks that needs to be calculated. (minimum value: 3 => d=7, chunks=49 per player)
• InitialRadius: The more this value is, the more calculation will be done. (larger = more CPU)
• EngineMode: Mode 1 uses slightly less CPU than Mode 2
• DarknessHideBlocks: This take extra processing to determine if a block in the darkness (light level 0) should be hidden. Disabling this might reduce CPU load
• ProximityHider: Uses some CPU every 0.5 seconds.
• UseCache: Caching is done so that chunks don't need to be calculated twice if there are no changes to them. This might take some disk read/write, but results in less CPU load. The effects of this is more significant if the previous options are taking much CPU

Memory

From a memory point of view, Orebfuscator does take some memory. Because a copy of the chunk's data needs to be kept during the calculations. Java usually clear nearly all the memory that Orebfuscator has used up, but sometimes, Java gets lazy and waits until the very last moment to clear the memory.

To learn more about Java garbage collection, please read: http://javarevisited.blogspot.com/2011/04/garbage-collection-in-java.html

More specifically, read the "Types of Garbage Collector in Java" section, which teaches different types of Garbage collection. You can try adding "-XX:+UseParallelGC" OR "-XX:+UseConcMarkSweepGC" (not both) to the command line of the server startup script if you are experiencing OutOfMemoryException.

Network

Network bandwidth is sometimes limited.

Orebfuscator will use slightly more bandwidth for sure, since block updates are sent more often than normally needed in order to reveal the correct blocks.

EngineMode 2 will consume more bandwidth than EngineMode 1 because the Compression done on chunks is less efficient before sending the chunk's data to the client. Since stone has been randomized with ores, there are less regularity in the data, and thus compressing it will be less efficient, resulting in a larger packet being sent.