Mod-Konflikte und Serverabstürze in Arma Reforger lösen
Der Wechsel der Arma-Serie auf die neue Enfusion-Engine hat die Verwaltung von Modifikationen grundlegend verändert. In Arma Reforger werden Mods direkt über die integrierte Werkstatt (Bohemia Workshop) heruntergeladen und aktualisiert, während ihre Steuerung ausschließlich über JSON-Konfigurationsdateien erfolgt. Allerdings reagiert die Architektur der neuen Engine äußerst empfindlich auf Fehler im Addon-Code. Ein fehlerhaftes Skript oder ein Replikationskonflikt zwischen zwei komplexen Modifikationen für Fahrzeuge oder Waffen kann dazu führen, dass der Server in eine endlose Neustart-Schleife gerät oder beim Laden von Szenarien wie Conflict oder Combat Operations komplett einfriert.
In diesem Artikel analysieren wir, wie Sie Server-Protokolldateien (console.log) professionell auswerten, Mods identifizieren, die die Netzwerkreplikation stören, und die Ladereihenfolge der Addons im Hosting-Control-Panel optimal strukturieren.
Teil 1: Wo ist die console.log zu finden und wie liest man sie?
Wenn ein Arma Reforger-Server unerwartet abstürzt, registriert das Hosting-Panel den Ausfall, liefert jedoch keine technische Begründung. Die Antwort verbirgt sich immer in den Textprotokollen des Servers. Navigieren Sie über den integrierten Dateimanager oder einen SFTP-Client in das Verzeichnis Ihres Serverprofils (standardmäßig profile/logs/ oder das Stammverzeichnis des Servers) und suchen Sie nach der neuesten Datei console.log oder application.log.
Scrollen Sie ans Ende des Dokuments – direkt vor der Systemzeile, die das Beenden des Prozesses ankündigt, finden Sie kritische Fehler (Errors) und Warnungen (Warnings). In der Enfusion-Engine sind diese präzise klassifiziert.
Teil 2: Die wichtigsten Replikationsfehler und Skriptausnahmen
1. Netzwerkreplikationsfehler (Replication Token / Node Errors)
Der Netzwerkcode der Enfusion-Engine basiert auf einem strukturierten Replikationssystem – einer strikten Vereinbarung zwischen der Serverinstanz und der Clientanwendung darüber, welche Zustandsparameter von Objekten über das Netzwerk übertragen werden. Wenn eine Mod versucht, die Eigenschaften eines Fahrzeugs zu ändern (z. B. Panzerung hinzuzufügen), während eine andere Mod gleichzeitig die Radphysik desselben Fahrzeugs überschreibt, bricht das Netzwerklayout des Servers zusammen.
In den Protokollen äußert sich dies wie folgt:
[Replication] ERROR: Component 'SCR_VehicleWeaponComponent' has mismatched replication layout!
[Server] CRASH: REPL_RECONCILE_FAILED for entity: Vehicle_Ural4320_RHS
Auswertung: Die Engine verweist direkt auf einen Desynchronisationskonflikt innerhalb der Waffensystem-Komponente (SCR_VehicleWeaponComponent) eines Ural-Trucks, der aus dem RHS-Modifikationspaket stammt. Das bedeutet, dass zwei installierte Mods gleichzeitig versuchen, das Schussverhalten oder die Turmsteuerung dieses Fahrzeugs zu beeinflussen.
2. Skript-Laufzeitausnahmen (Script Runtime Exceptions)
Die in Reforger verwendete Programmiersprache Enforce Script ist streng typisiert. Wenn ein Mod-Entwickler einen Logikfehler einbaut (z. B. auf einen Objekt-Pointer verweist, der serverseitig noch gar nicht geladen oder instanziiert wurde), stoppt der Engine-Thread augenblicklich und bricht den laufenden Spielmodus ab.
(E) Script: Runtime exception: 'Null pointer' access
(E) Script: Function: 'BaseGameMode.OnPlayerSpawned()' at MyCoolMod/Scripts/Game/GameMode/OnPlayerSpawn.c:42
Auswertung: Der Absturz wurde durch den Zugriff auf einen nicht existierenden Speicherpointer (Null pointer) innerhalb der Spieler-Spawn-Logik verursacht. Das Protokoll verweist direkt auf den Dateipfad im Mod-Ordner: Verzeichnis MyCoolMod, Zeile 42. Dieses Addon muss umgehend deaktiviert oder aktualisiert werden.
Teil 3: Die Ladereihenfolge richtig anpassen (Die JSON-Hierarchie)
Im Gegensatz zu Arma 3, bei dem die Ladereihenfolge über Startparameter gesteuert wurde, liest Arma Reforger aktive Modifikationen aus dem mods-Array innerhalb der Datei config.json aus. Die Engine verarbeitet diesen Block strikt von oben nach unten. Wenn eine komplexe Modifikation eine grundlegende Framework-Mod benötigt, um ihre Klassen aufzulösen, muss diese Basis-Mod weiter oben in der Liste stehen.
Beispiel für ein optimiertes Mod-Array in der config.json:
"mods": [
{
"modId": "595F284F4E402BF4",
"name": "RHS_Status_Quo_Core",
"version": "1.0.5"
},
{
"modId": "5A3B189C4F201AA2",
"name": "RHS_Extra_Vehicles_Extension",
"version": "1.0.2"
},
{
"modId": "5C2A449B8D105FF4",
"name": "Server_Admin_Tools",
"version": "2.1.0"
}
]
Grundregeln für die Strukturierung der Mod-Hierarchie:
- Basis-Frameworks und Core-Mods: Platzieren Sie globale Modifikationen (wie RHS Status Quo, grundlegende Kartenerweiterungen oder Skriptbibliotheken) immer an die absolute Spitze des Arrays. Diese definieren die grundlegenden Objektklassen.
- Sub-mods und Addon-Erweiterungen: Modifikationen, die spezifische Tarnungen, Visiere oder einzelne Fahrzeuge zu größeren Paketen hinzufügen, müssen zwingend nach ihren Haupt-Abhängigkeiten eingereiht werden.
- Server-Tools und Administration: Plugins für Server-Logs, Admin-Menüs und Rechteverwaltung sollten am Ende des JSON-Arrays stehen. So wird sichergestellt, dass sie erst initialisiert werden, wenn die Spielwelt und alle Kernelemente erfolgreich geladen wurden.
Schritt-für-Schritt-Checkliste zur Behebung versteckter Konflikte
Wenn Ihr Server abstürzt, die Protokolle jedoch keine eindeutige Mod-ID nennen, nutzen Sie die Bisektionsmethode (Halbierungsverfahren), um den Fehler einzugrenzen:
- Erstellen Sie eine Sicherheitskopie Ihrer funktionierenden
config.json. - Deaktivieren Sie genau die Hälfte der installierten Mods aus Ihrer JSON-Liste.
- Starten Sie den Server neu und versuchen Sie, ein Conflict-Szenario zu laden.
- Wenn der Server fehlerfrei startet, liegt die problematische Mod in der Hälfte der Liste, die Sie gerade isoliert haben.
- Tritt der Absturz erneut auf, befindet sich die fehlerhafte Mod unter den verbleibenden aktiven Addons.
- Wiederholen Sie dieses 50/50-Teilungsverfahren rekursiv, bis Sie die spezifische
modIdisoliert haben, die den Thread-Fehler verursacht.
| Absturz-Symptom | Technische Ursache | Lösungsstrategie |
|---|---|---|
Server friert beim Schritt [GameMode] Spawn entities... ein |
Konflikt zwischen benutzerdefinierten Spawn-Punkten im Szenario oder auf der Karte. | Prüfen Sie, ob gleichzeitig zwei verschiedene Karten-Modifikationen geladen sind, die dieselbe Zielregion überschreiben (z. B. konkurrierende Everon-Overrides). |
Spieler werden mit der Meldung Connection Timeout / Replication Loss gekickt |
Eine unoptimierte Skript-Mod überflutet die Netzwerkkarte mit zu vielen hochfrequenten RPC-Paketen. | Deaktivieren und entfernen Sie Mods, die hochauflösende Einrichtungsgegenstände oder komplexe Kleidungsstücke mit aufwendigen prozeduralen Animationsskripten hinzufügen. |
| Endlose Mod-Downloadschleife bei Server-Neustarts | Die config.json verweist auf eine veraltete Versionsnummer, die auf den Workshop-Servern nicht mehr existiert. |
Löschen Sie den Text innerhalb des "version"-Attributs (lassen Sie leere Anführungszeichen stehen: ""). Der Server fragt dann automatisch die neueste stabile Version ab. |
Hinweis für Server-Admins: Nach großen Updates des Hauptspiels durch Bohemia Interactive werden interne API-Klassen innerhalb der Enfusion-Engine häufig geändert oder entfernt. Es wird dringend empfohlen, skriptbasierte Gameplay-Mods in den ersten 24–48 Stunden nach einem Patch zu pausieren, bis die Mod-Entwickler entsprechende Kompatibilitäts-Updates veröffentlicht haben.