No such export getSharedObject in resource es_extended: düzeltme

Hatanın tamamı genellikle sunucu konsolunda veya F8'de şu şekilde görünür:

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

Kod doğru. exports['es_extended']:getSharedObject(), ESX Legacy'in nesnesini tam olarak nasıl dağıttığıdır. Sorun, çalıştığı zamandır: o anda es_extended yanıt verecek durumda değildir.

#1. es_extended komut dosyanızdan sonra başlar

On vakadan dokuzunun nedeni budur. FiveM, kaynakları server.cfg sıranıza göre başlatır ve ilk satırında ESX isteyen bir komut dosyasının zaten çalışıyor olması için es_extended gerekir.

Bir ESX sunucusu için güvenli bir sipariş:

# database and libraries first
ensure oxmysql
ensure ox_lib

# the framework
ensure es_extended
ensure [esx]

# everything else after
ensure [scripts]
ensure my_script

[scripts] gibi klasör kategorilerine dikkat edin: ensure [scripts] her şeyi içeride başlatır, bu nedenle bu satır ensure es_extended'den önce gelirse, içindeki her komut dosyası çok erken başlar.

Ayrıca fxmanifest.lua dosyasında bağımlılığı bildirerek betiğin kendisinin ESX'i beklemesini sağlayabilirsiniz:

dependency 'es_extended'

FiveM daha sonra önce es_extended'i başlatacak veya eksikse komut dosyasını başlatmayı reddedecek.

#2. es_extended başlatılamadı

Eğer es_extended başlatılırken çökerse, dışa aktarımları hiçbir zaman mevcut olmaz. Sunucu konsolunu yukarıya doğru kaydırın ve komut dosyanızın hatasından önce es_extended'den itibaren kırmızı çizgiler arayın. Olağan suçlular:

• Veritabanı. oxmysql bağlanamıyor (yanlış şifre, mevcut olmayan bir veritabanı, MySQL çalışmıyor). server.cfg'nizde mysql_connection_string'yi işaretleyin:

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

• Eksik bir bağımlılık. Son ESX Legacy derlemelerinin oxmysql ve ox_lib'nin onlardan önce başlatılması gerekiyor.
• Tablolar eksik. İçe aktarılan ESX SQL olmadan yeni bir yükleme, ilk sorguda kilitleniyor.

İlk hatayı düzelttiğinizde dışa aktarma hatası da onunla birlikte kaybolur.

#3. Klasörün adı es_extended

Dışa aktarma, tam olarak es_extended adlı bir kaynakta bulunuyor. Bunlar onu bozuyor:

• klasör yeniden adlandırıldı (es_extended-legacy, es_extended_main…);
• farklı klasörlerde es_extended dosyasının iki kopyası var ve yanlış olan başlıyor;
• Linux ana bilgisayarında ad farklı büyük harflere sahiptir (ES_Extended): Linux büyük/küçük harfe duyarlıdır, Windows ise değildir.

resources klasörünüzde, es_extended adlı klasörlerin içindeki fxmanifest.lua dosyalarını arayın ve tam olarak bir tanesini saklayın.

#4. es_extended sunucu çalışırken

restart es_extended zararsız görünüyor, ancak zaten ESX nesnesini almış olan her komut dosyası eskisini koruyor ve yeniden başlatma sırasında dışa aktarmayı çağıran her şey bu hatayı alıyor. es_extended'ye dokunduktan sonra tüm sunucuyu yeniden başlatın veya en azından ESX komut dosyalarını sonra

#5. Sunucu hiçbir şekilde ESX

Sunucunuz QBCore veya QBox çalıştırıyorsa, es_extended yoktur ve yalnızca ESX komut dosyası tam olarak bu şekilde başarısız olur. Bir çerçeve seçeneği için betiğin yapılandırmasına bakın veya çerçeveniz için oluşturulmuş bir sürümü kullanın. Bu hatanın QBCore eşdeğeri, bir nil değerini (global 'QBCore') dizine ekleme girişiminde ele alınmıştır.

#On saniye içinde kontrol ediliyor

Sunucu konsolunda:

ensure es_extended

es_extended temiz bir şekilde başlarsa ve hata devam ederse, bu başlangıç sırasıdır. Hata yazdırıyorsa, önce bunları düzeltin. Sonra:

restart my_script

Komut dosyası artık hatasız başlıyorsa, ensure dosyasını server.cfg içindeki es_extended altına taşıyın, böylece yeniden başlatmanın ardından da çalışır.

#Özet