Установка кастомных MLO-карт на FiveM-сервер

MAATRIX GAMES

Купил или скачал MLO — новый полицейский участок, больницу или клуб для своего RP-проекта — и на этапе ensure понял, что «просто закинуть папку в resources» не работает: сервер либо не видит интерьер, либо видит, но игрок проваливается сквозь пол, либо всё грузится, а через неделю выясняется, что старый и новый MLO спорят за одну и ту же точку на карте. Разберём установку MLO по шагам: куда класть ресурс, что должно быть в fxmanifest.lua, чем подмена существующего интерьера отличается от простого добавления нового, и как разруливать конфликт, если два MLO нацелены на одну локацию.

Куда класть ресурс и с чего начинается установка

MLO — это обычный ресурс FiveM, только вместо скриптов у него в основном стрим-данные: .ymap (расстановка объектов и точка входа-портал) и .ytyp (описание архетипов, включая сам интерьер). Кладётся ресурс туда же, куда и любой другой — в resources/, обычно в подпапку-категорию вроде resources/[maps]/mrpd_custom/. Квадратные скобки и любые префиксы в имени папки-категории — это чисто для порядка в файловой системе, FXServer их игнорирует и ищет fxmanifest.lua на любом уровне вложенности.

Прежде чем разворачивать архив на боевом сервере, стоит открыть его и убедиться, что внутри действительно есть fxmanifest.lua в корне ресурса (а не на два уровня глубже — так бывает, если автор запаковал архив прямо из своей рабочей папки с лишним уровнем вложенности), и папка stream/ с файлами .ymap/.ytyp. Если у тебя ещё не поднят сервер вообще — базовый процесс описан в статье про подъём FiveM-сервера с нуля, здесь предполагается, что resources/ и server.cfg уже на месте.

fxmanifest.lua: минимум, без которого MLO не запустится

Для карты и MLO манифест выглядит немного иначе, чем для обычного скрипта — упор не на client_scripts/server_scripts, а на data_file и files:

fx_version 'cerulean'
game 'gta5'

author 'ИмяАвтора'
description 'MLO: кастомный полицейский участок'
version '1.0.0'

data_file 'DLC_ITYP_REQUEST' 'stream/mrpd_custom.ytyp'

files {
    'stream/mrpd_custom.ymap',
    'stream/mrpd_custom.ytyp'
}

this_is_a_map 'yes'

Три вещи здесь критичны и чаще всего пропускаются при ручной сборке или переупаковке чужого MLO:

• data_file 'DLC_ITYP_REQUEST' — без этой строки движок не подгрузит архетипы из .ytyp, и объекты интерьера просто не появятся, даже если файл физически лежит в ресурсе.
• this_is_a_map 'yes' — сообщает серверу, что ресурс содержит статические карты, и включает синхронизацию потоковых данных между всеми клиентами одинаково. Без неё типичная жалоба — «у меня в игре всё видно, а у остальных нет».
• Пути в files {} должны буква в букву совпадать с реальной структурой папок. Опечатка в имени файла — самая частая причина ошибки Couldn't find asset в консоли при старте.

Порядок загрузки: provide и подмена интерьера — это разные вещи

Здесь чаще всего путаются даже опытные админы, потому что оба механизма звучат похоже, но решают разные задачи.

provide — это директива уровня загрузчика ресурсов, а не карты. Она пишется в манифесте так: provide 'mrpd_base' — и говорит FXServer «этот ресурс можно считать заменой ресурса с именем mrpd_base». Смысл в том, что если у тебя стоит несколько альтернативных вариантов одного и того же MLO (например, разные визуальные варианты полицейского участка от разных авторов) и другие скрипты завязаны на конкретное имя через dependency 'mrpd_base', provide позволяет подставить вместо базового ресурса твой кастомный вариант, не переписывая зависимости во всех остальных скриптах. На практике эту директиву используют не все авторы MLO-паков, и полагаться на неё вслепую не стоит — проверяй в документации конкретного ресурса, объявлена ли она вообще.

Подмена интерьера (interior swap) — это уже не про имена ресурсов, а про то, что происходит в самом игровом мире. Когда MLO не добавляет новую локацию, а заменяет существующий ванильный интерьер (например, другой дизайн MRPD вместо стокового), ресурс должен как-то «спрятать» оригинальные объекты и портал, а вместо них активировать свои. Делается это через данные самого .ymap/.ytyp — комнаты (rooms), порталы (portals) и точку входа привязываются к тем же координатам и тому же архетипу интерьера, что и оригинал. Если два ресурса одновременно пытаются занять один и тот же архетип интерьера, движок не «складывает» их — обычно побеждает тот, что загрузился и активировался последним, а второй либо не проявляется вообще, либо создаёт визуальные артефакты в проёме двери.

Из этого следует практическое правило: если ставишь MLO, которая заменяет существующую локацию (а не добавляет новую в чистом поле), сразу выясняй у автора или из README, какой именно интерьер она подменяет — и проверяй, нет ли у тебя уже другого ресурса, нацеленного на ту же точку.

