Satisfactory lädt die falsche Fabrik: Session, Save und Auto-Load verstehen

Die kurze Antwort: Prüfe im Server Manager die gewünschte Session und deren Spielstände. Lade den richtigen Save ausdrücklich, kontrolliere die Fabrik im Spiel und gleiche danach Auto-Load Session Name mit dieser Session ab. Auto-Load bezeichnet eine Session; laut Serverdokumentation startet der Server mit deren jüngstem Save. Ein erfolgreicher Upload allein beweist deshalb noch nicht, dass beim nächsten Neustart deine gewünschte Fabrik erscheint. Sichere die Dateien, bevor du etwas ersetzt.

Dieser Guide hilft PC-Spielern auf einem Dedicated Server: selbst gehostet, bei einem anderen Anbieter oder bei SupremeTier. Du brauchst keinen neuen Server und keinen Anbieterwechsel. Ohne Adminrechte kannst du die Fabrik prüfen und die Diagnose vorbereiten; Laden, Upload und Servereinstellungen übernimmt eine berechtigte Person. Für eine lokal gehostete Koop-Runde findest du unten einen eigenen Abschnitt. Die derzeitige Hersteller-FAQ schließt den Beitritt von Konsolen zu Dedicated Servern aus; die folgenden Server-Manager-Schritte sind daher keine Konsolenanleitung. Quelle: Coffee Stain

Stand der Quellenprüfung: 29. Oktober 2026. Menütexte können je nach Sprache und Build abweichen. Der Ablauf ist eine dokumentationsgestützte Anleitung. Das Beispiel ist konstruiert und kein Bericht über einen von uns ausgeführten Spielservertest.

Erst eingrenzen: Welt, Stand oder Charakter?

Nach einem Neustart fehlt deine Bahnstrecke. Das kann drei ganz verschiedene Dinge bedeuten: Eine andere Fabrik wurde geladen, ein älterer Stand derselben Fabrik läuft oder du stehst mit einem anderen Charakter am falschen Ort. Bevor jemand Dateien löscht, vergleicht gemeinsam zwei oder drei unverwechselbare Merkmale: die Lage eures HUBs, eine auffällige Produktionsanlage und einen zuletzt erreichten Meilenstein. Ein Spawnpunkt oder ein leeres Inventar reicht als Beweis für eine falsche Welt nicht aus.

Prüfe außerdem den Servereintrag. Hat die Gruppe mehrere Server, eine alte Adresse in den Favoriten oder zusätzlich eine lokale Koop-Runde? Notiere Adresse und Port des tatsächlich verwendeten Eintrags. Der angezeigte Servername ist eine Beschriftung und muss nicht dem Namen eurer Session entsprechen. Lass einen zweiten Spieler bestätigen, dass ihr denselben Eintrag meint. Veröffentlicht dabei weder Adminpasswort noch Zugangstoken.

Die Hersteller-FAQ erklärt, dass ein anderer Online-Spielerbezug einen neuen Charakter verursachen kann. Passt eure Fabrik, klärt zuerst diesen Kontofall. Ein Welt-Rollback würde sonst möglicherweise den Fortschritt aller zurücksetzen, ohne das eigentliche Problem zu lösen. Quelle: Coffee Stain, Fehlerbehebung

Session, Save und Auto-Load: drei Begriffe, drei Aufgaben

Eine Session ist der benannte Zusammenhang eures Spielverlaufs. Zu einer Session können mehrere Spielstände gehören. Ein Save ist eine bestimmte gespeicherte Momentaufnahme. Auto-Load Session Name gibt an, aus welcher Session der Dedicated Server beim Start laden soll. Die Serverdokumentation beschreibt dabei die Auswahl des jüngsten Saves dieser Session. Quelle: Serverdokumentation

Stell dir eure Session als „Nordwerk“ vor. Dazu gehören die Momentaufnahmen „Vor-Umbau“, „Abendstand“ und automatische Sicherungen. Die Session beantwortet „Welche Fabrikreihe?“, der Save „Welcher Stand davon?“. Diese Trennung erklärt zwei typische Irrtümer: Der neueste Upload muss nicht die aktuell geladene Welt sein, und der Name einer Datei muss nicht als Auto-Load-Session geeignet sein.

Hochladen ist noch kein Startauftrag

