Troubleshooting
World not recognised after renaming the world folder manually
Blueprint tracks worlds by the folder name stored in its SQLite database. Renaming a world folder outside of Blueprint will cause it to become unrecognised.
Resolution: Do not rename world folders manually. Use /blueprint clone <source> <target> to duplicate a world under a new name, then delete the old one with /blueprint delete.
/blueprint clone fails with "world must be closed"
Blueprint requires the source world to be unloaded before cloning to ensure file consistency.
Resolution: Run /blueprint close <world> before cloning.
/blueprint snapshot restore fails with "world must be closed"
The same constraint applies to restores — the world must be unloaded so Blueprint can safely replace its files.
Resolution: Run /blueprint close <world> before restoring.
Server freezes during world creation or clone
Blueprint operations run asynchronously. If the server is still freezing, the bottleneck is likely disk I/O rather than the plugin itself.
Resolution: Check disk throughput and consider moving your world storage to faster storage (e.g. NVMe SSD). Large worlds on spinning disks will cause noticeable delays regardless of async handling.
Snapshots are consuming too much disk space
Each snapshot is a full copy of the world. High disk usage is expected if worlds are large or many snapshots are kept.
Resolution: Prune old snapshots regularly with /blueprint snapshot delete. Consider lowering max-snapshots-per-world in config.yml to make the limit more visible.
"World name does not match pattern" on create or clone
Blueprint validates world names against the world-name-pattern regex in config.yml.
Resolution: Use only alphanumeric characters, underscores, and hyphens in world names, or update world-name-pattern to match your naming convention.