server.cfg порядок ensure: правильный порядок запуска ресурсов для FiveM

Половина ваших скриптов выдает ошибки nil при запуске, но они работают, когда вы перезагружаете их вручную. Этот паттерн обычно означает, что ресурсы запускаются в неправильном порядке. Этот гайд дает вам порядок, который работает для ESX, QBCore и QBox, и объясняет ensure против start, папки со скобками и дубликаты.

#Почему порядок имеет значение

Ресурсы запускаются в порядке строк в server.cfg. Скрипт, который читает фреймворк при загрузке, получает nil, если фреймворк еще не запущен. То же самое относится к слою базы данных и библиотекам, таким как ox_lib. Вы решаете это, поместив базовые слои сверху:

1. База данных: oxmysql
2. Библиотека: ox_lib
3. Фреймворк: es_extended, qb-core или qbx_core
4. Инвентарь
5. Все остальное

#Порядок, который работает

Для QBCore:

ensure oxmysql
ensure ox_lib
ensure qb-core
ensure ox_inventory
ensure [qb]

ensure [standalone]
ensure [mic]

Для QBox:

ensure oxmysql
ensure ox_lib
ensure qbx_core
ensure ox_inventory
ensure [qbx]
ensure [standalone]

Для ESX:

ensure oxmysql
ensure ox_lib
ensure es_extended
ensure ox_inventory
ensure [esx]
ensure [standalone]

Отрегулируйте имена категорий на ваши собственные папки. Если вы используете qb-inventory или другой инвентарь вместо ox_inventory, поместите этот на ту же позицию, сразу после фреймворка (или перед ним, если его собственная документация говорит так).

Совет: храните ресурсы, которые вы ensure по имени (oxmysql, ox_lib, фреймворк, инвентарь), в папках, которые вы также не ensure как скобка. Иначе они ensure дважды, смотрите Дубликаты ниже. Многие настройки помещают их в папку [core], которая никогда не ensure целиком.

Совет: ваш рецепт txAdmin может содержать свой собственный порядок. Держите то, что работает, и только добавляйте ваши скрипты ниже базовых слоев, вместо переписывания файла.

#ensure против start

start my_script
ensure my_script

• start запускает ресурс, если он остановлен.
• ensure запускает его, если он остановлен, и перезагружает его, если он уже запущен.

При нормальной загрузке ничто не запущено, поэтому они ведут себя одинаково. Разница проявляется, когда вы запускаете их в live console: ensure my_script - это тот, который вы хотите перезагрузить скрипт, который вы только что отредактировали. В server.cfg используйте ensure везде, чтобы вам нужно было запомнить только одно слово. Для другого направления stop my_script останавливает его, а refresh заставляет сервер повторно сканировать папку resources на предмет новых или измененных манифестов.

#Папки со скобками как категории

Папка, имя которой находится в скобках, не является ресурсом. Это категория, и FiveM смотрит внутри нее:

resources/
  [core]/
    ox_lib/
    oxmysql/
    qb-core/
  [qb]/
    qb-garages/
  [standalone]/
    my_other_script/
  [mic]/
    my_script/

ensure [qb] запускает каждый ресурс внутри [qb]. Это делает server.cfg коротким, и это то, как поставляется большинство пакетов фреймворков. Две вещи, которые нужно знать:

• Порядок внутри папки со скобками не следует полагаться на нее. Если qb-garages нуждается в qb-core, ensure qb-core на собственной строке выше ensure [qb] или объявите dependency 'qb-core' в манифесте. Ядро не должно ждать удачи.
• Ресурс не может быть вложен внутри другого ресурса. Скобки только для группировки. Если вы поместите папку скрипта внутри папки другого скрипта, FiveM не найдет ее. Смотрите Couldn't start resource.

Ресурс внутри папки со скобками все еще находится по его собственному имени, поэтому ensure ox_lib работает, даже если папка имеет имя [core]/ox_lib.

#Зависимости в манифесте

Строки порядка в server.cfg - это один инструмент. Строка dependency в манифесте скрипта - это другой, и это более надежно:

dependency 'ox_lib'
dependency 'oxmysql'

FiveM тогда проверяет, что эти ресурсы существуют и запускает их в первую очередь. Если одного не хватает, вы получаете четкое сообщение вместо ошибки nil: Could not find dependency X for resource Y. Используйте оба: хороший порядок в файле и зависимости в манифестах, которые вы контролируете.

#Дубликаты

С дубликатами происходят две вещи:

• То же самое ensure дважды. Ensure ресурса дважды в server.cfg запускает его, а затем перезагружает его сразу же. Это тратит время загрузки и может вызвать дублированные записи базы данных или события при запуске. Удалите вторую строку. Проверьте, что папка со скобками уже не включает ресурс, который вы также ensure по имени.
• Две папки с одним и тем же именем ресурса. Если у вас есть resources/[old]/my_script и resources/[mic]/my_script, используется только одна, и какая именно - это то, что вы не контролируете. Удалите или переименуйте одну, и всегда удаляйте старую версию скрипта перед установкой новой.

Когда исправление, которое вы сделали, кажется, не имеет никакого эффекта, проверьте, что вы не отредактировали копию, которая не запущена.

#Найти виновника, когда порядок неправильный

Запустите сервер, затем прочитайте консоль сверху. Первый ресурс, который выводит ошибку, - это причина, и все после него может быть побочным эффектом. Типичные примеры:

• oxmysql выводит ошибку базы данных: ничто, что использует SQL, не будет работать.
• ox_lib не удается: каждый скрипт с @ox_lib/init.lua ломается (ox_lib fix).
• Фреймворк не удается: каждый скрипт, который просит у него объект игрока, получает nil.

Исправьте первый отказ и перезагрузитесь.

#Контрольный список