Beim Upload wird ein Spielstand auf den Server übertragen. In der API ist das unmittelbare Laden eine eigene Option namens LoadSaveGame. Ein Upload ohne anschließendes Laden kann also erfolgreich sein, obwohl die Gruppe weiter in der bisherigen Fabrik spielt. Prüfe das sichtbare Ergebnis im Spiel; ein abgeschlossener Fortschrittsbalken bestätigt zunächst nur den Vorgang, den die Oberfläche tatsächlich ausgeführt hat.

Jetzt laden ist nicht dasselbe wie künftig laden

Die API trennt LoadGame und SetAutoLoadSessionName. Der erste Aufruf lädt einen benannten Save. Der zweite setzt das Ziel für den automatischen Start und ändert laut Dokumentation die bereits geladene Session nicht. Verlasse dich deshalb nicht darauf, dass jedes Anbieterpanel diese Schritte automatisch miteinander verbindet. Lies den eingestellten Wert nach dem Speichern erneut aus. Quelle: mitgelieferte API-Dokumentation, öffentlich gespiegelt

Dateiname, Sessionname und Servername auseinanderhalten

Schreibe die drei Namen getrennt auf. „Wochenendserver“ kann der Server heißen, „Nordwerk“ die Session und „Nordwerk-vor-Neustart“ ein manueller Save. Einen Dateinamen außerhalb des Spiels umzubenennen ist kein belastbarer Weg, die interne Sessionzuordnung zu ändern. Lies die Zuordnung in der Spielstandverwaltung ab. Verwende für Auto-Load den dort angezeigten Sessionnamen, nicht eine vermutete Bezeichnung aus dem Uploadordner.

Vor Änderungen: erst eine Sicherung

Bestimmt eine Person, die den Vorgang führt. Die anderen bauen während der Auswahl und des Neustarttests nicht weiter. Ein späteres Zurückladen kann sonst gerade erzeugten Fortschritt verwerfen. Notiere den zuletzt sicher richtigen Zeitpunkt und den Zustand, den die Gruppe jetzt wiederhaben möchte. Ein „Backup vorhanden“ ohne Datum und Herkunft hilft bei mehreren ähnlichen Dateien wenig.

Sichere den gewünschten Originalsave und zusätzlich den vorgefundenen Serverstand außerhalb des aktiven Save-Verzeichnisses. Wenn du Dateizugriff hast, sichere auch die zum Server gehörenden Einstellungen über den vorgesehenen Backupweg. Bei einem Anbieter ohne Dateizugriff nutze dessen Export- oder Backupfunktion und prüfe, ob der Download wirklich vorliegt. Eine Sicherung nur im selben flüchtigen Serververzeichnis schützt nicht vor dessen Ersetzung.

Lass einen Speichervorgang abschließen. Für direkte Kopien auf Dateisystemebene sollte der Server über den regulären Dienst- oder Panelweg sauber gestoppt sein. Das ist von einem Upload über den laufenden Server Manager zu unterscheiden: Die Verwaltungsfunktion braucht einen erreichbaren Server. Kopiere keine gerade beschriebene Datei als vermeintlich konsistentes Backup und beende den Prozess nicht gewaltsam, nur damit es schneller geht.

Speichere vor dem Stoppen ausdrücklich. Verlasse dich nicht darauf, dass ein Neustartknopf einen frischen Weltsave erzeugt. Die Pterodactyl-Egg-Dokumentation weist für ihren Stoppweg ausdrücklich auf diese Grenze hin. Prüfe den neu geschriebenen Eintrag im Server Manager und sichere ihn, bevor du die Instanz beendest. Damit trennst du „der Server wurde sauber beendet“ von „unser letzter Baufortschritt wurde tatsächlich gespeichert“. Quelle: Pterodactyl, Save Files

Dein Sicherungsvermerk sollte mindestens enthalten:

• Herkunft: Spieler-PC, bisheriger Server oder früheres Backup.
• Datum, Uhrzeit und Zeitzone der Sicherung.
• Sessionname und Dateiname, soweit sichtbar.
• Spielzeit und Speicherzeit aus der Spielstandverwaltung.
• Branch, Build und verwendete Mods, soweit bekannt.
• Zwei Fabrikmerkmale, an denen die Gruppe den Stand erkennt.
• Ablageort der unveränderten Originalkopie.

