AEONHOST / WISSEN

Paper-Konfigurationsdateien und Welt-Overrides zuordnen

Bei Paper gibt es keine allgemeine Regel, nach der einfach die zuletzt gelesene Konfigurationsdatei gewinnt. Jede Datei hat einen eigenen Aufgabenbereich; nur ausdrücklich unterstützte Einstellungen können eine Welt- oder Standardvorgabe überschreiben. Prüfe deshalb zuerst den genauen Namen der Einstellung und danach den passenden Pfad für deine Paper-Version.

Aktualisiert am 07.10.2026

Bei Paper gibt es keine allgemeine Regel, nach der einfach die zuletzt gelesene Konfigurationsdatei gewinnt. Jede Datei hat einen eigenen Aufgabenbereich; nur ausdrücklich unterstützte Einstellungen können eine Welt- oder Standardvorgabe überschreiben. Prüfe deshalb zuerst den genauen Namen der Einstellung und danach den passenden Pfad für deine Paper-Version.

Welche Datei passt?

Datei Aufgabe Weltbezug
server.properties Java-Servereinstellungen wie MOTD und Verbindung Im Regelfall serverweit; einzelne Paper-Einstellungen können an anderer Stelle eigene Overrides haben.
config/paper-global.yml Paper-Einstellungen, die für den Server insgesamt gelten Keine allgemeine Welt-Override-Ebene.
config/paper-world-defaults.yml Standardwerte für Paper-Einstellungen, die pro Welt gesetzt werden können Gilt für Welten ohne eigenen Wert.
paper-world.yml Abweichende Paper-Einstellungen einer einzelnen Welt Nur eingetragene unterstützte Schlüssel überschreiben den Paper-Standard.
bukkit.yml Bukkit-Einstellungen, zum Beispiel Spawn-Limits Bestimmte Werte können laut Paper-Referenz durch die Paper-Weltkonfiguration ersetzt werden.
spigot.yml Spigot-Einstellungen und manche Weltwerte Unterstützte Werte verwenden world-settings.default und einen optionalen Eintrag für den Ordnernamen der Welt.

Paper ordnet paper-global.yml im Ordner config/ ein. In der aktuellen Referenz liegt paper-world-defaults.yml ebenfalls dort; eine einzelne Welt erhält ihre Abweichungen in paper-world.yml im Weltordner. Die dokumentierte aktuelle Struktur verwendet dafür zum Beispiel world/dimensions/<namespace>/<key>/paper-world.yml. Prüfe den tatsächlichen Pfad in der Dokumentation, die zu deinem laufenden Paper-Build gehört: ältere Versionen und andere Forks können die Dateien anders anordnen. Die Paper-Konfigurationsübersicht zeigt die Dateien und Weltpfade.

Die Standardpfade gelten nur, wenn der Startbefehl keine anderen Dateien auswählt. Paper kann mit -c beziehungsweise --config eine andere server.properties laden, mit -b oder --bukkit-settings eine andere bukkit.yml, mit -S oder --spigot-settings eine andere spigot.yml und mit --paper-dir ein anderes Paper-Konfigurationsverzeichnis verwenden. -w oder --world setzt den Weltnamen; -W oder --world-dir ändert den übergeordneten Weltordner. Prüfe diese Angaben im Startprofil oder Panel, bevor du eine Datei bearbeitest. Paper dokumentiert zudem, dass Startoptionen, die direkte Gegenstücke zu Einträgen in server.properties sind, den dort gespeicherten Wert übersteuern. Das ist eine konkrete Regel für diese Gegenstücke, keine Rangfolge aller Konfigurationsdateien. Paper listet die Startoptionen, ihre Standardpfade und das Vorrangverhalten.

--paper beziehungsweise --paper-settings ist der Pfad zur alten Paper-Konfiguration (Standard: paper.yml) und laut Paper nur für deren Migration ins neue Format vorgesehen, nicht für neue Server. Behandle _version in paper-world.yml und interne config-version-Felder nicht als frei wählbare Versionsnummern.

