Rust-Plugins fehlen nach dem Update: Framework, Plugin oder Abhängigkeit?

Kurzantwort: Prüfe nach einem Rust-Update zuerst das tatsächlich laufende Framework. Unter Oxide helfen oxide.version, oxide.plugins und der Startlog. Fehlt nur ein Plugin, unterscheide Compilerfehler, fehlende Abhängigkeit und Konfigurationsfehler. Geladene Plugins schließen einen Frameworkfehler nicht aus. Sichere Dateien und Spielstand vor Änderungen; ein Wipe oder das Löschen aller Configs ist kein sinnvoller erster Diagnoseschritt.

Dieser Guide gilt für Rust Dedicated Server der PC-Version, selbst gehostet oder bei einem beliebigen Anbieter. Du brauchst für administrative Schritte Zugriff auf die echte Serverkonsole beziehungsweise autorisiertes RCON und gegebenenfalls auf die Serverdateien. Ein Kundenkonto bei SupremeTier ist nicht erforderlich. Spielst du nur auf dem betroffenen Server, beginne mit dem nächsten Abschnitt.

Stand: 29. Oktober 2026. Die Befehle im Hauptablauf beziehen sich auf Oxide. Carbon wird gesondert eingeordnet. Die Fehlerpfade „einzelnes Plugin kompiliert nicht“ und „Abhängigkeit fehlt“ wurden auf einem eigenen isolierten Testserver kontrolliert ausgelöst und repariert. Diese Proben simulieren Fehlerzustände; sie sind keine Beobachtung eines ausgefallenen Fremdplugins nach dem Update. Auch ein absichtlich gemischter Framework-Stand wurde isoliert geprüft. Dabei luden Plugins, während ein Framework-Hook scheiterte. Die folgenden Originalausgaben stammen aus kontrollierten Fehlerproben und werden nicht als natürlicher Vorfall eines Kundenservers dargestellt.

Als Spieler: Was kannst du tun?

Ein verschwundenes /kit-Menü beweist nicht, dass dein Inventar gelöscht wurde. Vielleicht fehlt nur das Plugin, das den Befehl bereitstellt. Frage zuerst, ob andere Spieler dieselbe Funktion vermissen und ob mehrere voneinander unabhängige Funktionen betroffen sind. Notiere den Zeitpunkt, den eingegebenen Befehl und die sichtbare Antwort. Ein Screenshot einer Meldung hilft; private Spielernamen kannst du vor dem Weitergeben abdecken.

Melde beispielsweise: „Seit dem Neustart gegen 19 Uhr erscheint bei meinem Kit-Befehl keine Antwort. Teleport funktioniert ebenfalls nicht. Normales Bauen funktioniert. Vor dem Neustart ging beides.“ Damit kann die Administration gezielt nach dem zugehörigen Startlauf suchen. Die Aussage „Alles wurde gewiped“ wäre ohne Prüfung zu weitgehend.

Installiere keine zufällig angebotenen Clientdateien als vermeintliche Reparatur eines Serverplugins. Als Spieler kannst du das serverseitige Framework nicht neu laden. Falls Schutzfunktionen fehlen, etwa die auf diesem Server zugesagten PvE-Regeln, verlasse dich bis zur Klärung nicht darauf. Die Administration muss entscheiden, ob normales Weiterspielen sicher ist.

Erst die drei Ebenen auseinanderhalten

Ein modifizierter Rust-Server besteht für diese Diagnose aus drei Ebenen. Rust selbst stellt Spielwelt und Spielabläufe bereit. Das Framework, hier Oxide oder alternativ Carbon, ermöglicht die Erweiterungen. Einzelne Plugins implementieren etwa Kits, Teleport, Verwaltungsfunktionen oder Änderungen an Spielregeln. Manche Plugins benötigen weitere Plugins oder Extensions.

Wenn eine untere Ebene fehlt, wirken viele darüberliegende Funktionen gleichzeitig kaputt. Wenn eine einzelne Erweiterung ausfällt, können die übrigen weiterarbeiten. Diese Unterscheidung ist der Ausgangspunkt, aber noch kein Beweis: Auch mehrere Plugins können dieselbe fehlende Bibliothek benötigen. Umgekehrt kann ein Framework antworten und dennoch bei bestimmten Spielereignissen Probleme haben.

„Datei vorhanden“, „kompiliert“, „geladen“ und „funktioniert“ sind vier verschiedene Zustände. Eine .cs-Datei im richtigen Ordner belegt nur, dass dort Quellcode liegt. Kompilieren bedeutet, dass daraus ausführbarer Code erzeugt wurde. Laden umfasst die Initialisierung. Erst der gezielte Funktionstest zeigt, ob das gewünschte Verhalten mit deinen Einstellungen und Berechtigungen tatsächlich arbeitet.

Die offizielle Oxide-Dokumentation zur Plugininstallation beschreibt .cs-Dateien, automatisches Kompilieren und das Pluginverzeichnis. Verwechsle diese Dateiebene nicht mit dem sichtbaren Erfolg im Spiel.

Der schnelle Entscheidungsweg

Beginne nach abgeschlossenem Serverstart in der Serverkonsole, nicht im normalen Spielchat. Diese erste Prüfung verändert keine Plugins:

oxide.version
oxide.plugins

oxide.version fragt die Frameworkversion ab. oxide.plugins listet Plugins einschließlich fehlgeschlagener Ladeversuche auf. Die offizielle Befehlsreferenz beschreibt die Pluginliste und die gezielten Ladebefehle; der Owner-Guide zu Commands erklärt Konsole und Chat.

