Wikipedia MTA
Comandos personalizados en MTA:SA: cómo crear tu propio sistema con addCommandHandler
Casi todo gamemode de MTA:SA necesita comandos de chat propios:
/tp, /curar, /vip, /reportar, etc. La función que hace esto posible es addCommandHandler, y entenderla bien es uno de los primeros pasos para cualquiera que empiece a scriptear en MTA.¿Qué hace addCommandHandler?
Registra una palabra (el comando) y la asocia a una función que se ejecuta cada vez que un jugador la escribe en el chat con
/ adelante.addCommandHandler("curar", function(player, commandName)setElementHealth(player, 100)outputChatBox("Te has curado por completo.", player, 0, 255, 0)end)
En este ejemplo, cuando un jugador escribe
/curar, el servidor le devuelve la vida al máximo y le muestra un mensaje en verde solo a él.Comandos con argumentos
Los comandos suelen necesitar parámetros, por ejemplo
/tp 100 200 50 o /dar arma1 munición. MTA pasa esos argumentos como parámetros adicionales a la función:addCommandHandler("tp", function(player, commandName, x, y, z)if not x or not y or not z thenoutputChatBox("Uso correcto: /tp [x] [y] [z]", player, 255, 0, 0)returnendsetElementPosition(player, tonumber(x), tonumber(y), tonumber(z))end)
Los argumentos siempre llegan como texto (
string), por eso es importante convertirlos con tonumber() antes de usarlos como coordenadas.Restringir comandos a administradores
No todos los comandos deberían estar disponibles para cualquier jugador. Antes de ejecutar la acción, se valida el permiso del jugador usando el sistema de ACL (ver nuestro artículo de ACL y permisos):
addCommandHandler("banear", function(player, commandName, targetName, ...)if not hasObjectPermissionTo(player, "function.kickPlayer", false) thenoutputChatBox("No tienes permiso para usar este comando.", player, 255, 0, 0)returnend-- lógica de baneo aquíend)
hasObjectPermissionTo consulta directamente el acl.xml, así que el control de quién puede banear no depende de una lista hardcodeada en el script, sino de los permisos reales configurados en el servidor.Buenas prácticas al diseñar comandos
- Valida siempre los argumentos antes de usarlos; un comando que falla silenciosamente o rompe el script por un argumento faltante es una mala experiencia para el jugador y un riesgo de estabilidad para el servidor.
- Responde siempre algo al jugador, incluso si el comando falla ("uso incorrecto", "no tienes permiso", etc.). Un comando que no responde nada genera confusión.
- No dupliques nombres de comando entre distintos recursos activos: si dos recursos registran el mismo comando, solo uno terminará ejecutándose y puede ser difícil de depurar.
- Sepára la lógica de negocio de la validación, sobre todo en comandos administrativos, para que sea fácil de mantener a medida que el gamemode crece.
Aporte por:
Nicolas ECM
