PlayerCulling

# PlayerCulling <img src="https://imgur.com/wjxP6Wh.png" alt="logo" width="200"> (https://img.shields.io/github/v/tag/MinceraftMC/PlayerCulling?style=flat-square)](https://github.com/MinceraftMC/PlayerCulling) (https://img.shields.io/badge/License-AGPL%20v3-yellow.svg?style=flat-square)](https://opensource.org/license/agpl-v3/) !(https://img.shields.io/badge/Status-Alpha-red?style=flat-square) (https://img.shields.io/discord/1094193723191070793?style=flat-square&label=Discord&link=https%3A%2F%2Fdiscord.gg%2FzC8xjtSPKC)](https://discord.gg/zC8xjtSPKC) ## Description PlayerCulling is an anti-cheat plugin and mod for Minecraft servers. It prevents players from seeing other players through walls using cheats. It utilizes a unique allocationless asynchronous voxel stepping-faced-ray-casting algorithm. ## Features - Asynchronous, multithreaded culling - Allocationsless voxel raycasting algorithm - Advanced scheduler system - Support for nametag visibility, potions, glowing and spectating - 2x2x2-scale voxel occlusion for non-full blocks - Efficient storage of occlusion block data - Nearly instant block updates - Easily enable/disable culling globally/per-player <details> <summary><strong>Scheduler Overview</strong></summary> PlayerCulling uses a custom multi-threaded culling execution system. Using this system, PlayerCulling is able to scale according to server load, and can cull both very few players and very many players, as long as enough CPU is available. The scheduler will dynamically start/stop threads ("containers") based on how many threads are needed. To limit the amount of resources PlayerCulling can use, see the thread limit in the plugin configuration. By default it limits itself to (number of CPU threads / 3). Here are some examples on how the PlayerCulling scheduler works. The following examples were tested on an arch linux desktop environment with an AMD Ryzen 5 3600X CPU: <ul> <li> <details> <summary>One Container</summary> One container is able to handle the load of 42 players without many problems. <br> <br> <img src="https://imgur.com/aImcHRU.gif" alt="One cull container with a few players" width="600" loading="lazy"> </details> </li> <li> <details> <summary>Two Containers</summary> If the load increases, the scheduler will automatically create a second container and distribute the players to maintain a buffer. In this example, a total of 55 players are together in an area. <br> <br> <img src="https://imgur.com/WskzbWA.gif" alt="Two cull containers with a few more players" width="600" loading="lazy"> </details> </li> <li> <details> <summary>Cleanup of Containers</summary> If a container is no longer used because the load decreased, it gets parked first. After its time-to-live (TTL) runs out because the load didn't increase again, it will get cleaned up automatically. <br> <br> <img src="https://imgur.com/ahP2Ynm.gif" alt="One cull container which gets cleaned up after its TTL expires" width="600" loading="lazy"> </details> </li> <li> <details> <summary>Heavy Load</summary> The scheduling system is theoretically able to scale to an infinite amount of containers. As long as the load increases (and the limit of containers hasn't been reached yet), the scheduler will automatically continue to add more containers. In this example, a total of 112 players are together in an area. <br> <br> <img src="https://imgur.com/Z1Gkxxd.gif" alt="A lot of cull containers with a lot of players" width="600" loading="lazy"> </details> </li> <li> <details> <summary>Merging of Containers</summary> If the load of multiple containers is too low, they will be merged together after a few seconds. <br> <br> <img src="https://imgur.com/qqFvxk2.gif" alt="A few cull containers with low load get merged into a single cull container" width="600" loading="lazy"> </details> </li> </ul> </details> <details> <summary><strong>Performance Overview</strong></summary> Using this view you can keep track of PlayerCulling's performance. The first bossbar shows info about the container with the highest load and general container scheduling statistics: - The count of **R**unning containers - The count of **P**arked containers - The count of total container **T**hreads - The count of total **R**aysteps per cull tick The second bossbar shows the load of the occlusion world cache, the working threads, amount of **C**ompleted tasks, amount of **S**tored chunks and the chunk cache size in bytes. The third bossbar shows info about culled players. The maximum amount of culled players can be calculated by (playercount) * (playercount - 1). In this example, a total of 112 players are together in an area. The server was running in an arch linux desktop environment with an AMD Ryzen 5 3600X CPU. <br> <br> <img src="https://imgur.com/3cFkBec.gif" alt="Performance overview with 42 players" width="600" loading="lazy"> </details> ### Supported Software | Server Vers