Rückweg: Bei einem Fehlschlag stoppst du die Versuchsreihe. Bewahre den problematischen Zwischenstand separat auf, lade die gesicherte gewünschte Kopie über den normalen Verwaltungsweg und stelle das zuvor dokumentierte Auto-Load-Ziel wieder her. Musstest du Versionen ändern, gehört auch eine passende Serverversion zum Wiederherstellungsplan. Ein Backup aus einem neueren Format wird durch Kopieren nicht automatisch für ältere Software lesbar.

Build und Branch vergleichen, bevor du Saves ausprobierst

„Wir haben beide Satisfactory“ ist für eine Diagnose zu ungenau. Erfasse den Branch des Spielclients und des Dedicated Servers: regulärer Zweig oder Experimental. Ergänze die tatsächlich angezeigte Buildkennung aus Spiel, Serveranzeige oder Startprotokoll. Die Bezeichnungen im Anbieterpanel sind Hinweise; entscheidend ist, was der laufende Prozess meldet. Notiere außerdem, mit welchem Build der gewünschte Save zuletzt gespeichert wurde, sofern diese Information verfügbar ist.

Der Versionsvergleich beantwortet zuerst eine Frage: Kann diese Installation den gewünschten Stand überhaupt laden? Wenn schon das manuelle Laden fehlschlägt, löst ein anderer Auto-Load-Name das Problem nicht. Gibt es dagegen eine ladbare richtige Fabrik, aber nach jedem Neustart eine andere, ist das Startziel die nähere Spur. Mische diese beiden Fehlerklassen nicht durch gleichzeitige Updates, Umbenennungen und Rücksicherungen.

Coffee Stain empfiehlt ausdrücklich Backups beim Wechsel zwischen Versionen. Lege daher eine unveränderte Kopie beiseite, bevor du einen Save mit einem anderen Branch öffnest und anschließend speicherst. Versuche eine Rückkehr zu einer älteren Version nur mit einem dafür geeigneten Stand. Aus „Datei vorhanden“ folgt keine Kompatibilitätszusage. Quelle: Coffee Stain, Main und Experimental

Bei Mods kommt eine zusätzliche Ebene hinzu. Bewahre eine Liste der Mods und ihrer Versionen auf. Teste Änderungen an dieser Zusammenstellung ausschließlich mit einer Kopie des Saves. Ein erfolgreicher Start ohne Mods ist kein Beweis, dass modabhängige Inhalte erhalten bleiben. Wenn du die Mod-Abhängigkeiten nicht kennst, behandle diesen Save zunächst als gesonderten Wiederherstellungsfall. Der folgende Hauptablauf setzt einen Save voraus, der in der gewählten Serverumgebung grundsätzlich ladbar ist.

Den richtigen Spielstand finden

Beginne beim Spieler, der zuletzt die richtige Fabrik gesehen hat. Lass dir den konkreten Save nennen oder exportieren. „Nimm den neuesten“ ist unpräzise, sobald jemand Dateien kopiert, umbenannt oder alte Backups frisch heruntergeladen hat. Die Dateisystemzeit kann den Kopiervorgang beschreiben. Sie ist nicht automatisch der Zeitpunkt des Fabrikfortschritts.

Vergleiche deshalb mehrere Hinweise: Sessionzuordnung, Speicherzeit aus der Spielstandverwaltung, Spielzeit, erkennbare Bauwerke und zuletzt erledigte Meilensteine. Dateigröße ist nur eine Zusatzinformation. Eine größere Datei muss nicht richtiger sein; eine kleinere ist nicht allein deshalb beschädigt. Auch eine höhere Spielzeit beweist den gewünschten Bauzustand nicht, wenn mehrere Leute auf unterschiedlichen Abzweigungen weitergespielt haben.

Öffne verdächtige Kandidaten nur als Arbeitskopien. Dokumentiere für jeden Kandidaten, was du gesehen hast. Zwei klar bezeichnete Versuche sind hilfreicher als zehn unbeschriftete Uploads. Besonders bei einer älteren Wiederherstellung ist die Frage wichtig: Will die Gruppe einen historischen Stand sehen oder von ihm aus dauerhaft weiterspielen? Für den zweiten Fall brauchst du nach der Inhaltsprüfung einen neuen, bestätigten Speicherstand und einen erneuten Neustarttest.