Ein unbekannter Befehl ist ein Hinweis, keine fertige Diagnose. Prüfe, ob du wirklich die Konsole des betroffenen Servers geöffnet hast, ob der Start abgeschlossen ist und ob dieser Server überhaupt Oxide verwendet. Bei Carbon ist ein Oxide-spezifischer Test allein keine ausreichende Grundlage.

Vor jeder Reparatur: Belege und Rückweg sichern

Eine gute Diagnose beginnt mit einer kurzen Bestandsaufnahme. Halte fest, wann der Fehler erstmals auffiel, welches Spielupdate oder welcher Neustart vorausging und was seitdem bereits geändert wurde. Sichere den zusammenhängenden Startlog vom Prozessbeginn bis zur ersten Fehlermeldung. Eine Bildschirmaufnahme der letzten roten Zeile reicht häufig nicht, weil sie nur den Folgefehler zeigt.

Oxide schreibt Lade- und Compilerfehler zusätzlich in eigene Logdateien im Ordner oxide/logs deiner Serverinstallation. Dort steht eine Meldung oft vollständiger als im sichtbaren Konsolenausschnitt, etwa wenn die Konsole nur die letzten Zeilen anzeigt. Wähle die Datei, deren Datum zum betroffenen Start passt, und sichere sie zusammen mit dem Konsolenlog.

Notiere Rust-Version beziehungsweise Buildinformation, den verwendeten Releasezweig, Betriebssystem, Frameworkversion und betroffene Pluginversionen. Bewahre die Downloadquelle der installierten Dateien auf. „Neueste Version“ ist keine wiederholbare Versionsangabe: Die Datei kann seit deinem Download ersetzt worden sein, oder dein Startskript lädt einen anderen Stand als erwartet.

Was gehört ins Backup?

Sichere einen zusammengehörigen Stand der Welt- und Spielerdaten, der Startkonfiguration und der Modding-Dateien. Bei Oxide gehören insbesondere oxide/plugins, oxide/config und oxide/data in die Bestandsaufnahme; berücksichtige außerdem Berechtigungsdaten und eigene Erweiterungen. Die konkrete Speicherstruktur hängt von der Installation ab. Prüfe deine tatsächlich verwendeten Pfade, statt ein Beispielverzeichnis blind zu übernehmen.

Unterscheide Einstellungen von Nutzdaten. Eine Config bestimmt beispielsweise das Verhalten eines Plugins; dessen Daten können bereits vergebene Belohnungen, gespeicherte Positionen oder andere dauerhafte Zustände enthalten. Der Inhalt ist pluginabhängig. Ein pauschales Leeren von oxide/data kann deshalb mehr verändern als die fehlerhafte Funktion.

Nutze für eine konsistente Sicherung den dokumentierten Backupablauf deiner Installation. Eine Kopie während laufender Schreibzugriffe kann uneinheitlich sein. Prüfe, ob das Backup wirklich abgeschlossen und abrufbar ist. Entpacke oder kontrolliere es an einem getrennten Ort, ohne den aktuellen Server zu überschreiben. Ein angezeigter Backupname allein ist noch kein geprüfter Rückweg.

Lege die Grenze deiner Änderung fest

Schreibe vor dem Eingriff auf: „Ich ersetze nur diese Plugin-Datei“ oder „Ich installiere das zum aktuellen Rust-Stand passende Oxide-Paket neu“. Dazu gehören die gesicherte alte Datei, die neue Datei und das Erfolgskriterium. Ändere nicht gleichzeitig Framework, mehrere Plugins, Configs und Mapparameter. Sonst weißt du nachher nicht, welcher Eingriff geholfen oder geschadet hat.

Wenn ein Schutz-, Wirtschafts- oder Zugriffsplugin ausfällt, entscheide vor dem Test über die Verfügbarkeit des Servers. Eine technisch erreichbare Welt ist nicht automatisch unter den zugesagten Regeln spielbar. Kündige eine notwendige Unterbrechung an und nutze den regulären Stoppweg deiner Installation. Wiederholte harte Abbrüche ersetzen keine Diagnose.

Fall A: Das Framework fällt aus

Typische Konstellation: Der Server startet nach einem Spielupdate, aber zahlreiche voneinander unabhängige Pluginfunktionen fehlen. Oxide ist im aktuellen Startlog nicht erfolgreich erkennbar oder die Versionsabfrage liefert im richtigen Konsolenkontext keine Frameworkversion.

Die zu prüfende Ursache ist nicht nur „Oxide zu alt“. Das Spielupdate kann veränderte Dateien ersetzen; ein Startskript kann anschließend wieder Vanilla-Dateien herstellen; das Framework kann ins falsche Serververzeichnis entpackt worden sein. Ebenso kommen ein falsches Betriebssystempaket, ein nicht passender Spielzweig oder ein unvollständiger Upload infrage.

Facepunch weist in der Anleitung zum Dedicated Server ausdrücklich darauf hin, dass ein Spielupdate eine erneute Oxide-Installation erfordern kann und SteamCMD im Startablauf Dateien wieder auf Vanilla zurücksetzen kann. Daraus folgt die wichtige Reihenfolge: Spiel aktualisieren, passenden Frameworkstand installieren, dann den Server starten. Ein weiterer Spieldateiabgleich nach der Frameworkinstallation kann die Arbeit wieder zunichtemachen.

Reihenfolge beim Selbsthosting

Bei einem selbst gehosteten Server mit SteamCMD sieht die Reihenfolge so aus. Der Pfad ist ein Beispiel; setze dein tatsächliches Serververzeichnis ein:

steamcmd +force_install_dir /pfad/zum/rustserver +login anonymous +app_update 258550 validate +quit

258550 ist die App-ID des Rust Dedicated Servers. validate prüft die Spieldateien und stellt dabei die Vanilla-Fassung wieder her. Genau deshalb kommt Oxide erst danach: Lade aus dem offiziellen Oxide.Rust-Release das Archiv für dein Betriebssystem, Oxide.Rust-linux.zip für Linux oder Oxide.Rust.zip für Windows. Entpacke es mit seiner Ordnerstruktur in das Serverhauptverzeichnis, also dorthin, wo auch RustDedicated beziehungsweise RustDedicated.exe liegt, und lass bestehende Dateien überschreiben. Starte den Server erst danach und prüfe oxide.version.

Ruft dein Startskript SteamCMD vor jedem Start auf, ersetzt es die Oxide-Dateien bei jedem Neustart wieder. Dann gehört die Oxide-Installation ebenfalls ins Startskript, zwischen Update und Serverstart, oder du nimmst das automatische Update aus dem Startskript heraus. Bei Managed Hosting nutzt du stattdessen die Frameworkfunktion deines Anbieters.

Oktober 2026 richtig einordnen

Das uMod-Changelog für Rust enthält unter Oktober 2026 einen Patch für das Rust-Update vom 22. Oktober mit der Angabe 2635.289.1. Außerdem sind mehrere frühere Oktober-Hotfixes aufgeführt. Diese Angabe aus dem Changelog ist keine Oxide-Paketversionsnummer und keine Garantie für jeden späteren Serverstand. Der zugehörige offizielle Oxide.Rust-Release 2.0.7839 wurde am 22. Oktober 2026 um 18:02:03 UTC veröffentlicht. Bei unserer letzten Prüfung am 29. Oktober 2026 war er weiterhin der neueste Oxide.Rust-Release. Auf unserem isolierten Testserver meldeten version und oxide.version später tatsächlich Rust-Protokoll 2635.289.1 und Oxide.Rust 2.0.7839. Das ist eine konkrete Testkombination, keine dauerhafte Empfehlung, diese Nummern auch nach späteren Updates beizubehalten.

Prüfe beim tatsächlichen Eingriff erneut den aktuellen Release und den Rust-Stand deines Servers. Die Existenz eines passenden Releasehinweises beweist nicht, dass dein Anbieter oder Startskript diese Version bereits installiert hat. Entscheidend ist die anschließend aus der laufenden Instanz gelesene Version zusammen mit dem aktuellen Startlog.

Eigene Probe A: Frameworkfehler trotz geladener Plugins

Unser Ausgangsstand war Rust-Protokoll 2635.289.1 mit dem dazugehörigen Oxide.Rust 2.0.7839. Nach einem regulären Stopp und einer Sicherung der eigenen Testwelt samt Oxide-Verzeichnis setzten wir nur auf dem isolierten Testserver absichtlich die alte Oxide.Rust.dll aus dem offiziellen Release 2.0.7072 vom 19. Februar 2026 ein. Die übrige aktuelle Installation blieb bestehen. Das simuliert einen gemischten, nicht zusammenpassenden Framework-Stand; es ist kein Test eines vollständigen historischen Serverpakets.

Die Änderung wurde über den SHA-256 der tatsächlich eingesetzten DLL geprüft. Beim Start trat diese echte Meldung auf:

Failed to call hook 'IOnServerCommand' on plugin 'RustCore v2.0.7072' (MissingFieldException: Field not found: string .Arg.FullString Due to: Could not find field in class)

Gleichzeitig erreichten eigene Testplugins ihre Initialisierungsmarker. Der Serverprozess lief ebenfalls weiter. Das ist der wichtige Unterschied zu einer zu einfachen Faustregel: Ein Frameworkproblem muss nicht alle Plugins am Laden hindern. Eine erfolgreiche Pluginliste oder ein laufender Prozess ist keine vollständige Kompatibilitätsprüfung.

Die Meldung benennt RustCore, also eine Frameworkkomponente, und einen nicht gefundenen Feldzugriff. Sie ist kein JSON-Fehler einer Kit-Konfiguration. In dieser gezielt hergestellten Kombination liegt die Ursache im nicht zusammenpassenden Framework-Stand. Ein gleichlautender Fehlertyp bei einem anderen Namen kann dagegen in einem einzelnen Plugin entstehen; lies immer Komponente, Hook und Kontext zusammen.

Für die minimale Rücknahme stellten wir die zuvor gebundene passende DLL 2.0.7839 wieder her und starteten kontrolliert neu. Danach antwortete oxide.version wieder mit 2.0.7839, oxide.plugins listete alle vier eigenen Testplugins und der zuvor beobachtete MissingFieldException war im neuen verfügbaren Konsolenpuffer nicht mehr vorhanden. Der Rückweg zum passenden Framework ist damit für diese konkrete Probe geprüft. Für deinen produktiven Server folgt daraus keine Empfehlung, einzelne DLLs aus beliebigen Archiven zusammenzukopieren: Nutze dort den vollständigen passenden Framework-Installationsweg, damit der Stand konsistent ist.

Die Probe verwendet bewusst einen deutlich älteren Release. Sie behauptet weder, dass jede ältere Version identisch scheitert, noch dass genau dieses Fehlerbild bei jedem Oktoberupdate auftritt. Ein Frameworkausfall kann auch einfach Vanilla ohne geladenes Oxide bedeuten. Deshalb bleibt die Kombination aus tatsächlicher Version, erster Logdiagnose und Funktionstest nötig.