So greifen die Paper-Overrides ineinander

Bei Paper erben Welten zunächst die Einstellungen aus paper-world-defaults.yml. Eine einzelne paper-world.yml ändert nur die Schlüssel, die du dort ausdrücklich einträgst. Alles andere bleibt vom Standard übernommen. Die Datei pro Welt enthält standardmässig nur die Versionsmarkierung _version; kopiere nicht den vollständigen Default-Block in jede Welt. So bleibt sichtbar, welche Abweichung wirklich gewollt ist. Paper beschreibt diesen Vererbungsweg samt Beispiel.

Auch Bukkit-Werte können in dieser Kette liegen: Die Paper-Referenz nennt spawn-limits in bukkit.yml und weist darauf hin, dass die Paper-Weltkonfiguration diese Werte überschreiben kann. Bei spigot.yml legst du für unterstützte Optionen einen Schlüssel unter world-settings mit dem Level-Namen der Welt an. Ein Eintrag für die konkrete Welt ist dort die gezielte Abweichung zur Vorgabe default. Das ist eine Einstellung für diese dokumentierten Schlüssel, kein Vorranggesetz für sämtliche Dateien. Die Paper-Referenzen zu bukkit.yml und spigot.yml nennen diese Ausnahmen und Welt-Overrides.

Ein bekanntes Beispiel ist view-distance: Paper kann dafür Werte in spigot.yml je Welt vorsehen. Die einzelnen Werte, Rückfallregeln und die getrennte simulation-distance erklärt die Anleitung zu Sichtweite und Simulationsdistanz. Dieser Beitrag geht nur auf den Pfad und die Herkunft eines Werts ein.

Den wirksamen Wert sicher finden

  1. Version und Instanz feststellen. Notiere Java oder Bedrock, Paper oder einen Fork, die genaue Serverversion und den verwendeten Weltordner. Eine Datei aus einem alten Testordner ändert nicht die aktive Instanz.
  2. Den vollständigen Einstellungspfad notieren. Schreibe den Schlüssel mit Abschnitt auf, zum Beispiel entities.spawning.spawn-limits.monster. Suche genau diesen Pfad in der Dokumentation deiner Server-Version. Nicht jede Option aus paper-global.yml darf pro Welt verändert werden.
  3. Nur die dazugehörige Ebene vergleichen. Bei einer Paper-Weltoption liest du erst den Eintrag in paper-world-defaults.yml, dann denselben Schlüssel in der paper-world.yml der betroffenen Welt. Bei einer spigot.yml-Option vergleichst du world-settings.default mit dem Eintrag für genau den Weltordner. Prüfe weitere Dateien nur, wenn die passende Referenz sie ausdrücklich nennt.
  4. Vor einer Änderung den Rückweg sichern. Stoppe den Server sauber und sichere die betroffenen Konfigurationsdateien. Ändere eine Einstellung an der dokumentierten Stelle. Lass _version- oder config-version-Felder unverändert und übernimm keine vollständige Beispielkonfiguration aus einer anderen Paper-Version.
  5. Nach dem Start gezielt prüfen. Kontrolliere die Startausgabe auf YAML- oder Versionshinweise und prüfe die Funktion dort, wo der Wert wirken soll. Wenn sich nichts ändert, prüfe zuerst den aktiven Ordner, den exakten Schlüssel und die richtige Welt. Stelle die gesicherte Datei wieder her, wenn der Server nach der Änderung nicht korrekt startet.

Ein häufiger Irrtum ist, einen Wert in server.properties zu ändern und anzunehmen, dass er überall gilt. Paper- oder Spigot-Optionen können für unterstützte Einstellungen einen präziseren Wert liefern. Umgekehrt überschreibt eine Datei nicht automatisch jede gleichnamige Einstellung in einem anderen System. Wenn du nur die einfache Textdatei bearbeiten musst, hilft Minecraft server.properties richtig bearbeiten. Bei einem anschliessenden Startfehler findest du einen eigenen Ablauf unter Minecraft-Server startet nicht.

Quellen