Wenn kein Kandidat die erwartete Fabrik enthält, beende die Startziel-Diagnose. Suche in weiteren vorhandenen Backups und lokalen Saves nach dem fehlenden Stand. Eine Einstellung kann keine Gebäude rekonstruieren, die in keiner gesicherten Momentaufnahme vorhanden sind. Behaupte gegenüber der Gruppe noch keinen Datenverlust, solange nicht geklärt ist, welche Quellen überhaupt durchsucht wurden.

Beispiel: vom Upload bis zum Neustart

Beispiel, kein Live-Test: Vier Spieler möchten an „Nordwerk“ weiterspielen. Auf dem Dedicated Server läuft nach dem Neustart jedoch „Probefabrik“. Der gewünschte lokale Save heißt „Nordwerk-Abend“. In „Nordwerk“ erkennt die Gruppe einen Bahnhof neben dem HUB und eine neue Aluminiumlinie. Namen und Beobachtungen dienen hier ausschließlich dazu, den Ablauf verständlich zu machen.

1. Ausgangslage festhalten

Die verantwortliche Person notiert Serveradresse, Port, aktive Session und den angezeigten Auto-Load-Wert. Außerdem sichert sie sowohl den vorgefundenen Serverstand als auch die lokale Datei „Nordwerk-Abend“. Der Download bleibt unverändert an einem zweiten Ablageort. Alle Beteiligten wissen, dass während des Tests niemand produktiv weiterbaut.

Erwartetes Zwischenresultat: Ihr könnt erklären, welche Fabrik momentan läuft und wohin ihr zurückkehrt, wenn der Versuch scheitert. Ist schon die Serveradresse unklar, wird nicht hochgeladen. Ein korrekt ausgeführter Upload auf den falschen Server wäre trotzdem das falsche Ergebnis.

2. Den Kandidaten und die Version prüfen

Die Gruppe vergleicht Branch und Build von Client und Server und prüft den gewünschten Save anhand der bekannten Merkmale. Der Name allein genügt nicht. Gibt es eine Fehlermeldung zur Kompatibilität, wird diese zuerst geklärt. Der Originalsave bleibt geschützt; ihr probiert nicht nacheinander beliebige Versionen an derselben einzigen Kopie aus.

Erwartetes Zwischenresultat: „Nordwerk-Abend“ ist der beabsichtigte Kandidat, seine Herkunft ist bekannt und die ausgewählte Serverumgebung kann ihn laden. Wenn diese Voraussetzungen fehlen, bleibt die nächste Aktion offen, statt als Erfolg abgehakt zu werden.

3. Über den Server Manager hochladen

Öffne im Hauptmenü den Server Manager, wähle den richtigen Server und authentifiziere dich mit Adminrechten. Die dokumentierte Oberfläche bietet die Save-Verwaltung unter Manage Saves. Wähle dort den lokalen Spielstand für den Upload. Verwende die in deinem Build angezeigte Uploadfunktion und warte auf ihr Ergebnis. Quelle: Serverdokumentation, Loading a save file

Kontrolliere anschließend, ob die Datei in der serverseitigen Spielstandliste auftaucht und welcher Session sie zugeordnet ist. Falls die Oberfläche zusätzlich anbietet, den Upload direkt zu laden, notiere, ob du diese Option gewählt hast. Fehlt sie, folgt das Laden separat. Bei einem bereits vorhandenen gleichen Dateinamen brich eine unklare Überschreibabfrage zunächst ab und sichere die vorhandene Datei.

4. Genau diesen Save laden und die Fabrik prüfen

Wähle den hochgeladenen Kandidaten ausdrücklich zum Laden aus. Warte, bis der Ladevorgang abgeschlossen ist. Die API-Dokumentation weist darauf hin, dass die API während des Ladens vorübergehend nicht erreichbar sein kann. Ein kurzer Ausfall in dieser Phase ist daher für sich genommen noch kein Beweis für einen gescheiterten Save. Wiederhole Ladebefehle nicht blind. Quelle: API-Dokumentation, LoadGame

Tritt bei und kontrolliere Bahnhof, HUB und Aluminiumlinie. Ein zweiter Spieler bestätigt die Merkmale. Fehlt die Aluminiumlinie, ist möglicherweise der falsche Zeitpunkt gewählt. Dann kehrt ihr zur Kandidatenauswahl zurück. Das Auto-Load-Ziel jetzt schon auf „Nordwerk“ zu setzen würde die inhaltliche Prüfung nicht ersetzen.

