No such export getSharedObject in resource es_extended: a correção

O erro completo geralmente fica assim, no console do servidor ou em F8:

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

O código está correto. exports['es_extended']:getSharedObject() é exatamente como ESX Legacy distribui seu objeto. O problema é quando ele é executado: naquele momento, es_extended não está lá para responder.

#1. es_extended começa depois do seu script

Esta é a causa nove em cada dez vezes. FiveM inicia recursos na ordem de server.cfg, e um script que solicita ESX na primeira linha precisa que es_extended já esteja em execução.

Um pedido seguro para um servidor 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

Cuidado com as categorias de pastas como [scripts]: ensure [scripts] inicia tudo dentro dela, portanto, se essa linha vier antes de ensure es_extended, todos os scripts nela contidos começarão muito cedo.

Você também pode fazer o próprio script esperar por ESX, declarando a dependência em seu fxmanifest.lua:

dependency 'es_extended'

FiveM iniciará es_extended primeiro ou se recusará a iniciar o script se ele estiver faltando.

#2. es_extended falha ao iniciar

Se es_extended travar durante a inicialização, suas exportações nunca existirão. Role o console do servidor até o topo e procure as linhas vermelhas de es_extended antes do erro do seu script. Os culpados de sempre:

• O banco de dados. oxmysql não pode se conectar (uma senha errada, um banco de dados que não existe, MySQL não está em execução). Marque mysql_connection_string em seu server.cfg:

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

• Uma dependência ausente. Compilações ESX Legacy recentes precisam de oxmysql e ox_lib iniciadas antes delas.
• Tabelas ausentes. Uma nova instalação sem o ESX SQL importado falha na primeira consulta.

Corrija o primeiro erro e o erro de exportação desaparecerá com ele.

#3. A pasta não se chama es_extended

A exportação reside em um recurso chamado exatamente es_extended. Estes quebram:

• a pasta foi renomeada (es_extended-legacy, es_extended_main…);
• há duas cópias de es_extended em pastas diferentes, e a cópia errada é iniciada;
• em um host Linux, o nome tem letras maiúsculas diferentes (ES_Extended): o Linux diferencia maiúsculas de minúsculas, o Windows não.

Procure na sua pasta resources por fxmanifest.lua arquivos dentro de pastas chamadas es_extended e mantenha exatamente um.

#4. Você reiniciou es_extended enquanto o servidor estava em execução

restart es_extended do console parece inofensivo, mas todo script que já pegou o objeto ESX mantém o antigo, e qualquer coisa que chame a exportação durante a reinicialização recebe esse erro. Depois de tocar em es_extended, reinicie todo o servidor ou, pelo menos, reinicie os scripts ESX depois dele.

#5. O servidor não é ESX

Se o seu servidor executa QBCore ou QBox, não há es_extended e um script somente ESX falha exatamente assim. Procure na configuração do script uma opção de framework ou use uma versão feita para seu framework. O equivalente QBCore desse erro é abordado em tentativa de indexar um valor nil (global 'QBCore').

#Verificando em dez segundos

No console do servidor:

ensure es_extended

Se es_extended iniciar corretamente e o erro persistir, esta é a ordem de início. Se imprimir erros, corrija-os primeiro. Então:

restart my_script

Se o script iniciar agora sem o erro, mova seu ensure abaixo de es_extended em server.cfg para que ele também funcione após a reinicialização.

#Resumo