server.cfg ensure-Reihenfolge: Die richtige Ressourcen-Startreihenfolge für FiveM

Die Hälfte deiner Scripts wirft nil-Fehler beim Start, aber sie funktionieren, wenn du sie von Hand neu startest. Dieses Muster bedeutet normalerweise, dass die Ressourcen in der falschen Reihenfolge starten. Diese Anleitung gibt dir eine Reihenfolge, die für ESX, QBCore und QBox funktioniert, und erklärt ensure vs start, Bracket-Ordner und Duplikate.

#Warum die Reihenfolge wichtig ist

Ressourcen starten in der Reihenfolge der Zeilen in server.cfg. Ein Script, das das Framework beim Laden liest, bekommt nil, wenn das Framework noch nicht gestartet wurde. Das Gleiche gilt für die Datenbankschicht und Bibliotheken wie ox_lib. Du löst es, indem du die Basisschichten oben platzierst:

1. Die Datenbank: oxmysql
2. Die Bibliothek: ox_lib
3. Das Framework: es_extended, qb-core oder qbx_core
4. Das Inventar
5. Alles andere

#Eine Reihenfolge, die funktioniert

Für QBCore:

ensure oxmysql
ensure ox_lib
ensure qb-core
ensure ox_inventory
ensure [qb]

ensure [standalone]
ensure [mic]

Für QBox:

ensure oxmysql
ensure ox_lib
ensure qbx_core
ensure ox_inventory
ensure [qbx]
ensure [standalone]

Für ESX:

ensure oxmysql
ensure ox_lib
ensure es_extended
ensure ox_inventory
ensure [esx]
ensure [standalone]

Passe die Kategorienamen an deine eigenen Ordner an. Wenn du qb-inventory oder ein anderes Inventar statt ox_inventory verwendest, platziere das an derselben Position, direkt nach dem Framework (oder davor, wenn seine Dokumentation das sagt).

Tipp: Behalte Ressourcen, die du nach Namen sicherst (oxmysql, ox_lib, das Framework, das Inventar), in Ordnern, die du nicht auch als Bracket sicherst. Sonst werden sie zweimal gesichert, siehe Duplikate unten. Viele Setups platzieren sie in einem [core]-Ordner, der nie als Ganzes gesichert wird.

Tipp: Dein txAdmin-Rezept könnte seine eigene Reihenfolge geschrieben haben. Behalte, was funktioniert, und füge deine Scripts nur unterhalb der Basisschichten hinzu, statt die Datei umzuschreiben.

#ensure vs start

start my_script
ensure my_script

• start startet eine Ressource, wenn sie gestoppt ist.
• ensure startet sie, wenn sie gestoppt ist, und startet sie neu, wenn sie bereits ausgeführt wird.

Bei einem normalen Start wird nichts ausgeführt, also verhalten sie sich gleich. Der Unterschied zeigt sich, wenn du sie in der Live-Konsole ausführst: ensure my_script ist der, den du verwenden möchtest, um ein Script, das du gerade bearbeitet hast, neu zu laden. In server.cfg verwende überall ensure, damit du dir nur ein Wort merken musst. Für die andere Richtung stoppt stop my_script es, und refresh macht, dass der Server den resources-Ordner nach neuen oder geänderten Manifesten durchsucht.

#Bracket-Ordner als Kategorien

Ein Ordner, dessen Name in Klammern steht, ist keine Ressource. Es ist eine Kategorie, und FiveM schaut hinein:

resources/
  [core]/
    ox_lib/
    oxmysql/
    qb-core/
  [qb]/
    qb-garages/
  [standalone]/
    my_other_script/
  [mic]/
    my_script/

ensure [qb] startet jede Ressource darin. Das hält server.cfg kurz, und so versenden die meisten Framework-Pakete. Zwei Dinge zu wissen:

• Reihenfolge innerhalb eines Bracket-Ordners ist nicht etwas, auf das man sich verlassen sollte. Wenn qb-garages qb-core braucht, stelle qb-core auf einer eigenen Zeile über ensure [qb] hin, oder erkläre dependency 'qb-core' im Manifest. Der Kern muss nicht auf Glück warten.
• Eine Ressource kann nicht in einer anderen Ressource verschachtelt sein. Klammern sind nur zum Gruppieren. Wenn du einen Script-Ordner in den Ordner eines anderen Scripts legst, findet FiveM ihn nicht. Siehe Ressource konnte nicht gestartet werden.

Eine Ressource in einem Bracket-Ordner wird immer noch nach ihrem eigenen Namen gefunden, also funktioniert ensure ox_lib, obwohl der Ordner [core]/ox_lib ist.

#Abhängigkeiten im Manifest

Reihenfolgezeilen in server.cfg sind ein Tool. Eine dependency-Zeile im Manifest eines Scripts ist das andere, und es ist zuverlässiger:

dependency 'ox_lib'
dependency 'oxmysql'

FiveM überprüft dann, dass diese Ressourcen vorhanden sind und startet sie zuerst. Wenn eine fehlt, bekommst du eine klare Meldung statt eines nil-Fehlers: Abhängigkeit X für Ressource Y konnte nicht gefunden werden. Verwende beide: eine gute Reihenfolge in der Datei und Abhängigkeiten in den Manifesten, die du kontrollierst.

#Duplikate

Zwei Dinge gehen mit Duplikaten schief:

• Dasselbe ensure zweimal. Das zweimalige Sichern einer Ressource in server.cfg startet sie und startet sie dann sofort neu. Es verschwendet Boot-Zeit und kann doppelte Datenbankschreibvorgänge oder Events bei Start auslösen. Entferne die zweite Zeile. Überprüfe, dass ein Bracket-Ordner eine Ressource nicht bereits enthält, die du auch nach Namen sicherst.
• Zwei Ordner mit dem gleichen Ressourcennamen. Wenn du resources/[old]/my_script und resources/[mic]/my_script hast, wird nur einer verwendet, und welcher ist etwas, das du nicht kontrollierst. Lösche oder benenne einen um, und lösche immer die alte Version eines Scripts, bevor du eine neue installierst.

Wenn eine Behebung, die du gemacht hast, keinen Effekt zu haben scheint, überprüfe, dass du nicht die Kopie bearbeitet hast, die nicht ausgeführt wird.

#Finde den Schuldigen, wenn die Reihenfolge falsch ist

Starte den Server und lies dann die Konsole von oben. Die erste Ressource, die einen Fehler ausgibt, ist die Ursache, und alles danach kann Auswirkung sein. Typische Beispiele:

• oxmysql gibt einen Datenbankfehler aus: nichts, das SQL verwendet, wird funktionieren.
• ox_lib schlägt fehl: jedes Script mit @ox_lib/init.lua bricht (ox_lib-Behebung).
• Das Framework schlägt fehl: jedes Script, das es um einen Spielerobjekt fragt, bekommt nil.

Behebe den ersten Fehler und starte neu.

#Checkliste