Apply a Paper setting to one world using inheritance

Paper separates settings shared by worlds from settings overridden for one world or dimension. Editing a shared default can change more than you intended, while editing an unused file can change nothing. Use a minimal override when a single world needs a different supported behaviour.

Map the installed layout

Record the exact Paper build and world or dimension you intend to change. Open the configuration reference for that release. Current documentation describes config/paper-world-defaults.yml and per-dimension paper-world.yml files under paths such as world/dimensions/<namespace>/<key>/. Earlier versions, including 1.21.11 layouts, can organise dimensions differently. Inspect generated files rather than creating a guessed current-version path.

Download both the shared defaults and the target world's existing override. Also inspect spigot.yml if the option belongs to its world-settings section. A Spigot setting does not move into Paper's world file simply because it affects a world. Establish the correct configuration owner before editing.

Understand inheritance

A minimal world file can contain little more than its version marker. Missing supported options inherit from the shared Paper defaults; that does not necessarily mean they are disabled. If the option already appears in the world override, that local value can explain why changing the shared default had no effect there.

Choose one documented setting and write down its effective old value, expected new behaviour and rollback. Avoid copying the entire shared defaults file into the override. A large copy hides which differences were intentional and can prevent future shared adjustments from reaching that world. Leave the generated _version marker unchanged.

Add the smallest override

Announce a restart and stop the server cleanly. Add the setting under its correct parent sections in the existing world file, using spaces and the documented value type. Merge with existing sections instead of duplicating the same top-level key. Check the diff against your downloaded copy before starting again.

Use a low-risk behaviour test related to your chosen option. Do not trial destructive settings, chunk resets or entity save limits as a first exercise in inheritance. If your goal is Anti-Xray or autosave, follow that feature's dedicated instructions after establishing the correct scope.

Verify scope, not just startup

Start the server and inspect for parsing or migration warnings. Test the chosen behaviour inside the target world. Then visit a second world that should retain its previous behaviour. A clean startup confirms that the file was accepted, but only this comparison checks that your change stayed within the intended scope.

Record both observations, including any plugin that may override the result. If the setting appears ineffective, recheck the exact dimension and path before adding a second copy elsewhere. Multiverse-style plugin names and on-disk world names may not be identical.

Return to the default

To remove the exception, stop the server, remove only the override entry you added and restart. The setting should inherit again from the current shared defaults. Restore the downloaded file if the edit was malformed. Keep all world data intact and preserve a note explaining why the exception existed.

Related help

• Back up game files before making changes
• Find Minecraft logs and send useful troubleshooting details
• Update Paper, Purpur and plugins safely

Reference

Paper configuration inheritance and paths. Paper world settings. Inherited Spigot world settings.