Стрим-файлы: как устроены ymap и ytyp у MLO

Внутри .ytyp описаны архетипы: сама «коробка» интерьера (CMloArchetypeDef в терминах структуры данных), комнаты внутри неё и порталы, через которые движок понимает, что видно из одной комнаты в другую. Внутри .ymap — конкретная расстановка: где именно в игровом мире находится точка входа, какие объекты (мебель, декор, свет) расставлены внутри.

Практические моменты, которые стоит проверить перед продом:

• Держи файлы строго в stream/ и подключай через data_file/files в манифесте — это штатный путь, через который FiveM понимает, что данные нужно стримить, а не пытается сразу загрузить всё целиком.
• Если MLO пришла разбитой на несколько .ymap (сам интерьер отдельно, декор отдельно) — все части должны быть перечислены в files {}, иначе часть объектов не появится, а ошибки в консоли при этом может и не быть.
• Не переименовывай файлы .ymap/.ytyp внутри уже собранного ресурса, если не уверен на 100% — часть паков ссылается на конкретные имена файлов внутри самих данных, и переименование ломает связку без явной ошибки при старте.
• Проверяй entity sets (наборы сущностей, которые можно включать и выключать группами) — многие MLO используют их для вариативности отделки, и если пак предполагает активацию конкретного набора через отдельный скрипт-конфиг, без этого шага часть интерьера может просто не появиться.

Подробнее про общую логику стриминга ассетов и оптимизацию карт под слабое железо — в статье про карты и MLO для FiveM-сервера, здесь фокус именно на установке и конфликтах, а не на визуальной оптимизации.

Конфликт нескольких MLO на одной локации

Ситуация встречается чаще, чем кажется: сначала поставили один пак интерьеров для больницы, через полгода докупили другой — и не заметили, что оба целятся в одну и ту же точку на карте (например, оба заменяют Pillbox Hill Medical Center). Симптомы разные и не всегда очевидные:

• Игрок заходит в дверь и видит пустоту или разрозненные объекты без стен — оба интерьера пытаются занять одно пространство.
• Портал (дверной проём) телепортирует не туда, где ожидалось — активным оказался не тот интерьер, что виден снаружи.
• В консоли ничего критичного нет, но по факту работает только один из двух ресурсов, а второй просто «проигрывает» по порядку загрузки.

Диагностика начинается с элементарного: временно stop один из двух конфликтующих ресурсов и проверить, воспроизводится ли проблема без него. Если да — конфликт подтверждён, дальше решается один из трёх вариантов:

1. Оставить только один из двух MLO на этой локации — самый надёжный способ, если оба реально бьют по одной точке.
2. Проверить, не предусмотрел ли автор одного из паков конфигурационный флаг для отключения конкретного интерьера в его наборе (актуально для больших сборников MLO на несколько локаций сразу — там части можно включать выборочно).
3. Развести локации вручную, если ресурс это позволяет — некоторые кастомные MLO дают возможность задать координаты точки входа через конфиг ресурса, а не жёстко зашиты на оригинальные.

Порядок ensure в server.cfg тоже влияет — если конфликтующие ресурсы стартуют в разном порядке при разных перезапусках (например, из-за refresh и точечного ensure уже во время работы сервера), поведение может «плавать» от рестарта к рестарту, что особенно неприятно диагностировать. Если сталкивался с похожими плавающими конфликтами ресурсов и скриптов не по картам, а по коду — общий подход к поиску виновника бинарным делением server.cfg описан в статье про конфликт ресурсов и скриптов на FiveM, тот же метод работает и для карт.

Тестирование и запуск в server.cfg

Как и с любым ресурсом, запуск — строка ensure в server.cfg:

ensure mrpd_custom

Если MLO зависит от базового пака интерьеров или от загрузчика дверей (часть паков продаётся именно так — «база» плюс «дополнительные локации» отдельными ресурсами), база должна стоять в server.cfg раньше зависимых от неё карт. Общий принцип порядка загрузки ресурсов для RP-фреймворков (ESX/QBCore, если ещё выбираешь между ними — вот сравнение фреймворков) такой же, как и для обычных скриптов.

Перед выкаткой на прод обязательно проверь на тестовом инстансе:

1. Заходишь физически в интерьер, а не смотришь на него через дверной проём издалека — часть проблем со стримингом видна только внутри.
2. Смотришь консоль на ошибки вида Failed to load ytyp или Couldn't find asset — почти всегда это несовпадение путей в манифесте.
3. Проверяешь, нет ли «дыр» в текстурах или пропавших стен — типичный признак того, что часть .ymap не попала в files {}.
4. Если рядом уже стоит другой MLO — специально проверяешь именно эту локацию у обоих ресурсов на предмет пересечения.

Крупные MLO-паки на живом сервере с онлайном лучше выкатывать в окно минимальной активности — рестарт ресурса с картой иногда тянет за собой рассинхрон стрим-данных у уже подключённых клиентов, и часть игроков может не увидеть новый интерьер до переподключения.

Частые вопросы