LetUrMemoryRest

LetUrMemoryRest is a Bukkit/Spigot plugin designed to help optimize your Minecraft server's performance through configurable memory management, redstone activity control, and explosion handling. It aims to reduce server load and improve stability by managing resources more effectively.

Bstats:

bstats

Key Features:

LetUrMemoryRest offers several modules to manage server resources. Each is configurable via plugins/LetUrMemoryRest/config.yml.

1. Memory Management

Mechanism:
- Periodically triggers Java's garbage collector (System.gc()) to free up unused memory.
- If server RAM usage (Java heap) exceeds a configurable "critical" threshold, the plugin performs a more intensive cleanup which includes System.runFinalization() and forces a save of all worlds to disk.
Configuration:
- memory.cleanup-interval: Frequency (in ticks) of regular memory cleanups.
- memory.skip-when-ram-usage-is-in-percentage: If RAM usage is below this percentage, cleanup is skipped.
- memory.ram-warning-threshold & memory.ram-critical-threshold: Percentage thresholds that trigger warnings or more aggressive actions.
- memory.aggressive-cleanup-threshold: (Note: This seems to be another threshold, ensure its distinct role is clear or consolidated if it overlaps with ram-critical-threshold's aggressive cleanup).
🔴 Important JVM Note: For effective memory management, ensure your server's JVM arguments do not include -XX:+DisableExplicitGC. This flag prevents System.gc() calls, rendering this feature ineffective. The plugin includes a startup check and will warn if this flag (or ExplicitGCInvokesConcurrent) is detected.

2. Redstone Management

Mechanism:
- Component Limiting: Allows setting a maximum number of redstone components (e.g., dust, repeaters, pistons) per chunk area. If the limit is reached, placing more redstone components in that chunk is prevented.
- Experimental Redstone Slowdown: (Default: Disabled) Optionally introduces a configurable delay (in ticks) to redstone signal changes for certain components. This can reduce the server load from very active or rapid-fire redstone circuits.
Configuration:
- redstone.max-per-area: Maximum redstone components allowed per chunk. Set to -1 to disable.
- redstone.check-chunk-on-start: If true, counts existing redstone components in chunks as they load to enforce limits.
- redstone.slowdown.enabled: Set to true to enable the experimental slowdown.
- redstone.slowdown.ticks: The delay applied to redstone updates when slowdown is active.
⚠️ Warning: The Redstone Slowdown feature is experimental. It may have bugs and could significantly alter vanilla redstone behavior. Use with caution and test thoroughly before enabling on a production server.

3. Chunk Management

Mechanism: Periodically scans for and unloads inactive chunks to free server memory. A chunk is considered inactive if:
- No players are currently within or very near the chunk.
- The chunk's inhabitedTime (how long players have spent in it) is below a configurable value.
- This process does not affect chunks that are force-loaded (e.g., by other plugins or commands).
Configuration:
- chunk.unload-inactive: Set to true to enable automatic unloading.
- chunk.unload-delay-in-ticks: How often (in ticks) the plugin attempts to unload inactive chunks.
- memory.chunk-unload-frequency: The minimum inhabitedTime (in ticks) a chunk must have to be considered "active" enough to avoid unloading by this feature (if no players are present).

4. Explosion Optimization

Mechanism: Intercepts entity and block explosion events to provide granular control:
- Block Limit: Limits the maximum number of blocks affected by a single explosion.
- Item Drop Control:
  - explosions.clear-drops: If true, explosions will not drop any items (yield is set to 0).
  - explosions.drop-chance: If clear-drops is false, this sets a percentage chance (0-100) for each affected block to drop its items.
- Explosion Slowdown: (Default: slowdown-ticks: 2) Optionally, the original explosion event is cancelled, an explosion sound is played, and the affected blocks are broken sequentially over a series of ticks. This helps spread the server load from large explosions. A slowdown-ticks value of 0 attempts to break blocks instantly within the optimized logic (respecting other settings like drop chance).
- Ignored Explosions: You can specify entity types (e.g., CREEPER) or block types (e.g., TNT) in explosions.ignored-explosions to exclude them from these optimizations.
Configuration:
- explosions.enabled: Toggle the entire explosion optimization system.
- explosions.limit-blocks: Max blocks affected. -1 for no limit (still subject to other optimizations).
- explosions.clear-drops, explosions.drop-chance, explosions.slowdown-ticks, explosions.ignored-explosions.
⚠️ Compatibility Note: The feature to specifically ignore explosions with ExplosionResult.KEEP or ExplosionResult.TRIGGER_BLOCK relies on API methods (getExplosionResult()) available in Spigot/Paper 1.20.5 and newer. On older server versions, this specific check might not function and could potentially cause errors if not handled gracefully by the server/API. (Developer note: Please verify this and ensure your plugin handles this API difference across the supported versions 1.13-1.21.x, or adjust the compatibility claims/note accordingly. If it can cause a NoSuchMethodError on 1.13-1.20.4, this is a critical accuracy point).

5. Dynamic Adjustment

Mechanism: This feature monitors server RAM usage. If RAM usage exceeds the memory.ram-critical-threshold, the plugin will stop and restart its background tasks (memory cleanup, chunk unloading).
Effect: This re-applies the current settings from config.yml to the tasks. If you've modified config.yml (e.g., changed cleanup intervals) and reloaded it with /lumr reload, this mechanism ensures tasks use these (potentially less demanding) settings if the server becomes critically low on memory.
Configuration:
- dynamic-adjustment.enabled: Set to true to enable this behavior.
- (Developer Note: The config options dynamic-adjustment.min-cleanup-interval and min-chunk-unload-interval are present in config.yml but appear unused in the v4.3 code. Consider removing them or implementing their functionality to avoid confusion.)

6. Configuration Management

Mechanism: All features are extensively configurable via the plugins/LetUrMemoryRest/config.yml file.
Auto-Update: When you update LetUrMemoryRest to a newer version, the plugin will attempt to automatically add any new configuration options to your existing config.yml file, preserving your current settings.
Commands: /lumr reload applies configuration changes without a server restart. /lumr reset reverts the configuration to the plugin's defaults (deletes config.yml and creates a new one).

7. Server Status & Updates

Status Commands:
- /lumr status: Shows current server RAM usage (Java heap percentage) and the total number of loaded chunks across all worlds.
- /lumr show: Displays the currently active values for most configuration settings.
Update Checker:
- Automatically checks Modrinth for new plugin versions on server startup and can be triggered manually with /lumr update.
- Notifies server operators (or players with leturmemoryrest.admin permission) in-game if an update is found, providing the new version number and a download link. Console is also notified.
- updates.enabled, updates.ignore-alpha, updates.ignore-beta in config.yml control this feature.

Commands:

(Your command list is good, ensure usage matches any changes)

/leturmemoryrest reload (Alias: /lumr reload): Reload the plugin configuration.
/leturmemoryrest reset (Alias: /lumr reset): Reset the plugin configuration to default.
/leturmemoryrest status (Alias: /lumr status): Check current server RAM and chunk status.
/leturmemoryrest free (Alias: /lumr free): Manually trigger an aggressive memory cleanup.
/leturmemoryrest update (Alias: /lumr update): Check for plugin updates from Modrinth.
/leturmemoryrest show (Alias: /lumr show): Display current effective configuration values.

Permissions:

(Your permission list is good)

leturmemoryrest.admin: Access to all plugin commands and receives update notifications.
leturmemoryrest.reload: Allows reloading the configuration.
leturmemoryrest.reset: Allows resetting the configuration.
leturmemoryrest.free: Allows manually triggering aggressive cleanup.
leturmemoryrest.status: Allows checking server status.
leturmemoryrest.update: Allows checking for updates.
leturmemoryrest.show: Allows displaying configuration values.

Installation:

Download the latest version of LetUrMemoryRest from Modrinth.
Place the .jar file in your server's plugins folder.
Restart your server or use a plugin manager to load the plugin.
Review and customize settings in plugins/LetUrMemoryRest/config.yml as needed. Pay special attention to the JVM Note under Memory Management.

Support:

Having issues or need help? Join our Discord server: Join our Discord

Crucial Steps for You (Developer):

Explosion Compatibility (getExplosionResult):
- Verify: Test ExplosionManager on a Spigot/Paper server version older than 1.20.5 (e.g., 1.19.4, 1.16.5, 1.13.2) to see if event.getExplosionResult() causes a NoSuchMethodError.
- Fix if Needed:
  - Use reflection with a try-catch block for getExplosionResult().
  - Or, use try { event.getExplosionResult(); ... } catch (NoSuchMethodError e) { /* fallback for older versions */ }.
  - Or, adjust your api-version in plugin.yml and stated compatibilities if you don't want to support older versions for this specific feature part.
- Update Description: Based on your findings, make the "Compatibility Note" under Explosion Optimization 100% accurate.
Unused Config Options:
- Decide what to do with dynamic-adjustment.min-cleanup-interval and min-chunk-unload-interval.
  - Implement them: Make them actually define minimums if dynamic adjustment reloads tasks.
  - Remove them: From config.yml (default) and ConfigManager.java to avoid user confusion. This is the cleanest if they serve no purpose.
- Update the description's "Dynamic Adjustment" section if you make changes here.
Config Value Clarification:
- For memory.aggressive-cleanup-threshold, ensure its role is distinct from memory.ram-critical-threshold if both trigger aggressive cleanups. The code seems to use ramCriticalThreshold for aggressive cleanup decisions in performMemoryCleanup and aggressive-cleanup-threshold is not directly used there, but getAggressiveCleanupThreshold() exists. Check its usage. If aggressive-cleanup-threshold is for something else or redundant, clarify/remove.