Cómo Instalar y Gestionar Resources en MTA:SA — Guía Completa
Aprende a instalar, configurar y gestionar resources en MTA:SA: meta.xml, dependencias, ACL, comandos start/stop/refresh y organización de gamemodes.
Los resources son la unidad fundamental de cualquier servidor Multi Theft Auto: San Andreas. Todo lo que corre en el servidor — gamemodes, mapas, sistemas de admin, scripts personalizados, recursos visuales — se empaqueta como resource. Entender cómo instalar, organizar y gestionar estos paquetes es lo que diferencia un servidor que funciona de uno que se rompe en cada deploy.
Este tutorial es para quien está montando o personalizando un servidor MTA:SA y necesita añadir resources de terceros (community.multitheftauto.com), crear los propios o reorganizar una carpeta resources/ que se volvió un caos. Vamos a cubrir estructura de carpetas, sintaxis del meta.xml, gestión de dependencias, ACL y los comandos operativos que vas a usar todos los días. Tiempo estimado de ejecución: 25 a 40 minutos, dependiendo de cuántos resources necesites configurar.
Se asume que ya tienes un servidor MTA:SA instalado y funcional, con acceso a la consola (terminal o panel) y a los archivos del servidor vía SSH, SFTP o panel de gestión.
Requisitos previos
Servidor MTA:SA versión 1.5.9 o superior ya instalado. Acceso a la consola del servidor (terminal SSH o panel). Acceso de lectura/escritura a la carpeta mods/deathmatch/resources/. Editor de texto que respete codificación UTF-8 (VSCode, Notepad++, nano). Conocimiento básico de XML.
mods/deathmatch/resources/ mods/deathmatch/mtaserver.conf mods/deathmatch/acl.xml 22003 Estructura de un resource
Un resource MTA:SA es simplemente una carpeta dentro de mods/deathmatch/resources/ que contiene, como mínimo, un archivo meta.xml. El nombre de la carpeta se convierte en el identificador del resource — es el nombre que usarás en start, stop, refresh y en cualquier referencia vía getResourceFromName().
La estructura mínima queda así:
mods/deathmatch/resources/
├── mi-resource/
│ ├── meta.xml
│ ├── server.lua
│ ├── client.lua
│ └── files/
│ └── imagen.pngEl meta.xml declara tres cosas: metadatos (autor, versión, descripción), archivos que componen el resource (scripts, mapas, archivos cliente) y dependencias (otros resources que deben estar corriendo antes).
Crea la carpeta de tu resource dentro de mods/deathmatch/resources/:
cd /ruta/al/servidor/mods/deathmatch/resources
mkdir mi-resource
cd mi-resourceEl nombre de la carpeta es case-sensitive en Linux. Convención: usa kebab-case o snake_case, sin espacios ni caracteres especiales.
Crea el meta.xml con la declaración mínima:
<meta>
<info author="TuNombre" version="1.0.0" type="script"
description="Descripción corta del resource" />
<script src="server.lua" type="server" />
<script src="client.lua" type="client" />
</meta>El atributo type en el elemento <info> acepta: script (por defecto), gamemode, map, misc. Usa gamemode solo para resources que controlan la lógica principal del juego — aparece en la lista del comando gamemode y bloquea otros gamemodes simultáneos.
Declara archivos del lado cliente que deben ser descargados por el jugador con <file>:
<file src="files/imagen.png" />
<file src="sonidos/efecto.wav" />Estos archivos se transfieren al cliente cuando entra al servidor. Los scripts del lado cliente (type="client") también se transfieren automáticamente, pero cualquier asset (imagen, sonido, modelo) requiere <file> explícito o no llegará al jugador.
Gestionando dependencias entre resources
Los resources raramente viven aislados. Un sistema de admin puede depender de una lib de UI; un gamemode puede depender de un sistema de scoreboard. Declarar las dependencias correctamente evita el escenario clásico: el resource A inicia, llama a una función exportada del resource B, y B todavía no terminó de cargar.
Declara la dependencia en el meta.xml del resource consumidor:
<meta>
<info author="TuNombre" version="1.0.0" type="script" />
<script src="server.lua" type="server" />
<include resource="scoreboard" />
<include resource="mysql-lib" />
</meta>El elemento <include> garantiza que scoreboard y mysql-lib estén iniciados antes de que el resource actual arranque. Si la dependencia falla al iniciar, el resource dependiente también falla — comportamiento deseado, evita estados parciales.
Para llamar funciones exportadas de otro resource, usa la sintaxis exports:
-- server.lua del resource consumidor
local exito = exports["scoreboard"]:addScoreboardColumn("Kills")
if not exito then
outputDebugString("Fallo al agregar columna en el scoreboard", 1)
endLa función debe estar declarada como exportada en el meta.xml del resource proveedor con <export function="addScoreboardColumn" type="server" />. Sin ese export, la llamada retorna nil silenciosamente.
Los resources listados en mtaserver.conf con startup="1" arrancan en el orden del archivo. Coloca libs y dependencias arriba, gamemodes y features de alto nivel al final. Invertir el orden causa errores de “function not found” que desaparecen tras un refreshall, enmascarando el bug real.
Comandos operativos del día a día
Todo el control de resources se ejecuta desde la consola del servidor (terminal donde corre mta-server64, o pestaña consola del panel de gestión de servidores de juegos). Estos comandos no requieren reinicio del servidor — los cambios se aplican en caliente.
| Comando | Qué hace |
|---|---|
start <nombre> | Inicia un resource específico |
stop <nombre> | Detiene un resource específico |
restart <nombre> | Detiene e inicia de nuevo (recarga meta.xml) |
refresh | Detecta resources nuevos/eliminados sin reiniciar |
refreshall | Refresh + recarga scripts de todos los resources en ejecución |
gamemode <nombre> | Define el resource como gamemode activo |
info <nombre> | Muestra metadatos y estado del resource |
resources | Lista todos los resources detectados |
Tras agregar un resource nuevo en la carpeta resources/, fuerza al servidor a detectarlo:
refreshSalida esperada: Refresh completed. Found X new resources, Y removed. Si tu resource no aparece en el conteo, verifica que el meta.xml sea válido (XML mal formado hace que el resource sea ignorado silenciosamente).
Inicia el resource:
start mi-resourceResultado esperado: mi-resource: Resource started. Si aparece un mensaje de dependencia faltante, inicia primero el resource dependiente.
Para que el resource se cargue automáticamente en cada arranque del servidor, edita mods/deathmatch/mtaserver.conf y añade:
<resource src="mi-resource" startup="1" protected="0" />El atributo protected="1" impide que los clientes descarguen el source-code del resource (útil para resources con lógica anti-cheat). Usa protected="0" solo en resources puramente del lado cliente o de community.
ACL — Access Control List
Los resources que intentan usar funciones administrativas (kickPlayer, banPlayer, setElementData sobre otros jugadores, acceso a la base de datos interna) requieren permiso explícito en la ACL. Sin eso, la función retorna false y genera un aviso en la consola.
Cuando un resource pide permiso, la consola muestra:
ACL: aclrequest list <nombre-resource>
ACL: aclrequest allow <nombre-resource> allLista los permisos solicitados:
aclrequest list admin-systemSalida de ejemplo: Pending ACL requests for admin-system: function.kickPlayer, function.banPlayer, general.ModifyOtherObjects.
Aprueba los permisos después de revisar lo que el resource está pidiendo:
aclrequest allow admin-system allAprueba all solo en resources de fuente confiable (autores conocidos de la community, o los tuyos propios). Resources de origen desconocido que pidan general.ModifyOtherObjects en masa deben auditarse línea por línea antes de la aprobación.
Aprobar todos los permisos da al resource acceso a kickear/banear jugadores, modificar datos de otros resources y, en algunos casos, ejecutar comandos en el shell del servidor. Lee el código antes de aprobar — especialmente archivos server.lua y cualquier llamada a executeCommandHandler o runcode.
Verificación
Confirma que todo está funcionando:
info mi-resourceLa salida esperada incluye State: Running, lista de scripts activos y conteo de exports. Si el estado es Loaded pero no Running, el resource cargó pero falló al iniciar — verifica la consola en busca de errores de Lua.
Para validar scripts del lado cliente, entra al servidor con el cliente MTA:SA, abre la consola en el juego (F8) y ejecuta:
debugscript 3El nivel 3 muestra errores, warnings y mensajes de debug del lado cliente. Los errores en archivos cliente suelen aparecer solo aquí, no en la consola del servidor.
Resolución de problemas
El resource no aparece en refresh
Causa más común: meta.xml mal formado. XML no tolera tags sin cierre ni atributos sin comillas. Valida con cualquier parser online o ábrelo en VSCode con la extensión XML. Causa secundaria: carpeta con nombre que contiene espacio o caracter especial (acento, cedilla) — renómbrala a ASCII puro.
Error “Couldn’t find file ‘archivo.lua’ for resource”
El meta.xml referencia un archivo que no existe o tiene typo en el nombre. Recuerda que Linux es case-sensitive: Server.lua y server.lua son archivos diferentes. Lista el contenido de la carpeta con ls -la y compara exactamente con el src= del meta.xml.
El resource inicia pero las funciones no funcionan
Generalmente es problema de ACL (función admin sin permiso) o de dependencia (resource proveedor no corriendo). Ejecuta info <nombre> en el consumidor para ver pendientes de ACL, y resources para confirmar que el proveedor está Running.
”Unable to start resource X (dependencies not met)”
La dependencia declarada en <include> no existe en la carpeta resources/ o falló al iniciar. Descarga e instala el resource dependiente primero, o elimina el <include> si la dependencia no es realmente necesaria.
Próximos pasos
Con los resources operativos, vale la pena profundizar en tres frentes: backup automatizado de la carpeta resources/ antes de cada deploy, versionado vía Git (commit de la carpeta entera excluyendo logs y cache), y monitoreo de excepciones vía outputDebugString centralizado en un resource de logging.
Si vas a poner un servidor MTA:SA en producción con muchos jugadores simultáneos, una VPS Hostini viene con latencia optimizada para Latinoamérica y protección DDoS en el borde — una diferencia notable en servidores con 50+ slots donde el lag del dueño trabaja todo. Para deploys frecuentes, considera automatizar vía webhook que ejecuta git pull en la carpeta resources/ y dispara refreshall en la consola del servidor.
Preguntas frecuentes
¿Cuál es la diferencia entre gamemode y resource en MTA:SA?
Todo gamemode es un resource, pero no todo resource es un gamemode. Un resource es cualquier paquete (scripts, mapas, mods, libs). Un gamemode es un resource especial declarado con <info type="gamemode"> en el meta.xml e iniciado mediante el comando gamemode en lugar de start directo.
¿Por qué mi resource inicia pero los scripts del lado cliente no se ejecutan?
Probablemente el script no está exportado correctamente en el meta.xml. Añade type="client" en el elemento <script> y confirma que el archivo esté dentro de la carpeta del resource. Verifica también /debugscript 3 en el cliente para ver errores de runtime que no aparecen en la consola del servidor.
¿Cómo hago para que un resource se cargue automáticamente cuando el servidor arranca?
Añade el nombre del resource en <resource src="nombre" startup="1" /> dentro de mods/deathmatch/mtaserver.conf. Los resources con startup="1" se inician en el orden del archivo, así que respeta las dependencias (la lib primero, el gamemode después).
¿Puedo editar un resource mientras el servidor está corriendo?
Sí. Edita los archivos y ejecuta refresh o refreshall en la consola — MTA detecta los cambios sin necesidad de reiniciar el servidor. Para cambios en el meta.xml, un restart con el nombre del resource garantiza una recarga limpia de las declaraciones.
¿Qué es la ACL y por qué mi resource pide permisos?
ACL es Access Control List — controla qué funciones administrativas (kick, ban, setElementData en jugadores, etc.) puede llamar cada resource. Edita mods/deathmatch/acl.xml o usa aclrequest allow en la consola para liberar las solicitudes pendientes.
¿Cómo organizo resources en categorías?
Crea subcarpetas dentro de mods/deathmatch/resources/ con prefijo [bracket], tipo [gamemodes], [admin], [maps]. MTA escanea recursivamente y trata el contenido igual — facilita el mantenimiento sin afectar el funcionamiento.