V Rising: краш сервера при загрузке мира

MAATRIX GAMES

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

Почему краш случается именно на загрузке, а не во время игры

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

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

Повреждённый файл сохранения

Сейвы V Rising лежат не рядом с exe-файлом, а в Saves\v1\<SaveName> — либо по стандартному пути %AppData%\..\Locallow\Stunlock Studios\VRising\Saves\v1\, либо там, куда вы перенаправили сохранения флагом -persistentDataPath при запуске (подробно про эту настройку — в инструкции по установке сервера V Rising). Файл может повредиться, если предыдущий процесс упал во время записи — например, оборвалось электричество на VPS, кончилось место на диске в момент автосохранения, или сработала настройка CompressSaveFiles: true в ServerHostSettings.json, а сжатие не успело завершиться до аварийного завершения процесса.

Признаки именно битого сейва:

• Сервер падает не время от времени, а стабильно в одной и той же точке — сразу после лога загрузки.
• На новом пустом мире (другой SaveName) сервер запускается нормально, проблема только с конкретным сохранением.
• Последняя по времени копия в папке сохранения заметно меньше по размеру или её время изменения не совпадает с ожидаемым интервалом AutoSaveInterval.

Проверить содержимое папки и найти подозрительный файл:

Get-ChildItem "C:\vrising-server\save-data\Saves\v1\world1" -Recurse |
  Sort-Object LastWriteTime -Descending |
  Select-Object -First 20 Name, Length, LastWriteTime

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

Не хватает RAM в момент загрузки мира

Загрузка — это разовый пик потребления памяти, зачастую выше, чем во время обычной игры или даже автосохранения: серверу нужно единовременно развернуть в памяти весь накопленный мир, а не только его активную часть. Официальный минимум Stunlock Studios — 4 ГБ RAM, но это скорее «хватит стартовать пустой мир», а не «дочитает до конца сейв, который рос месяцами». Если сервер и так работает у потолка по памяти, именно загрузка старого большого мира — самый вероятный момент, где его дожимает до краша.

Проверка на Windows, во время попытки запуска:

Get-Counter '\Memory\Available MBytes'

Смотрите на это значение в реальном времени в момент, когда в логе появляется Loading world... — если доступная память падает почти до нуля и процесс VRisingServer.exe тут же исчезает из диспетчера задач, дело в RAM. На Linux (для тех, кто держит сервер через Proton) картина проверяется привычно:

free -h
dmesg | grep -i "out of memory"

Строка Out of memory: Killed process с именем процесса сервера или обёртки Proton — прямое подтверждение, что систему остановил OOM Killer, а не сама игра «упала». Решение здесь не в тонкой настройке, а в апгрейде тарифа: если мир уже большой (десятки построек, активные кланы, история за месяцы), закладывайте запас сверх голого минимума — как посчитать нужный объём под конкретный сервер, разобрано в общей методике сколько RAM нужно под игровой сервер.

Конфликт модов после обновления игры

Модификации для V Rising устанавливаются через BepInEx — тот же принцип инжекции в игровой процесс, что используют многие игры на Unity. Поверх BepInEx сообщество строит инструменты вроде VampireCommandFramework для написания серверных плагинов. Проблема в том, что после каждого патча Stunlock Studios внутренние структуры данных, за которые цепляются моды, могут измениться — а именно к моменту загрузки сейва многие плагины привязывают свои хуки, чтобы читать и дополнять сохранённые данные. Если плагин собран под предыдущую версию игры, он может упасть именно на этом шаге, утаскивая за собой весь процесс сервера вместо аккуратного отключения себя одного.

Типичная картина: сервер грузил тот же самый мир нормально до обновления через SteamCMD (app_update 1829350), а сразу после патча начал падать на загрузке. Проверить версию BepInEx-плагинов и найти виновника проще всего через его собственный лог:

BepInEx\LogOutput.log

