All versions
Fixed ā
Fixed ā
Fixed ā
Fixed ā
Fixed ā
Fixed ā
1.5.2
Release
NeuroLag 1.5.26 months ago 24
Compatibility
Minecraft: Java Edition
1.21.x
Platforms
Paper
Purpur
Changes
[1.5.2] ā 2026-04-23 ā Bug Fix & Safety Patch
Fixed ā plugin.yml
- Critical: wrong
api-versionāapi-versionwas set to1.5.1(the plugin version) instead of the required Bukkit API version1.21. Paper rejects plugins with a non-standardapi-versionstring, causing the plugin to either fail to load or log a persistent warning on every server start. Changed toapi-version: 1.21.
Fixed ā WebDashboard
- Token not generated when
monitors.ymlis deleted or web dashboard is disabled.ensureStrongToken()was only called after theif (!webDashboardEnabled) returnguard, meaning servers that had the dashboard disabled (or whosemonitors.ymlwas deleted and recreated bysaveResource) would still have the default placeholder token the first time the dashboard was enabled ā a silent security hole.ensureStrongToken()now runs before the enabled check on everystart()call.- If
monitors.ymldoes not yet exist,saveResource()is called first to create the file structure before the generated token is written into it.
Fixed ā LagEngine ā Culling count wrong when protected zones are present
- Protected-zone mobs were counted toward
targetRemoveCountbut never actually removed, causing the cull pass to under-remove and leaving entity counts abovemaxEntitiesindefinitely on servers with active zone protection.cull()now pre-filters protected mobs from the candidate pool before computingtargetRemoveCount, so the removal math uses only the actually-cullable mob count.- The redundant zone check inside the removal loop is kept as a race-condition safety net.
Fixed ā LagEngine ā AI update scheduler saturation on very mob-dense worlds
- No upper bound on
runTaskLatercalls per tick ā on worlds with thousands of entities,applyAiBatched()could schedule dozens of batch tasks in a single tick, queuing more work than the scheduler could drain, leading to compounding latency.- Added
AI_UPDATE_PER_TICK_CAP = 80: at most 80 mob AI updates are scheduled per engine tick. The next monitor tick processes the remaining mobs, spreading load evenly.
- Added
Fixed ā StressTestManager ā Server crash on large spawns at low-chunk-count locations
- No per-chunk mob density check ā spawning 2 000+ mobs at or near the world spawn could
saturate loaded chunks and crash the server within seconds.
- Before spawning, the manager now scans a 7Ć7 chunk area around the target location and
compares the current entity count against
stress-test.max-mobs-per-chunk(default: 80). - If the limit would be exceeded, the spawn count is automatically reduced to the safe maximum and a warning is logged. If the area is already at capacity, the command is rejected with a descriptive error message.
- Before spawning, the manager now scans a 7Ć7 chunk area around the target location and
compares the current entity count against
- New config key in
systems.yml:stress-test.max-mobs-per-chunk: 80.
Fixed ā MultiServerSync ā MySQL reconnect attempt logged on every polling cycle
- When the MySQL database was down for an extended period,
ensureConnected()logged"MySQL connection lost ā reconnecting in Xsā¦"on every poll interval (default every 10 s), flooding the console with hundreds of lines.- Reconnect log messages are now gated behind the same power-of-2 streak filter already used for SQL error warnings (logs on streak 1, 2, 4, 8, 16 ā¦), reducing noise by up to 95% during prolonged outages while still keeping the first occurrence visible.
Config changes
# systems.yml ā new in 1.5.2
stress-test:
max-mobs-per-chunk: 80 # NEW ā per-chunk density safety cap for stress tests
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:NQv4Mv8q:C3vvoWh3"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:NQv4Mv8q:C3vvoWh3"
}

