ESX ist nil: Fixierung von esx:getSharedObject in ESX Legacy

Sie starten Ihren Server, öffnen die F8-Konsole und da ist es:

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

Oder der serverseitige Zwilling, attempt to index a nil value (upvalue 'ESX'). Das Skript ist in Ordnung, ESX wird ausgeführt und ESX ist immer noch nil. Dies ist der häufigste ESX Fehler, den es gibt, und er hat fast immer die gleiche Ursache.

#Warum ESX nil

Ältere ESX-Skripte erhalten das ESX-Objekt wie folgt:

ESX = nil

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

Dieses Ereignis war die Art und Weise, wie ESX 1.1 und 1.2 ihr gemeinsames Objekt verteilten. ESX Legacy hat es als veraltet markiert und aktuelle Versionen antworten nicht mehr darauf. Das Skript löst das Ereignis aus, niemand antwortet und ESX bleibt nil, bis die erste Zeile, die es verwendet, abstürzt.

Sie werden dies meist bei Skripten sehen, die vor Jahren geschrieben oder aus alten Tutorials kopiert wurden.

#Die Lösung: Fragen Sie es_extended direkt

Ersetzen Sie diese Zeilen durch den Export, den ESX Legacy bereitstellt:

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

Es funktioniert auf dem Client und auf dem Server gleich. Machen Sie es in jeder Datei, die ESX verwendet. Wenn das Skript auch eine Warteschleife wie diese hatte, löschen Sie diese; Der Export antwortet sofort:

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

#Noch einfacher: imports.lua

es_extended liefert eine kleine Datei, die ESX für Sie einrichtet. Fügen Sie es zum fxmanifest.lua:

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

shared_script '@es_extended/imports.lua'

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

Jetzt verfügt jede Client- und Serverdatei über ein globales ESX und auf dem Client bleibt ESX.PlayerData auf dem neuesten Stand, wenn sich der Job und das Geld des Spielers ändern. Sie können die Zeilen getSharedObject vollständig löschen.

Tipp: Verwenden Sie einen Ansatz pro Skript. Entweder der Export oben in jeder Datei oder imports.lua im Manifest; Beides zu mischen funktioniert, aber es ist Lärm.

#Immer noch nil? Überprüfen Sie die Startreihenfolge

Wenn Sie den Export bereits verwenden und ESX immer noch nil ist oder Sie No such export getSharedObject in resource es_extended erhalten, startet das Skript vor es_extended. Ihr server.cfg entscheidet über die Reihenfolge:

ensure oxmysql
ensure ox_lib
ensure es_extended
ensure [esx]

ensure my_script

Zwei weitere Dinge, die Sie in der Serverkonsole überprüfen sollten, von ganz oben:

• es_extended ohne Fehler gestartet. Wenn es fehlschlägt (ein fehlerhaftes mysql_connection_string, ein fehlendes oxmysql), schlägt auch jedes davon abhängige Skript fehl.
• Der Ordner heißt eigentlich es_extended. Eine umbenannte oder duplizierte Kopie unterbricht den Exportnamen, und unter Linux wird beim Namen zwischen Groß- und Kleinschreibung unterschieden.

Wir gehen diesen Fehler im Detail unter Kein solcher Export getSharedObject in Ressource es_extended.

#Spielerdaten auf dem Client

Alte Skripte lesen den Player auch so:

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

Das funktioniert immer noch in ESX Legacy, mit einem Detail: Warten Sie, bis der Player geladen ist, bevor Sie beim Start Job oder Geld lesen.

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)

Mit imports.lua wird ESX.PlayerData.job für Sie aktuell gehalten.

#Skripte, die Sie nicht bearbeiten können

Wenn das Skript treuhänderisch (verschlüsselt) ist und immer noch das alte Ereignis verwendet, können Sie seinen Code nicht ändern. In der Reihenfolge Ihrer Präferenz:

1. Bitten Sie den Autor um ein Update. Jedes Skript, das noch für ESX verkauft wird, sollte den Export verwenden.
2. Beantworten Sie das alte Ereignis von ESX selbst. Fügen Sie dies in es_extended einer Serverdatei und einer Clientdatei hinzu:

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

Achtung: Dies ist ein Patch für es_extended selbst. Durch das Aktualisieren von ESX wird es überschrieben, sodass Sie es nach jedem Update erneut hinzufügen müssen. Behalten Sie es als Notlösung, nicht als Lösung.

#Schnelle Checkliste