Nie ma takiego exportu X w zasobie Y: jak to naprawić w FiveM

Konsola pokazuje to, często w pętli:

SCRIPT ERROR: @my_script/server/main.lua:14: No such export GetItemCount in resource my_inventory

Twój skrypt wywołał exports['my_inventory']:GetItemCount(). W tym momencie my_inventory nie miał exportu o tej nazwie. Wiadomość wymienia obie części, więc rozwiązanie to jeden z małej liczby przyczyn. Ten przewodnik obejmuje ogólny przypadek. Jeśli export to getSharedObject z es_extended, przeczytaj zamiast tego No such export getSharedObject in resource es_extended, który zawiera przyczyny specyficzne dla ESX.

#1. Zasób nie jest uruchomiony

Export istnieje tylko gdy jego zasób jest uruchomiony. Sprawdź konsolę przy uruchomieniu:

• Czy zasób jest wymieniony w server.cfg z ensure lub start?
• Czy uruchomił się bez błędów, czy wydrukował Couldn't start resource lub Failed to load script?
• Czy jest zatrzymany w txAdmin? Sprawdź stronę Zasoby.

Zasób, który nie uruchomił się, na przykład z powodu błędu składni Lua lub brakującej zależności, nie ma exportów. Napraw najpierw jego własny błąd. Patrz Couldn't start resource i could not find dependency. Błąd składni w szczególności jest objęty w Lua syntax error: unexpected symbol near.

#2. Nazwa zasobu jest zła

exports['my_inventory'] używa nazwy folderu zasobu, nie tytułu skryptu. Jeśli folder został przemianowany, każdy skrypt, który go wywołuje ze starą nazwą, nie powiedzie się.

Typowe sytuacje:

• Przemianowałeś my_inventory-master lub my_inventory-main na coś krótszego i ciągle wywoływałeś starą nazwę.
• Nazwa używa myślnika w jednym miejscu i podkreślenia w innym: my-inventory i my_inventory to różne zasoby.
• Wielkość liter się różni: dopasuj dokładnie folder.
• Zasób znajduje się w folderze z nawiasami takimi jak [qb]. Nawiasy to tylko kategoria: nie są częścią nazwy, więc użyj my_inventory, nie [qb]/my_inventory.

Niektóre zasoby zastępują inny za pomocą provide 'other_name' w ich fxmanifest, aby skrypty pytające o starą nazwę nadal działały. Jeśli zastąpiłeś zasób kompatybilnym i stara nazwa nie powiedzie się, sprawdź czy nowy go dostarcza, i czy usunąłeś stary folder aby dwa się nie zderzały.

#3. Export jest po drugiej stronie

Exporty są na stronę. Export zarejestrowany w skrypcie klienta może być wywoływany tylko z innego skryptu klienta, a ten zarejestrowany na serwerze tylko ze skryptu serwera.

-- my_inventory/server/main.lua
exports('GetItemCount', function(source, item)
    return 0
end)

-- my_script/client/main.lua
-- fails: GetItemCount exists on the server only
local count = exports['my_inventory']:GetItemCount('water')

Aby sprawdzić, spójrz w pliki dostawcy: linia exports(...) jest w client/ lub server/, lub w pliku wymieniony pod shared_scripts, który uruchamia się po obu stronach. Jeśli export jest tylko na serwerze, wywołaj go ze skryptu serwera, i dostarcz dane do klienta za pomocą zdarzenia lub callback'u, patrz server callbacks.

#4. Export został przemianowany lub usunięty

Zasoby się zmieniają pomiędzy wersjami. Export o nazwie GetItemCount w starszym wydaniu może być getItemCount lub Search w nowszym, i nazwy Lua są wrażliwe na wielkość liter. Jeśli błąd pojawił się po aktualizacji jednego z zasobów:

1. Otwórz fxmanifest.lua dostawcy, README lub dokumentację i szukaj aktualnej listy exportów.
2. Przeszukaj folder zasobu dla exports( i dla nazwy którą wywoływałeś.
3. Zaktualizuj swoje wywołanie, lub zaktualizuj drugi zasób do wersji dla której skrypt był napisany.

Pamiętaj że odwrotnie też istnieje: skrypt zaktualizowany aby wywoływać nowy export, podczas gdy dostawca nadal uruchamia starą wersję bez niego.

grep -rn "exports(" resources/[mic]/my_inventory

Na Windows, użyj pola wyszukiwania twojego edytora zamiast tego.

#5. Kolejność uruchamiania i zależności

Jeśli zasób istnieje i ma export, ale wywołanie następuje zanim jest gotowy, dostajesz ten sam błąd. Zasoby uruchamiają się w kolejności server.cfg:

ensure oxmysql
ensure ox_lib
ensure my_inventory

ensure my_script

Umieść dostawcę powyżej skryptu, który go używa. Do stałej naprawy, napisz link w fxmanifest.lua rozmówcy:

dependency 'my_inventory'

Wtedy FiveM uruchamia my_inventory pierwszy, i odmawia uruchomienia skryptu bez niego. Więcej o kolejności w server.cfg resource order.

Dwie powiązane pułapki:

• Export jest zarejestrowany późno. exports('Name', fn) uruchamia się gdy linia jest osiągana. Jeśli plik błędzisz powyżej, lub rejestrujesz go po długim Wait, rozmówcy, którzy działają w międzyczasie, nie powiedzą. Rejestruj exporty blisko góry pliku.
• Wywołanie w czasie ładowania. Wywołanie na poziomie najwyższym takie jak local count = exports['my_inventory']:GetItemCount('water') uruchamia się zaraz gdy plik się ładuje. Przenieś to do zdarzenia lub wątku, lub upewnij się że zależność już jest uruchomiona.

Możesz też chronić opcjonalną integrację za pomocą pcall i sprawdzenia że zasób jest uruchomiony:

if GetResourceState('my_inventory') == 'started' then
    local ok, count = pcall(function()
        return exports['my_inventory']:GetItemCount('water')
    end)
end

GetResourceState zwraca 'started', 'stopped', 'missing' lub inne stany, więc możesz też zalogować który to przypadek. Aby głębszy wgląd w jak exporty pracują, przeczytaj FiveM exports in Lua.

#6. Ponownie uruchomiony jeden zasób, nie drugi

Ponowne uruchomienie dostawcy, podczas gdy serwer działa, nie zawsze ponownie łączy skrypty, które trzymają jego obiekty. Po ponownym uruchomieniu lub aktualizacji dostawcy, ponownie uruchom skrypty, które go wywoływają, lub uruchom ponownie serwer.

#Checklist