DayZ: проблема с модами после обновления игры

MAATRIX GAMES

Bohemia выкатила очередной патч, вы обновили сервер как обычно — и он либо вообще не стартует, либо стартует, но игроки не могут подключиться с невнятной ошибкой. В логе на первый взгляд каша, а виноватых полсотни модов из коллекции. Знакомая ситуация почти для каждого, кто держит модовый DayZ дольше одного патч-цикла: игра обновилась быстрее, чем автор мода успел выпустить совместимую версию. Разберём, как быстро определить, что дело именно в модах, что делать прямо сейчас, чтобы вернуть сервер игрокам, и как в следующий раз пережить патч без паники в дискорде.

Как понять, что дело именно в модах

Первое, что нужно сделать после неудачного старта — не гадать, а посмотреть в лог. DayZ пишет два типа логов в папке profiles/ внутри установки сервера: script_*.log (ошибки скриптового слоя Enfusion) и *.RPT-файлы (report-логи движка, там же обычно лежит причина падения при старте). Смотрите самый свежий по времени файл:

ls -lt ~/dayzserver/profiles/*.RPT | head -n 1
tail -n 80 ~/dayzserver/profiles/DayZServer_x64_*.RPT

Признаки, что виноваты именно моды, а не сам сервер или конфиг:

• В RPT-логе есть строка вида Addon '...' requires addon '...' — не хватает зависимости, порядок в -mod= или сама зависимость сломались после апдейта.
• Сервер стартует, но в консоли или логе мелькает что-то про несовпадение версии контента, а игроки при попытке зайти получают обрыв соединения почти сразу после начала загрузки — это чаще всего рассинхрон версии между ядром игры и модом, который её меняет.
• Ошибка появляется на конкретном шаге загрузки — при инициализации конкретного класса конфига (CfgVehicles, CfgWeapons и т.д.) — это почти всегда мод, который правит эти же классы и не успел адаптироваться под изменившуюся структуру данных патча.

Если же сервер падает без единого намёка в RPT сразу на старте, до всякой загрузки контента — вероятнее проблема не в модах, а в самом бинарнике сервера (App ID 223350) или в правах на файлы после обновления; тут стоит перепроверить шаги из статьи про SteamCMD-установку и обновление серверов, прежде чем грешить на моды.

Почему DayZ так жёстко реагирует на рассинхрон версий

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

• Сервер не стартует вовсе — движок падает при инициализации мода, который ссылается на изменившиеся или удалённые классы.
• Сервер стартует, но подключение игроков рвётся с ошибками вида BattlEye: Client not responding или похожими сообщениями о несовпадении — по сути тот же рассинхрон, только проявляется он не при старте сервера, а при рукопожатии с клиентом.
• Сервер и клиент вроде бы работают, но начинаются десинки на конкретных предметах или зонах карты — самый неприятный сценарий, потому что баг не сразу очевиден и списывается на что угодно, кроме мода.

Важный нюанс: чем крупнее патч (не мелкий хотфикс, а сезонное обновление с изменением структуры данных или переработкой части движка), тем выше шанс, что сломаются сразу несколько модов одновременно, особенно завязанные на общие базовые фреймворки вроде Community Framework (@CF). Если у вас стоит сборка с крупными оверхол-модами вроде Namalsk или Deer Isle, закладывайте на восстановление после большого патча не часы, а иногда день-два — это не показатель того, что автор забросил проект, крупные карты и оверхолы просто сложнее адаптировать.

Быстрый фикс: временно убираем проблемный мод из запуска

Пока автор не выпустил совместимую версию, самый надёжный способ вернуть сервер онлайн — временно отключить проблемный мод из параметров запуска. Если вы уже прошли через установку модов на DayZ-сервер, помните: моды перечисляются через точку с запятой в -mod= (клиентский контент) и -serverMod= (только серверная логика). Найдите строку запуска — она либо в скрипте старта, либо в ExecStart= вашего systemd-юнита — и уберите из списка мод-подозреваемого:

# было
-mod=@CF;@Windstride;@Namalsk;@BrokenMod

# стало — @BrokenMod временно убран
-mod=@CF;@Windstride;@Namalsk

Если используете systemd, после правки юнита не забудьте перечитать конфигурацию и перезапустить службу:

sudo systemctl daemon-reload
sudo systemctl restart dayzserver
sudo journalctl -u dayzserver --since "5 min ago"

Как найти виновника, если модов много и непонятно, кто именно сломался: если RPT-лог явно называет мод по имени папки — повезло, отключайте сразу его. Если нет — действуйте методом исключения: отключите последнюю добавленную партию модов (обычно ломается свежедобавленное или то, что давно не обновлялось), запустите сервер, и если он поднялся — возвращайте моды по одному или группами, пока не найдёте виновника. Для коллекции из полусотни модов это дольше, но надёжнее, чем угадывать.

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

Проверяем Workshop-страницу мода: когда ждать обновление

Прежде чем паниковать или писать автору гневный коммент, откройте страницу мода на Steam Workshop и посмотрите на объективные признаки:

• Дата последнего обновления и changelog. Если автор уже опубликовал апдейт с пометкой вроде "compatibility fix" за последние часы — просто обновите мод тем же способом, что скачивали изначально.
• Раздел обсуждений (Discussions) и последние комментарии. Активные авторы обычно сразу пишут статус: "работаю над фиксом", "жду апдейта от разработчиков базового фреймворка" — это экономит вам часы гадания.
• Required items. Иногда ломается не сам мод, а его зависимость — например, обновился @CF, а надстройка над ним ещё не подстроилась. Проверьте, у всех ли модов в цепочке зависимостей вышло обновление, а не только у верхнего в списке.
• Как давно мод вообще поддерживается. Мод, не обновлявшийся год и больше до патча — кандидат на то, что фикса можно не дождаться вовсе; стоит поискать активный форк или замену заранее, а не после третьего дня простоя.

Что делать, пока ждёте фикс: временные меры

Полностью без модов сервер работать не обязан — решение зависит от того, насколько критичен отключённый мод для вашей сборки:

• Мод некритичный (косметика, доп. лут-таблица, второстепенная QoL-фича) — просто оставьте его отключённым до апдейта, большинство игроков даже не заметят.
• Мод критичный (карта, вся экономика трейдеров, база построек) — тут решать сложнее. Если это отдельная карта вроде Namalsk или Deer Isle, откат может означать временную недоступность всего сервера для этой сборки — тут либо ждать, либо заранее держать запасной ванильный/лёгкий инстанс на случай долгого простоя основного.
• Мод — только серверная логика (-serverMod=, например админ-тулза или бэкенд экономики) — часто можно временно откатиться на последнюю рабочую версию мода вручную, если вы сохраняли бэкап папки @Мод перед обновлением. Держите такой бэкап в привычке — это резко сокращает время простоя.

Не спешите откатывать сам сервер обратно на старую версию игры ради совместимости с модом: DayZ обновляется принудительно для всех клиентов через Steam, и игроки со свежим клиентом просто не смогут зайти на сервер со старой версией. Откат сервера — не рабочий вариант почти никогда, кроме совсем узких случаев с полностью закрытым для внешних игроков тестовым инстансом.

Автоматизация: обновляем и проверяем моды одним скриптом

Чтобы в следующий раз не разбираться с этим вручную посреди ночи, имеет смысл держать скрипт, который обновляет сервер и все моды разом и не поднимает боевую службу, если что-то пошло не так. База — тот же workshop_download_item через SteamCMD, что и при первой установке модов, но с проверкой перед перезапуском:

#!/bin/bash
set -e

DAYZ_DIR=~/dayzserver
STEAMCMD_DIR=~/steamcmd
APP_ID=221100        # App ID клиента DayZ — используется и для Workshop-контента
SERVER_APP_ID=223350 # App ID выделенного сервера

MODS=(1559212036 2116151222 1608638848)  # Workshop ID модов вашей сборки

systemctl stop dayzserver

cd "$STEAMCMD_DIR"
UPDATE_CMD="+force_install_dir $DAYZ_DIR +app_update $SERVER_APP_ID validate"
for MOD_ID in "${MODS[@]}"; do
  UPDATE_CMD="$UPDATE_CMD +workshop_download_item $APP_ID $MOD_ID"
done
./steamcmd.sh +login anonymous $UPDATE_CMD +quit

# Переносим свежие версии модов в папки сервера и обновляем ключи
for MOD_ID in "${MODS[@]}"; do
  SRC="$STEAMCMD_DIR/steamapps/workshop/content/$APP_ID/$MOD_ID"
  find "$SRC" -iname "*.bikey" -exec cp {} "$DAYZ_DIR/keys/" \;
done

systemctl start dayzserver
sleep 30
journalctl -u dayzserver --since "1 min ago" | grep -qi "addon.*requires" && \
  echo "ВНИМАНИЕ: конфликт зависимостей модов, проверь лог вручную" || \
  echo "Сервер стартовал без явных ошибок модов"

Скрипт грубый — он не заменяет чтение логов руками, но снимает часть рутины и сразу подсвечивает явный конфликт зависимостей после обновления. Более безопасный вариант, который стоит завести отдельно от боевого сервера: тестовый инстанс на другом порту (-port=2402 вместо боевого -port=2302), куда прилетает то же обновление первым, до того как трогать продакшн. О разнице между Steam Workshop-моделью обновления и ручными плагин-экосистемами, а также о рисках слепого автообновления подробнее — в статье про автообновление модов на сервере.

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