No such export getSharedObject in resource es_extended: исправление

Полная ошибка обычно выглядит так: в консоли сервера или по F8:

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

Код правильный. exports['es_extended']:getSharedObject() — это именно то, как ESX Legacy передает свой объект. Проблема в том, когда он запускается: в этот момент es_extended нет ответа.

#1. es_extended начинается после вашего скрипта

Это причина в девяти случаях из десяти. FiveM запускает ресурсы в порядке вашего server.cfg, а сценарий, который запрашивает ESX в первой строке, должен уже запустить es_extended.

Безопасный заказ для сервера 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

Остерегайтесь папок категорий, таких как [scripts]: ensure [scripts] запускает все внутри, поэтому, если эта строка предшествует ensure es_extended, каждый сценарий в ней запускается слишком рано.

Вы также можете заставить сам скрипт ждать ESX, объявив зависимость в его fxmanifest.lua:

dependency 'es_extended'

FiveM сначала запустит es_extended или откажется запускать скрипт, если он отсутствует.

#2. es_extended не удалось запустить

Если es_extended происходит сбой при запуске, его экспорт никогда не будет выполнен. Прокрутите консоль сервера вверх и найдите красные линии от es_extended до ошибки сценария. Обычные виновники:

• База данных. oxmysql не может подключиться (неправильный пароль, база данных не существует, MySQL не работает). Проверьте mysql_connection_string в своем server.cfg:

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

• Отсутствует зависимость. Для последних сборок ESX Legacy необходимо, чтобы oxmysql и ox_lib запускались раньше них.
• Отсутствуют таблицы. При новой установке без ESX SQL происходит сбой при первом запросе.

Исправьте первую ошибку, и ошибка экспорта исчезнет вместе с ней.

#3. Папка не называется es_extended

Экспорт находится в ресурсе с именем точно es_extended. Вот что сломает:

• папка переименована (es_extended-legacy, es_extended_main…);
• в разных папках две копии es_extended, и запускается не та;
• на хосте Linux имя имеет разные заглавные буквы (ES_Extended): Linux чувствителен к регистру, Windows — нет.

Найдите в папке resources файлы fxmanifest.lua внутри папок с именем es_extended и сохраните ровно один.

#4. Вы перезапустили es_extended во время работы сервера

restart es_extended из консоли выглядит безобидным, но каждый скрипт, который уже принял объект ESX, сохраняет старый, и все, что вызывает экспорт во время перезапуска, получает эту ошибку. После нажатия es_extended перезапустите весь сервер или хотя бы перезапустите сценарии ESX после этого.

#5. Сервер вообще не ESX

Если на вашем сервере работает QBCore или QBox, es_extended не существует, и сценарий только для ESX завершается с ошибкой точно так же. Найдите в конфигурации скрипта параметр фреймворка или используйте версию, созданную для вашей фреймворка. QBCore эквивалент этой ошибки описан в попытке индексировать значение nil (глобальное 'QBCore').

#Проверяем за десять секунд

В консоли сервера:

ensure es_extended

Если es_extended запускается без ошибок и ошибка не устранена, это порядок запуска. Если он печатает ошибки, сначала исправьте их. Тогда:

restart my_script

Если скрипт теперь запускается без ошибки, переместите его ensure ниже es_extended в server.cfg, чтобы он также работал после перезагрузки.

#Сводка