No such export getSharedObject in resource es_extended: die Lösung

Der vollständige Fehler sieht normalerweise so aus, in der Serverkonsole oder in F8:

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

Der Code ist richtig. exports['es_extended']:getSharedObject() ist genau die Art und Weise, wie ESX Legacy sein Objekt verteilt. Das Problem ist wann es läuft: In diesem Moment ist es_extended nicht da, um zu antworten.

#1. es_extended startet nach Ihrem Skript

In neun von zehn Fällen ist dies die Ursache. FiveM startet Ressourcen in der Reihenfolge Ihrer server.cfg, und ein Skript, das in der ersten Zeile nach ESX fragt, muss es_extended bereits ausführen.

Eine sichere Reihenfolge für einen ESX Server:

# database and libraries first
ensure oxmysql
ensure ox_lib

# the framework
ensure es_extended
ensure [esx]

# everything else after
ensure [scripts]
ensure my_script

Achten Sie auf Ordner-Kategorien wie [scripts]: ensure [scripts] startet alles darin. Wenn diese Zeile also vor ensure es_extended steht, startet jedes Skript darin zu früh.

Sie können das Skript auch selbst auf ESX warten lassen, indem Sie die Abhängigkeit in seinem fxmanifest.lua:

dependency 'es_extended'

FiveM startet dann zuerst es_extended oder weigert sich, das Skript zu starten, wenn es fehlt.

#2. es_extended konnte nicht gestartet werden

Wenn es_extended beim Start abstürzt, sind seine Exporte nie vorhanden. Scrollen Sie in der Serverkonsole nach oben und suchen Sie nach roten Linien von es_extended vor dem Fehler Ihres Skripts. Die üblichen Übeltäter:

• Die Datenbank. oxmysql kann keine Verbindung herstellen (ein falsches Passwort, eine Datenbank, die nicht existiert, MySQL läuft nicht). Aktivieren Sie mysql_connection_string in Ihrem server.cfg:

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

• Eine fehlende Abhängigkeit. Aktuelle ESX Legacy Builds müssen vor ihnen mit oxmysql und ox_lib gestartet werden.
• Fehlende Tabellen. Eine Neuinstallation ohne die importierten ESX SQL stürzt bei der ersten Abfrage ab.

Beheben Sie den ersten Fehler und der Exportfehler verschwindet damit.

#3. Der Ordner heißt nicht es_extended

Der Export befindet sich in einer Ressource mit dem Namen genau es_extended. Diese machen es kaputt:

• Der Ordner wurde umbenannt (es_extended-legacy, es_extended_main…);
• Es gibt zwei Kopien von es_extended in verschiedenen Ordnern und die falsche startet;
• auf einem Linux-Host hat der Name unterschiedliche Großbuchstaben (ES_Extended): Linux unterscheidet zwischen Groß- und Kleinschreibung, Windows nicht.

Durchsuchen Sie Ihren Ordner resources nach fxmanifest.lua Dateien in Ordnern namens es_extended und behalten Sie genau eine.

#4. Sie haben es_extended neu gestartet, während der Server lief

restart es_extended von der Konsole sieht harmlos aus, aber jedes Skript, das bereits das ESX-Objekt verwendet hat, behält das alte, und alles, was den Export während des Neustarts aufruft, erhält diesen Fehler. Nachdem Sie es_extended berührt haben, starten Sie den gesamten Server neu oder starten Sie zumindest die ESX-Skripte danach neu.

#5. Der Server ist überhaupt nicht ESX

Wenn Ihr Server QBCore oder QBox ausführt, gibt es kein es_extended und ein reines ESX-Skript schlägt genau so fehl. Suchen Sie in der Konfiguration des Skripts nach einer Framework-Option oder verwenden Sie eine für Ihr Framework erstellte Version. Das QBCore-Äquivalent dieses Fehlers wird im Versuch, einen nil-Wert zu indizieren (global 'QBCore') behandelt.

#Überprüfe es in zehn Sekunden

In der Serverkonsole:

ensure es_extended

Wenn es_extended sauber startet und der Fehler weiterhin besteht, handelt es sich um die Startreihenfolge. Wenn Fehler ausgegeben werden, beheben Sie diese zuerst. Dann:

restart my_script

Wenn das Skript jetzt ohne Fehler startet, verschieben Sie es ensure nach unten es_extended in server.cfg, damit es auch nach einem Neustart funktioniert.

#Zusammenfassung