5. Den bestätigten Zustand sichern und Auto-Load abgleichen

Speichere die bestätigte Fabrik mit einem eindeutigen manuellen Namen, etwa „Nordwerk-vor-Neustart“. Prüfe, dass der neue Eintrag in der Save-Verwaltung tatsächlich erscheint. Dieser Schritt ist besonders wichtig, wenn ihr einen älteren Stand als neue Fortsetzung gewählt habt: Auto-Load soll nicht unbemerkt einen bereits vorhandenen jüngeren, aber unerwünschten Stand derselben Session erwischen.

Trage unter Auto-Load Session Name den tatsächlich angezeigten Sessionnamen „Nordwerk“ ein. Speichere die Einstellung und lies sie nach erneutem Öffnen der Ansicht nochmals ab. Trage dort nicht „Nordwerk-vor-Neustart“ ein, sofern das nur der Dateiname ist. Prüfe auch die jüngsten Saves dieser Session. Weitere automatische Speicherungen können hinzukommen; deshalb protokollierst du die Liste unmittelbar vor dem Neustart.

6. Regulär neu starten, ohne den Erfolg vorwegzunehmen

Vereinbare mit der Gruppe einen kurzen Neustart. Lass die Speicherung abschließen und verwende den regulären Neustartweg deines Panels oder Dienstmanagers. Bei Selbsthosting ist der tatsächlich konfigurierte Dienst maßgeblich. Ein fremder Beispiel-Dienstname aus einer Anleitung ist kein ausführbarer Befehl für jedes System. Erzeuge keinen Absturz als Test und ändere nicht gleichzeitig Startskript, Version und Save-Verzeichnis.

Nach dem Start wartet ihr auf einen betriebsbereiten Server. Ladet jetzt nicht sofort manuell „Nordwerk“ nach, denn genau das würde die Prüfung des automatischen Starts verdecken. Lest zunächst die aktive Session und das Auto-Load-Ziel ab. Danach betritt ein Spieler die Welt und prüft dieselben Fabrikmerkmale wie zuvor.

7. Ergebnis nach klaren Kriterien festhalten

Der Test gilt für diesen Neustart als bestanden, wenn ohne manuelles Nachladen die gewünschte Session läuft, die vereinbarten Fabrikmerkmale vorhanden sind und der neue kontrollierte Stand erkennbar ist. Notiert Uhrzeit, aktive Session, Auto-Load-Ziel und Ergebnis. Ein laufender Serverprozess oder ein grüner Statuspunkt allein reicht nicht.

Kommt wieder „Probefabrik“, vergleicht die Einstellung mit der Notiz vor dem Neustart. Bleibt „Nordwerk“ aktiv, aber die Aluminiumlinie fehlt, untersucht ihr die Saves innerhalb dieser Session. Das sind unterschiedliche Folgepfade. Der erste fragt nach Startkonfiguration und deren Persistenz, der zweite nach dem geladenen Zeitpunkt. Bewahrt die Sicherung auf, bis die Gruppe den erfolgreichen Zustand bestätigt hat.

Richtig eingestellt und trotzdem falsch

Der Auto-Load-Wert ist nach dem Start wieder anders

Prüfe zuerst, ob die Änderung wirklich gespeichert und anschließend erneut angezeigt wurde. Wenn ja, suche beim Betreiber nach Mechanismen, die Einstellungen beim Start zurückspielen: Startvorlagen, Wiederherstellungsskripte, wechselnde Konfigurationsverzeichnisse oder ein nicht dauerhaft gespeicherter Containerpfad. Das sind Diagnosehypothesen, keine automatische Schuldzuweisung an deinen Anbieter.

Vergleiche nur eine Variable pro Versuch. Halte fest, welcher Wert vor dem Stoppen vorlag und welcher danach. Wird gleichzeitig der Servername oder die Admin-Einrichtung zurückgesetzt, deutet das auf einen breiteren Verlust beziehungsweise Austausch der Servereinstellungen hin. Lösche diese Einstellungen nicht als Schnellreparatur: Damit könntest du zusätzliche Informationen und den bisherigen Zugangszustand verlieren.

Auto-Load und aktive Session stimmen, der Fortschritt aber nicht

