ESX é nil: corrigindo esx:getSharedObject em ESX Legacy

Você inicia seu servidor, abre o console F8 e aí está:

SCRIPT ERROR: @my_script/client/main.lua:12: attempt to index a nil value (global 'ESX')

Ou o gêmeo do lado do servidor, attempt to index a nil value (upvalue 'ESX'). O script está correto, ESX está em execução e ESX ainda está nil. Este é o erro ESX mais comum que existe e quase sempre tem a mesma causa.

#Por que ESX é nil

Scripts ESX mais antigos obtêm o objeto ESX assim:

ESX = nil

TriggerEvent('esx:getSharedObject', function(obj) ESX = obj end)

Esse evento foi como ESX 1.1 e 1.2 distribuíram seu objeto compartilhado. ESX Legacy o substituiu e as versões atuais não respondem mais. O script aciona o evento, ninguém responde e ESX permanece nil até que a primeira linha que o utiliza trave.

Você verá isso principalmente em scripts escritos anos atrás ou copiados de tutoriais antigos.

#A solução: pergunte es_extended diretamente

Substitua essas linhas pela exportação que ESX Legacy fornece:

ESX = exports['es_extended']:getSharedObject()

Funciona da mesma forma no cliente e no servidor. Faça isso em todos os arquivos que usam ESX. Se o script também tiver um loop de espera como este, exclua-o; a exportação responde imediatamente:

-- old code: remove it
Citizen.CreateThread(function()
    while ESX == nil do
        TriggerEvent('esx:getSharedObject', function(obj) ESX = obj end)
        Citizen.Wait(0)
    end
end)

#Ainda mais simples: imports.lua

es_extended envia um pequeno arquivo que configura ESX para você. Adicione-o ao fxmanifest.lua do script:

fx_version 'cerulean'
game 'gta5'
lua54 'yes'

shared_script '@es_extended/imports.lua'

client_scripts { 'client/*.lua' }
server_scripts { 'server/*.lua' }

Agora cada arquivo de cliente e servidor tem um ESX global, e no cliente ESX.PlayerData permanece atualizado conforme o trabalho e o dinheiro do jogador mudam. Você pode excluir totalmente as getSharedObject linhas.

Dica: use uma abordagem por script. A exportação no topo de cada arquivo ou imports.lua no manifesto; misturar os dois funciona, mas é ruído.

#Ainda nil? Verifique a ordem de início

Se você já usa a exportação e ESX ainda é nil, ou obtém No such export getSharedObject in resource es_extended, o script está iniciando antes de es_extended. Seu server.cfg decide a ordem:

ensure oxmysql
ensure ox_lib
ensure es_extended
ensure [esx]

ensure my_script

Mais duas coisas para verificar no console do servidor, desde o início:

• es_extended foi iniciado sem erros. Se falhar (um mysql_connection_string ruim, um oxmysql ausente), todos os scripts que dependem dele também falharão.
• A pasta se chama es_extended. Uma cópia renomeada ou duplicada quebra o nome de exportação e, no Linux, o nome diferencia maiúsculas de minúsculas.

Examinamos esse erro detalhadamente em Não existe essa exportação getSharedObject no recurso es_extended.

#Dados do jogador no cliente

Scripts antigos também leem o player assim:

-- old
ESX.GetPlayerData()
RegisterNetEvent('esx:playerLoaded')
AddEventHandler('esx:playerLoaded', function(xPlayer) PlayerData = xPlayer end)

Isso ainda funciona em ESX Legacy, com um detalhe: espere até que o player seja carregado antes de ler trabalho ou dinheiro na inicialização.

CreateThread(function()
    while not ESX.IsPlayerLoaded() do Wait(250) end
    local job = ESX.GetPlayerData().job
    print(('job: %s (%s)'):format(job.name, job.grade))
end)

RegisterNetEvent('esx:setJob', function(job)
    -- the job changed: refresh whatever shows it
end)

Com imports.lua, ESX.PlayerData.job é mantido atualizado para você.

#Scripts que você não pode editar

Se o script estiver sob custódia (criptografado) e ainda usar o evento antigo, você não poderá alterar seu código. Em ordem de preferência:

1. Peça uma atualização ao autor. Qualquer script ainda vendido por ESX deve usar a exportação.
2. Responda você mesmo ao evento antigo de ESX. Em es_extended, adicione isto a um arquivo do servidor e a um arquivo do cliente:

AddEventHandler('esx:getSharedObject', function(cb)
    cb(ESX)
end)

Atenção: este é um patch para o próprio es_extended. Atualizar ESX o sobrescreve, então você terá que adicioná-lo novamente após cada atualização. Mantenha isso como um paliativo, não como uma solução.

#Lista de verificação rápida