No such export getSharedObject in resource es_extended: la soluzione

L'errore completo solitamente appare così, nella console del server o in F8:

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

Il codice è corretto. exports['es_extended']:getSharedObject() è esattamente il modo in cui ESX Legacy distribuisce il suo oggetto. Il problema è quando viene eseguito: in quel momento, es_extended non è lì per rispondere.

#1. es_extended inizia dopo lo script

Questa è la causa nove volte su dieci. FiveM avvia le risorse nell'ordine di server.cfg e uno script che richiede ESX nella sua prima riga necessita che es_extended sia già in esecuzione.

Un ordine sicuro per un server 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

Fai attenzione alle categorie di cartelle come [scripts]: ensure [scripts] avvia tutto all'interno, quindi se quella riga viene prima di ensure es_extended, ogni script al suo interno inizia troppo presto.

Puoi anche fare in modo che lo script stesso attenda ESX, dichiarando la dipendenza nel suo fxmanifest.lua:

dependency 'es_extended'

FiveM avvierà prima es_extended o rifiuterà di avviare lo script se manca.

#2. es_extended avvio non riuscito

Se es_extended si arresta in modo anomalo all'avvio, le sue esportazioni non esistono mai. Scorri la console del server fino all'inizio e cerca le linee rosse da es_extended prima dell'errore dello script. I soliti colpevoli:

• Il database. oxmysql non può connettersi (una password errata, un database che non esiste, MySQL non in esecuzione). Controlla mysql_connection_string nel tuo server.cfg:

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

• Una dipendenza mancante. Le build ESX Legacy recenti richiedono che oxmysql e ox_lib siano iniziate prima.
• Tabelle mancanti. Una nuova installazione senza le ESX SQL importate si blocca alla prima query.

Correggi il primo errore e anche l'errore di esportazione scomparirà.

#3. La cartella non si chiama es_extended

L'esportazione si trova in una risorsa denominata esattamente es_extended. Questi lo rompono:

• la cartella è stata rinominata (es_extended-legacy, es_extended_main…);
• ci sono due copie di es_extended in cartelle diverse e si avvia quella sbagliata;
• su un host Linux, il nome ha diverse maiuscole (ES_Extended): Linux fa distinzione tra maiuscole e minuscole, Windows no.

Cerca nella tua cartella resources fxmanifest.lua file all'interno delle cartelle chiamate es_extended e conservane esattamente uno.

#4. Hai riavviato es_extended mentre il server era in esecuzione

restart es_extended dalla console sembra innocuo, ma ogni script che ha già preso l'oggetto ESX mantiene quello vecchio e tutto ciò che richiama l'esportazione durante il riavvio riceve questo errore. Dopo aver toccato es_extended, riavvia l'intero server o almeno riavvia gli ESX script dopo.

#5. Il server non è affatto ESX

Se il tuo server esegue QBCore o QBox, non esiste es_extended e uno script solo ESX fallisce esattamente in questo modo. Cerca nella configurazione dello script un'opzione del framework o utilizza una versione creata per il tuo framework. L'equivalente QBCore di questo errore è coperto nel tentativo di indicizzare un valore nil (globale 'QBCore').

#Controllo tra dieci secondi

Nella console del server:

ensure es_extended

Se es_extended si avvia in modo pulito e l'errore persiste, è l'ordine di avvio. Se stampa errori, correggili prima. Quindi:

restart my_script

Se lo script ora si avvia senza errori, sposta il suo ensure sotto es_extended in server.cfg in modo che funzioni anche dopo un riavvio.

#Riepilogo