Inhaltlich aktualisiert:
In dieser Anleitung
- Paper oder Fabric: Die benötigten Erweiterungen entscheiden
- Vergleich nach Funktionen statt nach Etiketten
- Wann Paper gut zu deinem Projekt passt
- Wann Fabric die passendere Grundlage ist
- Client und Server bewusst getrennt auswählen
- Schritt 1: Versions- und Laufzeitplan erstellen
- Schritt 2: Paper-Server mit Plugins aufbauen
- Schritt 3: Fabric-Server mit Mods aufbauen
- Leistung fair vergleichen
- Sichtweite, Farmen und technische Mechaniken prüfen
- Bestehende Welt zwischen Paper und Fabric übernehmen
- Typische Irrtümer und Reparaturwege
- Betrieb, Updates und Entscheidung überprüfen
- Quellen und praktische Abschlussprüfung
Paper oder Fabric: Die benötigten Erweiterungen entscheiden
Wähle Paper, wenn deine Serverfunktionen aus dem Paper-/Bukkit-/Spigot-Plugin-Ökosystem kommen. Wähle Fabric, wenn du Fabric-Mods einsetzen möchtest. Beide Grundlagen können für private Java-Runden geeignet sein, aber sie führen unterschiedliche Erweiterungen aus. Eine pauschale Aussage „Paper ist immer schneller“ oder „Fabric ist immer leichter“ hilft bei der konkreten Auswahl nicht.
Die Entscheidung in drei Fragen: Welche Erweiterungen sind unverzichtbar? Müssen Spieler zusätzliche Clientdateien installieren? Wie wichtig ist euch die genaue Vanilla-Mechanik eurer Farmen und technischen Bauten? Erst danach vergleichst du die Leistung des passenden Setups unter eurer tatsächlichen Last.
Paper ist auf dieser Seite vorausgewählt. Diese Auswahl lässt sich anpassen, wenn deine Anforderungen zu Fabric führen. Die Anleitung erklärt beide Wege, ihren ersten Start, sinnvolle Leistungstests und die Grenzen eines späteren Softwarewechsels.
Vergleich nach Funktionen statt nach Etiketten
Paper ist eine Minecraft-Java-Serversoftware mit Plugin-Unterstützung und eigenen Optimierungen beziehungsweise Einstellungen. Fabric ist ein Modloader für passende Fabric-Mods. Welche Funktionen daraus entstehen, hängt von der tatsächlich installierten Erweiterung und deren Environment ab.
| Entscheidungspunkt | Paper | Fabric |
|---|---|---|
| Paper-/Bukkit-/Spigot-Plugins | Passende Plugins des unterstützten Ökosystems | Kein direkter normaler Pluginweg |
| Fabric-Mods | Keine direkte Fabric-Modunterstützung | Passende Fabric-Mods mit ihren Abhängigkeiten |
| Normale Vanilla-Clients | Für reguläre serverseitige Pluginfunktionen geeignet | Bei kompatiblen rein serverseitigen Mods möglich |
| Neue Modinhalte auf beiden Seiten | Kein Ersatz für den verlangten Modloader | Passende Client-Modinstallation erforderlich |
| Leistung | Eigene Optimierungen und Konfigurationen | Konkrete Mods, Einstellungen und Last entscheiden |
| Technische Vanilla-Bauten | Änderungen und relevante Einstellungen prüfen | Auch hier konkrete Mods und deren Änderungen prüfen |
Die Paper-Dokumentation zur Migration benennt die Modgrenze ausdrücklich. Die Fabric-Dokumentation zur Modinstallation erklärt die nötige Übereinstimmung von Version, Loader und Abhängigkeiten. Ein Dateiname mit .jar entscheidet nicht, zu welcher Plattform eine Erweiterung gehört.
Prüfe außerdem, ob deine gewünschte Erweiterung überhaupt für deine Spielversion verfügbar ist. Eine vorhandene ältere Version bedeutet keine Unterstützung der neuesten Minecraft-Ausgabe. Plane den gemeinsamen kompatiblen Stand, bevor ihr eine Welt beginnt.
Wann Paper gut zu deinem Projekt passt
Paper bietet sich an, wenn du typische Serverfunktionen über Plugins einrichten möchtest: etwa abgestufte Rechte, geschützte Grundstücke oder Verwaltungsfunktionen. Wähle die konkrete Erweiterung anhand ihrer unterstützten Plattform und Version. Der Servertyp allein installiert diese Funktionen noch nicht.
Für eine Gruppe mit normalen Java-Clients kann dieser Weg praktisch sein, weil serverseitige Plugins häufig keine zusätzliche Clientinstallation verlangen. Prüfe dennoch die Anforderungen der einzelnen Funktion. Ein Plugin kann beispielsweise ein Ressourcenpaket oder zusätzliche Clientfunktionen voraussetzen; „Plugin“ bedeutet nicht automatisch völlig voraussetzungsfreie Darstellung.
Paper verfügt über umfangreiche Einstellungen. Ändere sie nicht als pauschales Tuningpaket aus einem fremden Tutorial. Manche Optionen beeinflussen Spielverhalten, Entitäten oder Farmen. Für eine einfache Runde ist ein nachvollziehbarer Ausgangsstand hilfreicher als eine Sammlung unbekannter Optimierungen.
Wenn dein Projekt von einer bestimmten Vanilla-Mechanik abhängt, baue einen kleinen Funktionstest. Prüfe diese Mechanik auf dem tatsächlichen Paper-Stand und mit den vorgesehenen Einstellungen. Eine theoretische Softwarebeschreibung ersetzt nicht die Abnahme eures konkreten Baus.
Wann Fabric die passendere Grundlage ist
Fabric passt, wenn du konkrete Fabric-Mods verwenden möchtest. Das kann neue Inhalte, serverseitige Funktionen oder gezielte technische Änderungen umfassen. Die gewünschte Mod bestimmt ihre Minecraft-Version und benötigten Abhängigkeiten; ein beliebiger Loaderstand genügt nicht automatisch.
Viele Fabric-Mods benötigen Fabric API. Diese API ist eine zusätzliche Mod, während Fabric Loader die Ladegrundlage ist. Prüfe beides in der Projektbeschreibung. Ein Fehler über eine fehlende API ist kein Anlass, den Server auf Paper umzuschalten.
Ob deine Freunde Mods installieren müssen, hängt vom Environment der gewählten Mods ab. Rein serverseitige kompatible Mods können Vanilla-Clients erlauben. Mods mit eigenen Clientinhalten benötigen eine passende Clientinstallation. Ein Shader oder eine Minimap auf dem Client beweist dagegen nicht, dass auch der Server Fabric benötigt.
Fabric ist kein Versprechen für unveränderte Vanilla-Mechanik. Jede installierte Mod kann Verhalten ändern. Wenn euch technische Farmen wichtig sind, dokumentiert die Modliste und testet eure benötigten Mechaniken. Ein genauer, kleiner Modsatz lässt sich besser beurteilen als eine ungeprüfte Sammlung mit vielen Optimierungsversprechen.
Client und Server bewusst getrennt auswählen
Ein Spieler kann einen Fabric-Client für lokale Verbesserungen nutzen und damit auf einem normalen Server spielen, sofern seine Mods dies erlauben. Daraus folgt nicht, dass der Server dieselben Clientmods braucht. Umgekehrt kann eine serverseitige Inhaltsmod einen bestimmten Client verlangen.
| Beispielanforderung | Was daraus folgt |
|---|---|
| Nur lokale Darstellung oder Shader | Client-Anforderungen prüfen; Serverloader nicht allein deshalb ändern |
| Serverseitige Rechte über ein Paper-Plugin | Paper-Weg und Pluginanforderungen prüfen |
| Fabric-Mod mit neuen Blöcken | Server und passende Clients nach Projektvorgabe vorbereiten |
| Rein serverseitige kompatible Fabric-Mod | Vanilla-Clientfähigkeit ausdrücklich prüfen |
| Java und Bedrock gemischt | Geeigneten Geyser-Weg gesondert prüfen; nicht jede Mod wird dadurch kompatibel |
Bei Crossplay kann eine unterstützte Geyser-Installation Bedrock-Verbindungen zu einem Java-Server vermitteln. Eigene Java-Client-Modinhalte werden dadurch nicht allgemein für Bedrock verfügbar. Ein normales Paper-Pluginsetup und ein umfangreiches Fabric-Inhaltspack sind deshalb unterschiedliche Crossplay-Fragen.
Für die Planung schreibst du eine Liste unverzichtbarer Funktionen und ihrer konkreten Projekte. Ordne sie dem jeweiligen Softwareweg zu. Wenn sich die Liste auf beide Plattformen verteilt, prüfe Alternativen oder priorisiere die Funktionen; eine zufällige Hybridinstallation ist keine verlässliche Lösung.
Schritt 1: Versions- und Laufzeitplan erstellen
Notiere Minecraft-Version, Paper-Build beziehungsweise Fabric-Loader-Version, Erweiterungen und benötigte Java-Laufzeit. Prüfe die aktuellen Anforderungen der genauen Version. Eine Laufzeitempfehlung aus einer älteren Anleitung gilt nicht automatisch für eine aktuelle Minecraft-Ausgabe.
Paper dokumentiert seine Laufzeitanforderungen im Getting-started-Leitfaden. Dort unterscheidet die aktuelle Tabelle unter anderem die Versionen bis 1.21.11 von 26.1 und neuer. Verwende die zu deinem tatsächlich gewählten Stand gehörende Java-Version statt aus einer pauschalen „Java 21“-Anleitung eine allgemeine Regel abzuleiten.
Für Fabric prüfst du den Minecraft-Stand, Loader und Anforderungen der Mods zusammen. Der geforderte Stand einer wichtigen Mod kann eure Auswahl begrenzen. Wenn mehrere unverzichtbare Erweiterungen keine gemeinsame kompatible Version haben, löst du die Auswahl vor der Installation.
Bei einer vorhandenen Welt hältst du zunächst deren bisherigen Stand fest. Softwarewechsel und Minecraft-Versionswechsel sind getrennte Änderungen. Ein unveränderter Import mit späterem kontrolliertem Upgrade ist leichter zu prüfen als ein gleichzeitiger Wechsel aller Grundlagen.
Schritt 2: Paper-Server mit Plugins aufbauen
Wähle Paper im Konfigurator und gleiche die Minecraft-Version mit dem Plan ab. Starte zunächst die Basis, prüfe die Konsole und stoppe den Server vollständig, bevor du Plugin-Dateien ergänzt. Verwende die für deine Plattform vorgesehene Installation.
- Plugin aus seiner offiziellen Distribution für den passenden Serverstand auswählen.
- Notwendige Abhängigkeiten ebenfalls prüfen und herunterladen.
- Passende JAR in den
plugins-Ordner der Serverinstallation übertragen. - Alte ersetzte Pluginversion aus dem aktiven Ordner nehmen, nachdem sie gesichert ist.
- Server neu starten und die Plugin-Ladeausgabe prüfen.
- Funktion und gewünschte Berechtigungen mit einem normalen Spielerkonto testen.
Die Paper-Anleitung zum Installieren von Plugins beschreibt diesen Weg und typische Ladefehler. Installiere keine Fabric-Mod in diesen Ordner und erwarte eine Umwandlung. Ein ZIP-Archiv muss gegebenenfalls erst die richtige Plugin-JAR freigeben.
Gib nicht allen Spielern OP, damit ein Plugin „endlich funktioniert“. Prüfe die vorgesehenen Berechtigungen und nutze einen gezielten Rechteweg. Ein erfolgreicher Test mit einem Administrator beweist nicht, dass normale Spieler die gewünschte Funktion benutzen können.
Schritt 3: Fabric-Server mit Mods aufbauen
Wähle Fabric und die passende Minecraft-Version. Prüfe einen ersten Grundstart, stoppe anschließend und ergänze die vorgesehenen Servermods. Verwende den mods-Ordner der tatsächlichen Serverinstallation; der Clientordner auf deinem Rechner ist ein anderer Ort.
- Moddatei für Fabric und die exakte Spielversion auswählen.
- Abhängigkeiten, insbesondere eine gegebenenfalls benötigte Fabric API, abgleichen.
- Nur die für den Server vorgesehenen Komponenten hochladen.
- Doppelte alte Versionen aus dem aktiven Ordner entfernen, nachdem sie gesichert sind.
- Kontrolliert starten und den ersten konkreten Ladefehler beziehungsweise den Erfolg prüfen.
- Mit dem geforderten Clientprofil beitreten und die Modfunktion testen.
Bei Mods mit Clientanteil verteilst du einen eindeutigen Installationsstand an die Gruppe. Bei einem vollständigen Pack verwendest du dessen eigenen Server- und Client-Release. Ein zufällig ähnlicher Modsatz ist kein reproduzierbares Pack.
Ergänze neue Mods einzeln oder in einer klar zusammengehörenden Gruppe. Wenn eine Änderung fehlschlägt, kannst du zum vorherigen Stand zurückkehren. Entferne Inhaltsmods aus einer wichtigen Welt nicht bloß zur Fehlersuche und starte dann weiter; teste gegebenenfalls mit einer neuen Testwelt oder einer Kopie.
Leistung fair vergleichen
Ein sinnvoller Vergleich verwendet eine vergleichbare Welt, denselben Minecraft-Stand, dieselbe Lastsituation und nachvollziehbare Einstellungen. Zwei leere Server mit unterschiedlichen Sichtweiten liefern keinen belastbaren Sieger für eure spätere Survival-Runde.
Unterscheide Tickverarbeitung, Speicherbedarf, Netzwerklatenz und Client-Bildrate. Ein Spieler mit niedrigem FPS-Wert misst nicht automatisch die Serverleistung. Wenn alle zeitgleich beim Abbauen zurückgesetzt werden oder Mobs stocken, ist eine serverseitige Prüfung naheliegend.
Für die normale Spielsimulation sind 20 Ticks pro Sekunde das Ziel; dafür steht ungefähr ein Zeitbudget von 50 Millisekunden pro Tick zur Verfügung. Die Paper-Befehlsdokumentation beschreibt TPS und MSPT. Ein gemittelter Wert kann einzelne Lastspitzen verbergen, deshalb gehören Beobachtung und Profil der problematischen Situation zusammen.
Paper beschreibt den mitgelieferten spark-Profiler in seiner Profiling-Anleitung. Auf einem unterstützten Paper-Stand kannst du beispielsweise im Spiel mit passender Berechtigung eine zeitlich begrenzte Aufnahme starten:
/spark profiler start --timeout 600
Das ist kein universeller Befehl für jede Fabric-Installation. Dort braucht ein Profiler eine passende Distribution und Unterstützung deiner Version. Zeichne die echte Problemphase auf und teile Berichte nur nach Prüfung auf private Informationen.
Sichtweite, Farmen und technische Mechaniken prüfen
Eine hohe Sichtweite lädt mehr sichtbare Weltbereiche. Die Simulationsweite beeinflusst die aktive Simulation. Beide Einstellungen müssen zur Welt und Spielerzahl passen. Senke einen auffällig hohen Wert kontrolliert und vergleiche denselben Abschnitt, statt ein fremdes Komplettprofil zu übernehmen.
Für technische Projekte prüfst du Farmen, Redstone, Entitäten und verwendete Dimensionswechsel gezielt. Paper und Mods können auf diesen Ebenen Verhalten beeinflussen. Eine Aussage über „Vanilla-Nähe“ ist für euren Bau erst hilfreich, wenn dessen benötigte Mechanik auf dem tatsächlichen Stand funktioniert.
Bei einer Leistungskorrektur geht es um die Ursache: neue Chunks, übermäßige Entitäten, eine Erweiterung oder bestimmte aktive Gebiete. Mehr RAM kann einen Speicherengpass lösen, aber keine beliebige Ticklast beseitigen. Ein Loaderwechsel allein ist ebenfalls kein garantierter Fix.
Haltet die bewussten Änderungen fest. Wenn eine Farm danach anders arbeitet, könnt ihr erkennen, welche Einstellung oder Mod zuletzt verändert wurde. Für ein großes technisches Projekt ist diese Dokumentation oft wertvoller als eine vermeintlich allgemein „beste“ Serverkonfiguration.
Bestehende Welt zwischen Paper und Fabric übernehmen
Ein Softwarewechsel erfordert eine vollständige Sicherung und eine zur Version passende Anleitung. Prüfe zuerst, ob die Welt Modinhalte enthält. Paper kann solche Fabric-Inhalte nicht einfach laden; neue Blöcke, Gegenstände und Dimensionsdaten können ohne ihre Mods unbrauchbar sein.
Auch die Weltordnerstruktur ist versionsabhängig. Die aktuelle Paper-Migrationsanleitung trennt die älteren Wege vor 26.1 von den neueren Regeln. Eine alte Anleitung mit getrennten world_nether- und world_the_end-Ordnern ist deshalb kein allgemeiner Befehlssatz für jede aktuelle Installation.
Gehe für eine geprüfte Übernahme so vor:
- Bisherigen Server vollständig stoppen und gesamten Stand sichern.
- Minecraft-Version, Software und verwendete Erweiterungen dokumentieren.
- Aktuelle Migrationshinweise für genau diese Kombination lesen.
- Mit einer Kopie die notwendige Dateistruktur und Erweiterungsalternativen prüfen.
- Overworld, Nether, End, Spielerdaten und besondere Inhalte abnehmen.
- Erst danach die eigentliche Welt auf den geprüften Weg umstellen.
Entferne Inhaltsmods nicht als beiläufigen Teil einer Performance-Reparatur. Wenn euer Ziel nur mehr Leistung ist, diagnostiziert zuerst den vorhandenen Stand. Ein inkompatibler Wechsel kann ein größeres Problem erzeugen als die ursprüngliche Lastspitze.
Typische Irrtümer und Reparaturwege
Viele Fehler entstehen durch eine Verwechslung der Plattform oder der Ausführungsseite. Prüfe die konkrete Datei und ihre Anforderungen, bevor du den Servertyp änderst. Eine ähnliche Projektbezeichnung auf einer anderen Plattform garantiert keine austauschbaren Konfigurationen.
| Problem | Prüfen | Korrektur |
|---|---|---|
| Fabric-Mod in Paper lädt nicht | Falsche Plattform | Passenden Loader oder tatsächlich unterstützte Pluginalternative wählen |
| Paper-Plugin in Fabric startet nicht | Kein normaler Pluginweg | Passende Fabric-Modalternative prüfen |
| Fabric API fehlt | Abhängigkeit nicht installiert | Geforderten kompatiblen API-Stand ergänzen |
| Zwei Versionen derselben Erweiterung | Alte JAR blieb aktiv | Ersetzte Datei nach Sicherung entfernen |
| Nur ein Client scheitert | Profil und Mod-Environment | Mit funktionierendem Client vergleichen |
| Fehler nach Weltwechsel | Version und Verzeichnisstruktur | Vollständige Sicherung und passende Migrationsanleitung verwenden |
| Niedrige FPS bei einem Spieler | Clientleistung | Grafik und lokale Mods prüfen |
| Hohe MSPT bei allen | Serverlast | Problemphase profilieren und Ursache gezielt korrigieren |
Bei Problemen nach einem Update sichere zuerst die Meldung und den letzten funktionierenden Stand. Nutze keinen Downgrade einer bereits konvertierten Welt als allgemeinen Rettungsversuch. Für einen echten Rückweg stellst du die alte Welt und ihre vollständige Softwarebasis wieder her.
Betrieb, Updates und Entscheidung überprüfen
Sichere Welt, Erweiterungen und Konfiguration vor einem Update. Bei Paper gehören die Pluginstände dazu, bei Fabric die Mod- und Loaderstände. Prüfe die Anforderungen des Zielreleases, bevor du die Gruppe auf einen neuen Clientstand schickst.
Ersetze Dateien nicht im laufenden Serverprozess. Plane Stop, Update und kontrollierten Start. Teste danach normale Spielerrechte, benötigte Funktionen und einen erneuten Beitritt. Die Paper-Updateanleitung beschreibt den Sicherungs- und Austauschgrundsatz für diesen Softwareweg.
Deine Auswahl ist richtig, wenn die benötigten Erweiterungen kompatibel sind, die Gruppe zuverlässig beitritt und eure Mechaniken unter normaler Last funktionieren. Weder der Loadername noch eine einzelne RAM-Anzeige beweist das. Bewahre den überprüften Versions- und Konfigurationsstand für die nächste Änderung auf.
Quellen und praktische Abschlussprüfung
- Paper: Erster Start und Java-Anforderungen.
- Paper: Plugins installieren.
- Paper: Leistungsprofiling und Befehle.
- Paper: Softwaremigration für versionsabhängige Weltregeln.
- Fabric: Mods installieren und Player Guides.
Vor der Bestellung sollte jede unverzichtbare Funktion einem unterstützten Projekt und gemeinsamen Versionsstand zugeordnet sein. Nach der Einrichtung prüfst du echten Beitritt, normale Rechte, die wichtigste Mechanik und einen Neustart. Danach kannst du mit dem passenden Paper- oder Fabric-Setup weiterbauen.