Valheim с модификациями: как синхронизировать версии сервера и клиентов

Сервер в списке виден, пароль принимается, трое из четверых уже стоят на причале в новом биоме. Четвёртый смотрит на экран, где вместо входа в мир написано что-то про несовпадение версий. Он клянётся, что обновил «всё». Остальные клянутся в том же. И все по-своему правы: каждый действительно что-то обновлял. Просто «всё» у каждого оказалось своим.

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

Три слоя, у каждого своя версия

Первая ошибка в разговоре о модах — считать их единой кучей «версии игры». На деле их как минимум три слоя, и совместимость нужно проверять на каждом стыке.

• Игра. Valheim, которую обновляет Steam. И клиент, и серверная часть получают обновления независимо друг от друга, и номер сборки у них должен совпадать.
• Загрузчик. Программа, которая подгружает моды в игру. У неё своя версия и свои требования к сборке игры. Если игра вышла новой, а загрузчик под неё ещё не обновлён, моды могут просто не стартовать.
• Моды. Каждый — отдельный файл со своей версией, и многие зависят от других модов-библиотек, причём иногда от конкретных диапазонов их версий.

Цепочка зависимостей идёт сверху вниз: мод опирается на загрузчик, загрузчик — на игру. Поэтому обновление игры потенциально ломает всё, что лежит выше, а обновление мода обычно затрагивает только его самого и тех, кто от него зависит. Это важно запомнить: порядок проверки всегда начинается с игры.

Теперь о том, чего ждать от разработчиков. По FAQ Valheim, официальной поддержки модов нет, и работу модов после обновлений игры никто не гарантирует: всё зависит от того, обновил ли автор конкретный мод. Из этого следует практический вывод. Официальный dedicated server — это серверная программа игры, и нигде не сказано, что она поддерживает произвольные сторонние моды. Работает ли конкретный мод на сервере, определяет его автор и ваша проверка, а не документация сервера. Когда мы говорим «серверные моды», мы говорим о том, что вы сами установили поверх, и отвечаете за это тоже сами.

Один набор на всю группу: манифест вместо памяти

Лучшее лекарство от «у меня то же самое» — документ, в котором нет слов, только числа. Назовём его манифестом набора. Это обычный текстовый файл, где записаны сборка игры, версия загрузчика и построчно каждый мод с версией. Он живёт в одном месте, например в общем репозитории или закреплённом сообщении группы, и меняется только по договорённости.

Вот как выглядит сравнение двух наборов, когда вместо «обновлено всё» перед глазами две колонки. Названия модов и номера ниже условные, они нужны только для иллюстрации принципа:

Две расхождения в шести строках. Без таблицы игрок честно скажет, что у него «последние версии», потому что утилита управления модами когда-то показала ему зелёную галочку. С таблицей спор заканчивается за минуту: Мод Б нужно поднять до 3.2.0, а Мод Г — убрать или внести в манифест, если его решили оставить для всех.

Обратите внимание на вторую категорию — лишние моды. Они ловятся хуже всего, потому что игроку кажется, что он ничего не ломает, а всего лишь добавил красивую шапку. Правило простое: если мода нет в манифесте, его нет в сборке. Даже клиентские по духу украшения лучше внести в список заранее, чтобы манифест был исчерпывающим, а не «почти полным».

Что записывать в манифест

• Номер сборки игры в том виде, в каком он отображается в клиенте и в консоли сервера.
• Версию загрузчика и источник, откуда её брали.
• Каждый мод с точной версией, включая библиотеки-зависимости: именно они чаще всего теряются, потому что игрок не ставил их вручную.
• Ключевые параметры запуска сервера: имя мира, путь к сохранениям, режим подключения.

С параметрами стоит остановиться. В руководстве по dedicated server описано, что параметр -world выбирает существующий мир по имени либо создаёт новый, а -savedir меняет путь, где лежат миры и файлы прав. Здесь прячется коварная ловушка для модифицированных групп: опечатка в имени мира не вызовет ошибку, а тихо создаст новый пустой мир. Когда вы проверяете набор на копии, имя мира в строке запуска должно быть записано в манифесте так же, как и версии модов, иначе проверка сделана на чём-то другом, чем рабочий мир.

Там же сказано, что скрипт запуска лучше копировать, так как обновление Steam заменяет оригинал. Для сборки с модами это двойное предупреждение: ваши правки в стартовом скрипте не должны жить в файле, который обновление перезапишет. Держите свою копию скрипта рядом с манифестом и считайте её частью набора.

