DayZ script.log: как читать ошибки и не паниковать из-за каждой строки

Когда сервер не запускается, лагает после старта или какой-то мод ведет себя странно, первым делом почти все лезут в script.log. И вот тут начинается боль: строк много, половина красная, везде какие-то FIX-ME, Missing, NULL pointer, названия модов, обфусцированные папки и ощущение, что сервер сейчас развалится.

На деле не каждая страшная строка в script.log является причиной проблемы. В этом гайде разберем, на что смотреть в первую очередь, что можно временно пропустить и как читать лог по-человечески.

Где лежит script.log

Обычно он лежит в папке профилей сервера:

profiles/script_год-месяц-день_час-минута-секунда.log

Пример:

profiles/script_2026-07-27_13-59-38.log

Если у вас в параметрах запуска указано -profiles=profiles, значит лог будет внутри этой папки. Если путь другой, ищите там.

Сначала смотрим, сервер вообще дошел до миссии или нет

В нормальном запуске ближе к концу лога можно увидеть что-то вроде:

[MissionServer] OnInit - Server
[MissionServer] OnMissionStart - Server
[MissionServer] OnMissionLoaded - Server

Если OnMissionLoaded есть, сервер хотя бы дошел до загрузки миссии. Это не значит, что все идеально, но это уже не ситуация “сервер умер на первой секунде”.

Если лог обрывается до загрузки мира, тогда ищем последнюю ошибку перед обрывом. Обычно причина рядом.

Самые важные строки

В первую очередь ищем:

SCRIPT (E)
Virtual Machine Exception
Reason:
Stack trace:
NULL pointer to instance
Cannot open file
Can't compile
Unknown type
Undefined function
Bad type

Вот это уже не декоративный шум. Особенно если после ошибки сервер крашится, не пускает игроков или ломается конкретная система.

Как читать Virtual Machine Exception

Пример из живого лога:

SCRIPT (E): Virtual Machine Exception
Reason: NULL pointer to instance

Class: 'StashSearchManager'
Function: 'ReadStashSearchConfig'
Stack trace:
StashSearchServer/Scripts/4_World/stashsearchserver/plugins/pluginbase/stashmanager.c:70 Function ReadStashSearchConfig

Читаем не сверху вниз, а по смыслу:

Reason - что случилось.
Class - в каком классе.
Function - какая функция упала.
Stack trace - путь, где это произошло.

В этом примере проблема не в ванильном DayZ и не в карте. Ошибка идет от мода StashSearchServer, функция читает конфиг тайников и ловит NULL pointer.

Человеческий перевод: мод ожидал получить какие-то данные из конфига, но получил пустоту. Часто это бывает из-за пустого JSON, неправильной структуры файла, отсутствующего поля, битого конфига или несовместимой версии мода и его настроек.

NULL pointer - это важно

Reason: NULL pointer to instance

Это значит, что скрипт пытается обратиться к объекту, которого нет. Например:

• конфиг не загрузился;
• нужный массив пустой;
• файл есть, но внутри неверная структура;
• мод ждет объект, который не был создан;
• порядок модов или зависимостей неправильный;
• старая конфигурация осталась после обновления мода.

Если NULL pointer повторяется несколько раз в одном и том же моде, это уже кандидат номер один на проверку.

В моем примере StashSearchServer ругается сразу на несколько функций:

ReadStashSearchConfig
ReadStashGiftConfig
ReadTypedStashConfig
ReadStashSkillConfig
GetTotalSkillSearches

Значит, я бы первым делом проверял именно конфиги StashSearchServer: созданы ли они, не пустые ли, подходят ли под текущую версию мода, не слетели ли после обновления.

Явная ошибка настройки

Еще один пример:

[VPPAdminTools] Error parsing credentials.txt! Please input a valid password, with no // at the start of the line!

Вот это очень понятная ошибка. VPPAdminTools не смог прочитать credentials.txt.

