No such export getSharedObject in resource es_extended: poprawka

Pełny błąd zwykle wygląda tak w konsoli serwera lub po naciśnięciu klawisza F8:

SCRIPT ERROR: @my_script/server/main.lua:1: No such export getSharedObject in resource es_extended

Kod jest prawidłowy. exports['es_extended']:getSharedObject() to dokładnie sposób, w jaki ESX Legacy przekazuje swój przedmiot. Problem pojawia się, kiedy działa: w tym momencie nie ma es_extended, który mógłby odpowiedzieć.

#1. es_extended zaczyna się po skrypcie

Jest to przyczyna w dziewięciu przypadkach na dziesięć. FiveM uruchamia zasoby w kolejności server.cfg, a skrypt, który w pierwszej linii pyta o ESX, musi już działać es_extended.

Bezpieczne zamówienie na serwer ESX:

# database and libraries first
ensure oxmysql
ensure ox_lib

# the framework
ensure es_extended
ensure [esx]

# everything else after
ensure [scripts]
ensure my_script

Uważaj na kategorie folderów, takie jak [scripts]: ensure [scripts] zaczyna wszystko w środku, więc jeśli ta linia pojawi się przed ensure es_extended, każdy znajdujący się w niej skrypt zacznie się zbyt wcześnie.

Możesz także sprawić, aby sam skrypt czekał na ESX, deklarując zależność w swoim fxmanifest.lua:

dependency 'es_extended'

FiveM uruchomi wtedy najpierw es_extended lub odmówi uruchomienia skryptu, jeśli go brakuje.

#2. Uruchomienie es_extended nie powiodło się

Jeśli es_extended ulegnie awarii podczas uruchamiania, jego eksport nigdy nie nastąpi. Przewiń konsolę serwera do góry i poszukaj czerwonych linii od es_extended przed błędem skryptu. Typowi winowajcy:

• Baza danych. oxmysql nie może się połączyć (złe hasło, baza danych, która nie istnieje, MySQL nie działa). Sprawdź mysql_connection_string w swoim server.cfg:

set mysql_connection_string "mysql://user:password@localhost/es_extended?charset=utf8mb4"

• Brakująca zależność. Ostatnie ESX Legacy kompilacje wymagają uruchomienia oxmysql i ox_lib przed nimi.
• Brakujące tabele. Nowa instalacja bez zaimportowanego ESX SQL ulega awarii przy pierwszym zapytaniu.

Napraw ten pierwszy błąd, a błąd eksportu zniknie.

#3. Folder nie nazywa się es_extended

Eksport znajduje się w zasobie o nazwie dokładnie es_extended. Te łamią to:

• nazwa folderu została zmieniona (es_extended-legacy, es_extended_main…);
• są dwie kopie es_extended w różnych folderach i zaczyna się niewłaściwa kopia;
• na hoście z systemem Linux nazwa ma różne wielkie litery (ES_Extended): w systemie Linux rozróżniana jest wielkość liter, w systemie Windows nie.

Wyszukaj w swoim folderze resources pliki fxmanifest.lua w folderach o nazwach es_extended i zachowaj dokładnie jeden.

#4. Uruchomiłeś ponownie es_extended podczas pracy serwera

restart es_extended z konsoli wygląda nieszkodliwie, ale każdy skrypt, który już pobrał obiekt ESX, zachowuje stary, a wszystko, co wywołuje eksport podczas ponownego uruchamiania, otrzymuje ten błąd. Po dotknięciu es_extended zrestartuj cały serwer lub przynajmniej zrestartuj skrypty ESX po nim.

#5. Serwer w ogóle nie działa ESX

Jeśli na Twoim serwerze działa QBCore lub QBox, nie ma es_extended, a skrypt obsługujący tylko ESX kończy się właśnie w ten sposób niepowodzeniem. Poszukaj w konfiguracji skryptu opcji frameworka lub użyj wersji stworzonej dla twojego frameworka. QBCore odpowiednik tego błędu opisano w próbie indeksowania wartości nil (globalnej 'QBCore').

#Sprawdzanie w dziesięć sekund

W konsoli serwera:

ensure es_extended

Jeśli es_extended uruchamia się prawidłowo, a błąd nadal występuje, jest to kolejność uruchamiania. Jeśli wypisuje błędy, napraw je w pierwszej kolejności. Następnie:

restart my_script

Jeśli skrypt uruchomi się teraz bez błędu, przenieś jego ensure poniżej es_extended w server.cfg, aby działał również po ponownym uruchomieniu.

#Podsumowanie