Performance / Redstone limitsPrivate source
RedstoneLimiter
A spatial budget for redstone, not a blanket disable.
Sliding-window redstone and circuit limits at block, subchunk, chunk and region scope, with TPS scaling and manual quarantine.
Current build 3.0.3. The public changelog stops at 3.0.2, so 3.0.3 is a build version rather than a dated release note.
Checked version 3.0.3
Evidence checked 2026-10-30
The problem
Redstone lag is rarely one bad block. It is a circuit that activates too often across a volume, and by the time TPS drops the server has already paid for the work.
What I built
- Built a four-level spatial model: block, subchunk, chunk and region.
- Added sliding-window counters with a sustain period instead of a simple per-tick count.
- Made TPS scaling explicit and centralized so the same cap math is used at every scope.
- Kept quarantine manual after automatic quarantine proved too risky for operators.
Architecture and trade-offs
Record at every scope
An activation increments the block, subchunk, chunk and region windows. If any parent scope is already blocked, the event returns immediately, so the cheap check happens before more work.
Windows with memory
A sliding window with a sustain period distinguishes a short burst from a circuit that keeps firing. Caps are evaluated against nanosecond timestamps, not a reset-every-tick counter.
TPS scaling is deliberate
When TPS degrades, the multiplier moves toward the configured minimum; when the server is healthy it can rise to the maximum. The direction is explicit in the policy class, not scattered through listeners.
Observability over automatic action
Observer physics are telemetry, not cancellable events. Quarantine is operator-only, and notifications are globally throttled with a bounded message cache.