V Rising: установка модов на сервер

MAATRIX GAMES

Голый ванильный V Rising быстро упирается в потолок того, что можно настроить через штатные конфиги — хочется команд для админов, кастомной прогрессии или просто удобных плюшек вроде клан-менеджмента. Всё это приходит через моды, а моды в V Rising, как и в большинстве игр на Unity, цепляются к процессу через один и тот же фреймворк — BepInEx. Разберём, как поставить его правильно на уже работающий dedicated-сервер, не сломать автозапуск и не разойтись версиями с игроками, которые будут заходить с модами на клиенте.

Почему V Rising сложнее в моддинге, чем большинство игр на BepInEx

Если вы уже ставили BepInEx на другую игру — например, на Valheim (там процесс во многом похож на установку BepInEx для Valheim) — есть один важный нюанс, из-за которого V Rising нельзя настраивать по той же инструкции один в один. V Rising собран на IL2CPP, а не на классическом Mono-рантайме Unity. Для Mono-игр (как раз Valheim) хватает BepInEx 5.x — он подключается к уже готовой .NET-сборке игры напрямую. Для IL2CPP-игр код на старте компилируется в нативный C++, и никакого управляемого .NET-слоя изначально просто нет — BepInEx для таких игр (линейка BepInEx 6, IL2CPP-сборка) должен сначала сгенерировать прослойку из interop-сборок, через которые плагины смогут обращаться к внутренним классам игры.

Практическое следствие: установка занимает на один шаг больше, чем для Mono-игр, и на этом шаге проще всего словить панику, решив, что сервер завис. Разберём по порядку.

Скачиваем правильную сборку BepInEx под V Rising

Официальный голый BepInEx с GitHub для IL2CPP-игр требует ручной донастройки — конкретных путей до сборки игры, версии рантайма и генерации доменных сборок. Для V Rising сообщество, как и для большинства крупных модовых игр, собрало готовый пакет на Thunderstore (vrising.thunderstore.io) — в нём уже настроенная связка BepInEx 6 IL2CPP под конкретную версию движка игры. Ищите пакет с названием вида BepInExPack в разделе Tools/Modding на странице V Rising на Thunderstore — на момент публикации там же указана версия игры, под которую собран пакет, сверяйтесь с ней перед установкой, чтобы не поймать несовместимость сразу на старте.

Скачиваете zip-архив (обычно 15-25 МБ — заметно больше, чем для Mono-версий BepInEx, потому что в комплекте идёт urlmon/интероп-инструментарий) и переносите на сервер:

# с локальной машины, если скачали через браузер
scp BepInExPack_V_Rising-*.zip vrising@ваш-сервер:/home/vrising/vrising-server/

Если сервер стоит на Windows (штатный вариант для V Rising, подробнее — в инструкции по установке сервера V Rising), архив можно просто скачать браузером прямо на VPS через RDP или перекинуть тем же scp/через общую папку.

Распаковка: структура папок после установки

Главная грабля здесь та же, что и почти у всех пакетов Thunderstore: архив распаковывается во вложенную папку, а не прямо в текущую директорию. Разворачиваем правильно, рядом с VRisingServer.exe:

На Windows (PowerShell):

cd C:\vrising-server
Expand-Archive BepInExPack_V_Rising-*.zip -DestinationPath C:\vrising-server\bepinex-tmp
Move-Item C:\vrising-server\bepinex-tmp\BepInExPack_V_Rising\* C:\vrising-server\
Remove-Item -Recurse C:\vrising-server\bepinex-tmp

После распаковки рядом с VRisingServer.exe и VRisingServer_Data должны появиться:

vrising-server/
├── VRisingServer.exe
├── VRisingServer_Data/
├── BepInEx/
│   ├── core/              # сам фреймворк, не трогаем
│   ├── config/             # конфиги модов появятся здесь после первого запуска
│   ├── plugins/            # сюда кладём моды
│   └── interop/             # сгенерируется автоматически при первом запуске, пусто до этого
├── dotnet/                 # рантайм для IL2CPP-сборки BepInEx
├── doorstop_config.ini
└── winhttp.dll             # прокси-dll, через которую грузится BepInEx

Если структуры BepInEx/ рядом с exe нет, а вместо неё лежит папка BepInExPack_V_Rising — значит распаковали на уровень глубже, повторите перенос содержимого ещё раз.

Первый запуск: генерация interop-сборок

Это тот самый шаг, которого нет у Mono-игр вроде Valheim. Запускаете сервер как обычно:

VRisingServer.exe -persistentDataPath "C:\vrising-server\save-data" -serverName "Мой сервер V Rising" -saveName "world1" -logFile "./logs/server.log"

При первом запуске после установки BepInEx консоль надолго — от одной до нескольких минут, в зависимости от мощности CPU сервера — зависает на строках вроде:

[Message: BepInEx] Preloader started
[Message: BepInEx] Running under Unity v...
Generating Interop assemblies...

Это не зависание и не краш — BepInEx в этот момент разбирает нативный IL2CPP-код игры и генерирует управляемые заглушки классов в папку BepInEx/interop/, чтобы плагины могли к ним обращаться. Прогресс-бар или проценты в консоли не выводятся, и это главная причина, по которой админы, впервые ставящие моды на V Rising, убивают процесс на середине генерации, решив, что он завис — и в итоге получают битую, неполную папку interop/, из-за которой сервер потом не грузится вовсе. Просто дайте процессу закончить: явный признак завершения — в логе появляется полноценная строка загрузки мира и порты открываются штатно.

Повторная генерация не запускается при каждом рестарте — только когда меняется версия игры (после app_update 1829350) или версия самого BepInEx. Если после обновления сервер снова завис на Generating Interop assemblies... — это ожидаемо, а не баг.

Куда класть моды и порядок их загрузки

Сами моды кладутся в BepInEx/plugins/ — так же, как и в Mono-версии фреймворка. Каждый мод с Thunderstore обычно распространяется как zip с папкой вида BepInEx/plugins/ИмяМода/ внутри, где лежит .dll плагина и сопутствующие файлы:

cd C:\vrising-server\BepInEx\plugins
Expand-Archive ~\Downloads\SomeMod-1.2.3.zip -DestinationPath SomeMod

BepInEx сканирует всё содержимое plugins/ на старте и загружает валидные сборки — никакой отдельной регистрации не нужно. Порядок загрузки при этом не хаотичный: BepInEx подгружает плагины в порядке их внутренних зависимостей, объявленных через атрибут BepInDependency в самом моде — то есть если мод A требует библиотеку B, фреймворк сам гарантирует, что B загрузится раньше A, независимо от порядка файлов на диске. Единственное, что зависит от вас — чтобы сама зависимость физически лежала в plugins/: если её там нет, загрузка мода, который на неё ссылается, просто упадёт с ошибкой отсутствующей сборки в логе.

Для серверных модов V Rising частая база — фреймворк VampireCommandFramework, поверх которого многие плагины реализуют команды для админов и игроков. Если ставите несколько модов, которые на него ссылаются, VampireCommandFramework достаточно положить в plugins/ один раз — остальные подхватят его как общую зависимость, дублировать не нужно.

Синхронизация версий клиент-сервер

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

Ручная раздача zip-архивов по Discord работает, но плохо масштабируется на группу больше 2-3 человек. Практичнее — менеджер модов (r2modman или Thunderstore Mod Manager, они взаимозаменяемы и оба поддерживают V Rising как отдельную игру в списке): заводите профиль с нужным набором модов, экспортируете код профиля кнопкой Export и рассылаете его всем, кто подключается. Игрок импортирует код — менеджер сам подтягивает нужную версию BepInEx для клиента и все моды с точными версиями, без ручной распаковки.

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

Типичные ошибки при активации модов

• Сервер завис на Generating Interop assemblies... дольше нескольких минут. Проверьте загрузку CPU — если процесс реально молотит, просто ждите. Если CPU простаивает и лог не двигается вообще — вероятно, предыдущий запуск был прерван на этом же шаге и папка BepInEx/interop/ осталась битой: удалите её содержимое и перезапустите сервер, генерация пройдёт заново с нуля.
• Мод не загрузился, а в логе — ошибка про отсутствующую сборку (assembly not found). Почти всегда не хватает зависимости мода в plugins/ — распакованный архив с модом принесли, а библиотеку, от которой он зависит (тот же VampireCommandFramework), забыли. Смотрите раздел зависимостей на странице мода на Thunderstore.
• После установки мода сервер вообще перестал стартовать. Временно вынесите содержимое BepInEx/plugins/ в другую папку и запустите сервер на чистом BepInEx. Загрузился — возвращайте моды по одному с перезапуском после каждого, тем же методом исключения, что применяют для поиска конфликтующего мода или плагина в других играх. Если крашится именно на загрузке существующего мира с уже установленными модами — отдельно разобрано в статье про краш V Rising при загрузке мира.
• После обновления игры через SteamCMD моды перестали загружаться или сервер падает. Патч игры мог сломать совместимость либо с версией BepInEx, либо с конкретным плагином, который цепляется к внутренним классам напрямую. Проверьте BepInEx/LogOutput.log на предмет исключений сразу после app_update, и не спешите обновлять моды раньше, чем выйдет подтверждённо совместимая версия под новый патч.
• Клиент не может подключиться после того, как на сервере поставили моды. В девяти случаях из десяти дело не в портах, а в расхождении версий модов между клиентом и сервером — сверьте список через экспортированный профиль r2modman, а не на глаз.

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