Minecraft Bedrock: установка Add-ons на сервер

MAATRIX GAMES

Скачали аддон с Minecraft Marketplace или сторонней площадки, закинули на сервер по аналогии с Java-модами — и ничего не изменилось, мир как был ванильным, так и остался? На Bedrock всё работает иначе: тут нет mods/, куда достаточно бросить jar-файл, а есть два разных типа паков и минимум два JSON-файла, которые нужно прописать руками. Разберём по шагам, куда класть файлы, как их активировать для конкретного мира и почему на Bedrock не бывает ситуации «сервер аддон видит, а игроки — нет».

Что такое Add-Ons и чем они принципиально отличаются от модов Java

Add-Ons — это официальный и единственный способ модифицировать Bedrock-сервер, и состоит он из двух типов паков:

• Behavior pack (поведенческий пак) — меняет игровую логику: поведение мобов, характеристики предметов, рецепты крафта, лут-таблицы, правила спавна, а через Scripting API — ещё и произвольный код на JavaScript/TypeScript.
• Resource pack (ресурс-пак) — меняет визуал и звук: текстуры, модели, звуки, интерфейс. Работает так же, как обычные ресурс-паки, но может идти в комплекте с поведенческим паком как единый аддон.

Ключевое отличие от Forge/Fabric/Paper — на Bedrock нет байт-кода, который выполняется прямо в серверном процессе. Behavior pack — это данные (JSON) плюс, опционально, скрипты через официальный Scripting API (@minecraft/server), а не скомпилированный плагин, вклинивающийся в код сервера. Отсюда и разница в возможностях: переписать физику или добавить новое измерение аддоном не получится — Forge такое умеет, Add-Ons нет.

Нужен полный контроль над серверной логикой — это аргумент в пользу Java-версии. Важнее кроссплей с консолями и телефонами при разумном наборе модификаций — Add-Ons хватает для типовых задач: новые мобы, предметы, лут-таблицы, мини-игры на скриптах.

Структура аддона: manifest.json, UUID и версии

Любой пак — это папка, обязательный файл в которой один: manifest.json. Без него сервер пак просто не увидит.

Минимальный behavior pack:

{
  "format_version": 2,
  "header": {
    "name": "Мой behavior pack",
    "description": "Кастомные мобы и лут",
    "uuid": "b17a3c40-1e2d-4a3f-9c11-8e2f6a0d1234",
    "version": [1, 0, 0],
    "min_engine_version": [1, 21, 0]
  },
  "modules": [
    {
      "type": "data",
      "uuid": "f4e2d9a0-77c1-4b6e-a9d3-2f8c1e5b5678",
      "version": [1, 0, 0]
    }
  ]
}

Минимальный resource pack устроен так же, только "type" модуля — "resources":

{
  "format_version": 2,
  "header": {
    "name": "Мой resource pack",
    "description": "Текстуры к моим мобам",
    "uuid": "a2f0c5e1-3d8b-4f2a-8e91-1b6c7d0e9abc",
    "version": [1, 0, 0],
    "min_engine_version": [1, 21, 0]
  },
  "modules": [
    {
      "type": "resources",
      "uuid": "c9d1e7f3-5a4b-4c2d-9e8f-0a1b2c3d4e5f",
      "version": [1, 0, 0]
    }
  ]
}

Важные нюансы, на которых чаще всего спотыкаются в первый раз:

• UUID в header.uuid и в modules[].uuid — два разных, независимых значения, и они не должны совпадать ни между собой, ни с UUID любого другого установленного пака. Сгенерировать их можно командой uuidgen в Linux/macOS или любым онлайн-генератором UUID v4.
• min_engine_version — минимальная версия игры, с которой пак совместим. Слишком новое значение относительно версии вашего bedrock_server может привести к тому, что пак не загрузится вовсе.
• Если behavior и resource pack идут в паре, их принято связывать через dependencies в манифесте behavior pack — там указывается uuid и version парного resource pack. Не строго обязательно для запуска, но правильно с точки зрения того, что игра понимает паки как единое целое.
• Для скриптового Scripting API модуль в манифесте behavior pack выглядит иначе — "type": "script", "language": "javascript", "entry": "scripts/main.js", плюс блок "dependencies" с версией модуля @minecraft/server. Часть возможностей API на разных версиях помечена как экспериментальная (Beta APIs) — сверяйтесь с актуальной Microsoft Creator Documentation, а не со старыми гайдами: API меняется заметнее, чем формат данных.

Куда класть паки на сервере: behavior_packs/ и resource_packs/

В корне Bedrock Dedicated Server (там же, где бинарник bedrock_server, если вы разворачивали сервер по этой инструкции) лежат две папки-репозитория:

bedrock-server/
├── behavior_packs/
│   └── my_behavior_pack/
│       └── manifest.json
├── resource_packs/
│   └── my_resource_pack/
│       └── manifest.json
└── worlds/
    └── Bedrock level/

