Terraria с tModLoader: отдельный сервер для модифицированного прохождения

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

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

Обычная Terraria и окружение tModLoader живут порознь

Первое решение — не смешивать. Ванильный сервер Terraria и сервер tModLoader — разные окружения с собственными каталогами, собственными мирами и собственным набором модов. Если на одной машине уже стоит обычный сервер для друзей, не стоит пытаться «подключить моды» к нему: заведите для модифицированного прохождения отдельный каталог, а лучше отдельного пользователя системы и отдельный запуск. Тогда ошибка в списке модов не заденет мир, в котором никто модов не ждёт. Основы установки обычного сервера мы разбирали в статье Как установить и настроить Terraria на VPS; здесь предполагается, что с базовой частью вы знакомы, и речь пойдёт о том, что добавляет tModLoader.

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

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

Что лежит в каталогах: «установлено» и «включено» — два разных факта

В схеме каталогов серверной утилиты tModLoader есть два рабочих места, которые нас интересуют. В каталоге Mods находятся файлы install.txt и enabled.json, в каталоге Worlds — миры, каждый из которых представлен парой файлов с расширениями .wld и .twld (README серверной утилиты tModLoader).

Разница между двумя файлами в Mods принципиальна. install.txt отвечает на вопрос «что нужно получить»: он задаёт, какие моды из Steam Workshop сервер должен загрузить. enabled.json отвечает на вопрос «что должно работать»: он определяет, какие из имеющихся модов включены. Эти два списка не обязаны совпадать, и именно на их расхождении строится значительная часть странных историй.

Вот несколько ситуаций, к которым приводит разделение:

• мод есть в install.txt, но отсутствует в enabled.json — он скачан, но не работает; игроки с таким модом на клиенте могут обнаружить, что сервер его не ждёт;
• мод включён, но его нет среди установленных — сервер ожидает то, чего у него нет, и это та ошибка, которую хочется поймать до приглашения друзей, а не после;
• мод есть в обоих списках, но какой-то зависимый от него мод не включён — часть содержимого просто не заработает так, как ожидалось.

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

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

Согласуем моды, зависимости и настройки с участниками

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

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

Как реагирует конкретная сборка

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

Практический порядок поиска выглядит так.

1. Сначала версия tModLoader. Это самый грубый уровень: если окружения отличаются, остальные сравнения бессмысленны. Убедитесь, что клиент и сервер собраны с одной версией, и зафиксируйте её в записи группы.
2. Затем список включённых модов. Попросите участника прислать список с его стороны и сравните с enabled.json сервера. Лишние моды на клиенте и пропущенные на нём — самый частый источник отказа, и он решается за минуту.
3. Потом версии модов. Названия совпали — сверяйте номера сборок. Если автор мода обновил его после того, как вы собрали сервер, у новичка из Workshop окажется свежая версия, у вас — прежняя.
4. Дальше зависимости. Для каждого мода прочитайте, что ему нужно, и убедитесь, что это включено и на сервере, и на клиенте.
5. В конце настройки. Если всё остальное совпало, а поведение странное, сверяйте конфигурации модов, у которых они есть.
6. И только после этого читайте сообщения подключения. Текст отказа и записи журнала сервера нужно читать как улики по конкретной сборке: они подсказывают, какой мод или какое условие сработало. Не приписывайте им общего смысла — смотрите, что именно они называют в вашем случае.

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

Метод «деления пополам», когда простого сравнения мало

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

Этот пример условный: он показывает арифметику метода, а не отчёт о чьём-то испытании. С каждым делением число подозреваемых уменьшается вдвое, а значит, число шагов растёт как логарифм размера набора. У деления есть оговорка: зависимости нужно переносить вместе с зависящими модами, иначе вы получите отказ по причине неполного набора, а не по причине исходной неисправности.

Пакет для участников

Все эти проверки хорошо превращаются в один документ, который получает каждый игрок. Что в нём лежит:

• версия tModLoader, на которой запущен сервер;
• перечень модов с версиями — те, что скачиваются, и те, что включены;
• отметки о зависимостях, то есть какой мод без какого не работает;
• значения настроек для модов, у которых они критичны для игры;
• адрес сервера и способ получить пароль, если он задан.

Когда такой документ есть, фраза «у меня не заходит» превращается в сравнение двух текстов. Когда его нет, вы сравниваете показания людей, а те редко помнят, что именно ставили три недели назад.

Мир: создать с нуля или загрузить существующий

У мира в конфигурации сервера два режима, и путать их не стоит. Параметр world в serverconfig задаёт путь к уже существующему миру, а worldname предназначен для мира, который сервер создаёт (README серверной утилиты tModLoader).