Minimale Reparatur

1. Sichere Ausgangszustand und Log. Prüfe, ob ein automatischer Updater gerade arbeitet. Starte keinen zweiten gegenläufigen Installationsvorgang.
2. Gleiche Rust-Stand, Releasezweig, Betriebssystem und den dafür vorgesehenen Frameworkrelease ab.
3. Stoppe den Server regulär, wenn die Installation Änderungen an den Frameworkdateien erfordert.
4. Nutze den dokumentierten Installationsweg. Bei Selbsthosting entpackst du das vertrauenswürdige, passende Archiv unter Erhalt seiner Verzeichnisstruktur in die richtige Installation, in der oben beschriebenen Reihenfolge. Bei Managed Hosting nutze dessen Frameworkfunktion; übertrage keine fremden Panelmenüs auf deinen Anbieter.
5. Kontrolliere die Update-Reihenfolge und starte einmal kontrolliert. Lies den neuen Startlog.
6. Prüfe Frameworkversion, Pluginliste und mindestens eine zuvor ausgefallene Funktion.

Erfolg: Das erwartete Framework antwortet aus der richtigen Instanz, die erwarteten Plugins laden, und die geprüfte Funktion arbeitet. Rückweg: Bewahre den Zustand vor dem Eingriff. Spiele nicht blind eine alte Frameworkdatei über ein neues Spiel zurück. Wenn nur ein älteres Gesamtpaket kompatibel war, muss dessen Wiederherstellbarkeit einschließlich Weltformat und Clientkompatibilität separat geprüft werden. Ist sie unklar, bleibt der Server kontrolliert außer Betrieb, bis eine passende Version verfügbar ist.

Fall B: Ein Plugin kompiliert nicht

Typische Konstellation: Oxide antwortet, andere Plugins werden geladen, aber ein bestimmtes Plugin erscheint als fehlgeschlagen. Der Log nennt einen Compilerfehler, häufig mit Datei, Zeile, Spalte und einem fehlenden Symbol oder einer nicht mehr passenden Methode.

Ein Compilerfehler bedeutet zunächst nur: Der vorliegende Quellcode lässt sich gegen die verfügbaren Referenzen nicht übersetzen. Ein Spielupdate kann eine verwendete Schnittstelle geändert haben. Möglich sind aber auch ein beschädigter Download, eigener geänderter Code oder eine fehlende harte Abhängigkeit. „Failed to compile“ bedeutet deshalb nicht automatisch „Der Autor muss nur eine neue Version veröffentlichen“.

Eigene Probe B: Ein Compilerfehler

Auf unserem isolierten Testserver mit Rust-Protokoll 2635.289.1 und Oxide.Rust 2.0.7839 enthielt ausschließlich das Testplugin Guide7CompileBroken.cs eine absichtliche #error-Zeile. Das bereits geladene Kontrollplugin Guide7Probe blieb davon getrennt. Die echte Konsolenausgabe lautete:

Error while compiling Guide7CompileBroken: #error: 'GUIDE7_INTENTIONAL_COMPILE_FAILURE' | Line: 1, Pos: 8

Für die minimale Reparatur entfernten wir nur die absichtlich eingefügte Fehlerzeile. Danach meldete die Konsole:

Guide7CompileBroken was compiled successfully in 362ms
Loaded plugin Guide7CompileBroken v1.0.0 by Guide7 isolated test fixture

Der Rückweg für diese kontrollierte Probe ist die Wiederherstellung der unveränderten Fehlerdatei; damit würde derselbe absichtliche Compilerfehler erneut entstehen. Für ein echtes Drittplugin ist „irgendeine Zeile löschen“ ausdrücklich keine Reparaturanleitung. Unsere Probe belegt die Trennung von Framework und Plugincompiler, keinen konkreten API-Bruch durch das Oktoberupdate. Die beobachteten 362 ms beschreiben nur diesen einzelnen Test, keine allgemeine Ladezeit.

Suche im echten Log, in der Konsole oder in oxide/logs, zuerst den Namen der betroffenen Datei und die erste Compilerdiagnose. Ein späteres „Plugin konnte nicht geladen werden“ wiederholt oft nur das Ergebnis. Prüfe, ob mehrere Plugins exakt dasselbe fehlende Symbol nennen: Dann kann eine gemeinsame API-Änderung oder Referenz betroffen sein, statt mehrerer unabhängiger Defekte.

Lade ein Update ausschließlich aus der dokumentierten Quelle des Plugins. Lies die Änderungsnotizen: Beheben sie dein Problem, verlangen sie eine neue Abhängigkeit oder ändern sie das Datenformat? Eine höhere Versionsnummer allein garantiert keine Kompatibilität mit deiner Kombination.

Minimale Reparatur

Sichere die bisherige .cs-Datei sowie zugehörige Config und Daten. Ersetze zunächst nur das betroffene Plugin durch den vorgesehenen korrigierten Stand. Oxide beobachtet normalerweise Änderungen im Pluginordner; vermeide deshalb doppelte Uploads und hektische zusätzliche Reloads. Verfolge den Vorgang in der Konsole und prüfe danach den tatsächlichen Stand.

Wenn ein gezieltes Neuladen erforderlich ist, lautet die Form:

oxide.reload Pluginname

Pluginname steht hier für den tatsächlichen Plugin-Dateinamen ohne .cs, nicht für den Marketingtitel eines Downloads. Die offizielle Befehlsreferenz dokumentiert diesen gezielten Reload. Nutze während der Eingrenzung keinen Wildcard-Reload aller Plugins. Er verändert unnötig viele Zustände und kann neue Fehler erzeugen.

