server.cfg ensure order: właściwa kolejność uruchamiania zasobów dla FiveM

Połowa Twoich skryptów wyrzuca błędy nil przy starcie, ale działają, gdy zrestartujesz je ręcznie. Ten schemat zwykle oznacza, że zasoby zaczynają się w złej kolejności. Ten przewodnik daje Ci kolejność, która działa dla ESX, QBCore i QBox, i wyjaśnia ensure vs start, foldery w nawiasach i duplikaty.

#Dlaczego kolejność ma znaczenie

Zasoby zaczynają się w kolejności linii w server.cfg. Skrypt, który czyta framework, gdy się ładuje, uzyskuje nil, jeśli framework jeszcze się nie uruchomił. To samo dotyczy warstwy bazy danych i bibliotek takich jak ox_lib. Rozwiązujesz to, umieszczając warstwy bazowe na górze:

1. Baza danych: oxmysql
2. Biblioteka: ox_lib
3. Framework: es_extended, qb-core lub qbx_core
4. Inventory
5. Wszystko inne

#Kolejność, która działa

Dla QBCore:

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

ensure [standalone]
ensure [mic]

Dla QBox:

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

Dla ESX:

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

Dostosuj nazwy kategorii do własnych folderów. Jeśli używasz qb-inventory lub innego inventory zamiast ox_inventory, umieść to w tej samej pozycji, zaraz po framework'u (lub przed nim, jeśli jego dokumentacja tak mówi).

Wskazówka: przechowuj zasoby, które zapewniasz pod nazwą (oxmysql, ox_lib, framework, inventory) w folderach, które również nie zapewniasz jako nawiasy. W przeciwnym razie są zapewniane dwukrotnie, zobacz Duplikaty poniżej. Wiele konfiguracji umieszcza je w folderze [core], który nigdy nie jest zapewniany jako całość.

Wskazówka: Twój przepis txAdmin mógł napisać własną kolejność. Zachowaj to, co działa i tylko dodaj swoje skrypty poniżej warstw bazowych, zamiast przepisywać cały plik.

#ensure vs start

start my_script
ensure my_script

• start uruchamia zasób, jeśli jest zatrzymany.
• ensure uruchamia go, jeśli jest zatrzymany i restartuje go, jeśli już działa.

Przy normalnym starcie nic nie działa, więc zachowują się podobnie. Różnica pojawia się, gdy uruchamiasz je w konsoli na żywo: ensure my_script to ten, którego chcesz użyć, aby przeładować skrypt, który właśnie edytowałeś. W server.cfg używaj ensure wszędzie, abyś musiał pamiętać tylko jedno słowo. W innym kierunku stop my_script go zatrzymuje, a refresh sprawia, że serwer ponownie skanuje folder resources w poszukiwaniu nowych lub zmienionych manifestów.

#Foldery w nawiasach jako kategorie

Folder, którego nazwa jest w nawiasach, nie jest zasobem. To kategoria i FiveM patrzy wewnątrz:

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

ensure [qb] uruchamia każdy zasób wewnątrz [qb]. To utrzymuje server.cfg krótko i to jak większość paczek framework'u wysyła. Dwie rzeczy do wiedzy:

• Kolejność wewnątrz folderu w nawiasach nie jest czymś na czym można polegać. Jeśli qb-garages potrzebuje qb-core, zapewnij qb-core na własnej linii powyżej ensure [qb] lub zadeklaruj dependency 'qb-core' w manifeście. Core nie powinien czekać na szczęście.
• Zasób nie może być zagnieżdżony wewnątrz innego zasobu. Nawiasy służą tylko do grupowania. Jeśli umieścisz folder skryptu wewnątrz folderu innego skryptu, FiveM go nie znajdzie. Zobacz Couldn't start resource.

Zasób wewnątrz folderu w nawiasach jest nadal znajdowany przez jego własną nazwę, więc ensure ox_lib działa, nawet jeśli folder to [core]/ox_lib.

#Zależności w manifeście

Linie kolejności w server.cfg to jedno narzędzie. Linia dependency w manifeście skryptu to drugie i jest bardziej niezawodne:

dependency 'ox_lib'
dependency 'oxmysql'

FiveM następnie sprawdza, czy te zasoby istnieją i uruchamia je najpierw. Jeśli jeden brakuje, otrzymasz jasny komunikat zamiast błędu nil: Could not find dependency X for resource Y. Używaj obu: dobrej kolejności w pliku i zależności w manifestach, które kontrolujesz.

#Duplikaty

Dwie rzeczy idą nie tak z duplikatami:

• Ten sam ensure dwa razy. Zapewnienie zasobu dwa razy w server.cfg uruchamia go, a następnie natychmiast restartuje. Zmarnowuje czas startu i może wyzwolić duplikaty zapisów bazy danych lub zdarzeń przy starcie. Usuń drugą linię. Sprawdź, czy folder w nawiasach nie zawiera już zasobu, który również zapewniasz pod nazwą.
• Dwa foldery z tą samą nazwą zasobu. Jeśli masz resources/[old]/my_script i resources/[mic]/my_script, tylko jeden jest używany i które to nie jest coś, co kontrolujesz. Usuń lub zmień nazwę jednego i zawsze usuń starą wersję skryptu przed zainstalowaniem nowego.

Gdy naprawa, którą zrobiłeś, wydaje się nie mieć efektu, sprawdź, czy nie edytowałeś kopii, która nie działa.

#Znajdź winowajcę, gdy kolejność jest zła

Uruchom serwer, a następnie czytaj konsolę od góry. Pierwszy zasób, który wypisuje błąd, jest przyczyną i wszystko po nim może być następstwem. Typowe przykłady:

• oxmysql wypisuje błąd bazy danych: nic, co używa SQL, nie będzie działać.
• ox_lib się nie powiedzie: każdy skrypt z @ox_lib/init.lua się rozpada (ox_lib fix).
• Framework się nie powiedzie: każdy skrypt, który go pyta o obiekt gracza, uzyskuje nil.

Napraw pierwszy błąd i zrestartuj.

#Lista kontrolna