So richtest du es ein

1. Leg einen Server an und wähl das Spiel Minecraft. Es gibt ein Paket, nicht eines je Lader.
2. Entscheide dich für den Lader: Vanilla nimmt keine Mods. Paper nimmt Plugins und läuft flott. Fabric, NeoForge und Forge nehmen Mods.
3. Wähl die Spielausgabe oder lass „latest“ stehen.
4. Willst du ein fertiges Modpack, such es gleich beim Anlegen aus. Dann musst du Lader und Ausgabe nicht wählen: Das Modpack bestimmt beides.
5. Setz den Haken bei der EULA. Ohne ihn startet kein Minecraft-Server, und zustimmen musst du selbst.
6. Einzelne Mods kommen später über den Reiter „Mods“ dazu. Die Suche zeigt nur, was zu deinem Lader und deiner Ausgabe passt.

Was wir anders machen

Java wählt sich selbst. Der Hersteller gibt zu jeder Spielausgabe an, welche Java-Fassung sie braucht. Unser Server-Image trägt Java 8, 17, 21 und 25 nebeneinander, und bei der Installation wird die passende genommen. Damit laufen aktuelle Ausgaben genauso wie ein Forge-Server auf 1.12.2. Ein Auswahlfeld für Java gibt es nicht, weil es dort nichts zu raten gibt.

Der Lader ist eine Einstellung. Du kannst ihn später wechseln. Das Panel sagt dir vorher klar, dass das eine Neuinstallation ist, statt es stillschweigend zu tun oder gar nicht anzubieten.

Modpacks kommen ohne Client-Mods auf den Server. Shader, Zoom und Oberflächen-Mods haben auf einem Server nichts verloren und bringen ihn oft zum Absturz. Vor dem Einspielen fragen wir für jede enthaltene Mod nach, ob ihr Autor sie als reine Client-Mod führt, und lassen diese weg. Bei einem großen Technik-Paket waren das 81 von 241 Dateien. Das Panel zeigt dir die Zahl, statt etwas heimlich zu streichen.

Die Suche prüft die Datei, nicht das Etikett. Ob eine Mod zu deinem Lader passt, steht verlässlich nur an der einzelnen Fassung der Mod. Die Schlagworte eines Projekts sagen dazu wenig: In einer Stichprobe hatte die Hälfte der Treffer mit dem Etikett eines Laders in Wahrheit einen anderen.

Feste Fassungen, Updates auf Knopfdruck. Wie bei allen Spielen bleibt eine installierte Mod in ihrer Fassung, bis du sie aktualisierst.

Zusätzliche Ports bucht das Panel selbst. Bringt eine Mod einen eigenen Port mit, etwa für Sprachchat, wird er vor dem Start reserviert und freigegeben.

Typische Fehler, die wir vermeiden wollten

• Ein Servertyp je Lader und Ausgabe. Das ergibt lange Listen, und wer wechseln will, fängt von vorn an.
• Eine feste Java-Fassung je Servertyp oder ein Auswahlfeld dafür. Die falsche Wahl endet in Fehlern, die nach kaputten Mods aussehen, obwohl nur die Laufzeit nicht passt. Alte Forge-Ausgaben scheitern auf neuem Java, neue Ausgaben auf altem.
• Modpacks, die einfach komplett ausgepackt werden. Das Paket behauptet, jede Datei gehöre auf den Server. Verlässt man sich darauf, startet der Server nicht, und im Protokoll steht eine Mod, von der du nie gehört hast.
• Mods im falschen Ordner. Der Server startet sauber durch, lädt aber keine einzige Mod, und nirgends steht eine Meldung. „Installiert“ heißt erst dann etwas, wenn das Spiel die Mods im eigenen Protokoll auch lädt.
• Automatische Updates beim Start. Bequem, bis eine Mod über Nacht eine neue Fassung bekommt, die zu den anderen nicht mehr passt.
• Die Spielausgabe „latest“ bei jedem Start neu auflösen. Dann wird aus einem Neustart ein Versionssprung, den niemand bestellt hat. Bei uns gilt die Ausgabe vom Anlegen; ein Wechsel ist eine bewusste Neuinstallation.

Wo die Grenzen sind

Legt ein Modpack Mods lose bei, ohne dass es dazu eine Auskunft gibt, können wir sie nicht einordnen. Das Panel nennt dann ihre Zahl. Führt ein Autor seine Mod als servertauglich und sie bricht trotzdem ab, bleibt sie drin; in dem Fall nennt der Absturzgrund die Mod beim Namen. Und eine Mod, die Mitspieler ebenfalls brauchen, musst du ihnen weiterhin selbst nennen. Das Panel sagt dir, welche das sind.