Стенд использует набор компонентов windows-x86 или linux-x86 в зависимости от платформы. В справочнике описаны зависимости и ограничения проверок. Результаты конкретной сборки фиксируются в отчетах соответствующего запуска с версиями и хешами. Установка и команды описаны в руководстве сервера.
server.lock.json определяет URL архивов, SHA-256, обязательные файлы и пути установки. На обеих платформах используются следующие версии:
| Компонент | Фиксированная версия |
|---|---|
| ReHLDS | 3.15.0.896 |
| ReGameDLL_CS | 5.30.0.814 |
| Metamod-R | 1.3.0.138 |
| AMX Mod X base и cstrike | 1.10.0-git5484 |
| Модуль и include-файлы ReAPI | Архив 5.29.0.358, версия загруженного модуля 5.29.0.359-dev |
| База HLDS | Steam app 90, mod cstrike, ветка steam_legacy |
Include-файлы ReAPI должны быть из того же архива фиксированной версии, что и модуль. При установке хеши архивов проверяются до распаковки. SteamCMD может обновляться самостоятельно; содержимое депо Valve учитывается отдельно от архивов фиксированных версий компонентов. Установка сохраняет манифесты Steam и хеши базовых файлов до установки компонентов. Метаданные сессии содержат доступный снимок базы, текущий хеш SteamCMD, хеши плагина и сборки, карт и профилей, а также версии работающих компонентов. Если снимок базы отсутствует, записывается null.
start проверяет версии, которые сообщают компоненты, плагин TestLab и модули CStrike, FakeMeta, Ham Sandwich, ReAPI и JSON. Несовпадение версии считается ошибкой. Проверка при запуске не подтверждает совместимость отрисовки клиента.
Требуются Python 3.12 или новее и сетевой доступ к Steam и указанным в lock-файле HTTPS-источникам загрузки. Исполняемые файлы сервера, модули и компилятор Pawn имеют архитектуру x86, даже если система и Python 64-битные.
На Windows создается скрытая консоль, поскольку ReHLDS использует консольные API Win32. Перед управлением работающим сервером проверяются сохраненные данные, идентифицирующие процесс, а не только его PID.
В Ubuntu необходимо установить 32-битные библиотеки:
sudo dpkg --add-architecture i386
sudo apt update
sudo apt install libc6:i386 libstdc++6:i386 libgcc-s1:i386doctor проверяет наличие обязательных файлов и их архитектуру PE/ELF x86. В Linux также проверяются отсутствующие зависимости через ldd и наличие ~/.steam/sdk32/steamclient.so. По этому пути должна быть доступна официальная 32-битная библиотека SteamCMD. Настройка описана в руководстве сервера.
В WSL корень сервера должен находиться в файловой системе Linux, например /var/tmp/nextclient-testlab. 32-битные инструменты AMXX несовместимы с некоторыми особенностями inode/stat в DrvFs. Для компиляции исходники и include-файлы копируются во временный каталог Python; он также должен находиться в файловой системе Linux, в том числе при переопределении TMPDIR.
Для Windows и Linux используются отдельные файлы конфигурации. Одновременно запущенным серверам нужны отдельные доступные адреса или порты. Профили привязаны к точному хешу BSP. Серверные проверки геометрии подтверждают проходимость с учетом габаритов и прямую видимость; для проверки видимости клиентом требуется подключенный игрок.
С указанными версиями компонентов функция AMXX может возвращать нулевой идентификатор заложника или идентификатор, отличный от переданного в HostagePos. Плагин отслеживает реальные сообщения и сопоставляет их координаты с существующей сущностью заложника. Совпадение принимается только для единственной сущности на расстоянии не более 0,25 единицы и идентификатора из сообщения в диапазоне 1..255. Идентификатор из сообщения имеет приоритет над значением функции AMXX.
Состояние содержит выбранный hostage_id, native_hostage_id и hostage_id_source. Игровые проверки требуют положительных уникальных номеров и сохранения тех же идентификаторов при перезапуске раунда. Неоднозначное совпадение координат не позволяет определить идентификатор.
| Результат | Что подтверждает результат и каковы ограничения |
|---|---|
build |
Компиляция Pawn и соответствие метаданных сборки и плагина. Игровое поведение не проверяется. |
operations |
Действия сценария и проверка их результатов на выделенном сервере: движение, взаимодействие через Use, подбор, установка и обезвреживание C4, урон, спасение, перезапуск. |
server |
Серверные проверки, применимые к прогону. Для полного успешного отчета нужны все данные и успешное завершение прогона. |
pvs |
Видимость для подключенного клиента. PVS представляет собой набор потенциально видимых областей карты; также фиксируется исходный результат AddToFullPack. |
visual |
Ручная проверка изображения в клиенте. Требуются игровой клиент и записанный результат проверки. |
Сценарии без клиента отдельно возвращают operations, а поля pvs, visual и общий результат server оставляют в состоянии not_run. В сцене сопровождения заложника проверки inside/outside/return также остаются not_run без настоящего клиента. Успешные игровые операции не подтверждают доставку сообщения конкретному игроку или правильную отрисовку радара. Сообщение без установленного получателя отмечается как not_confirmed.
Для проверки движущегося заложника подключите клиент и не перемещайте игрока, от лица которого ведется наблюдение. Заложник должен войти в PVS, провести вне PVS не менее 6 непрерывных секунд при original_pack=0 и вернуться в PVS при original_pack=1. Оператор должен получить не менее 3 периодических сообщений HostagePos с выбранным идентификатором. Суммарное перемещение по этим сообщениям должно составить не менее 256 единиц. Разработчик также проверяет переключение источника координат на радаре. Порядок действий приведен в руководстве ручных проверок.
Для передачи результатов используются report.json, events.clean.jsonl и server.clean.log конкретного запуска. Исходные журналы и секреты сессии остаются локально. Проверяйте полноту отчета и статусы сборки, сервера и ручной визуальной проверки отдельно. not_run означает отсутствие требуемого подтверждения.