Каждый пак — отдельная подпапка внутри behavior_packs/ или resource_packs/ с именем на ваше усмотрение (лучше латиницей и без пробелов). Загрузить файлы можно через SFTP-клиент (FileZilla, WinSCP) или файловый менеджер в панели хостинга — так же, как ресурс-паки и датапаки на Java-сервере из статьи про установку ресурс-паков и датапаков.

Важно понимать: сам факт наличия пака в behavior_packs/ или resource_packs/ ещё ничего не включает. Это просто репозиторий, откуда конкретный мир может подтянуть себе паки — активация происходит отдельным шагом.

Активация для мира: world_behavior_packs.json и world_resource_packs.json

Внутри папки мира (worlds/Bedrock level/ по умолчанию — точное имя задаётся параметром level-name в server.properties) создаются или редактируются два файла:

worlds/Bedrock level/world_behavior_packs.json
worlds/Bedrock level/world_resource_packs.json

Синтаксис одинаковый — массив объектов с pack_id (это header.uuid из манифеста пака) и version (массив из манифеста, версия должна совпадать в точности):

[
  {
    "pack_id": "b17a3c40-1e2d-4a3f-9c11-8e2f6a0d1234",
    "version": [1, 0, 0]
  }
]

Такой же файл, только со своим pack_id, создаётся для world_resource_packs.json.

Грабли, о которые бьётся почти каждый в первый раз:

• Лишняя запятая после последнего элемента массива — валидный JSON её не допускает, файл целиком перестаёт парситься, и сервер тихо загружает мир без единого пака, без явной ошибки в консоли. Всегда проверяйте файл в любом онлайн JSON-валидаторе перед заливкой.
• version в world_behavior_packs.json не совпадает с версией в манифесте пака — пак не активируется, опять же без явного сообщения об ошибке. Копируйте массив версии буквально из manifest.json, а не вписывайте на память.
• Если паков несколько и они правят одни и те же сущности или текстуры — порядок в массиве влияет на то, какой пак победит при конфликте. При первой установке нескольких паков сразу проверяйте итог визуально в игре, а не полагайтесь на теорию.
• В отличие от датапаков на Java, где /reload подхватывает изменения на лету, у Bedrock-паков живого reload нет — после правки world-файлов сервер нужно полностью перезапустить.

Как аддон попадает к игрокам: синхронизация с клиентами

Здесь — самое приятное отличие от Java. На Java-сервере ресурс-пак нужно самому выложить по прямой ссылке и прописать её вместе с SHA-1-суммой в server.properties, а датапак игрок вообще не видит — он живёт только на сервере. На Bedrock всё устроено проще и одновременно жёстче:

• Resource pack клиент скачивает автоматически прямо в момент подключения — сервер сам передаёт пак по игровому протоколу, никакой внешней ссылки, хостинга под архив и подсчёта SHA-1 не требуется.
• Behavior pack тоже синхронизируется с клиентом в объёме, нужном для отображения результата (например, кастомные предметы), хотя основная логика выполняется на сервере.
• Отказаться от скачивания пака игрок, в отличие от Java, не может — это не диалог с выбором, а часть протокола подключения. Рычаг на стороне администратора один — параметр texturepack-required в server.properties, который решает, обязателен ли визуальный пак для входа.
• Обратная сторона автоматической раздачи — размер. Крупные текстур-паки заметно увеличивают время первого подключения: клиент реально качает архив с сервера при каждом первом заходе (дальше помогает локальный кэш). На публичном сервере с потоком новых игроков не стоит перегружать resource pack тяжёлыми 4K-текстурами без нужды.

Проверка работы и типичные ошибки

После перезапуска сервера с новыми паками проверьте лог загрузки — строки о поведенческих и ресурс-паках обычно попадают туда же, где идёт основной лог старта (journalctl -u bedrock -f, если сервер запущен через systemd, как описано в статье про установку сервера, либо прямо в консоли screen-сессии).

Быстрый чек-лист, если аддон «не работает»:

1. Пак вообще виден серверу? Проверьте, что manifest.json лежит на верхнем уровне папки пака (не на уровень глубже, в подпапке), а JSON синтаксически валиден.
2. Пак активирован для конкретного мира? Наличие в behavior_packs//resource_packs/ не равно активации — нужна запись в world_behavior_packs.json/world_resource_packs.json с правильными pack_id и version.
3. Версии совпадают буквально? version в world-файле должен посимвольно совпадать с version в манифесте — не «примерно», а точно тем же массивом чисел.
4. Сервер перезапущен после правок? Живого reload для паков нет — только полный рестарт процесса.
5. Для скриптовых аддонов — доступны ли нужные API? Если behavior pack использует @minecraft/server, а функциональность помечена как экспериментальная, часть возможностей требует включения соответствующего тумблера при создании мира — на действующем сервере включить это постфактум через простой JSON не всегда получится, и на практике многие админы создают мир с нужными экспериментами через клиент Minecraft, а затем переносят готовую папку мира на сервер.
6. Нет ли конфликта UUID? Если скопировали чужой пак и не поменяли UUID в манифесте — при установке второго пака с тем же UUID сервер может повести себя непредсказуемо. Особенно актуально с шаблонами и туториальными аддонами, где UUID из примера часто копируют не глядя.

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

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