Erfolg: Die Compilerdiagnose verschwindet, der erwartete Pluginstand wird geladen und die konkret betroffene Funktion besteht den Test. Rückweg: Wenn das Update scheitert, sichere auch diesen neuen Log. Stelle nur dann die alte Pluginfassung samt erforderlichem Datenstand wieder her, wenn diese Kombination zum aktuellen Spiel passt. Eine alte Datei, die nach dem Spielupdate bereits kaputt war, ist kein funktionsfähiger Rollback.

Fehlt ein kompatibler Fix, kann es sinnvoll sein, ausschließlich das betroffene Plugin vorübergehend zu deaktivieren. Prüfe vorher, welche anderen Plugins und Spielregeln davon abhängen. Verschiebe die gesicherte Quelldatei bei regulär gestopptem Server aus dem überwachten Pluginverzeichnis in einen getrennten Sicherungsordner. Lösche dabei weder Config noch Nutzdaten. Dokumentiere, welche Funktion bis zur Reparatur fehlt.

Fall C: Eine Abhängigkeit fehlt

Typische Konstellation: Ein Plugin nennt eine fehlende Voraussetzung. Andere Funktionen arbeiten weiter, oder mehrere ausgefallene Plugins hängen an derselben Bibliothek. Die vermisste Datei kann sogar vorhanden sein, aber selbst nicht laden.

Die Oxide-Richtlinie zu Abhängigkeiten unterscheidet optionale, erforderliche und harte Abhängigkeiten. Eine optionale Integration erweitert das Verhalten. Eine erforderliche Voraussetzung wird für die Funktion gebraucht. Eine harte Abhängigkeit kann bereits das Kompilieren verhindern. Die Begriffe erklären, warum „Abhängigkeit fehlt“ und „Compilerfehler“ sich überschneiden können.

Eigene Probe C: Eine fehlende Abhängigkeit

Auf demselben Testserver lud das eigene Testplugin Guide7Consumer.cs mit der deklarierten Voraussetzung // Requires: Guide7Dependency. Die zugehörige Abhängigkeit war zunächst absichtlich nicht installiert. Dies sind echte Ausgaben der kontrollierten Probe:

Guide7Consumer plugin requires missing dependency: Guide7Dependency
Ignored unexpected plugin compilation failure: Guide7Consumer
Error while compiling Guide7Consumer: Missing dependency: Guide7Dependency

Hier steht ebenfalls „Error while compiling“. Der entscheidende Zusatz ist aber die ausdrücklich benannte fehlende Abhängigkeit. Wir installierten ausschließlich Guide7Dependency.cs und luden anschließend den Verbraucher gezielt neu. Danach erschienen beide Initialisierungsmarker und beide Ladebestätigungen:

[Guide7Dependency] GUIDE7_DEPENDENCY_READY
Loaded plugin Guide7Dependency v1.0.0 by Guide7 isolated test fixture
[Guide7Consumer] GUIDE7_CONSUMER_READY
Loaded plugin Guide7Consumer v1.0.0 by Guide7 isolated test fixture

Die Marker belegen die Initialisierung beider Testplugins, keinen Shop-, Teleport- oder Schutzfunktionstest eines Fremdplugins. Für den Rückweg dieser Probe würde nach dem Entladen des Verbrauchers nur die eigene Abhängigkeit entfernt. Wiederholtes Neuladen des Verbrauchers allein installiert seine Voraussetzung nicht. Scheitert in deinem echten Log zunächst die Abhängigkeit selbst, behebe deren ersten Fehler zuerst. Eine ähnlich benannte Bibliothek aus einer zufälligen Downloadquelle ist kein Ersatz.

Prüfe die Pluginseite und die Dokumentation auf den exakten Namen, die Art der Abhängigkeit und gegebenenfalls geforderte Versionen. Ein weiteres .cs-Plugin und eine kompilierte Extension sind unterschiedliche Dinge. Sie können unterschiedliche Installationsorte und Neustartanforderungen haben. Verwende für Extensions deren eigene Installationsanleitung; kopiere eine DLL nicht auf Verdacht in oxide/plugins.

Minimale Reparatur

Erstelle eine kleine Kette: betroffenes Plugin → benötigte Voraussetzung → Status dieser Voraussetzung. Prüfe die Voraussetzung in der Pluginliste und im Startlog. Fehlt sie tatsächlich, installiere genau diese aus ihrer offiziellen Quelle. Ist sie bereits vorhanden, behebe ihren ersten Fehler, statt dieselbe Datei wieder und wieder hochzuladen.

Bei einer gewöhnlichen Pluginabhängigkeit kannst du anschließend gezielt zuerst die Voraussetzung und dann den Verbraucher laden, sofern deren Dokumentation diesen Ablauf unterstützt. Bei einer Extension oder geänderter Startinitialisierung kann ein kontrollierter Neustart nötig sein. Behandle einen Neustart als überprüfbaren Schritt mit neuem Log, nicht als automatisches Heilmittel.

Erfolg: Voraussetzung und Verbraucher laden in den vorgesehenen Versionen; die Funktion, die beide verbindet, arbeitet. Eine bloße Liste zweier geladener Plugins genügt dafür nicht. Rückweg: Stelle die gesicherte kompatible Kombination wieder her oder deaktiviere den Verbraucher, solange seine Voraussetzung fehlt. Prüfe vor einem Downgrade, ob die neue Version bereits Configs oder Daten umgeschrieben hat.

Geladen, aber ohne Funktion