Ищите стектрейс с именем сборки конкретного плагина прямо перед моментом краша. Диагностика методом исключения — тем же принципом, что применяют для поиска конфликтующего плагина в Minecraft: временно вынесите всё содержимое BepInEx\plugins в отдельную папку и попробуйте загрузить мир на чистом BepInEx. Если загрузилось — возвращайте плагины по одному, перезапуская сервер после каждого, пока не найдёте виновника. Дальше — либо ждать обновлённую сборку плагина под новую версию игры, либо (если хостинг и сама игра это позволяют) держать пока прежнюю версию сервера, не накатывая последний патч, пока автор мода не подтянет совместимость.

Как читать лог, чтобы не гадать

Путь к файлу лога сервер получает через флаг запуска -logFile, например -logFile "./logs/server.log" — если вы следовали базовой инструкции по установке, этот путь у вас уже настроен. Смотрите последние строки перед обрывом: полноценная загрузка обычно заканчивается явным сообщением о готовности сервера принимать подключения, а при краше лог просто обрывается сразу после Loading world... без этой финальной строки — значит, упало именно на десериализации.

Если BepInEx установлен, у него отдельный от игры лог — BepInEx\LogOutput.log — там же может обнаружиться исключение до того, как оно вообще попадёт в основной лог игры. Если ни один из логов ничего не объясняет и процесс просто молча исчезает (типичный признак access violation на уровне самого процесса, а не пойманного исключения), стоит проверить журнал событий Windows — «Просмотр событий» → «Журналы Windows» → «Приложение», по времени краша там иногда остаётся запись о самом факте аварийного завершения VRisingServer.exe, даже если причина в ней не расшифрована.

Восстановление сервера из бэкапа

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

1. Остановите процесс, чтобы исключить параллельную запись в повреждённые файлы:

Stop-Process -Name VRisingServer -Force

1. Отложите битую версию мира в сторону, не удаляя — иногда часть данных ещё можно вытащить вручную:

Rename-Item "C:\vrising-server\save-data\Saves\v1\world1" "world1-broken-2026-08-30"

1. Скопируйте на освободившееся место последнюю рабочую резервную копию:

Copy-Item -Recurse "D:\backups\world1-latest" "C:\vrising-server\save-data\Saves\v1\world1"

1. Запустите сервер и сразу следите за логом — должна появиться финальная строка успешной загрузки, а не повторный обрыв на Loading world....

На Linux-сервере через Proton логика та же самая, только команды заменяются на systemctl stop/start и cp -r. Игроки при этом теряют прогресс за промежуток между последним удачным бэкапом и моментом краша — это неизбежная цена, если внешние копии снимались реже, чем хотелось бы. Общая практика восстановления игровых серверов из бэкапов, включая типичные грабли с правами доступа и версиями, разобрана отдельно: восстановление сервера из бэкапа — практика.

Профилактика: как не попасть в эту ситуацию снова

• Настройте внешние резервные копии отдельно от встроенного AutoSaveInterval — автосейв защищает от кратковременного сбоя, но не от кривого патча или битого диска. Как выстроить расписание — в статье автобэкапы игрового сервера — настройка расписания.
• Перед крупным обновлением игры делайте отдельную копию папки сейва вручную, даже если расписание уже настроено — на случай, если сам патч ломает совместимость формата.
• Держите список модов минимальным и проверенным: перед обновлением сервера отключайте плагины, убеждайтесь, что мир грузится на чистом BepInEx, и только потом возвращайте моды по одному после проверки их совместимости с новой версией.
• Увеличьте AutoSaveCount до 3-5, если сейчас стоит меньше — лишняя пара рабочих копий в ротации не занимает много места, зато оставляет запасной вариант, если самая свежая окажется битой.
• Не экономьте на RAM для мира, который растёт месяцами — пиковая нагрузка на загрузке требует больше запаса, чем кажется по потреблению во время обычной игры.

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