Links
Tags
Creators
Details
2.0
Compatibility
Changes
๐ v2.0: The Performance Suite Update
This is a major feature update that introduces the Entity Culling System, transforming CircuitBreaker from a specialized physics-lag tool into an all-in-one server performance suite.
โจ New Feature: Entity Culling System
A new, optional system has been added to detect and clear excessive entity build-ups. This runs completely separately from the v1.0 physics lag detector.
- Fully Configurable: The entire feature is disabled by default. You can enable it and configure it in the new
entity-cullingsection of yourconfig.yml. - New Scanner: A new, slower, and server-friendly scanner (
startEntityScanner) runs on its own configurable timer (scan-interval-seconds) to check for entity-crammed chunks. - Threshold Culling: If the number of entities in a single chunk exceeds the
entity-threshold, the plugin will perform a "cull". - Admin Notifications: When a cull occurs, a message is sent to the console and to all in-game admins (with the
antilag.notifypermission) detailing how many entities were removed and from which chunk.
๐ง Smart Culling: No More Deleting Pets!
The biggest feature of the new system is its "smart" culling logic. The plugin will NOT remove entities that are considered "important."
An entity is considered important (and will be skipped) if it:
- Is on the new
entity-culling.whitelistin the config (e.g., "PLAYER", "VILLAGER"). - Has a custom name.
- Is a tamed pet.
- Is a vehicle.
๐จ Quality of Life & Fixes
- Console Color Fix: All console messages (startup, shutdown, and warnings) have been updated to use
Bukkit.getConsoleSender().sendMessage()for proper, sexy "blood-red" color rendering that avoidsยงcartifacts. - Code Cleanup: Cleaned up various classes and fixed minor bugs from v1.1.
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:89XN4Be6:7VxGlEMG"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:89XN4Be6:7VxGlEMG"
}