Обновился один компонент: что тянется следом

Допустим, автор Мода Б выпустил новую версию. Соблазн — нажать «обновить» и идти дальше. Разберём, что на самом деле нужно проверить, на условном примере.

Новая версия Мода Б, допустим, требует более свежей Библиотеки В. Библиотеку В используют ещё два мода из вашего списка, и один из них давно не обновлялся. Получается каскад: обновили один мод, он потянул библиотеку, библиотека может сломать мод, которым вы пользуетесь, но автор которого отстал. Описывать такое словом «обновили» бессмысленно, нужно записать цепочку:

1. Какой компонент меняется и на какую версию.
2. Какие компоненты требуют другую версию в ответ (у авторов это обычно перечислено в описании мода).
3. Какие из остальных модов используют ту же библиотеку и подтверждено ли, что они работают с её новой версией.
4. Если подтверждения нет — вопрос решается на тестовой копии, а не по принципу «авось».

Отдельный случай — обновление самой игры. Сборка Valheim выходит, Steam обновляет клиент у игроков, и сервер тоже нужно подтянуть. Но моды и загрузчик остаются прежними, пока их авторы не выпустят свои обновления. Если вы обновили сервер и игроки обновились автоматически, а загрузчик ещё нет, то поломка случится не из-за ошибки в группе, а из-за разницы темпов. Разумная политика здесь такая: в группе договариваются, что автоматическое обновление клиента у игроков не отключается (его отключать неудобно), но сервер обновляют по сигналу после проверки набора. В промежутке игроки просто ждут и не заходят. Это неприятно, зато предсказуемо.

Есть и разница между «мод не стартует» и «мод стартует, но что-то в мире ведёт себя иначе». Первое заметно сразу, второе — через несколько часов игры, когда в мире появляется странная постройка или пропадает предмет. Именно второй вид поломок делает проверку на копии мира необходимой, а не желательной.

Старое сохранение с новым набором

Здесь начинается самая ответственная часть. Набор может запускаться идеально, сервер может пускать игроков, и всё равно мир окажется испорчен: сохранение хранит то, что записали моды, и новая версия мода может прочитать старые данные иначе. А если обновляется ещё и игра, то может поменяться формат файлов сохранения.

Разработчики описывали такой случай в заметках к исправлению: ошибка конвертации формата сохранения могла повредить часть данных, а возврат резервной копии мира означает потерю прогресса, сделанного после неё. Автоматически восстановить утраченное новая версия не умеет. Из этого следуют два практических правила: копия делается до любого обновления, а возврат к копии — это не отмена, а потеря всего, что произошло после.

Порядок проверки на копии выглядит так:

1. Корректно остановить рабочий сервер. В руководстве корректная остановка описана через CTRL+C, и это не мелочь: копировать файлы мира с работающего процесса значит рисковать получить копию на полпути записи.
2. Скопировать файлы мира и файлы прав целиком в отдельную папку. Если вы используете -savedir, то копировать нужно именно этот каталог.
3. Поднять тестовый экземпляр с новым набором, указав в -world имя мира из копии, а в -savedir путь к копии. Рабочий каталог остаётся нетронутым.
4. Зайти одним-двумя игроками и пройти по конкретным местам: база с большим количеством построек, сундуки с модифицированными предметами, места, где работают механизмы от модов.
5. Остановить тестовый сервер тоже корректно, а затем запустить его снова и убедиться, что мир загрузился с сохранением, а не создался заново.

Последний пункт проверяет то, что многие пропускают: первый запуск после обновления может выглядеть хорошо, потому что мир ещё в памяти. А вот перезапуск покажет, записалось ли всё читаемо.

Что именно искать в мире после обновления? Список придумайте заранее, под свои моды. Для условного набора с модами на строительство и интерфейс это может быть: целы ли самые сложные постройки, на месте ли предметы в сундуках, сохранились ли настройки, которые мод хранил вместе с миром, нет ли ошибок в журнале сервера при загрузке. Если после теста что-то пропало — это ответ на вопрос «обновляться ли». Ответ «пока нет» тоже результат, ради которого копия и затевалась.

Встроенные копии сервера не отменяют этой дисциплины. В руководстве описано, что -saveinterval задаёт интервал сохранения, а -backups и интервалы short/long управляют встроенными копиями. Они полезны как страховка от сбоя посреди игры, но они делаются по расписанию и содержат состояние мира «как есть», в том числе уже испорченное. Перед обновлением набора нужна отдельная осознанная копия с понятной датой и подписью, какой набор версий был в момент её создания. Подписывайте копии номером манифеста: тогда ясно, с каким набором мир можно открыть.

