MTA:SA: установка сервера и настройка Lua-скриптов

MAATRIX GAMES

Скачать и запустить MTA:SA — дело десяти минут, а вот разобраться, почему скрипт ресурса не грузится, чем client-скрипт отличается от server, и почему игрок с правами админа вдруг не может выполнить команду kick — это уже отдельная история. Разберём весь путь: от установки бинарника до структуры meta.xml, различий client/server-side Lua и настройки ACL, чтобы сервер не просто запускался, а работал предсказуемо.

Установка сервера: бинарник, а не Steam-игра

MTA:SA — самостоятельный проект поверх GTA: San Andreas, и качается он только с multitheftauto.com, раздел загрузок. Ни SteamCMD, ни лицензии игры для серверной части не нужно — дедик работает как отдельный процесс, который гоняет сетевую синхронизацию и исполняет Lua-код ресурсов.

На Ubuntu/Debian:

mkdir -p ~/mtaserver && cd ~/mtaserver
wget https://linux.multitheftauto.com/dl/multitheftauto_linux_x64.tar.gz
tar -xvzf multitheftauto_linux_x64.tar.gz

Версия архива в ссылке меняется с релизами — актуальную бери со страницы загрузок, а не из старых форумных тем. После распаковки появится бинарник mta-server64 и папка mods/deathmatch/ — это рабочая директория сервера, в ней живут конфиг, ресурсы и логи. Запуск из этой же папки:

cd ~/mtaserver
./mta-server64

Если тема установки и systemd-автозапуска для тебя новая, детальный разбор портов, firewall и юнита есть в отдельном гайде — как поднять сервер MTA:SA. Здесь остановимся только на минимуме, а основной фокус — на том, что происходит внутри resources/, потому что именно там пишется вся игровая логика.

mtaserver.conf: порт 22003 и подключение ресурсов

Главный конфиг — mods/deathmatch/mtaserver.conf, обычный XML. Порт по умолчанию — 22003 UDP, его редко имеет смысл менять, если на машине один сервер:

<servername>Мой RP сервер</servername>
<serverport>22003</serverport>
<serverport_udp>22126</serverport_udp>
<httpport>22005</httpport>
<maxplayers>64</maxplayers>
<adminpassword>смени_меня</adminpassword>

В конце файла — секция <resources>, куда ресурсы прописываются построчно:

<resource src="freeroam" startup="1" protected="0" />
<resource src="мой-гейммод" startup="1" protected="0" />

startup="1" запускает ресурс автоматически при старте сервера. Без этого атрибута ресурс придётся включать вручную из консоли командой start мой-гейммод после каждого рестарта — на проде это удобно только для тестовых ресурсов, которые не должны стартовать сами.

meta.xml: как MTA понимает, что за скрипты в ресурсе

Ресурс — это папка в mods/deathmatch/resources/, и главный файл в ней — meta.xml. Он говорит серверу, какие Lua-файлы грузить и на какой стороне их исполнять. Без корректного meta.xml ресурс не запустится вообще, даже если Lua-код внутри идеален.

Минимальный пример для простого ресурса:

<meta>
    <info author="твой_ник" type="script" name="Мой ресурс" description="Тестовый ресурс" version="1.0.0" />

    <script src="server.lua" type="server" />
    <script src="client.lua" type="client" cache="false" />

    <file src="icon.png" />
</meta>

Разбор атрибутов, которые реально важны:

• type="script" в <info> — тип ресурса (script, gamemode, map и другие); влияет на то, как ресурс отображается в списке и как с ним работает admin-панель.
• type="server" / type="client" в <script> — на какой стороне исполняется файл. Это ключевое отличие MTA от многих других движков: сторона задаётся в meta.xml, а не угадывается по содержимому файла.
• cache="false" — отключает кэширование клиентского скрипта у игроков. Полезно при активной разработке: без этого атрибута игрок может получить старую версию файла из локального кэша клиента и словить баг, которого в актуальном коде уже нет.
• <file src="..." /> — non-Lua файлы (картинки, звуки, модели), которые ресурс должен раздавать клиентам через встроенный HTTP-сервер.

Если в meta.xml опечатка в имени файла или незакрытый тег — сервер обычно честно пишет об этом в консоли при попытке start ресурса, вместе с номером строки.

Client-side и server-side: где какой код работает

Это то место, где новички чаще всего путаются. В MTA:SA один и тот же гейммод состоит из двух независимых Lua-окружений:

Server-side (type="server") выполняется на дедике, видит всех игроков разом, работает с базой данных, хранит серверное состояние (деньги, инвентарь, права). Пример — обработка команды:

-- server.lua
addCommandHandler("heal", function(player)
    setElementHealth(player, 100)
    outputChatBox("Здоровье восстановлено", player)
end)

Client-side (type="client") выполняется у каждого игрока отдельно — интерфейс, HUD, локальные эффекты, обработка ввода с клавиатуры. Он не может напрямую менять состояние других игроков, только своё локальное окружение и то, что видит на экране.

Стороны общаются между собой событиями, а не прямыми вызовами функций:

-- client.lua
triggerServerEvent("onPlayerRequestHeal", localPlayer)

-- server.lua
addEvent("onPlayerRequestHeal", true)
addEventHandler("onPlayerRequestHeal", root, function()
    setElementHealth(source, 100)
end)

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

Отладка ошибок в каждом окружении смотрится по-своему: серверные ошибки — прямо в консоли сервера или через journalctl -u mta-server -f, если сервер поднят через systemd; клиентские — в игровой консоли (~ или F8 по умолчанию) командой debugscript 3, которая включает подробный вывод ошибок Lua на стороне клиента.

Установка готовых ресурсов из Community

Писать RP-гейммод с нуля решаются немногие — обычно берут готовую сборку или набор ресурсов с community.multitheftauto.com либо с GitHub конкретного проекта (MTA:Life-подобные RP-сборки, DD-race, DayZ-style выживачи — всё это чужой открытый код, который нужно просто правильно подключить).

Порядок действий:

cd ~/mtaserver/mods/deathmatch/resources
git clone https://github.com/автор/имя-ресурса.git

Если ресурс без git — просто распаковывается архивом в ту же папку. Дальше — обязательно прописать в mtaserver.conf:

<resource src="имя-ресурса" startup="1" protected="0" />

и перезапустить сервер либо выполнить в консоли refresh (пересканирует список ресурсов) и start имя-ресурса.

Частая грабля с чужими ресурсами — зависимости. Крупные RP-сборки почти всегда тянут за собой сторонние ресурсы (например, mysql-модуль для базы данных или общие библиотеки вроде dgs/dxi3d для интерфейсов) — они либо лежат в архиве отдельными папками рядом с гейммодом, либо перечислены как <include> в meta.xml самого ресурса:

<include resource="dgs" />
<include resource="mysql" />

Если сервер при старте ресурса пишет что-то вроде Warning: dependent resource dgs missing — качаешь недостающий ресурс отдельно и кладёшь рядом. Ещё одна деталь: у ресурсов из Community версии Lua-API иногда рассчитаны на определённую версию сервера — если гейммод писался пару лет назад, часть функций может быть уже deprecated в актуальном MTA:SA. Это стоит проверять по логу ошибок при первом запуске, а не считать ресурс автоматически рабочим только потому, что он скачался без ошибок.

ACL: кто и что может делать на сервере

ACL (Access Control List) — система прав MTA:SA, полностью описанная в файле mods/deathmatch/acl.xml. Она определяет, какие аккаунты входят в какие группы и какие действия эти группы могут выполнять — от банальной команды kick до права запускать и останавливать ресурсы.

Структура acl.xml — три связанные сущности:

<acl name="Admin">
    <right name="command.kick" access="true" />
    <right name="command.ban" access="true" />
    <right name="resource.admin.all" access="true" />
</acl>

<group name="Admin">
    <acl name="Admin" />
    <object name="user.твой_ник" />
</group>

<acl> — сам набор прав с конкретными right, <group> — группа, которая объединяет ACL-наборы и привязывает их к аккаунтам (user.ник) или ресурсам (resource.имя). Руками редактировать acl.xml при живом сервере не стоит — файл перезаписывается сервером на лету, и ручные правки легко потерять при следующем сохранении. Правильный путь — команды из консоли или через ресурс admin/webadmin, которые входят в стандартную поставку:

aclrequest list имя-ресурса
addaccount ник пароль
aclrequest allow имя-ресурса all

aclrequest — механизм, которым сами ресурсы просят у сервера доступ к определённым правам (например, ресурс с античитом просит general.ModifyOtherObjects); список запросов ресурса смотрится командой aclrequest list, а выдаётся право через aclrequest allow. Без выданных прав ресурс может запуститься, но часть его функций будет тихо не работать — это ещё одна частая причина, почему «скрипт вроде запустился, но не работает как надо».

Для RP-серверов ACL обычно строят многоуровневой пирамидой: Guest → Moderator → Admin → Owner, где каждая следующая группа наследует права предыдущей плюс что-то своё поверх. Логика похожая на распределение ролей в любом игровом дедике — например, в гайде по выбору движка для RP разбирается, чем система прав MTA отличается от подхода в SA-MP и FiveM, если стоишь перед выбором платформы для будущего проекта.

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