Что проверить:

• файл credentials.txt существует;
• пароль указан без // в начале строки;
• нет лишних комментариев в строке с паролем;
• файл лежит там, где его ждет VPP;
• после изменения сервер был перезапущен.

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

Ошибки доступа к папкам

Пример:

[RD_Admin] Radiation directory is empty or DayZ Server have not access to this
[RD_Admin] Resist directory is empty or DayZ Server have not access to this

Тут два варианта:

1. папка реально пустая;
2. серверный процесс не может прочитать эту папку.

Проверяем путь, наличие файлов и права доступа. Особенно если сервер запущен не от того пользователя, под которым вы редактировали файлы.

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

Что можно не чинить сразу

В DayZ-модах очень часто встречаются предупреждения:

FIX-ME: Overriding function but not marked as override
FIX-ME: Method argument can't be strong reference
Possible variable name conflict
No need to use Cast for up-casting
Missing ';' at the end of line

Звучит страшно, но не всегда является причиной падения сервера.

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

Но есть оговорка: если после обновления DayZ или мода таких предупреждений стало больше, а механика сломалась, тогда уже смотрим внимательнее.

Что нельзя пропускать

Я бы не пропускал:

• SCRIPT (E);
• Virtual Machine Exception;
• NULL pointer to instance;
• ошибки чтения JSON/XML;
• ошибки конкретного конфига;
• Cannot open file;
• Can't compile;
• ошибки в вашем init.c;
• ошибки в моде, который отвечает за ключевую механику сервера;
• повторяющуюся ошибку на каждом входе игрока.

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

Как понять, какой мод виноват

Смотрите на путь в stack trace.

Пример:

StashSearchServer/Scripts/4_World/...

Почти наверняка разбираемся с StashSearchServer.

Другой пример:

CodeLock/scripts/4_world/...

Смотрим CodeLock.

Еще пример:

$CurrentDir:mpmissions/DayZ.dz_map/init.c:98

Вот это уже ваша миссия и ваш init.c. Если ошибка приходит сюда, надо смотреть строку рядом с указанной.

Как я обычно разбираю лог

Мой порядок такой:

1. Открываю самый свежий script_*.log.
2. Иду в конец файла и смотрю, дошел ли сервер до OnMissionLoaded.
3. Ищу SCRIPT (E) и Virtual Machine Exception.
4. Смотрю Reason, потом Class, потом первый путь в Stack trace.
5. Если ошибка из мода, проверяю конфиги этого мода и его зависимости.
6. Если ошибка из init.c, открываю указанную строку и последние правки.
7. Если ошибка повторяется при входе игрока, чиню ее в первую очередь.
8. Только потом смотрю предупреждения SCRIPT (W).

Что делать после исправления

После правки не надо смотреть старый лог и ждать, что он сам исправится. Делайте так:

1. Остановить сервер.
2. Переименовать старый script.log или просто запомнить время.
3. Запустить сервер заново.
4. Открыть новый script_*.log.
5. Проверить, исчезла ли конкретная ошибка.

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

По конкретному примеру

Если брать лог с ошибками:

StashSearchManager
ReadStashSearchConfig
ReadStashGiftConfig
ReadTypedStashConfig
ReadStashSkillConfig
GetTotalSkillSearches

Я бы начал с StashSearchServer:

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

Параллельно стоит поправить VPPAdminTools credentials.txt, потому что там ошибка явная и простая.

Итог

script.log не надо читать как список всего, что срочно сломано. Его надо читать как след.

Главное правило простое: сначала ошибки SCRIPT (E) и stack trace, потом конкретные конфиги модов, потом ваш init.c, и только после этого предупреждения. Большая часть FIX-ME в модовом сервере может жить месяцами, а один NULL pointer в нужном месте будет ломать механику каждый рестарт.

И да, перед любой правкой конфига делайте бэкап. Это скучно ровно до первого вечера, когда он спасает сервер.