Разница важна не только формально. Если вы хотите продолжить прохождение, которое ведёте с друзьями в локальной игре, вам нужен world с путём к готовому миру. Если стартуете заново, подойдёт worldname. Перепутав режимы, вы рискуете получить не тот мир: сервер создаст новый, а старый будет лежать нетронутым, и первую неделю игроки с удивлением будут бродить по пустой карте. Заметьте: это исправимо, ничего не удаляется, но день-другой ушедшего времени и неразбериха в группе обеспечены.

Мир — это пара файлов

В каталоге Worlds каждый мир представлен парой .wld и .twld. Это один мир, а не два, и обращаться с ними нужно как с неделимым целым. Переносите пару вместе. Копируете — оба файла. Кладёте на сервер — оба файла. Храните резервную копию — тоже оба, из одного момента времени. Копия, где .wld взят из вчерашнего дня, а .twld из позавчерашнего, ничем не лучше отсутствия копии: она открывается, но не обязана быть согласованной.

Отсюда несколько правил, которые не требуют никакой экзотики:

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

Мир принадлежит набору модов

Содержимое мода — блоки, предметы, персонажи — записывается в мир. Отсюда следствие, которое неприятно узнавать на практике: нельзя спокойно убрать мод из набора, пока в мире остаются его постройки и предметы. Что произойдёт при загрузке без мода, зависит от конкретного мода, поэтому тактика одна: перед любым изменением набора сделайте копию пары файлов и пробуйте изменение на копии, а не на живом мире.

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

Первое подключение и проверка сохранения

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

Проведите пробный сеанс. Он не требует особых инструментов:

1. Запустите сервер с вашим набором и миром.
2. Подключитесь минимум двумя клиентами: один с чистой установкой по вашему пакету, другой — с компьютера, где игра ставилась давно. Если оба заходят, набор действительно воспроизводим, а не просто «работает у меня».
3. В игре сделайте то, что принадлежит модам: поставьте блок мода, создайте предмет, получите какой-нибудь прогресс.
4. Остановите сервер штатно и убедитесь, что время изменения обоих файлов мира — .wld и .twld — обновилось.
5. Запустите сервер снова, подключитесь и проверьте, что построенное и полученное на месте.

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

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

Какие ресурсы нужны машине

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

В публичном предложении VPS MAATRIX есть ряд тарифов: 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 ГБ). Диски на NVMe, процессоры AMD EPYC, доступ root. Для маленькой компании с небольшим набором логично начинать с одного из младших вариантов и смотреть на потребление памяти во время игры, а не выбирать «с запасом» вслепую. Для объёмных сборок начальную точку можно сдвинуть выше, и правильно сделать это после пробного сеанса, в котором вы наблюдаете память и загрузку процессора при реальном числе игроков.

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

Обновление одного элемента, а не всего набора сразу

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

В серверной утилите есть возможность установки выбранной версии, а обновление самого инструмента может обновить и моды (README серверной утилиты tModLoader). Из второго факта следует осторожность: если вы обновили инструмент ради новой версии окружения, моды при этом могли обновиться вместе с ним, хотя вы этого не планировали. Значит, обновление «только одного элемента» требует обдуманного порядка, а не одной кнопки.

Как менять один элемент

Идея проста: за один шаг меняется одна вещь, а после каждого шага набор снова сверяется. Порядок такой:

1. Запишите текущее состояние. Версия tModLoader, файлы install.txt и enabled.json, версии модов и оба файла мира — это и есть точка возврата.
2. Остановите сервер и скопируйте пару мира. Копия нужна именно до обновления, пока в мире нет ничего, записанного новой версией.
3. Измените один элемент. Например, только версию одного мода, а не окружение и не пачку модов.
4. Проверьте, что изменилось ровно одно. Если после действия поменялись другие версии модов, фиксируйте это: так вы видите, что обновление затронуло больше, чем планировалось.
5. Запустите сервер на копии мира или с остановленным доступом игроков. Сначала проверьте, что мир загружается и содержимое мода на месте.
6. Подключите клиент с обновлённым элементом. Если всё в порядке, сообщите группе, что именно им нужно обновить у себя.

Путь возврата

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

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

Когда лучше подождать

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

Один лист на всю группу

Хорошо подготовленный сервер tModLoader — это не особая конфигурация, а набор договорённостей, записанных на одну страницу. На ней стоит версия tModLoader, перечень скачиваемых модов в том виде, в каком они записаны для сервера, список включённых, зависимости, настройки, значимые для игры, имя мира и способ его загрузки — через world для существующего или через worldname для нового, — а также дата и место последней пары файлов мира, снятой перед изменением.

Если сервер завтра придётся поднять заново — на другой машине, в другом каталоге, через полгода — по такому листу это можно сделать без угадывания: сначала окружение нужной версии, затем install.txt и enabled.json, затем пара .wld и .twld в каталоге Worlds. А если у кого-то из друзей перестанет получаться подключение, сравнение идёт по строкам листа, а не по воспоминаниям. Именно такой комплект и позволяет группе вернуться в тот же мир в том же состоянии, в каком его оставили.