Dann ist die Auswahl innerhalb der Session die nähere Spur. Prüfe, ob der erwartete Fortschritt überhaupt gespeichert wurde und ob der von euch geprüfte Save tatsächlich serverseitig vorliegt. Unterscheide die Zeit des letzten Bauens von der Zeit des letzten erfolgreichen Speicherns. Mehrfaches Neustarten erzeugt keinen fehlenden Zwischenstand.

Bei einer Wiederherstellung eines älteren Saves vergleiche die übrigen jüngeren Einträge, bevor du die Diagnose als beendet ansiehst. Speichere die bestätigte Fortsetzung neu und prüfe erneut. Entferne keine Kandidaten, nur weil ihre Namen ähnlich aussehen. Wenn eine Bereinigung nötig wird, exportiere sie vorher separat und dokumentiere die Zuordnung.

Der Save verschwindet nach einem Container- oder Dienstneustart

Das spricht für eine Prüfung der Ablage und ihrer Dauerhaftigkeit. Ein Upload kann in einer laufenden Instanz sichtbar sein, während ein Neustart eine andere Instanz mit anderer Ablage startet. Lass den Betreiber den tatsächlich eingebundenen Speicherpfad, das ausführende Dienstkonto und die Startkonfiguration vergleichen. Ein Neuaufsetzen wäre hier kein sinnvoller erster Diagnoseschritt.

Prüfe bei Selbsthosting auch, ob du versehentlich zwei Instanzen verwaltest. Trenne Installationsordner, Save-Ablage und Dienstkonto gedanklich: Dass die Programmdateien an einem bestimmten Ort liegen, beweist nicht, dass dort auch die genutzten Saves gespeichert werden. Für eine Reparatur brauchst du die tatsächlich beobachteten Pfade, nicht bloß einen Standard aus dem Internet.

Der Server lädt den Kandidaten nicht oder meldet Fehler

Sichere die vollständige relevante Fehlermeldung und den zeitlichen Ablauf. Gibt es die Datei in der serverseitigen Liste? Passt ihre Sessionzuordnung? Wurde der Upload abgeschlossen? Erst danach folgen Build-, Branch- und gegebenenfalls Mod-Prüfung. Eine Datei mit erkennbarem Ladefehler sollte nicht zum unbeaufsichtigten Startziel einer produktiven Runde erklärt werden.

Wenn ein zweiter, gesicherter Save derselben Fabrik funktioniert, halte diesen Unterschied fest. Das grenzt den Fehler ein, beweist aber noch keine konkrete Dateibeschädigung. Vermeide „Reparatur“-Werkzeuge an der einzigen Kopie. Ein minimaler Bericht mit einem fehlschlagenden und einem ladbaren Kandidaten ist hilfreicher als eine lange Liste bereits ausgeführter, nicht dokumentierter Änderungen.

Selbst gehostet oder gemietet?

Für den normalen Ablauf brauchst du den Server Manager und Adminrechte. Direkter Dateizugriff ist eine zusätzliche Möglichkeit für Sicherungen und Diagnose, keine Voraussetzung für jeden Spieler. Auf einem Mietserver können Export und Neustart über das Anbieterpanel laufen. Die Namen dieser Schaltflächen unterscheiden sich; eine Anleitung sollte nicht so tun, als sähe jedes Panel gleich aus.

Auf einem selbst gehosteten Windows-PC nennt Coffee Stain für lokale Saves den Basisordner %LOCALAPPDATA%\FactoryGame\Saved\SaveGames. Entscheidend ist das Benutzerkonto, unter dem du nachschaust. Ein Serverdienst kann unter einem anderen Konto laufen als dein interaktives Spiel. Der Herstellerpfad für deinen angemeldeten Benutzer beweist deshalb noch nicht den richtigen Dienstpfad. Quelle: Coffee Stain, Save files

Bei Linux und Containern lässt du dir die tatsächlich verwendete Save-Ablage aus der konkreten Installation bestätigen. Kontrolliere die Einbindung des dauerhaften Speichers und die Schreibrechte des Dienstkontos, bevor du Dateien kopierst. Verwende keine pauschale Rechtefreigabe für alle Benutzer. Ein Rechteproblem wird über die passende Eigentümerschaft und den vorgesehenen Zugriff gelöst, nicht über blindes Freischalten.

