Team Fortress 2: краш при загрузке плагина или кастомной карты

MAATRIX GAMES

Всё работало нормально, потом поставили новый SourceMod-плагин или залили кастомную карту — и сервер либо не стартует вообще, либо валится при смене карты, а игроки видят "This server is currently unavailable" вместо честного коннекта. Самое неприятное в таких крашах — что причина почти никогда не написана открытым текстом в консоли. Разберём, как методично найти виновника (плагин, MetaMod-модуль или саму карту) и почему TF2, несмотря на возраст, до сих пор регулярно ловит именно этот тип проблем.

Сначала — определить, кто виноват: плагин или карта

Прежде чем что-то отключать, стоит понять характер краша, потому что он подсказывает направление поиска.

• Краш сразу при старте сервера, до захода первого игрока — почти всегда виноват плагин, расширение SourceMod или сам MetaMod:Source. Карта тут ни при чём, она ещё даже не успела толком загрузиться со всем содержимым.
• Краш именно при смене карты (map change) — подозревать нужно обе стороны: либо саму новую карту (битый bsp, отсутствующие зависимости), либо плагин, который вешает логику на событие смены карты (OnMapStart, OnMapEnd и подобные хуки).
• Краш через какое-то время игры на одной и той же карте — это реже про карту и чаще про плагин, который триггерится на конкретное игровое событие (капут, смерть определённым оружием, использование команды).

Быстрая проверка, которая сразу отсекает половину версий: закомментируйте загрузку кастомной карты в server.cfg или mapcycle.txt, поднимите сервер на стоковой карте вроде cp_dustbowl или ctf_2fort с текущим набором плагинов. Стартует нормально — проблема в карте. Падает и на стоковой карте — ищите в плагинах или MetaMod.

Обратная проверка: временно уберите все сторонние плагины (см. ниже) и попробуйте поднять сервер именно с проблемной картой. Если так всё работает — дело в плагине, который конфликтует именно с этой картой (бывает при кастомных гейммодах с нестандартными сущностями).

Метод отключения по одному

Когда направление поиска понятно, дальше — обычный бинарный поиск, только руками.

Если сервер стартует, но крашится позже (при смене карты, через время), можно работать «на живую» через консоль SourceMod:

sm plugins list
sm plugins unload <id>

Отключайте по одному плагину, начиная с самых новых или недавно обновлённых — они первые кандидаты. При большом списке (20+ плагинов) быстрее отключить сразу половину и смотреть, повторяется ли краш — так и работает бинарный поиск: если краш пропал, виновник в отключённой половине, если остался — в оставшейся.

Если сервер не стартует вообще, консольные команды бесполезны — плагины нужно двигать руками. В addons/sourcemod/plugins по умолчанию уже есть подпапка disabled — именно для этого:

mv addons/sourcemod/plugins/*.smx addons/sourcemod/plugins/disabled/

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

Отдельно проверяется MetaMod:Source — он грузится через addons/metamod.vdf ещё до самого SourceMod. Если краш происходит даже с пустой папкой плагинов, временно переименуйте metamod.vdf (например, в metamod.vdf.bak), чтобы движок вообще не подхватил MetaMod, и поднимите чистый srcds без сторонних модулей. Команда meta list в рабочей консоли покажет отдельно загруженные MetaMod-модули (не путать со списком SourceMod-плагинов) — иногда виноват именно сторонний MetaMod-плагин, а не что-то из SourceMod.

Проверка версии карты у клиента и сервера

Тут часто путают два разных явления, и стоит их развести.

Рассинхрон версий карты между клиентом и сервером (когда у игрока и на сервере разные .bsp с одним именем) — это не краш сервера, а дисконнект конкретного игрока с сообщением в духе несовпадения таблиц классов или версии карты. Причина обычно банальна: обновили карту на сервере, но не обновили её у игроков (для кастомных карт нет автообновления через Steam, как для официальных). Решение — раздача через sv_downloadurl (fast download) с актуальной версией файла, либо явное предупреждение игрокам обновить карту вручную.

Настоящий краш сервера от кастомной карты обычно связан с содержимым самого файла:

• Битый или недокачанный .bsp — оборвалась загрузка на сервер, файл повреждён. Проверяется банально: скачать карту заново и сверить размер/контрольную сумму с оригиналом у автора.
• Отсутствующие зависимости карты — карта ссылается на кастомные текстуры, модели, звуки или partikл-системы, которые не запакованы внутрь .bsp через VBSP pack и которых нет отдельно на сервере. Посмотреть, что реально упаковано в карту, можно так:

bspzip -list tf/maps/cp_имя_карты.bsp

Если в выводе не хватает материалов или моделей, которые упоминаются в описании карты (часто автор пишет отдельный список зависимостей на странице скачивания) — их нужно разложить вручную по tf/materials, tf/models, tf/particles в соответствующих подпапках.

• Проблемы с nav mesh, если на сервере есть боты — карта без сгенерированного .nav-файла может уронить сервер или ботов при попытке построить путь. Генерируется через nav_generate на listen-сервере с картой, файл кладётся рядом с .bsp.

Недостающие зависимости плагинов и расширений

Многие SourceMod-плагины требуют не только сам SourceMod, но и конкретные расширения (extensions) — например SDKHooks, SteamWorks или что-то узкоспециализированное под конкретный режим. Если нужного расширения нет или установлена несовместимая версия, плагин либо тихо не загружается, либо в отдельных случаях тянет за собой краш всего сервера при попытке вызвать несуществующую native-функцию.

Первым делом — логи SourceMod:

addons/sourcemod/logs/errors_YYYYMMDD.log
addons/sourcemod/logs/L<дата>.log

Ищите строки вида «Unable to load plugin», «Native not found», «Unable to load extension» — это прямое указание, чего не хватает.

На Linux частая причина падения именно расширений (.ext.so) — недостающие системные библиотеки. Проверяется командой:

ldd addons/sourcemod/extensions/имя.ext.so

Всё, что помечено как not found (обычно это libcurl.so.4 нужной версии или библиотеки libstdc++), нужно доустановить через пакетный менеджер дистрибутива.

Отдельно стоит сверить версии: MetaMod:Source и SourceMod должны быть из совместимых веток именно под TF2, и архитектура сборки расширений (32-бит vs 64-бит) должна совпадать с архитектурой самого srcds. TF2-сервер исторически 32-битный, но стоит явно проверить, какой бинарник реально запущен, если ставили расширения из непроверенного источника — несовпадение архитектуры это тоже частая причина падения именно при загрузке плагина, а не во время игры.

Чтение краш-логов и core dump

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

Включите подробное логирование в server.cfg или автоисполняемом конфиге:

log on
mp_logfile 1

Логи пишутся в tf/logs — там же можно найти последние команды и события перед падением, если краш не мгновенный.

Если сервер запускается напрямую через srcds_run, не теряйте вывод консоли — при запуске через screen или systemd-юнит перенаправьте stdout/stderr в файл:

./srcds_run -game tf +map cp_dustbowl > tf_server.log 2>&1

На Linux для по-настоящему глубокого разбора включите сохранение core dump перед запуском:

ulimit -c unlimited

После краша анализируется через gdb:

gdb srcds_linux core
(gdb) bt

Backtrace покажет стек вызовов на момент падения. Если в верхних кадрах стека видно имя .so-файла кастомного плагина или расширения — вот и виновник. Если крашится сам engine.so или server.so без стороннего кода в стеке — вероятнее проблема в самой карте (повреждённые данные, переполнение при парсинге) или в баге движка, а не в плагине.

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

Частые конкретные причины: чек-лист

Свести всё в одну таблицу для быстрой сверки:

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

Профилактика: как не ловить это в проде

Полностью исключить краши не получится — TF2 старая игра с горой сторонних модулей, написанных разными людьми с разным уровнем аккуратности. Но снизить частоту и ускорить диагностику вполне реально.

• Тестовый сервер отдельно от боевого. Не обязательно отдельный VPS — часто достаточно поднять второй srcds на другом порту (например 27016 вместо 27015) на том же сервере и гонять там новые плагины и карты перед вводом в основную ротацию.
• Бэкап перед любым изменением. Перед установкой плагина или новой карты сохраните текущее рабочее состояние:

tar -czf backup_$(date +%Y%m%d).tar.gz addons cfg maps

Это откатывает ситуацию за секунды, вместо того чтобы разбираться в панике посреди краша на живом сервере с игроками.

• Обновляйте по одному, не всё разом. Если разом обновить MetaMod, SourceMod и десяток плагинов, при следующем краше придётся разбирать сразу все переменные. Обновление по одному компоненту делает следующий краш (если он случится) сразу понятным по причине.
• Проверяйте changelog перед апдейтом плагина. Автор часто сам пишет о breaking changes или требуемой минимальной версии SourceMod — минута на чтение экономит часы поиска причины.

Похожая логика поиска виновника работает и в других играх на движке Source — при краше от аддона в Garry's Mod процесс почти идентичный. Если сервер TF2 ещё не поднят, сначала свериться с базовой инструкцией по установке — это сразу снимет часть типичных ошибок конфигурации.

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