Operator wiki

Getting started

ResourceWorldResetter schedules and coordinates resource-world regeneration. It evacuates players, invokes the installed world provider, verifies the result, and records a terminal history entry.

Spigot / CraftBukkit installation

1. Install Multiverse-Core 5.8.0+.
2. Confirm every intended resource world already exists in Multiverse-Core.
3. Place RWR-Spigot-5.1.0.jar in plugins/.
4. Remove any Paper/Folia RWR artifact and restart fully.
5. Configure worlds using the plain legacy name reported by Multiverse-Core.

Multiverse-Core is a hard dependency for this artifact. RWR delegates regeneration to its API; RWR does not directly delete world folders.

Paper, Purpur, and Folia installation

1. Install Worlds by TheNextLvl 4.4.0+.
2. Confirm intended resource dimensions are registered in Worlds.
3. Place RWR-Paper-Folia-5.1.0.jar in plugins/.
4. Remove the Spigot RWR artifact and restart fully.
5. Use the Worlds key detected by the admin GUI, such as worlds:resource.

Do not install Multiverse-Core for RWR on this platform. The Paper/Folia artifact uses Worlds and Folia-safe schedulers. Player evacuation is asynchronous and does not block the global-region thread.

Configuration model

v5 requires config-version: 5. A reload is transactional: invalid input is rejected while the previous active settings and schedules remain in service.

worlds:
  rainforest:
    multiverse-world: rainforest
    display-name: "Rainforest"
    enabled: true
    managed: true
    schedule:
      type: DAILY
      time: "03:00"
    warning-minutes: [30, 10, 5, 1]
    regeneration:
      seed-policy: RANDOM
      keep-world-config: true
      keep-gamerules: true
      keep-world-border: true
    evacuation:
      enabled: true
      destination: world

Command reference

Permissions

These nodes are registered in both platform artifacts. Destination-specific access is configured per teleport entry rather than as a second static plugin node.

Leave a destination permission blank to make it public to anyone with rwr.tp. Set it to any Bukkit node (for example a LuckPerms group) to restrict that destination. Operators with rwr.teleport.world.* still see and use locked destinations.

Reset phases and safety

Schedules and warnings

Supported types are daily, weekly, monthly, and interval. Calendar schedules use the configured timezone. Warning values are whole minutes and are deduplicated before scheduling.

• After editing schedules manually, run /rwr reload.
• Confirm the calculated next schedule with /rwr status.
• Use an empty warning list when countdown broadcasts are unwanted.
• Shutdown cancels one-shot reset and warning tasks; schedules are reconstructed on normal startup.

Evacuation and teleport protection

The destination must resolve to a loaded, safe location. A disabled or unavailable destination stops the reset safely while players remain.

• Spigot performs synchronous Bukkit teleports on its server thread.
• Paper uses its safe primary-thread path without waiting on teleportAsync.
• Folia begins entity-region asynchronous teleports and resumes the reset from the global scheduler only after completion.
• Regeneration is never invoked while the remaining-player count is non-zero.

Admin and player GUIs

The administration dashboard supports managed-world setup, global settings, teleport configuration, history, and guarded confirmations. The player GUI discovers eligible provider worlds without loading them, paginates destinations, shows player counts, respects custom permissions, and blocks unsafe access during resets.

If anvil text input is unavailable, RWR falls back to chat input. GUI changes pass through the same configuration validation and persistence path as manual edits.

Interrupted and failed operations

1. Read /rwr status and /rwr history 10.
2. Inspect the server log and reset-history.json.
3. Verify the provider reports the expected world identity and loaded state.
4. Confirm no players remain in the managed world.
5. Retry only when the result says safe to retry. Review ambiguous outcomes manually.

RWR intentionally does not auto-repeat an interrupted regeneration. Repeating an operation whose provider outcome is unknown can destroy valid world state.

Migration from v4.2.1 or earlier

v4.2.1 is the final legacy maintenance release. v5 does not automatically load v4 configuration.

1. Back up worlds and the complete legacy plugin folder.
2. Choose the v5 artifact and provider matching the server platform.
3. Remove the v4 JAR; never run both generations together.
4. Start v5 once to generate config-version: 5.
5. Manually recreate stable world IDs, provider identities, display names, schedules, warning minutes, evacuation destinations, and teleport permissions.
6. Run a supervised reset before enabling unattended schedules.

Read the complete Operations & Migration guide →

Troubleshooting

Frequently asked questions

Does Paper/Folia use Multiverse-Core?

No. It requires Worlds by TheNextLvl. Multiverse-Core belongs to the Spigot/CraftBukkit artifact.

Should I install rwr-core?

No. It is shaded into both platform JARs.

Can v5 load my v4 config?

No. Migrate values manually into a fresh v5 configuration.

Does RWR delete world folders itself?

No. It delegates the authoritative regeneration operation to the selected provider and independently verifies the outcome.

Can I hot reload the plugin?

No. Replace JARs and platform dependencies only while stopped, then perform a full restart.

Report a useful problem

Open a GitHub issue and include:

• Complete logs/latest.log, not only the final exception
• Exact server build and Java version
• Exact RWR artifact filename
• World-provider name and version
• Relevant configuration with secrets removed
• The command, scheduled event, or GUI action that triggered the issue