Wenn du keinen Adminzugriff hast, schicke der berechtigten Person die gewünschte Session, den Kandidatennamen und die Fabrikmerkmale. Bitte um die Werte vor und nach dem Neustart. So kann die Gruppe den Erfolg selbst beurteilen, ohne dass alle das Adminpasswort erhalten müssen.

Lokale Koop-Runde: der Host wählt den Save

Wenn ein Spieler die Welt direkt auf seinem PC hostet, ist dieser PC die maßgebliche Quelle der geladenen Runde. Der Auto-Load-Wert eines Dedicated Servers ist dafür nicht die richtige Stellschraube. Der Host beendet die laufende Runde nach einer Sicherung, wählt im Laden-Menü den gewünschten Save und lädt die Freunde wieder ein. Auch hier prüft ihr zuerst die Fabrik und anschließend den Fortschritt.

Vergleicht vor allem, wer diesmal hostet. Zwei Spieler können Kopien derselben Fabrik mit unterschiedlichem Stand haben. Wenn plötzlich jemand anderes die Runde öffnet, ist ein älterer lokaler Save eine naheliegende Prüfspur. Ein weitergereichter Dateiname allein dokumentiert nicht, welche Kopie zuletzt weitergespielt wurde.

Bewahre vor einer Cloud-Synchronisierung mit unklarem Ergebnis die lokal vorhandenen Kandidaten separat auf. Entscheide anhand von Speicherinformationen und Fabrikmerkmalen, welche Fassung ihr weiterführen wollt. Schalte Synchronisierung nicht wahllos ein und aus, während mehrere Geräte unterschiedliche Kopien öffnen. Die sichere Reihenfolge bleibt: Kopien sichern, Herkunft klären, bewusst laden, Inhalt prüfen und die neue maßgebliche Fortsetzung dokumentieren.

Neustartprotokoll zum Übernehmen

Fülle diese Felder vor und nach dem Test aus. Ein leerer Wert bedeutet „noch nicht geprüft“. Die Vorlage ist kein automatischer Nachweis und liest keine Serverdaten aus.

Abschlussentscheidung: „Bestanden“ bedeutet: richtige Session, richtiger Fabrikzustand, kein manuelles Nachladen. „Teilweise“ bedeutet beispielsweise: Fabrik stimmt, aber Auto-Load-Wert konnte nicht ausgelesen werden. „Fehlgeschlagen“ bedeutet: Ein vereinbartes Merkmal fehlt oder eine andere Session läuft. Damit bleibt klar, was bewiesen wurde und was noch offen ist.

Für Fortgeschrittene: die Server-API

Wenn dein bestehendes Verwaltungswerkzeug die Satisfactory-API bereits unterstützt, kannst du damit die manuellen Beobachtungen ergänzen. QueryServerState unterscheidet die aktive Session (ActiveSessionName) vom Startziel (AutoLoadSessionName). EnumerateSessions liefert Sessiongruppen mit Save-Informationen. Diese Trennung hilft, einen falsch gesetzten Startwert von einem falschen Save innerhalb der richtigen Gruppe zu unterscheiden. Quelle: API-Dokumentation

Die mit dem Spiel ausgelieferte Referenz liegt laut der Entwicklerdokumentation der Modding-Community unter CommunityResources/DedicatedServerAPIDocs.md im Installationsverzeichnis. Für konkrete Aufrufe ist die zum installierten Build gehörende Datei maßgeblich. Die hier verlinkte öffentliche Spiegelung stammt aus 2024 und ersetzt diesen Abgleich nicht. Der Guide liefert bewusst keine ungeprüfte Befehlsfolge mit Zugangsdaten. Quelle zum Dokumentationsort

Ein API-Status allein beweist den sichtbaren Inhalt der Fabrik nicht. Verwende ihn zusammen mit dem Beitrittstest. Ebenso zeigt eine erfolgreiche Antwort auf eine Einstellungsänderung noch nicht, dass eine externe Startvorlage diesen Wert beim Neustart unangetastet lässt. Deshalb gehören die Beobachtungen vor und nach dem Start in dasselbe Protokoll.

FAQ

Muss ich den Dateinamen in Auto-Load Session Name eintragen?

Verwende den in der Spielstandverwaltung angezeigten Sessionnamen. Die Dateiauswahl bestimmt einen konkreten Save; Auto-Load bezeichnet die Session für den nächsten automatischen Start. Gleiche die Zuordnung ab, statt aus dem Dateinamen zu raten.

