Direct answer

YAML configuration files use indentation to describe nested settings. Edit the YAML file for the relevant plugin, not plugin.yml inside its JAR. Spaces, colons, quotes and data types all matter.

Recommended procedure

  1. Stop the server or follow the plugin’s documented reload procedure, then save a copy of the original config.yml.
  2. Use spaces consistently for indentation; never insert tabs. Keep sibling keys at the same indentation level.
  3. Write a mapping such as messages: followed by enabled: true. Use - for list entries and quote strings containing a colon followed by a space.
  4. Do not confuse true with "true" or 10 with "10"; some plugins require a specific data type.
  5. Validate the YAML syntax, then restart or use only the plugin’s documented config reload command. Read startup errors with their line numbers.

Why this matters

A syntactically valid YAML file can still be rejected if a key is misspelled, under the wrong section or uses the wrong value type. Plugin defaults and available keys change between releases.

Practical example: Example: worlds: followed by survival: true creates a nested mapping. worlds: true is a different data type, and worlds: followed by an unindented survival: true is a different structure. A YAML checker can catch broken indentation, but only the plugin documentation can confirm whether worlds.survival is a supported key.

How to verify the result

  • Check for parser errors such as mapping values are not allowed or found character TAB.
  • Confirm the plugin acknowledges the selected feature rather than silently falling back to defaults.
  • If behavior is wrong, restore the saved file and compare against the configuration generated by your installed plugin version.

Version and compatibility notes

  • Never edit a packaged JAR to change its external configuration.
  • Do not paste unverified settings from another plugin or version.

Official references

These sources were checked for the current MSH revision. Version-sensitive details should always be confirmed against the project documentation for the release you run.

Was this article helpful?
Help us improve this article

Tell us what is missing, unclear, outdated, or incorrect. You can also suggest something we should add.

What could we improve?
Do not include passwords, server IPs, or other private information.0 / 1000