Frequently Asked Questions
- Orebfuscator offers a two level cache for already obfuscated chunks to safe on computing power
- Orebfuscator provides more advanced configuration to tune every little detail to your liking
- Orebfuscator adds the proximity hider which is able to hide surface blocks and reveal them should a player be close enough to them
- Support for multiple deobfuscation check such as distance, direction, frustum culling and ray cast culling
- Less invasive obfuscation thanks to the block below obfuscation mode
- Orebfuscator is designed to run in the main game thread as little as possible (which will lessen its impact on TPS)
- Orebfuscator can hide Tile-/Block-Entities (chest, furnace, etc.) correctly without leaving them in chunk packets
The proximity hider obfuscates surface-level blocks and reveals them to nearby players. This can be helpful since an anit-xray only obfuscates below surface-level blocks to create the illusion for non-xray players that their is no anti-xray. Once a player gets close enough to a block that is proximity hidden it is automatically revealed for said player.
This is strongly simplified. We calculate the players view frustum (camera view) every proximity update and check if a proximity block is inside the cameras view if it isn't it won't get deobfuscated. The frustum uses the players position, rotation, aspect ratio of 16:9 and the configured FOV to calculate the exact camera view the player would have if he had the same FOV and aspect ratio. This will force x-ray players to spin like crazy if the want to deobfuscate proximity blocks. The frustum culling is just another "bonus" check after the distance check passes meaning the player still has to be close to block for it to appear. (here is the proximity code: https://github.com/Imprex-Developme...ebfuscator/proximity/ProximityWorker.java#L85)
When a chunk packet is being send it will get intercepted by ProtocolLib and redirected it to us. We then create an obfuscation request (ignoring cache for this explanation) and enqueue it in the obfuscation queue which gets processed at a later time. We have to cancel or delay the packet because the whole system is async and we want to edit the packets content based on the response to our obfuscation request. If the useAsyncPacketListener is turned on (true) we will use ProtocolLib's built-in async packet listener which allow us to delay packets and contiune their transmission at a later time. If however the opposite is the case we will use a normal packet listener and have to cancel the packets transmission and restart the entire transmission at a later time. That would entail passing the whole packet through the entire ProtocolLib pipeline which probably won't affect performance but I didn't write ProtocolLib so I can't 100% garentee that.
Every time we need to load neighboring chunks we have to do it in the servers main thread. To limit the amount of performance impact on the main thread we try to limit the amount of time we take every tick to get those chunks. The way it works is we check every four chunks we loaded how much time it took and stop loading chunks if the threshold is reached. That would mean that Orebfuscator shouldn't under normal circumstances take more time then the set limit (default 10ms).
