Автообновление модов на сервере

MAATRIX GAMES

Обновили сервер — и половина модов перестала грузиться, а мир, который вчера работал, сегодня падает при загрузке чанка с постройкой из "устаревшего" мода. Знакомая ситуация почти для любого админа, который держит сборку с внешними модами или плагинами дольше пары недель. В этой статье разберём, что на самом деле умеет автообновляться само, а что нужно настраивать руками, и почему полное автообновление модов на боевом сервере — это риск, а не удобство.

Мод vs плагин: почему обновляются они по-разному

Прежде чем говорить про автообновление, важно развести два типа контента, которые часто путают. Мод меняет саму игру — добавляет предметы, механики, иногда переписывает часть игрового кода (Forge, Fabric для Minecraft, BepInEx для Valheim и десятков других игр на Unity). Плагин работает поверх серверного API, не трогая клиент напрямую — классика тут Bukkit/Spigot/Paper-плагины для Minecraft или Oxide/uMod-плагины для Rust.

Разница критична именно для темы обновлений: моды в подавляющем большинстве случаев должны совпадать по версии у сервера и у каждого игрока — иначе рассинхрон и краш при коннекте. Плагины же чаще всего живут только на сервере, клиенту их видно лишь через результат (команды, GUI, механики), поэтому обновить плагин можно независимо от того, что стоит у игроков. Это первое, что определяет, насколько вообще безопасно что-то автообновлять.

Steam Workshop: автообновление, которое уже встроено

Если сборка держит моды через Steam Workshop (ARK: Survival Evolved, 7 Days to Die, Project Zomboid, часть модов DayZ и другие Source/Steamworks-игры), хорошая новость — механизм автообновления фактически уже есть, просто он не отдельный, а часть обычного обновления сервера через SteamCMD.

Когда сервер настроен на конкретный набор Workshop ID модов (обычно через параметр запуска вроде -GameModIds= или переменную в конфиге, в зависимости от игры), SteamCMD при каждом app_update сверяет депо и подтягивает актуальные версии подписанных модов вместе с самим билдом игры. Отдельно вызывать что-то для модов не нужно — про сам механизм app_update и структуру команд подробно написано в статье про установку и обновление серверов через SteamCMD.

Практический нюанс: у части игр (например, ARK) моды из Workshop скачиваются и обновляются отдельным вызовом workshop_download_item, который стоит держать в том же скрипте, что и обновление самого сервера, а не запускать отдельно по своему расписанию — иначе сервер может стартовать с новым билдом игры, но старой версией мода, и вы получите ровно тот рассинхрон, которого пытались избежать.

# Пример для ARK: обновление сервера + мода одним блоком
./steamcmd.sh +login anonymous \
  +force_install_dir /home/steam/ark \
  +app_update 376030 \
  +workshop_download_item 346110 <MOD_ID> \
  +quit

Здесь 376030 — App ID сервера ARK, 346110 — App ID самой игры (Workshop-контент привязан к клиентскому приложению, а не к серверному), <MOD_ID> — конкретный ID мода со страницы Workshop. Точные ID и синтаксис флага для модов отличаются от игры к игре — сверяйтесь с официальной вики конкретного тайтла, не переносите команду один в один между играми.

Плагин-экосистемы: автообновления нет "из коробки"

С Bukkit/Spigot/Paper-плагинами для Minecraft, Oxide/uMod-плагинами для Rust и подобными плагин-экосистемами для других игр ситуация другая: сам сервер не умеет проверять и подтягивать новые версии плагинов сам по себе. Разработчик выкладывает .jar или .cs-файл на площадку (SpigotMC, Modrinth, Codefling, uMod) — и обновление до новой версии это всегда отдельное скачивание нового файла и замена старого в папке plugins/ (Minecraft) или oxide/plugins/ (Rust).

Есть категория сторонних менеджеров плагинов — обычно они существуют как отдельные плагины поверх основной платформы или как консольные утилиты — которые умеют периодически опрашивать API площадки на предмет новой версии и либо уведомлять админа, либо (у части из них) сразу скачивать и подменять файл. Конкретные названия таких инструментов и их возможности сильно зависят от экосистемы и версии платформы, поэтому смотрите актуальный список на самой площадке (например, в разделе "Plugin Managers" на SpigotMC) — рынок этих утилит меняется, и то, что было популярно год назад, может быть заброшено сейчас.

