NeuroLag

[1.7.1] — 2026-05-18 — Bug Fix Release

This release corrects five bugs identified in a full source-code audit of 1.7.0. Three of them were silent correctness failures that made advertised features behave differently from their documented intent without producing any visible error.

🔴 Critical Fixes

Fixed — LagEngine — Safe Mode FOLLOW_RANGE silently overwritten every tick

• Root cause: After SafeModeOptimizer.applySafeMode() set FOLLOW_RANGE = 4.0, the lambda in applyAiBatched() fell through to an unconditional attr.setBaseValue(attr.getDefaultValue() * multiplier) at the bottom of the loop. In CRITICAL state multiplier = 1.0, so the attribute was reset to its default value on every single tick — completely negating the FOLLOW_RANGE reduction that Safe Mode is supposed to maintain.
• Fix: Added continue immediately after safeModeOptimizer.applySafeMode(mob) to skip the unconditional setBaseValue line, matching the existing pattern used by the pathfinding-distance branch above it.
• Impact: Safe Mode now actually reduces mob target-scanning range during CRITICAL state as documented. Servers using safe-mode: true will see measurably lower entity processing cost during lag spikes.

Fixed — SafeModeOptimizer — NullPointerException crash on certain entity types

• Root cause: disableExpensiveAI() and the previous restoreAI() called mob.getAttribute(FOLLOW_RANGE).setBaseValue(...) without a null-check. getAttribute() returns null for entity types that do not expose FOLLOW_RANGE (e.g. Slime, Bat, some modded mobs), causing an unhandled NullPointerException that bubbled up through the scheduler and printed a stack trace every tick.
• Fix: Extracted the result of getAttribute() into a local variable and guarded both call sites with if (attr != null).

Fixed — SafeModeOptimizer — restoreAI() used a hardcoded FOLLOW_RANGE table

• Root cause: The previous implementation maintained an internal switch table mapping EntityType → double for the restore path. This table was incomplete (missing dozens of types) and ignored any custom attributes set by other plugins or datapacks, silently restoring the wrong range.
• Fix: Replaced the hardcoded table with attr.getDefaultValue(), which reads the actual server-side default and therefore works correctly for all entity types including custom ones.

🟡 Medium Fixes

Fixed — LagEngine — applyDifficultyScaling() had HARD and EASY inverted

• Root cause: case HARD → tps + 1.0 raised the effective TPS, causing optimizations to trigger later on Hard worlds. case EASY → tps - 1.0 lowered it, triggering optimizations earlier on Easy worlds. Both are the opposite of what the logic requires: Hard mobs pathfind more aggressively and consume more CPU; optimizations should therefore activate sooner, not later.
• Fix: Swapped the offsets — EASY → tps + 1.0, HARD → tps - 1.0.
• Impact: Servers running Hard difficulty worlds will now have mob AI throttled earlier under load, meaningfully reducing the lag window that was previously unaddressed.

Fixed — WebDashboard — Rate-limit map memory leak on long-running servers

• Root cause: rateLimitCounters and rateLimitWindows only cleared on stop(). Each unique IP that ever touched the dashboard created a permanent entry. On servers with public web dashboards, scanner/probe traffic could accumulate thousands of entries over days of uptime without any mechanism to reclaim the memory.
• Fix: At the start of each checkRateLimit() call, entries whose 60-second window has already expired are pruned via removeIf, and rateLimitCounters is kept in sync via retainAll. Cost is amortised O(n) across all incoming requests — negligible compared to the HTTP overhead of each call.

🛠️ Code Quality

Documented — LagEngine — AIThrottler field is intentionally unused

• The 1.7.0 refactor extracted AIThrottler as a separate class but did not update the applyAiBatched() call site to delegate to it. The inline throttle logic continued to run using LagEngine's own throttleCounters, leaving AIThrottler as unreachable code with its own duplicate counter map.
• This release adds an explicit NOTE comment on the field explaining why the field exists, why it is not called, and what is required before delegation can be completed safely. No behaviour change — cleanup is deferred to a dedicated refactor release.

---