|
| 1 | +# Resource World Auto-Wipe — How It Works |
| 2 | + |
| 3 | +This document explains the design and runtime behaviour of the Resource World Auto-Wipe system. It describes when wipes run, what happens before/during/after a wipe, configuration examples, commands, safety behaviour, backups, and recovery. |
| 4 | + |
| 5 | +## Summary |
| 6 | + |
| 7 | +- Purpose: Automatically reset (wipe) configurable resource worlds on a schedule or on-demand, while taking backups and ensuring player safety. |
| 8 | +- Default strategy: reset-by-template (copy a prepared template world into the resource world folder). The implementation also supports other strategies (e.g., chunk-regeneration) if configured. |
| 9 | +- Backups: pre-wipe compressed snapshots with retention/rotation. |
| 10 | + |
| 11 | +## Core concepts |
| 12 | + |
| 13 | +- Resource world: a world configured to be periodically wiped (e.g. "mining", "islands", "resource_world"). |
| 14 | +- Template world: a pristine world folder used as the source for resets. Kept under the plugin data folder or a configured path. |
| 15 | +- Backup snapshot: a compressed archive of the current world created before a wipe. |
| 16 | +- Scheduler: drives automatic wipes based on human-friendly intervals or cron expressions. |
| 17 | +- WorldManager: component that performs the unload, copy, and reload operations safely (Folia-aware when running on Folia). |
| 18 | + |
| 19 | +## When wipes run |
| 20 | + |
| 21 | +Wipes occur under these triggers (configurable): |
| 22 | + |
| 23 | +- Scheduled automatic wipe: run at configured intervals or cron expression (recommended for predictable resets). |
| 24 | +- Manual wipe: executed immediately via admin command (`/resourcewipe force <world>`). |
| 25 | +- On server start: optionally run a wipe on server startup if enabled in config. |
| 26 | +- Conditional triggers: optional plugin hooks for external criteria (player count, world size) — available via plugin API. |
| 27 | + |
| 28 | +Typical schedule examples: |
| 29 | + |
| 30 | +- Daily at midnight: `0 0 * * *` (cron) or `every 1d at 00:00` (human-friendly form) |
| 31 | +- Weekly on Monday at 04:00: `0 4 * * 1` or `every 7d at 04:00` (depending on config parser) |
| 32 | + |
| 33 | +## High-level wipe workflow |
| 34 | + |
| 35 | +1. Announcement phase |
| 36 | + - When a scheduled wipe is imminent, the system broadcasts configurable countdown messages (action bar/title/chat) at configurable intervals (e.g., 10m, 5m, 1m, 10s). |
| 37 | +2. Prepare players |
| 38 | + - Players currently inside the target world will be teleported to a safe world or spawn (configurable), or optionally moved to spectator mode until the wipe completes. |
| 39 | + - Optionally preserve and store player inventories if configured. |
| 40 | +3. Pause world access |
| 41 | + - The world is locked to prevent new joins while the wipe proceeds. |
| 42 | +4. Create backup (optional but recommended) |
| 43 | + - The BackupManager creates a compressed snapshot (zip) of the world folder and stores it under `plugins/resource-wipe/backups/<worldname>/<timestamp>.zip`. |
| 44 | + - Rotation: only the last `N` snapshots are kept (configurable; default: 7). Older snapshots are removed. |
| 45 | +5. Unload world |
| 46 | + - The plugin uses server APIs and respects Folia dispatchers to safely unload the world. |
| 47 | +6. Reset world |
| 48 | + - Template-copy strategy (default): move or rename the existing world folder out of the active folder and copy the template world folder into place. |
| 49 | + - Alternative strategies (if enabled): chunk regeneration using server APIs to change blocks back to template state. |
| 50 | +7. Load world |
| 51 | + - Load the fresh world and restore spawn, world settings, and any configured metadata. |
| 52 | +8. Post-wipe steps |
| 53 | + - Run optional post-wipe script or hook. |
| 54 | + - Re-allow player access and announce completion. |
| 55 | + |
| 56 | +## Configuration (example) |
| 57 | + |
| 58 | +Place configuration under `plugins/resource-wipe/config.yml` with keys similar to the example below. |
| 59 | + |
| 60 | +```yaml |
| 61 | +# Example config snippet |
| 62 | +resourceWorlds: |
| 63 | + - name: resource_world |
| 64 | + templatePath: templates/resource_world |
| 65 | + wipeSchedule: "0 4 * * *" # cron expression (daily at 04:00) |
| 66 | + backup: true |
| 67 | + retention: 7 |
| 68 | + preserveInventories: false |
| 69 | + teleportTarget: lobby |
| 70 | +announce: |
| 71 | + preWipeSeconds: [600,300,60,10] |
| 72 | + messages: |
| 73 | + - "Resource world will wipe in {time}. Save your stuff!" |
| 74 | +wipe: |
| 75 | + strategy: template-copy # or chunk-regen |
| 76 | + dryRun: false |
| 77 | +safety: |
| 78 | + safeWorld: hub |
| 79 | + teleportPlayers: true |
| 80 | + lockDuringWipe: true |
| 81 | +``` |
| 82 | +
|
| 83 | +Notes: |
| 84 | +- `templatePath` can be relative to the plugin data folder or an absolute path. |
| 85 | +- `wipeSchedule` supports cron expressions and human-friendly intervals when the parser is enabled. |
| 86 | + |
| 87 | +## Commands & permissions |
| 88 | + |
| 89 | +- `/resourcewipe status [world]` — show next scheduled wipe and last wipe details. Permission: `vanilife.resourcewipe.status` (or read default). |
| 90 | +- `/resourcewipe force <world>` — force immediate wipe (requires confirmation or `--force`). Permission: `vanilife.resourcewipe.admin`. |
| 91 | +- `/resourcewipe backup <world>` — create a backup now. Permission: `vanilife.resourcewipe.admin`. |
| 92 | +- `/resourcewipe pause <world>` — pause scheduled wipes for the world. Permission: `vanilife.resourcewipe.admin`. |
| 93 | +- `/resourcewipe resume <world>` — resume scheduled wipes. Permission: `vanilife.resourcewipe.admin`. |
| 94 | + |
| 95 | +Admin command examples: |
| 96 | +- ` /resourcewipe force resource_world --force` |
| 97 | +- ` /resourcewipe status resource_world` |
| 98 | + |
| 99 | +## Safety considerations |
| 100 | + |
| 101 | +- Always enable backups (default) to avoid accidental data loss. |
| 102 | +- Use the template-copy strategy for reliability and speed; ensure template is prepared and tested. |
| 103 | +- When running on Folia, the plugin uses region/world dispatchers and unload/load APIs to avoid cross-thread operations. |
| 104 | +- Use announcements and a configurable grace period to give players time to prepare. |
| 105 | +- Validate free disk space before performing backups or copy operations to avoid partial wipes. |
| 106 | + |
| 107 | +## Failure modes & recovery |
| 108 | + |
| 109 | +- Backup creation failed: the plugin will abort the wipe and re-open the world to players, and log an error. Admin notification will be broadcast. |
| 110 | +- Copy or filesystem error during reset: the plugin will attempt to roll back by restoring the moved world folder (if present) and loading it back; it will then notify admins and keep the world available. |
| 111 | +- Partial load failure: plugin logs error and does not mark wipe as successful; backup remains intact for manual recovery. |
| 112 | + |
| 113 | +Manual recovery steps (if something goes wrong): |
| 114 | +1. Stop the server. |
| 115 | +2. Restore a backup manually by unzipping `plugins/resource-wipe/backups/<world>/<timestamp>.zip` into the server root and renaming to the world folder name. |
| 116 | +3. Start the server and verify. |
| 117 | + |
| 118 | +## Storage & retention |
| 119 | + |
| 120 | +- Backups default to `plugins/resource-wipe/backups` and are compressed to save space. |
| 121 | +- Default retention: keep the most recent 7 backups per world; older files are deleted automatically. |
| 122 | +- For larger deployments consider offloading backups to remote storage (S3) via custom post-backup hook or an integration; this is not enabled by default. |
| 123 | + |
| 124 | +## Notifications & logs |
| 125 | + |
| 126 | +- The plugin logs operations to the server log at INFO level; failures are logged at ERROR. |
| 127 | +- Admins may opt-in for more verbose debug logs in `config.yml`. |
| 128 | +- Broadcast messages are configurable and support placeholders (e.g., `{world}`, `{time}`, `{remaining}`). |
| 129 | + |
| 130 | +## Recommended defaults |
| 131 | + |
| 132 | +- Strategy: `template-copy` |
| 133 | +- Backups: enabled, retention 7 |
| 134 | +- Pre-wipe announcements: `[600,300,60,10]` seconds |
| 135 | +- Teleport players to a safe world named `hub` or `lobby` |
| 136 | + |
| 137 | +## FAQ |
| 138 | + |
| 139 | +Q: Can players keep their inventories across wipes? |
| 140 | +A: Yes — enable `preserveInventories: true` in the world config. The plugin will save inventories and attempt to restore them after the wipe for safety. This can be storage/time intensive. |
| 141 | + |
| 142 | +Q: How long does a wipe take? |
| 143 | +A: Depends on world size and storage speed. A template-copy for a few hundred MB may take seconds to a minute; backups add time proportional to world size and compression settings. |
| 144 | + |
| 145 | +Q: Can I test a wipe without affecting players? |
| 146 | +A: Use `dryRun: true` to simulate the wipe process (no filesystem changes). You can also run backups only with `/resourcewipe backup <world>`. |
| 147 | + |
| 148 | +## Where to find the docs |
| 149 | + |
| 150 | +- This file: `docs/resource-wipe.md` |
| 151 | +- Plugin data folder runtime examples: `plugins/resource-wipe/config.yml` and `plugins/resource-wipe/backups` |
| 152 | + |
| 153 | +--- |
| 154 | + |
| 155 | +If you want, I can now: |
| 156 | +- Create an initial `plugins/plugin-resourcewipe` skeleton with `plugin.yml` and `config.yml` example. |
| 157 | +- Implement the BackupManager or WorldManager next. |
| 158 | + |
| 159 | +Which would you like me to do next? |
0 commit comments