Если готового менеджера под вашу связку нет или вы ему не доверяете, минимальная автоматизация — скрипт, который дёргает API площадки и просто пишет в лог/уведомление, что вышла новая версия, без автоматической подмены файла:

#!/bin/bash
# check_plugin_update.sh — проверка новой версии плагина через Spigot API (пример)
PLUGIN_ID="34315"  # ID ресурса на SpigotMC
CURRENT_VERSION="2.4.1"
LATEST=$(curl -s "https://api.spiget.org/v2/resources/${PLUGIN_ID}/versions/latest" | grep -oP '"name":"\K[^"]+')

if [ "$LATEST" != "$CURRENT_VERSION" ]; then
  echo "[$(date)] Доступна новая версия плагина ${PLUGIN_ID}: ${LATEST} (текущая: ${CURRENT_VERSION})" >> /home/minecraft/logs/plugin-updates.log
fi

Это не готовое решение для продакшена (нужно свериться с актуальным форматом ответа API площадки — он меняется), а иллюстрация подхода: проверка отдельно от применения.

Почему слепое автообновление модов и плагинов — риск

Главная причина, по которой мы не рекомендуем ставить полное автообновление модов/плагинов на боевом сервере без контроля — совместимость. Новая версия мода или плагина может:

• Поменять формат сохраняемых данных так, что старый прогресс игроков (инвентари, постройки, экономика на сервере) частично или полностью потеряется при загрузке.
• Перестать работать вместе с другим модом/плагином, с которым до этого была зависимость или просто совместное использование одних и тех же хуков/событий — краш при старте или тихий конфликт без ошибок в логе.
• Изменить баланс или механики без предупреждения игроков, что для ролевых и PvP-серверов с устоявшимся комьюнити может быть хуже, чем сама техническая поломка.
• Требовать более новую версию платформы (Paper/Spigot определённого билда, конкретную версию Forge/Fabric), которой у вас ещё нет — и тогда плагин просто не загрузится, залив консоль ошибками.

Особенно опасно это для сборок с несколькими десятками модов/плагинов одновременно — модпаки для 7 Days to Die или крупные Rust-сборки с 15+ Oxide-плагинами: чем больше компонентов, тем выше шанс, что автообновление одного из них сломает цепочку зависимостей, а разбираться, какой именно компонент виноват, придётся уже после жалоб игроков.

Практический компромисс: проверка вместо слепого апдейта

Рабочая схема, которая закрывает и удобство, и риски — разделить "проверку" и "применение":

1. Автоматическая проверка новых версий по расписанию (cron, встроенный менеджер плагинов, скрипт вроде примера выше) с уведомлением админа — в лог, на почту или в Discord-канал сервера.
2. Ручное решение — читаете changelog новой версии, оцениваете, ломает ли она что-то критичное (breaking changes к формату данных, новые зависимости, известные баги в свежем релизе по отзывам комьюнити).
3. Тест на копии сервера или в тестовом окружении перед выкаткой на прод — особенно если мод/плагин трогает сохраняемые данные напрямую.
4. Бэкап прямо перед применением обновления, даже если тест прошёл нормально — про то, как это организовать по расписанию, подробно в статье про настройку автобэкапов игрового сервера.
5. Применение обновления в окно низкой активности игроков, с предупреждением заранее, если сервер активный.

Этот же принцип "бэкап → тест → применение → возможность отката" разобран подробнее применительно к обновлению самого сервера (не модов) в статье обновление сервера без потери прогресса игроков — для модов и плагинов логика ровно та же, просто масштаб риска обычно меньше, чем при мажорном патче самой игры.

Настройка cron для регулярной проверки

Даже если вы решили не автоматизировать применение, регулярную проверку стоит повесить на cron — это снимает с админа необходимость помнить и заходить проверять руками:

crontab -e

# Проверка обновлений модов/плагинов каждый день в 9:00, лог пишется отдельно
0 9 * * * /home/steam/check_plugin_update.sh >> /home/steam/logs/cron-plugins.log 2>&1

Для Steam Workshop-модов, где обновление и так встроено в цикл апдейта сервера, отдельный cron не нужен — используйте расписание из статьи про SteamCMD, синхронизированное с бэкапами. А вот для плагин-экосистем стоит держать проверку и применение раздельными по времени: например, проверка каждое утро, а применение — вручную, в заранее выбранное окно раз в неделю, а не по факту появления новой версии.

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