Режим подключения тоже входит в набор

В том же руководстве описаны два способа подключения: Steam backend и Crossplay backend, причём Crossplay использует relay, а permittedlist ограничивает вход указанными Platform User ID. Для группы с модами это означает, что режим подключения нужно держать одинаковым в тестовом и рабочем запуске. Иначе вы проверите один путь входа, а игроки пойдут другим. Если в группе используется список разрешённых игроков, проверьте, что тестовый экземпляр читает те же файлы прав, иначе тест пройдёт «от имени администратора», а у остальных вход не получится.

Как передать версию остальным

Хороший способ проверить свою систему — представить, что новый участник присоединяется к группе без ваших объяснений. Что ему нужно получить? Не пересказ, а три вещи: манифест, инструкцию применения и контрольный способ убедиться, что у него теперь то же, что у остальных.

Манифест мы уже обсудили. Инструкция применения должна быть короткой и однозначной: удалить текущий набор модов, поставить загрузчик указанной версии, поставить моды из списка, не добавляя ничего сверх. Слово «удалить» здесь принципиально. Игроки, которые «докладывают» новые версии поверх старых, получают смесь файлов, которую не может прочитать никто, включая их самих.

Контрольный способ — это сравнение, а не вера. Игрок присылает свой список установленных модов с версиями (скриншот или текст), а ответственный за набор сверяет его с манифестом построчно, как в таблице выше. Занимает пару минут и снимает тот самый спор о том, чьё «всё» актуальнее.

Полезно завести правило смены набора, которое помещается в четыре предложения:

• Любое изменение начинается с записи в манифесте новой версии, а не с установки.
• Изменение проверяется на копии мира, остановленной и перезапущенной корректно.
• Только после успешной проверки рабочий сервер обновляется, и группе приходит новый манифест с номером.
• Пока игрок не подтвердил совпадение со своим списком, он на рабочий сервер не заходит.

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

Где разместить тестовый и рабочий экземпляры

Отдельный вопрос — на чём всё это держать. Для схемы «рабочий мир плюс копия для проверки» нужно, чтобы оба экземпляра могли существовать одновременно хотя бы на время теста, а значит нужен запас памяти, процессора и диска. На VPS MAATRIX есть root-доступ, NVMe-диски и процессоры AMD EPYC, и это удобно для такой работы: можно положить копии мира рядом, держать несколько каталогов с сохранениями и запускать тестовый экземпляр, не трогая рабочий. В публичном предложении указаны тарифы Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe), Uab (2 vCPU, 4 ГБ, 80 ГБ), Heka (4 vCPU, 8 ГБ, 160 ГБ), Maat (8 vCPU, 16 ГБ, 240 ГБ) и Djed (16 vCPU, 32 ГБ, 320 ГБ).

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

Если вы только собираете сервер и вам нужна базовая установка, её порядок разобран отдельно в материале как установить и настроить Valheim на VPS. Здесь мы исходим из того, что сервер уже работает, и речь идёт только о том, как держать вокруг него согласованный набор версий.

Разбор вечера: что изменилось бы в начальной истории

Вернёмся к четвёртому игроку. Что бы произошло в группе с манифестом? Он открыл бы файл, сравнил свои моды с таблицей и нашёл бы отстающий Мод Б и лишний Мод Г меньше чем за пять минут. Никто не переустанавливал бы игру, не менял пароль и не подозревал сервер. Ответственный за набор объяснил бы, что Мод Г нужно либо удалить, либо добавить в общий список после проверки, и вопрос решился бы без обид.

Тот же манифест помогает и при обновлении игры. Когда выходит новая сборка, первый вопрос не «что сломалось», а «что у нас записано и что из этого уже поддержано авторами». Если загрузчик ещё не обновлён, ответ очевиден: ждём. Если обновлён, а часть модов нет, группа решает, обходиться ли без них или подождать. Решение принимается по списку, а не по настроению того, кто громче настаивает.

И последнее. Совместимость в мире модов никогда не бывает окончательной: она подтверждается для конкретной комбинации версий в конкретный момент. Поэтому единственная устойчивая опора — не обещание, что «всё работает», а записанная точка: вот такая сборка игры, вот такой загрузчик, вот эти моды с этими номерами, вот эта копия мира, которая с ними проверена. Любой игрок, открыв этот список, видит, от чего отталкиваться. Если что-то пошло не так, возвращаться нужно к этой точке, и она у группы одна на всех.