Como Instalar e Gerenciar Resources no MTA:SA — Guia Completo

Resources são a unidade fundamental de qualquer servidor Multi Theft Auto: San Andreas. Tudo que roda no servidor — gamemodes, mapas, sistemas de admin, scripts customizados, recursos visuais — é empacotado como resource. Entender como instalar, organizar e gerenciar esses pacotes é o que separa um servidor que funciona de um que quebra a cada deploy.

Este tutorial é para quem está montando ou customizando um servidor MTA:SA e precisa adicionar resources de terceiros (community.multitheftauto.com), criar os próprios ou reorganizar uma pasta resources/ que virou bagunça. Vamos cobrir estrutura de pastas, sintaxe do meta.xml, gerenciamento de dependências, ACL e os comandos operacionais que você vai usar todo dia. Tempo estimado de execução: 25 a 40 minutos, dependendo de quantos resources você precisa configurar.

Pré-suposto: você já tem um servidor MTA:SA instalado e funcional, com acesso ao console (terminal ou painel) e aos arquivos do servidor via SSH, SFTP ou painel de gerenciamento.

Pré-requisitos

Estrutura de um resource

Um resource MTA:SA é simplesmente uma pasta dentro de mods/deathmatch/resources/ contendo, no mínimo, um arquivo meta.xml. O nome da pasta vira o identificador do resource — é o nome que você usa em start, stop, refresh e em qualquer referência via getResourceFromName().

A estrutura mínima fica assim:

mods/deathmatch/resources/
├── meu-resource/
│   ├── meta.xml
│   ├── server.lua
│   ├── client.lua
│   └── files/
│       └── imagem.png

O meta.xml declara três coisas: metadados (autor, versão, descrição), arquivos que compõem o resource (scripts, mapas, arquivos cliente) e dependências (outros resources que precisam estar rodando antes).

cd /caminho/para/servidor/mods/deathmatch/resources
mkdir meu-resource
cd meu-resource

<meta>
    <info author="SeuNome" version="1.0.0" type="script"
          description="Descrição curta do resource" />
    <script src="server.lua" type="server" />
    <script src="client.lua" type="client" />
</meta>

<file src="files/imagem.png" />
<file src="sons/efeito.wav" />

Gerenciando dependências entre resources

Resources raramente vivem isolados. Um sistema de admin pode depender de uma lib de UI; um gamemode pode depender de um sistema de scoreboard. Declarar dependências corretamente evita o cenário clássico: resource A inicia, chama uma função exportada do resource B, e B ainda não terminou de carregar.

<meta>
    <info author="SeuNome" version="1.0.0" type="script" />
    <script src="server.lua" type="server" />
    <include resource="scoreboard" />
    <include resource="mysql-lib" />
</meta>

-- server.lua do resource consumidor
local sucesso = exports["scoreboard"]:addScoreboardColumn("Kills")

if not sucesso then
    outputDebugString("Falha ao adicionar coluna no scoreboard", 1)
end

Comandos operacionais do dia a dia

Todo o controle de resources roda pelo console do servidor (terminal onde o mta-server64 está rodando, ou aba console do painel de gerenciamento de servidores de jogos). Esses comandos não exigem reinício do servidor — mudanças são aplicadas a quente.

refresh

start meu-resource

<resource src="meu-resource" startup="1" protected="0" />

ACL — Access Control List

Resources que tentam usar funções administrativas (kickPlayer, banPlayer, setElementData em outros jogadores, acesso ao banco de dados interno) precisam de permissão explícita na ACL. Sem isso, a função retorna false e gera um aviso no console.

ACL: aclrequest list <nome-resource>
ACL: aclrequest allow <nome-resource> all

aclrequest list admin-system

aclrequest allow admin-system all

Verificação

Confirme que tudo está funcionando:

info meu-resource

Saída esperada inclui State: Running, lista de scripts ativos e contagem de exports. Se o estado for Loaded mas não Running, o resource carregou mas falhou ao iniciar — verifique o console pra erros de Lua.

Para validar scripts client-side, entre no servidor com o cliente MTA:SA, abra o console no jogo (F8) e rode:

debugscript 3

Nível 3 mostra erros, warnings e mensagens de debug do client-side. Erros em arquivos client costumam aparecer só aqui, não no console do servidor.

Resolução de problemas

Resource não aparece no refresh

Causa mais comum: meta.xml mal-formado. XML não tolera tags sem fechamento ou atributos sem aspas. Valide com qualquer parser online ou abra no VSCode com extensão XML. Causa secundária: pasta com nome contendo espaço ou caracter especial (acento, cedilha) — renomeie pra ASCII puro.

Erro “Couldn’t find file ‘arquivo.lua’ for resource”

O meta.xml referencia um arquivo que não existe ou tem typo no nome. Lembre que Linux é case-sensitive: Server.lua e server.lua são arquivos diferentes. Liste o conteúdo da pasta com ls -la e compare exato com o src= do meta.xml.

Resource inicia mas funções não funcionam

Geralmente é problema de ACL (função admin sem permissão) ou de dependência (resource provedor não rodando). Rode info <nome> no consumidor pra ver pendências ACL, e resources pra confirmar que o provedor está Running.

”Unable to start resource X (dependencies not met)”

A dependência declarada em <include> não existe na pasta resources/ ou falhou ao iniciar. Baixe e instale o resource dependente primeiro, ou remova o <include> se a dependência não for realmente necessária.

Próximos passos

Com resources operacionais, vale aprofundar em três frentes: backup automatizado da pasta resources/ antes de cada deploy, versionamento via Git (commit a pasta inteira excluindo logs e cache), e monitoramento de exceções via outputDebugString centralizado em um resource de logging.

Se você está colocando um servidor MTA:SA em produção com muitos jogadores simultâneos, uma VPS Hostini já vem com latência otimizada pra Brasil e proteção DDoS na borda — diferença sensível em servidores com 50+ slots onde o lag do dono trava tudo. Para deploys frequentes, considere automatizar via webhook que faz git pull na pasta resources/ e dispara refreshall no console do servidor.