Suggestion #14127

Server Update Suggestion: Resolving TNT & Explosion Lag

For your Information:
All of this comes from my experience as a Developer, I just asked gemini ai, to further enhance my suggestion and also since my english is so bad, some people might a hard time understanding what i'm trying to say.

[ SUGGESTION ]

I’m not entirely sure how our current server infrastructure is set up, but I’d like to offer a few architectural suggestions to help fix the lag when handling large TNT cannons and explosions.

When large cannons fire, the lag is primarily a CPU processing bottleneck on the main thread, rather than a network or memory (RAM) issue. In standard Minecraft architectures, entity velocity, collision checks, and 3D raycast calculations for every single explosion are processed sequentially on a single thread. When hundreds of TNT blocks explode at once, that single thread stalls, bringing down the server’s TPS for everyone.

1. Network Segmentation (Multi-Server / Proxy Setup)
- If all gamemodes run inside a single monolithic server instance, heavy physics tasks in one area eat up the CPU resources needed for the entire player base. Why don' you try to host each gamemode on its own independent server process behind a proxy (like Velocity or BungeeCord).

- Splitting gamemodes isolates CPU and RAM usage. A massive explosion event on one gamemode won't cause lag or drop TPS for players on other gamemodes.

2. Transition to Multi-Threaded Server Software
- Traditional servers run the entire world on a single thread. Folia breaks the world into independent regional tick loops across multiple CPU threads. If a massive TNT cannon fires in Chunk A, only the thread handling that specific region takes the load. The rest of the world operates smoothly at 20 TPS.

For Developers: If you’re familiar with Kubernetes, think of Folia like pod isolation. Instead of running everything inside one giant monolithic container, each region operates as an isolated execution context. Heavy load in one "pod" won't crash or slow down the rest of the cluster.

3. Implement Optimized TNT Algorithms
- Implement a custom TNT engine plugin like FastTNT or enable Paper's native explosion optimizations. Instead of calculating 500 individual explosions, these tools batch overlapping TNT into single mathematical passes and cache block checks. This alters the heavy $O(N^2)$ calculations and can reduce TNT engine load by 80%+.