Der Moment, in dem ein Satisfactory-Save richtig gut wird, ist meistens der Moment, in dem es aufhört, spielbar zu sein. Jemand stellt um zwei Uhr nachts eine Aluminiumlinie fertig, drei Leute loggen sich am nächsten Abend ein, und nichts lädt, weil der eine PC mit der Welt darauf zusammen mit seinem Besitzer auf der Arbeit ist. Ein Dedicated Server löst das. Er ist allerdings keine bloße Kopie des Spielclients, und Satisfactory macht ein paar Dinge anders als jeder andere Survival-Server, den du bisher betrieben hast.
Ein Dedicated Server ist nicht einfach das Spiel auf einem fremden PC
Der Satisfactory Dedicated Server ist ein eigenständiges, kostenloses Tool. Er rendert nichts, hat keinen eigenen Spieler und führt die Fabriksimulation headless aus. Genau deshalb läuft er problemlos auf einer Maschine ohne GPU und stemmt trotzdem ein Save, bei dem ein Gaming-Laptop ins Schwitzen käme.
Drei Dinge ändern sich an dem Tag, an dem ihr eine clientseitig gehostete Session verlasst.
Die Welt gehört nicht mehr einer Person. Das Save liegt auf dem Server, die Fabrik produziert also weiter, egal ob derjenige online ist, der sie gestartet hat.
Die Latenz wird fair. In einem clientseitig gehosteten Spiel spielt der Host mit null Ping, und alle anderen bezahlen dafür. Deshalb ruckeln die Bänder bei den Gästen und nie beim Host. Auf einem Dedicated Server sind alle gleich weit entfernt, und gleich weit ist eine deutlich bessere Ausgangslage.
Uptime wird zur Einstellung statt zum Gefallen. Niemand muss nachts einen PC laufen lassen, damit ein Freund in einer anderen Zeitzone spielen kann.
Was der Server wirklich braucht
Die Dokumentation von Satisfactory setzt die Untergrenze bei 8 GB RAM und empfiehlt 16 GB für größere Saves oder für mehr als vier Spieler. Betrachte 8 GB als "das startet und trägt eine junge Fabrik", nicht als Ziel.
Der Hinweis zur CPU wiegt schwerer als der zum RAM. Der Server nutzt mehrere Kerne, bevorzugt aber sehr deutlich hohe Single-Core-Leistung, und die praktische Untergrenze liegt bei einem Single-Thread-Rating um 2000. Das ist keine Marotte, das ist die Form des Spiels. Ein Save im späten Spiel besteht aus Tausenden Gebäuden und Zehntausenden Items auf Bändern, und diese Simulation ist ein serieller Tick. Die Kernzahl zu verdoppeln bringt sehr wenig. Den Takt zu erhöhen bringt sehr viel. Wenn du für Satisfactory zwischen mehr Kernen und schnelleren Kernen wählen musst, nimm jedes Mal die schnelleren.
RAM skaliert mit deinem Save, nicht in erster Linie mit der Spielerzahl. Vier Leute auf einem 20-Stunden-Save fühlen sich in 8 GB wohl. Dieselben vier auf einer 400-Stunden-Megabase mit vollem Schienennetz wollen das Doppelte. Wer lieber Zahlen sieht als rät: Unser Satisfactory RAM-Rechner rechnet über Save-Größe und Spielerzahl.
Noch eine Zahl lohnt sich: Der Dedicated Server erlaubt standardmäßig maximal vier Spieler, genau wie Koop. Du kannst das mit einem Startparameter anheben (-ini:Game:[/Script/Engine.GameSession]:MaxPlayers=8), es ist aber nicht unterstützt, und jeder zusätzliche Pioneer bedeutet mehr Replikationsarbeit auf einer Simulation, die ohnehin an einem Thread hängt. Heb den Wert bewusst an und gib dem Server dann mehr Luft.
Ports und der Server-Manager-Handshake
Hier stolpern Leute, die schon Minecraft-Server betrieben haben. Satisfactory nutzt zwei Ports, und keiner davon ist optional:
- 7777 TCP für Servertraffic und die HTTPS API
- 7777 UDP für Spieltraffic und die Lightweight Query API
- 8888 TCP für Reliable Messaging
Portweiterleitung mit abweichender Nummer wird für den Standardport nicht unterstützt, externer und interner Port müssen also identisch sein. Du kannst 7777 nicht als 25565 nach außen geben und erwarten, dass der Handshake funktioniert. Der Reliable Port ist der flexible: Er lässt sich mit -ExternalReliablePort= umlegen.
Und jetzt der Teil, der fast jeden erwischt. Die Server-IP zu kopieren und in einen Beitrittsdialog zu setzen, bringt dich nicht hinein. Satisfactory claimt Server über den Server Manager im Client. Du startest das Spiel, gehst im Hauptmenü zum Server Manager, fügst den Server über IP und Port hinzu, und der Server antwortet über diese HTTPS API. Erst danach gibst du ihm einen Namen und setzt das Administrator-Passwort, und genau dieser Schritt claimt den Server und schließt den Token-Handshake ab. Bis dahin ist der Server unclaimed und weist dich ab.
Ist er geclaimt, startest du entweder ein neues Spiel oder lädst ein vorhandenes Save hoch, und ab da erscheint der Server wie jeder andere in deiner Liste. Für beide Schritte haben wir Anleitungen: Server claimen und Admin werden und mit dem Server verbinden.
Autosaves, Neustarts und die Einstellungen, die falsch verstanden werden
Die Servereinstellungen liegen im Server Manager statt in einer Konfigurationsdatei, in die du dich per SSH einloggst, was angenehmer ist, als es klingt. Über vier davon solltest du nachdenken, bevor 200 Stunden drinstecken.
Auto-Save Interval. Autosaves rotieren, ein kurzes Intervall liefert also mehr jüngste Zustände, reicht aber weniger weit zurück. Wenn du gleich ein Manifold herausreißt oder ein neues Mod installierst, lade vorher ein Save herunter. Verlass dich nicht darauf, dass die Rotation eine Stunde später noch eine saubere Kopie hält.
Server Restart Interval. Der Name lügt und legt jeden herein, der ihn wörtlich nimmt. Es bedeutet nicht "alle N Stunden neu starten". Es ist die Tageszeit, zu der der Server täglich neu startet.
Auto Pause. Pausiert die Welt, wenn niemand verbunden ist. Das spart CPU und ist für die meisten Gruppen die richtige Voreinstellung. Es heißt aber auch, dass die Produktion nachts steht. Wenn für dich der halbe Reiz darin liegt, sich zu vollen Containern einzuloggen, schalte es aus und nimm die Dauerlast in Kauf.
Network Quality. Lohnt sich anzuheben, wenn die Gruppe über mehrere Länder verteilt ist, und lässt sich in Ruhe lassen, wenn alle lokal sitzen.
Deine Saves liegen unter ~/.config/Epic/FactoryGame/Saved/SaveGames/server, die Servereinstellungen in ServerSettings.PORT.sav und Blueprints in einem eigenen Ordner daneben. Wenn du eine Solo-Welt auf einen Server umziehst, ist eine vorhandene Speicherdatei hochladen der passende Artikel.
Mods verändern die Rechnung
Mods auf einem Dedicated Server werden auf beiden Seiten installiert, Server und Client, in derselben Version. Das klingt selbstverständlich und ist trotzdem der mit Abstand häufigste Grund, warum jemand nicht auf den eigenen Server kommt, meist ein oder zwei Tage nach einem Patch, wenn der Client aktualisiert hat und das Mod-Set des Servers nicht.
Zwei Gewohnheiten machen das schmerzfrei. Bewahre vor einem Modded-Durchlauf eine Vanilla-Kopie deines Saves auf, denn ein Save, das ein Mod angefasst hat, öffnet ohne dieses Mod nicht immer sauber. Und gib einem Modded Server echten RAM-Puffer, denn Content Mods legen Gebäude, Rezepte und Entities auf genau die Simulation, die ohnehin dein Flaschenhals war.
Für Empfehlungen, die auf einem Server bestehen und nicht nur auf einem Singleplayer-Screenshot, siehe unseren Überblick über die besten Satisfactory-Mods.
Plane für das Save, das du bekommst, nicht für das, das du hast
Fast jedes Serverproblem in Satisfactory ist dasselbe Problem, nur verspätet: Die Maschine wurde für die Fabrik in Stunde 20 ausgelegt und trägt jetzt die Fabrik in Stunde 300. Wähle die Hardware für die Megabase, die ihr bauen wollt, halte die Claim- und Portregeln gleich beim ersten Mal sauber, und lade ein Save herunter, bevor ihr etwas Ehrgeiziges anfangt.
Wer sich das SteamCMD-Setup und die Portrechnerei sparen will: Unser Satisfactory Server Hosting läuft auf Ryzen 9 Hardware mit hohem Takt, also genau der CPU-Sorte, nach der dieses Spiel verlangt, mit offenen Ports und Saves nur einen Klick entfernt.