Wenn ein Plugin als geladen erscheint, wechsle von der Installationsdiagnose zum Funktionstest. Prüfe zuerst, ob du die richtige Funktion mit dem richtigen Konto testest. Ein Admin kann andere Rechte besitzen als ein gewöhnlicher Spieler. Das Ergebnis eines einzigen Adminversuchs lässt sich deshalb nicht automatisch auf alle Spieler übertragen.

Kontrolliere anschließend dokumentierte Berechtigungen und Einstellungen. Sind die benötigte Funktion, Welt, Zone oder Benutzergruppe freigeschaltet? Gibt es Bedingungen wie Cooldown, Kampfstatus oder eine Voraussetzung im Spiel? Diese Beispiele sind mögliche Prüfbereiche, keine Behauptung über jedes Plugin. Entscheidend ist die Dokumentation genau deiner Erweiterung.

Ein erfolgreicher Start beweist außerdem nicht, dass jeder Hook funktioniert. Ein Hook ist eine vom Framework bereitgestellte Anknüpfung an ein Spielereignis. Wird eine solche Schnittstelle verändert, kann ein Plugin laden und erst beim betroffenen Ereignis scheitern oder nicht mehr reagieren. Wiederhole daher den eigentlichen Auslöser und beobachte den Log genau in diesem Moment.

Bei einer Laufzeitausnahme sichere den vollständigen relevanten Stacktrace und die Handlung davor. Änderungen an vielen Berechtigungen „zum Testen“ sind kein guter Ersatz: Sie können Zugriffe erweitern und den ursprünglichen Fehler verdecken. Ein sauberer Vergleich benutzt ein festgelegtes Konto und dokumentierte Rechte.

Warum Configs löschen selten der richtige Anfang ist

Eine Konfigurationsdatei kann tatsächlich fehlerhaft sein. Hinweise sind beispielsweise ein ausdrücklich gemeldeter JSON-Parsefehler oder ein Fehler unmittelbar beim Einlesen einer Einstellung. Ein Compilerfehler über eine fehlende Spielmethode wird dagegen nicht durch das Zurücksetzen sämtlicher Configs repariert.

Die Oxide-Anleitung zu Konfigurationen warnt auch vor Plugins, die beim Entladen Einstellungen zurückschreiben. Eine Bearbeitung während des laufenden Plugins kann dann überschrieben werden. Sichere die Datei, befolge die Anleitung des Plugins und entlade es bei Bedarf vor der Bearbeitung.

Prüfe JSON zunächst lokal mit einem geeigneten Validator. Vertrauliche Werte wie Zugangsdaten oder Webhookadressen gehören nicht in öffentliche Onlinevalidatoren. Gültiges JSON ist allerdings nur die Syntaxprüfung: Ein sauber geschriebenes Feld kann trotzdem einen unzulässigen Wert oder ein veraltetes Schema enthalten.

Falls eine frische Config als Vergleich erforderlich ist, arbeite möglichst in einer isolierten Kopie. Bewahre die Originaldatei unverändert auf. Vergleiche anschließend einzelne Einstellungen und übernimm nur nachvollziehbare Änderungen. Ein vollständiger Reset kann Regeln, Preise, Berechtigungsbezüge oder andere pluginabhängige Vorgaben verändern, ohne dass es im ersten Funktionstest auffällt.

Kein Wipe als Pluginreparatur

Ein Wipe betrifft den Spielstand beziehungsweise ausgewählte Fortschrittsdaten. Ein Plugin-Compilerfehler betrifft Code und dessen Voraussetzungen. Diese Ebenen sind verschieden. Eine neue Welt macht eine entfernte API-Methode nicht wieder verfügbar und installiert keine fehlende Bibliothek.

Dass ein Fehler an einem Wipetag auftritt, beweist keinen Zusammenhang mit beschädigten Weltdaten. Spielupdate, Frameworkupdate, Pluginupdate und Wipe finden häufig im selben Wartungsablauf statt. Trenne diese Ereignisse in deiner Zeitleiste. Prüfe auch, ob nach dem Neustart eine andere Serveridentität oder ein anderes Datenverzeichnis verwendet wurde.

Wenn tatsächlich ein Welt- oder Datenproblem vermutet wird, ist das ein eigener Diagnoseauftrag mit eigener Sicherung und eigenem Erfolgskriterium. Führe ihn nicht als beiläufigen letzten Schritt einer Pluginreparatur aus. Vor dem Wiederherstellen eines älteren Backups muss klar sein, welcher seitdem entstandene Fortschritt verloren ginge und ob der Stand überhaupt kompatibel ist.

Carbon: gleicher Diagnosegedanke, eigener Installationsweg

Wenn der Server Carbon verwendet, beginne mit dessen Versionsabfrage:

c.version

Die Carbon-Konfiguration und die offiziellen Release Notes dokumentieren Carbon-eigene Funktionen und Versionsinformationen. Verwende die Befehle und Pfade deiner tatsächlichen Carboninstallation. Ein fehlgeschlagener Oxide-Befehl allein beweist dort keinen Frameworkausfall.

Die grundlegenden Fragen bleiben gleich: Läuft das Framework? Welche Erweiterungen sind tatsächlich geladen? Scheitert ein einzelner Verbraucher oder eine gemeinsame Voraussetzung? Welche Funktion wurde wirklich geprüft? Daraus folgt aber nicht, dass jedes Oxide-Plugin unverändert unter jeder Carbonversion arbeitet oder dass ein Frameworkwechsel eine risikofreie Sofortreparatur ist.

