7 Days to Die: краш сервера при генерации региона карты

MAATRIX GAMES

Сервер 7 Days to Die стоит нормально, игроки ходят по карте, и тут кто-то забредает в непроигранный квадрат — процесс вылетает, все отваливаются с "Connection lost", в консоли тишина или голый краш-дамп. Это классика: генерация региона (RWG) — самый тяжёлый момент для сервера, и падает он именно в эту секунду не просто так. Разберём, что там ломается на самом деле, и как перестать бояться "белых пятен" на карте.

Что вообще происходит при генерации региона

7 Days to Die генерирует мир не целиком заранее, а по кускам — регионам (region), это плитки примерно 512×512 блоков. Пока никто не заходил на территорию, региона физически не существует на диске: есть только карта высот и разметка биомов, посчитанная на старте (RWG — Random World Generator). Как только игрок (или зомби-спавнер, или трейдер, которого сервер пытается разместить) впервые касается непроигранного участка, движок на лету:

• достаёт правила генерации из rwgmixer.xml и всех активных prefabrules.xml,
• расставляет префабы (дома, POI, дороги, водоёмы) по biome-карте,
• считает освещение и коллизии для нового куска,
• пишет получившийся регион на диск как .7rg-файл в папку сохранения мира.

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

Нехватка RAM — самая частая причина

Генерация региона — это кратковременный, но заметный скачок потребления памяти поверх и так немаленького базового аппетита 7DTD (сам процесс сервера с прогруженным миром среднего размера обычно съедает несколько гигабайт, и это без учёта модов). Если серверу впритык хватало памяти на "спокойный" геймплей, скачок при RWG выталкивает процесс за лимит — и тут возможны два сценария:

• OOM killer на Linux молча убивает процесс 7DaysToDieServer, в логе останется просто обрыв без внятной ошибки;
• на Windows сервер либо крашится с access violation, либо намертво зависает (лаг-спайк на 100% CPU), а следом валится по таймауту.

Проверить гипотезу просто: смотрите на потребление памяти в момент краша (через htop/диспетчер задач, если успеваете, или через мониторинг в панели хостинга) — если пик приходится ровно на момент захода игрока в новый регион, это оно. Ориентировочно (сильно зависит от версии игры, числа модов и GameWorldSize) для карты 8k рекомендуют закладывать заметный запас сверх обычного потребления именно на генерацию — если у вас впритык 6 ГБ на сервер с картой 10k и модами, это фактически гарантированная проблема. Решение — либо поднять план по RAM, либо честно уменьшить GameWorldSize в serverconfig.xml, либо снизить нагрузку модами (об этом ниже).

Диск: свободное место и скорость записи

Второй по частоте виновник — банально забитый диск. Регионы копятся: чем больше игроки исследуют карту, тем больше .7rg-файлов ложится в Saves/<GameName>/<WorldGenSeed>/Region/. Если на карте 10k активный клан облазил половину территории, папка сохранения легко разрастается до нескольких гигабайт, и если хост уже стоит на грани заполнения диска, попытка записать новый регион упирается в ошибку записи — а её движок обрабатывает не всегда изящно, чаще просто падает.

Проверка на Linux:

df -h
du -sh ~/.local/share/7DaysToDie/Saves/*

На Windows — просто свойства диска и папки %AppData%\7DaysToDie\Saves. Держите запас минимум в несколько гигабайт свободного места сверх текущего размера сохранения — с ростом карты он вам понадобится. Отдельно: если сервер стоит на медленном сетевом или переполненном HDD-разделе, генерация может не падать по нехватке места, а просто вылетать по таймауту записи — тогда решает переезд на NVMe/SSD, а не увеличение места на том же медленном диске.

Повреждённый или проблемный сид

Иногда дело не в ресурсах, а в самом сиде (WorldGenSeed). Бывают сиды, на которых RWG стабильно спотыкается на конкретных координатах — например, если правила расстановки не могут найти подходящее место под обязательный POI (торговец, заправка, аванпост) в заданном биоме и уходят в затяжной, а иногда и бесконечный, перебор вариантов. Внешне это выглядит как зависание сервера именно при подходе к определённому квадрату карты, а не как случайный краш где попало.

Как проверить:

• посмотрите лог (7DaysToDieServer_Data/output_log__*.txt на Windows или journalctl/логи сервиса на Linux) на предмет повторяющихся строк вида Generating region или ошибок парсинга prefab-правил прямо перед обрывом;
• если краш всегда в одних и тех же координатах — попробуйте телепортироваться (или направить туда GPS другого игрока) на другом, тестовом сиде с теми же модами: если там генерация региона проходит без проблем, дело в конкретном сиде, а не в модах или конфиге;
• как временное решение — можно вручную удалить проблемный .7rg-файл из папки региона (сервер перегенерирует его заново при следующем заходе), но если ошибка воспроизводится стабильно, это лечит симптом, а не причину.

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

Конфликт с модами при генерации мира

Моды, которые трогают rwgmixer.xml, свои префабы или XML-правила спавна, — второй по частоте источник крашей именно на RWG (в отличие от крашей "во время боя" или "при стрельбе", которые обычно про другие моды). Логика простая: пока регион не сгенерирован, движок ни разу не обращался к XML этого мода в бою — он обращается к нему именно в момент расстановки префабов. Если в XML опечатка, конфликт правил (два мода описывают один и тот же tag/rule с разными параметрами) или сломанный .rwgpath/.tts-файл префаба — крash вылезет именно на генерации, а не на старте сервера.

Что делать:

1. Проверить лог загрузки модов на старте — многие XML-ошибки Modding Framework (0-SCore/DMT) печатает сразу, но не всегда фатально останавливает запуск.
2. Если модов несколько — временно откатиться до "чистого" сервера (без модов) и проверить, генерируется ли новый регион нормально. Если да — проблема в одном из модов.
3. Добавлять моды по одному и каждый раз тестировать заход в новый (непроигранный) регион, а не в уже сгенерированный — иначе тест ничего не покажет.
4. Особое внимание — модам с новыми POI/tile-сетами и overhaul-сборкам вроде Darkness Falls, которые сильно переписывают rwgmixer.xml: несовместимая версия оверхола с версией игры — частая причина именно таких крашей. Подробнее о популярных overhaul-модах и их особенностях — в обзоре Darkness Falls и других крупных сборок.

Если ставите моды через лаунчер, а не руками — процесс установки и порядок загрузки разобраны в статье про установку модов через Mod Launcher.

Нельзя менять мир "на лету" после первого старта

Отдельная категория крашей — самодельная. Сервер уже сгенерировал часть регионов под конкретные GameName / WorldGenSeed / GameWorldSize, а потом кто-то в serverconfig.xml меняет размер карты или сид, оставляя старое имя мира (GameName) и старую папку сохранения нетронутой. Движок находит несовпадение между уже записанными регионами и новыми параметрами генерации — и падает именно при попытке сгенерировать регион, который раньше существовал по другим правилам.

Правило простое: GameWorldSize, WorldGenSeed и по сути весь набор параметров генерации фиксируется в момент первого запуска мира. Если хотите что-то поменять:

<!-- serverconfig.xml -->
<property name="GameName" value="MyNewWorld" />
<property name="GameWorldSize" value="8192" />
<property name="WorldGenSeed" value="new-seed-2026" />

— это должно быть новое имя мира (GameName), а не тот же самый, иначе сервер попытается совместить старые данные с новыми правилами генерации. Держите руки подальше от GameWorldSize и WorldGenSeed уже запущенного мира — это не "настройка на лету", а по сути создание нового мира под старым ярлыком.

Управление несколькими мирами и переключение между регионами на одном сервере разобрано отдельно в статье про управление мирами и регионами.

Предгенерация карты локально — лучшая профилактика

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

Как это сделать:

1. Установите дедик-сборку 7 Days to Die локально (через SteamCMD, App ID 294420 для сервера) или используйте штатный клиент с тем же GameWorldSize/WorldGenSeed/набором модов, что будет на боевом сервере.
2. Запустите генерацию мира с нужными параметрами — на локальной машине с достаточным запасом RAM это пройдёт кратно быстрее и без риска для "боевого" сервера.
3. При желании — облетите карту в дебаг/спектейт-режиме или через команду телепорта по координатам, чтобы принудительно сгенерировать все ключевые регионы (спавн-зоны, трейдеры, места будущей застройки базы) ещё до того, как это придётся делать живым игрокам под нагрузкой.
4. Найдите папку готового мира: Windows — %AppData%\7DaysToDie\Saves\<GameName>\<WorldGenSeed>\, Linux — ~/.local/share/7DaysToDie/Saves/<GameName>/<WorldGenSeed>/.
5. Залейте её целиком по SFTP/FTP в такую же структуру папок на сервере, с точным совпадением GameName и WorldGenSeed в serverconfig.xml сервера.
6. Запустите сервер — регионы, которые вы уже "проиграли" локально, подхватятся с диска мгновенно, без повторной генерации, а RWG будет срабатывать только на реально новых для всех участках.

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

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