Warum funktioniert mein Upload, aber die alte Fabrik bleibt aktiv?

Prüfe, ob nach dem Upload tatsächlich ein Laden ausgelöst wurde. Upload und unmittelbares Laden sind getrennte Vorgänge. Wähle den hochgeladenen Save ausdrücklich, betrete die Welt und kontrolliere bekannte Bauwerke. Erst dann lässt sich beurteilen, ob der richtige Inhalt angekommen ist.

Kann ich einen älteren Stand dauerhaft weiterspielen?

Ja, wenn er mit deiner Installation ladbar ist und den gewünschten Inhalt enthält. Sichere die anderen Kandidaten, lade den alten Stand, prüfe ihn und speichere die gewählte Fortsetzung neu. Kontrolliere Auto-Load und die jüngsten Saves dieser Session. Der anschließende Neustarttest zeigt, ob die Fortsetzung wirklich wieder erscheint.

Reicht es, die Save-Datei umzubenennen?

Nein, damit ist die Sessionzuordnung nicht nachgewiesen. Lies die Zuordnung in der Verwaltung ab und prüfe das Startziel getrennt. Ein verständlicher manueller Savename ist für deine Dokumentation nützlich, ersetzt aber keine Auswahl und keinen Neustarttest.

Muss ich alte Autosaves löschen?

Nicht für die erste Diagnose. Sichere und vergleiche sie zunächst. Ein alter Autosave kann der einzige noch vorhandene gewünschte Stand sein. Wenn später eine gezielte Bereinigung erforderlich ist, bewahre exportierte Kopien außerhalb der aktiven Ablage auf und dokumentiere, was entfernt wurde.

Soll ich zuerst den Server neu installieren?

Beginne mit Serveridentität, Save-Auswahl, Auto-Load und Persistenz der Einstellungen. Eine Neuinstallation kann zusätzliche Variablen ändern und die Diagnose erschweren. Wenn eine Installation tatsächlich repariert werden muss, brauchst du vorher einen vollständigen Wiederherstellungsplan samt gesicherten Daten.

Ist ein leerer Rucksack ein Zeichen für die falsche Fabrik?

Nicht zuverlässig. Prüfe zuerst Gebäude und Fortschritt. Ein anderer Online-Spielerbezug kann einen anderen Charakter erklären. Stimme daher Kontozugang und tatsächlichen Weltzustand ab, bevor du den Fortschritt der gesamten Gruppe zurücksetzt.

Was gebe ich dem Support oder meinem Serveradministrator?

Nenne den genauen Zeitpunkt, Servereintrag, Branch und Build, gewünschte und aktive Session, Auto-Load-Wert sowie den getesteten Save. Ergänze die Beobachtung vor und nach einem regulären Neustart und die relevante Fehlermeldung. Beschreibe auch, ob der Save manuell lädt. Übermittle keine Passwörter oder Tokens; Spielstände mit privaten Daten nur über einen dafür vorgesehenen geschützten Weg.

Quellen und Prüfstand

Prüfstand: Quellen gelesen am 29. Oktober 2026. Die Hersteller-FAQ bestätigt Sicherungen, Versionswechsel und die genannten Abgrenzungen. Die von Coffee Stain verlinkte Community-Wiki dokumentiert den Server Manager und die Bedeutung des Auto-Load-Ziels. Deren Direktabruf war bei dieser Prüfung gesperrt; die relevanten Aussagen waren im aktuellen Suchindex lesbar. Die API-Begriffe wurden zusätzlich in der öffentlich verfügbaren Spiegelung der mitgelieferten Dokumentation geprüft. Ein Test auf einer konkreten aktuellen Serverinstallation wurde nicht durchgeführt.

• Coffee Stain: Support und FAQ
• Satisfactory Wiki: Dedicated Server
• Öffentliche Spiegelung der Server-API-Dokumentation
• FICSIT: API-Referenz im Installationsordner

Die Prüfprotokolle und der Beispielablauf sind redaktionelle Hilfsmittel. Sie versprechen keine Wiederherstellung nicht vorhandener Daten. Bewahre die unveränderte Sicherung auf, bis eure Gruppe die richtige Fabrik und ihren Fortschritt nach dem Neustart bestätigt hat.