Wechsle während der Eingrenzung nicht nebenbei zwischen Oxide und Carbon. Eine Migration verändert mehrere Voraussetzungen zugleich. Plane sie separat, sichere Daten und Berechtigungen und teste die benötigten Plugins. Für einen einzelnen Compilerfehler ist die kleinste passende Änderung meistens besser nachvollziehbar als ein vollständiger Plattformwechsel.

Drei Fälle im direkten Vergleich

Diese Gegenüberstellung zeigt den Diagnoseablauf, keine gemessenen Reparaturzeiten. Nicht jeder Fehler passt eindeutig in eine Zeile. Ein fehlendes DLL-Referenzziel kann etwa einen Compilerfehler auslösen. Ordne nach der ersten belegten Ursache, nicht nach der letzten roten Meldung.

So prüfst du die Reparatur belastbar

Lege vor der Änderung einen kleinen Test fest, der den ursprünglichen Ausfall sichtbar macht. Bei einem Kit-Plugin wäre das beispielsweise ein dokumentierter Abruf mit einem dafür vorgesehenen Testkonto und einem bekannten Testkit. Bei einem Schutzplugin ist der vorher zugesagte Schutz unter kontrollierten Bedingungen zu prüfen. Verwende dafür keine fremden Bauten oder echten wirtschaftlichen Werte.

Vergleiche anschließend denselben Test vor und nach genau einer Änderung. Notiere Kontoart, relevante Rechte, Pluginversion, Einstellungen, Handlung und Ergebnis. Prüfe auch eine benachbarte Funktion, die nicht kaputt war. Damit bemerkst du, wenn eine Reparatur zwar das sichtbare Problem löst, aber eine andere zentrale Regel verändert.

Ein sinnvoller Abschluss umfasst fünf Fragen:

• Antwortet das erwartete Framework aus der richtigen Serverinstanz?
• Stimmen die tatsächlich geladenen Pluginversionen mit dem vorgesehenen Stand überein?
• Ist der erste Fehler im neuen Log verschwunden, ohne einen anderen zu erzeugen?
• Funktioniert der konkrete Anwendungsfall mit dem passenden Benutzerkonto?
• Bleibt das Ergebnis nach dem nächsten geplanten kontrollierten Start bestehen?

Der letzte Punkt prüft insbesondere Installationsreihenfolge und Startautomatik. Erzwinge dafür nicht unnötig einen weiteren Neustart während des Spielbetriebs. Ist dieser Nachweis noch ausstehend, dokumentiere die Reparatur als funktionell geprüft mit offenem Startnachweis.

Ein hilfreicher Fehlerbericht

Schicke keine Sammlung ungeordneter Screenshots. Ein kurzer, reproduzierbarer Bericht beschleunigt die Eingrenzung. Die Oxide-Hinweise zum Melden von Problemen empfehlen Umgebungsdaten, Schritte, erwartetes und tatsächliches Ergebnis sowie relevante Logs.

Betroffene Funktion:
Erster beobachteter Fehler mit Datum und Zeitzone:
Rust-Stand und Releasezweig:
Framework und tatsächlich gelesene Version:
Pluginname, Version und Downloadquelle:
Benötigte Abhängigkeiten und deren Status:
Letzte Änderung vor dem Fehler:
Erste vollständige Fehlermeldung:
Schritte zum Nachstellen:
Erwartetes Ergebnis / tatsächliches Ergebnis:
Bereits versuchte einzelne Änderung und Ergebnis:
Vorhandenes Backup und Rückweg:

Entferne Passwörter, Tokens, Webhookadressen und nicht benötigte personenbezogene Angaben aus der Kopie. Bewahre das unveränderte Original geschützt für dich auf. Eine bereinigte Logkopie soll die technische Ursache erhalten: Entferne nicht versehentlich den Plugin-Dateinamen oder die Fehlermeldung, die zur Diagnose nötig ist.

Richte die Anfrage an die passende Stelle. Bei falscher Installationsreihenfolge oder nicht anwählbarem Framework kann der Hosting-Support helfen. Bei einem reproduzierbaren Fehler in einem einzelnen Plugin ist dessen Entwickler häufig der passende Ansprechpartner. Sind mehrere Ebenen unklar, sende die Befunde statt einer voreiligen Schuldzuweisung.

Vor dem nächsten Rust-Update

Führe eine kleine Bestandsliste deiner kritischen Plugins und Abhängigkeiten. Halte fest, welche Spielregeln ohne sie nicht gelten und welche Funktionen lediglich Komfort bieten. So kannst du nach einem Update zuerst die für eure Community entscheidenden Dinge prüfen, statt alphabetisch jede Erweiterung anzufassen.

Sichere vor geplanten Änderungen einen nachvollziehbaren Stand und bewahre die zugehörigen Versionsinformationen auf. Prüfe aktuelle Hinweise des Frameworkprojekts und der wichtigsten Pluginentwickler. Verlasse dich nicht auf eine feste Wartezeit: Ein Release kann schnell erscheinen, aber ein bestimmtes Plugin kann weiterhin eine Anpassung benötigen.

Kontrolliere außerdem, was dein Startskript oder Anbieter automatisiert. Aktualisiert es Rust, das Framework, beides oder keines von beiden? In welcher Reihenfolge? Ein Hoster kann dies bei jedem Start erledigen, ein anderer über eine separate Updatefunktion. Die Anleitung eines fremden Panels beschreibt nicht automatisch deinen Server.

Für größere Communitys lohnt sich ein getrennter Testablauf mit bekannten Testdaten. Eine Probe muss dieselben relevanten Versionen und Einstellungen verwenden, sonst ist ihr Erfolg nur begrenzt aussagekräftig. Dokumentiere Testgrenzen, statt aus einem leeren Testserver allgemeine Stabilitätsversprechen abzuleiten.

FAQ

Muss ich nach jedem Pluginupdate den ganzen Server neu starten?

Nicht grundsätzlich. Oxide unterstützt das automatische Erkennen von Pluginänderungen und gezieltes Neuladen. Frameworkdateien, Extensions und bestimmte Initialisierungsabläufe können dagegen einen Neustart verlangen. Entscheidend ist die Dokumentation der betroffenen Komponente. Prüfe nach einem Reload den Log und die Funktion; ein erfolgreich angenommener Befehl allein reicht nicht.

Alle Plugins fehlen. Ist Oxide sicher schuld?

Nein. Es ist eine starke Spur, aber prüfe Konsolenkontext, vollständigen Start, Frameworkwahl, Serverinstanz und gemeinsame Abhängigkeiten. Auch ein falsches Datenverzeichnis oder mehrere Plugins mit derselben Voraussetzung kann wie ein Totalausfall wirken. Erst die Kombination der Befunde grenzt den Fehler zuverlässig ein.

Hilft ein Neustart, sobald ein neues Framework erschienen ist?

Nur wenn dein Installationsablauf dieses Framework dabei tatsächlich installiert oder du es vorher korrekt aktualisiert hast. Bei Selbsthosting ist ein Neustart allein kein Download. Vergleiche die danach gelesene Frameworkversion mit dem vorgesehenen Stand. Bleibt sie unverändert, untersuche den Updateweg.

Kann ich die Config löschen und neu erstellen lassen?

Eine neue Config kann in einer gesicherten Testkopie beim Vergleich helfen. Als pauschale Reparatur ist sie ungeeignet und kann eigene Regeln zurücksetzen. Suche zuerst nach einem konkreten Konfigurationsfehler. Sichere Original und Daten und beachte, ob das Plugin beim Entladen Einstellungen zurückschreibt.

Warum bleibt ein Plugin nach dem Update als geladen sichtbar, funktioniert aber nicht?

Laden ist nur eine Stufe. Die konkrete Funktion kann an Berechtigungen, Einstellungen, einer erst später benötigten Abhängigkeit oder einem geänderten Hook scheitern. Prüfe den Auslöser unter kontrollierten Bedingungen und lies den Log zum selben Zeitpunkt. Behaupte nicht allein aufgrund des Listeneintrags, die Funktion sei repariert.

Wie lange muss ich auf Oxide oder einen Pluginfix warten?

Eine feste Dauer lässt sich nicht seriös versprechen. Prüfe den aktuellen Releasekanal und den Status des betroffenen Plugins. Ist ein kritischer Schutz nicht verfügbar, entscheide über den sicheren Betriebszustand des Servers, statt auf eine geschätzte Uhrzeit zu vertrauen.

Darf ich einfach auf eine ältere Version zurückgehen?

Nur mit einer geprüften kompatiblen Kombination und einem gesicherten Rückweg. Altes Framework plus neues Rust kann erneut scheitern. Eine neue Pluginversion kann Daten verändert haben, die der alte Stand nicht versteht. Sichere den aktuellen Zustand zusätzlich und prüfe die Datenverträglichkeit, bevor du zurückspielst.

Begriffe, die im Log häufig auftauchen

Framework: Grundlage für die Erweiterungen, etwa Oxide oder Carbon. Plugin: Einzelne Erweiterung mit einer bestimmten Funktion. Compiler: Übersetzt den Pluginquellcode in ausführbaren Code. Abhängigkeit: Eine weitere Komponente, die eine Erweiterung benötigt. Extension: Zusätzliche Frameworkerweiterung, häufig als kompilierte Bibliothek mit eigenem Installationsweg. Hook: Anknüpfung an ein Ereignis im Spiel. RCON: Autorisierter Fernzugriff auf die Serverkonsole. Rollback: Geprüfte Wiederherstellung eines früheren, zusammenpassenden Zustands. Wipe: Zurücksetzen ausgewählter Spielstände; keine allgemeine Pluginreparatur.

Dein sinnvollster nächster Schritt am betroffenen Server ist klein: Sichere den aktuellen Startlog, prüfe das tatsächlich laufende Framework und verfolge die erste Fehlermeldung. Erst dann entscheidest du, welche einzelne Komponente geändert werden muss.

Quellen und Prüfstand

• Oxide.Rust-Releases auf GitHub: Release 2.0.7839 vom 22. Oktober 2026 („Patch for October 22nd Rust update (2635.289.1)“) und Release 2.0.7072 vom 19. Februar 2026.
• uMod-Changelog für Rust: Oktober-Einträge einschließlich des Updates vom 22. Oktober 2026.
• Oxide-Dokumentation: Plugininstallation, oxide/logs, Befehle, Konfiguration, Abhängigkeiten und Fehlerberichte.
• Facepunch-Anleitung zum Dedicated Server: SteamCMD, App-ID 258550 und Oxide nach Spielupdates.
• Carbon-Dokumentation: Versionsbefehl und Konfiguration.

Prüfstand: 29. Oktober 2026. Die drei Fehlerproben liefen am 29. Oktober 2026 auf einem eigenen, isolierten Testserver mit Rust-Protokoll 2635.289.1 und Oxide.Rust 2.0.7839; der Testserver wurde danach gelöscht. Nach jedem weiteren Rust-Update sind diese Versionsnummern nur noch ein Beispiel.