ES/Introducción a Lua: Difference between revisions

From Multi Theft Auto: Wiki
Jump to navigation Jump to search
No edit summary
 
(13 intermediate revisions by 6 users not shown)
Line 4: Line 4:


'''Lo primero que debes tener en cuenta al iniciarte en la programacion en LUA, es conseguir un editor que funcione para ello. Esto hace mucho más facil tu trabajo, permitiéndote corregir el sintaxis de las matemáticas, por ejemplo. El equipo de MTA recomienda [http://notepad-plus.sourceforge.net/uk/site.htm Notepad++] y [http://luaedit.sourceforge.net/ LuaEdit].'''
'''Lo primero que debes tener en cuenta al iniciarte en la programacion en LUA, es conseguir un editor que funcione para ello. Esto hace mucho más facil tu trabajo, permitiéndote corregir el sintaxis de las matemáticas, por ejemplo. El equipo de MTA recomienda [http://notepad-plus.sourceforge.net/uk/site.htm Notepad++] y [http://luaedit.sourceforge.net/ LuaEdit].'''
'''También en cuanto a Tutoriales, puedes guiarte de estos: [http://forum.mtasa.com/viewtopic.php?f=145&t=70852 Scripteando Cosas Básicas] .'''


==Creando un script funcional==
==Creando un script funcional==
Line 51: Line 53:
outputChatBox("Bienvenido a Mi Servidor", source)
outputChatBox("Bienvenido a Mi Servidor", source)
end
end
addEventHandler("onPlayerJoin", getRootElement(), joinHandler)
addEventHandler("onPlayerJoin", getRootElement(), manejadorDeInicio)
</syntaxhighlight>
</syntaxhighlight>


Line 204: Line 206:
===Resources más complejos===
===Resources más complejos===


(Falta traducir desde aquí)


La seccion previa es de como poner scripts de modo clientside, pero hay cosas mas posibles. Como se menciona al principio de este texto, los resources pueden hacer casi cualquier cosa. Su proposito es definido de porque hacen. Veamos unos resources teoricamente, por ver los archivos que tienen, el''meta.xml'' y que podrian hacer:


The previous section showed briefly how to add clientside scripts to the resource, but there is also much more possible. As mentioned at the very top of this page, resources can be pretty much everything. Their purpose is defined by what they do. Let's have some theoretical resources, by looking at the files it contains, the ''meta.xml'' and what they might do:
====Primer Ejemplo - Un script util====
 
====First example - A utility script====
<syntaxhighlight lang="xml">
<syntaxhighlight lang="xml">
/admin_commands
/admin_commands
Line 218: Line 218:
<syntaxhighlight lang="xml">
<syntaxhighlight lang="xml">
<meta>
<meta>
<info author="Someguy" description="admin commands" />
<info author="AlexD" description="Comandos de Admin" />
<script src="commands.lua" />
<script src="commands.lua" />
<script src="client.lua" type="client" />
<script src="client.lua" type="client" />
Line 224: Line 224:
</syntaxhighlight>
</syntaxhighlight>


* The ''commands.lua'' provides some admin commands, like banning a player, muting or something else that can be used to admin the server
* El ''commands.lua'' tiene comandos de administrador, como banear a un jugador, mutearlo o cualquier cosa que pueda usar un administrador
* The ''client.lua'' provides a GUI to be able to perform the mentioned actions easily
* El ''client.lua'' tiene el GUI para poder ejecutar los comandos sencillamente.


This example might be running all the time (maybe even auto-started when the server starts) as it's useful during the whole gaming experience and also wont interfere with the gameplay, unless an admin decides to take some action of course.


====Second example - A gamemode====
Este ejemplo estaria corriendo todo el tiempo (talvez auto-empezado cuando el servidor empieza) Y es util durante toda la experiencia en el juego y tambien no interfiere con el Juego en general, al menos que un administrador decide de ejecutar algun acto, por supuesto.
 
====Segundo Ejemplo - Un modo de Juego====
<syntaxhighlight lang="xml">
<syntaxhighlight lang="xml">
/counterstrike
/counterstrike
Line 238: Line 239:
<syntaxhighlight lang="xml">
<syntaxhighlight lang="xml">
<meta>
<meta>
<info author="Someguy" description="Counterstrike remake" type="gamemode" />
<info author="AlexD" description="Recreacion de CounterStrike" type="gamemode" />
<script src="counterstrike.lua" />
<script src="counterstrike.lua" />
<script src="buymenu.lua" type="client" />
<script src="buymenu.lua" type="client" />
Line 244: Line 245:
</syntaxhighlight>
</syntaxhighlight>


* The ''counterstrike.lua'' contains similiar to the following features:
* El ''counterstrike.lua'' contiene lo similar a las siguientes caracteristicas:
** Let players choose their team and spawn them
** Dejar que los jugadores elijan su equipo y aparezcan en el
** Provide them with weapons, targets and instructions (maybe read from a Map, see below)
** Darles armas, objectivos e instrucciones (talvez leer de un Mapa, vease mas adelante)
** Define the game's rules, e.g. when does the round end, what happens when a player dies
** Definir las reglas del juego, ejemplo: cuando la partida acabe, que pasa cuando un jugador muere
** .. and maybe some more
** .. y talvez algo mas
* The ''buymenu.lua'' is a clientside script and creates a menu to buy weapons
* El ''buymenu.lua'' es un script Clientside y crea un menu para comprar armas


This example can be called a gamemode, since it not only intereferes with the gameplay, but actually defines the rules of it. The ''type'' attribute indicates that this example works with the [[Map manager]], yet another resource that was written by the QA Team to manage gamemodes and map loading. It is highly recommended that you base your gamemodes on the techniques it provides.
Este ejemplo puede ser llamado modo de juego, porque no solo interviene con el juego en general, pero actualmente define las reglas de el. El atributo ''type'' indica que este ejemplo sirve con el  [[Map manager]], si otro resource que fue escrito por el Equipo QA para gestionar modos de juego y carga de mapas. Es altamente recomendado que tu base tus modos de juego en las tecnicas que proporciona.


This also means that the gamemode probably won't run without a map. Gamemodes should always be as generic as possible. An example for a map is stated in the next example.
Esto tambien significa que el modo de juego no cargara sin el mapa. Los modos de juego tienen que ser tan genericos posibles. Un ejemplo de un mapa  es mostrado en el siguiente ejemplo.


====Third example - A Map====
====Tercer ejemplo - Un mapa====
<syntaxhighlight lang="xml">
<syntaxhighlight lang="xml">
/cs-airport
/cs-airport
Line 270: Line 271:
</syntaxhighlight>
</syntaxhighlight>


* The ''airport.map'' in a XML file that provides information about the map to the gamemode, these may include:
* El ''airport.map'' es un archivo XML que proporciona información sobre el mapa para el modo de juego, estos pueden incluir:
** Where the players should spawn, with what weapons, what teams there are
** Donde deben spawnear los jugadores, con que armas, que equipos hay
** What the targets are
** Cuales son los objetivos
** Weather, World Time, Timelimit
** Clima, tiempo, tiempo limite
** Provide vehicles
** Proporcionar vehículos
* The ''airport.lua'' might contain map-specific features, that may include:
* El ''airport.lua'' puede contener funciones del mapa específicas, que pueden incluir:
** Opening some door/make something explode when something specific happens
** Apertura de alguna puerta / hacer que algo explote cuando suceda algo específico
** Create or move some custom objects, or manipulate objects that are created through the .map file
** Crear o mover algunos objetos personalizados, o manipular los objetos que se crean a través del archivo de mapa.
** .. anything else map-specific you can think of
** .. cualquier cosa mapa-específicas que se pueda imaginar
Como puede ver, el atributo ''type'' cambió a 'map', diciéndole al [[Map manager]]  que este recurso es un mapa, mientras que el atributo ''gamemodes'' indica para que tipos de juego o gamemode este mapa es válido, en este caso el modo de juego en el ejemplo anterior. Lo que puede venir como una sorpresa es que también hay script en el recurso de mapa. Por supuesto, esto no es necesario en un mapa, pero abre un amplio abanico de posibilidades para los creadores de mapas para crear su propio mundo dentro de las reglas del modo de juego que para el que crean.


As you can see, the ''type'' attribute changed to 'map', telling the [[Map manager]] that this resource is a map, while the ''gamemodes'' attribute tells it for which gamemodes this map is valid, in this case the gamemode from the above example.
El archivo ''airport.map'' debe tener un aspecto similar a este:
What may come as a surprise is that there is also a script in the Map resource. Of course this is not necessarily needed in a map, but opens a wide range of possibilities for map makers to create their own world within the rules of the gamemode they create it for.
 
The ''airport.map'' file might look similiar to this:
<syntaxhighlight lang="xml">
<syntaxhighlight lang="xml">
<map mode="deathmatch" version="1.0">
<map mode="deathmatch" version="1.0">
Line 300: Line 299:
</syntaxhighlight>
</syntaxhighlight>


When a gamemode is started with a map, the map resources is automatically started by the mapmanager and the information it contains can be read by the gamemode resource. When the map changes, the current map resource is stopped and the next map resource is started. For a more in-depth explanation and examples of how map resources are utilized in the main script, please visit the [[Writing Gamemodes]] page.
Cuando se inicia un modo de juego con un mapa, los resources del mapa se inicia automáticamente por el mapmanager y la información que contiene puede ser leída por el recursos del modo de juego. Cuando el mapa cambia, el recurso de mapa actual se detiene y se inicia el siguiente recurso de mapa. Para una explicación más detallada y ejemplos de cómo se utilizan los recursos del mapa en el main script, por favor visite la pagina [[Writing Gamemodes]].


===Events===
===Eventos===
Events are the way MTA tells scripts about things that happen. For example when a player dies, the [[onPlayerWasted]] event is triggered. In order to perform any actions when a player dies, you have to prepare yourself similiar to adding a command handler, as shown in [[#Writing_the_script|the first chapter]].
Los eventos son la manera en la cual MTA le informa a los scripts cuando las cosas estan ocurriendo. Por ejemplo cuando un jugador muere, el evento [[onPlayerWasted]] es llamado. De manera de realizar cualquier accion cuando un jugador muere, tienes que prepararlo tu mismo, de manera similar a como cuando añades un command handler en[[#Writing_the_script|el primer capitulo]].


This example will output a message with the name of the player who died:
Este ejemplo mostrara un mensaje con el nombre del jugador que murió.
<syntaxhighlight lang="lua">
<syntaxhighlight lang="lua">
function playerDied(totalAmmo, killer, killerWeapon, bodypart)
function playerDied(totalAmmo, killer, killerWeapon, bodypart)
Line 323: Line 322:


*Benxamix2/The Kid
*Benxamix2/The Kid
[[en:Scripting Introduction]]
[[it:Introduzione allo scripting]]
[[nl:Scripting_introductie]]
[[pt-br:Introdução ao Scripting]]
[[ru:Scripting Introduction]]


*AlexD
[[en:Scripting Introduction]]
[[it:Introduzione allo scripting]]
[[nl:Scripting_introductie]]
[[pt-br:Introdução ao Scripting]]
[[ru:Scripting Introduction]]
[[ru:Scripting Introduction]]
[[it:Introduzione allo scripting]]
 
*Rockero
[[en:Scripting Introduction]]
[[en:Scripting Introduction]]

Latest revision as of 19:45, 7 April 2014

Los llamados "resources" son fundamentales en MTA. Básicamente consisten en una carpeta o archivo ZIP que contiene una colección archivos, además de un archivo meta.xml que define qué archivos pertenecen al resource, algunas configuraciones, y otras cosas. Como los programas en un sistema operativo, los resources pueden ser iniciados, detenidos, y reiniciados, y varios pueden funcionar al mismo tiempo.

Todo lo que es la programación ocurre dentro de los resources. Lo que éste haga define si se trata de un modo de juego, un mapa, un script sencillo, u otra cosa. MTA, por defecto, trae ciertos resources que puedes usar opcionalmente en tus modos de juego.

Lo primero que debes tener en cuenta al iniciarte en la programacion en LUA, es conseguir un editor que funcione para ello. Esto hace mucho más facil tu trabajo, permitiéndote corregir el sintaxis de las matemáticas, por ejemplo. El equipo de MTA recomienda Notepad++ y LuaEdit.

También en cuanto a Tutoriales, puedes guiarte de estos: Scripteando Cosas Básicas .

Creando un script funcional

Primero, aprenderemos a hacer un script que permita al jugador caminar libremente por la ciudad. Esto lo explicaremos paso a paso.

Estructura de un script y ubicación del mismo

Dirijámonos a la carpeta raíz de tu servidor para MTA (por defecto es C:\Archivos de Programa\Multi Theft Auto\server). Después vamos a la siguiente ubicación:

\server\mods\deathmatch\resources\

Verás muchos archivos ZIP. Como mencioné antes, estos ZIP son los resources, que vienen por defecto con MTA. Para crear tu propio resource, añade una carpeta a esta ubicación, y dale un nombre. Recomiendo que, al ser tu primer script, sigas las instrucciones al pie de la letra, y a esta carpeta la llames "myserver".

Ahora, entremos a la ubicación:

\resources\myserver\

Identificando tu resource

Como mencioné antes, todo resource tiene un archivo que define el tipo, los archivos, y las configuraciones del resource, es el meta.xml. Siempre debe estar dentro de cada resource, de otra forma éste no funciona. Así que creemos un archivo de texto, y llamémoslo "meta.xml" (sin las comillas). Luego abrámoslo con el Bloc de Notas, o con Microsoft Wordpad.

Una vez dentro de este archivo, agregaremos el siguiente código:


<meta>
     <info author="TuNombre" type="gamemode" name="Mi Servidor" description="Mi primer servidor de MTA DM" />
     <script src="script.lua" />
</meta>


En la etiqueta <info /> hay un campo "type". Éste indica el tipo de resource, que siendo "gamemode" en este caso, define que es un modo de juego. Nótese que cuando es otro tipo de resource, el valor "type" cambia. Pero eso lo veremos luego. Por ahora, un modo de juego es lo que necesitas para comenzar un servidor.

La etiqueta <script /> indica el script que tendrá nuestro modo de juego. A continuación, cómo crearlo.

Creando un script simple

Nótese que en la etiqueta <script />, el archivo Lua no está en otro directorio, como por ejemplo myserver\script.lua. Esto es porque el archivo LUA del que hablamos será creado en el mismo lugar en el que el archivo meta.xml. Bueno, ahora creamos en "myserver", otro archivo de texto, y lo llamamos "script.lua". Abrámoslo y agreguemos estas líneas:


function manejadorDeInicio()
	local x = 1959.55
	local y = -1714.46
	local z = 10
	spawnPlayer(source, x, y, z)
	fadeCamera(source, true)
	setCameraTarget(source, source)
	outputChatBox("Bienvenido a Mi Servidor", source)
end
addEventHandler("onPlayerJoin", getRootElement(), manejadorDeInicio)


Este script inicia a tu jugador en las coordenadas "x", "y" y "z" (spawnPlayer) cuando entras al servidor. OJO: ¡La función fadeCamera siempre debe ser usada cuando inicias al jugador, de otra forma, la pantalla quedará en negro!. Lo mismo pasa con la función setCameraTarget; si no la usas, el jugador no podrá verse a sí mismo, si no que mirará al cielo infinito.

La variable source indica qué fue lo que ocasionó al evento. Como el evento onPlayerJoin significa alIniciarJugador, lógico que lo que ocasione a este evento sea el jugador. Así, evitaremos iniciar a cualquier jugador.

Ahora, dirigiéndonos a addEventHandler, podrás ver que posee 3 cosas: onPlayerJoin (el nombre del evento), getRootElement() (que indica por qué o quién será iniciado el evento, ya que getRootElement() significa "todo"), y joinHandler, que es el nombre de la función a ejecutar cuando el evento sea activado.

Con esto, deberías poder comenzar a jugar. Pero faltan algunos detalles... ¡Sigamos!

Corriendo el script

Para que tu servidor local sea iniciado, debes ir a la carpeta raíz de tu servidor (recuerda cuando fuimos a los resources, 2 puestos encima). Una vez que lo inicies, aparecerá una consola con una serie de datos; recuerda el número del puerto, porque lo necesitarás para jugar. Cuando aparezca un mensaje que diga "Server started and is ready to accept connections!", sabrás que ya está listo.

Pero antes de jugar, debes iniciar el modo de juego. Escribe "gamemode myserver" en la consola del servidor, y presiona Enter. El servidor emitirá algunos mensajes, e iniciará tu modo de juego, y si algún error surge, nos lo dirá. Bueno, ahora es tiempo de probar el modo de juego. Inicia MTA, y en el menú principal escoge "Quick Connect". Apareceren 3 campos. En el primero, escribe "localhost", en el segundo, el número del puerto de tu servidor, y en el tercero, nada, después de todo es la contraseña,y tú no pusiste ninguna. Si todo funciona bien, deberías poder comenzar a jugar en Los Santos.

A continuación, te enseñaremos a crear un comando que permita crear un vehículo a tu lado. Si quieres, puedes saltarte este paso y seguir la programación avanzada con Map Manager, que continúa este tutorial. También puedes revisar Introducción a la Programación del GUI, en el que te enseñaremos a diseñar la Interfaz Gráfica de Usuario (GUI en inglés, por Graphical User Interface).

Creando un Comando

Volvamos a script.lua. Como dije hace un momento, crearemos un comando que permita crear un vehículo a tu lado. Primero, necesitaremos crear una función a la que llamar, y un manejador de comandos que cree el comando buscado.


-- Aquí creamos la función que llama el manejador, con los argumentos "elJugador", "nombreDelComando", "modeloDeVehiculo":
function crearVehículoParaJugador(elJugador, nombreDelComando, modeloDeVehículo)
   -- Crear el vehículo y otros.
end

-- Aquí creamos el manejador de comandos:
addCommandHandler("crearvehiculo", crearVehículoParaJugador)


Nota: Los nombres de las funciones tienen enlaces que te llevan a la documentación de ellas.

Acerca de los manejadores de comandos

El primer argumento de addCommandHandler es el nombre del comando que el jugador podrá ingresar, y el segundo es la función que ejecutará en el momento de ingreso del comando (en este caso crearVehiculoParaJugador).

Si tienes alguna experiencia con la programación en C o algún lenguaje parecido, sabrás que las funciones se ejecutan de la forma:


nombreDeFunción(argumento1, argumento2, argumento3, ..)
nombreDeFunción(elJugador, nombreDelComando, argumento3, ..)


Fijémonos bien en esto. Vemos que argumento1 es elJugador y argumento2 es nombreDelComando. elJugador representa al jugador que haya ingresado el comando, por lo que de la forma que lo llames, esta variable será el jugador. nombreDelComando es simplemente el nombre del comando (sin la barra "/"), no hay ningún misterio en ello, por lo que si el jugador escribió "/crearvehiculo" entonces esta variable sería "crearvehiculo". Por último, argumento3 representa una variable más, que estudiaremos más adelante. Nunca olvides que los 2 primeros argumentos son obligatorios y están predefinidos (y debes tenerlos en el orden que se indican), pero puedes llamarlos como sea.

addCommandHandler permite llamar fácilmente a funciones como crearVehículoParaJugador, de forma interna.

Por ejemplo: Alguien entra el comando "/crearvehiculo 468". El servidor creará el vehículo 468, es decir, la moto Sánchez. Dentro del código, addCommandHandler llama a la función crearVehículoParaJugador como si hubiera sido escrito así:


crearVehículoParaJugador(elJugador,"crearvehiculo","468") -- Recuerda que "elJugador" es el elemento jugador que entró el comando.


Como podemos ver, esto prevée ciertos argumentos que ya hemos mencionado. Pero el más importante es "468", que es el "argumento3" del que hablábamos más arriba. Éste se refiere al modelo del vehículo. Recuerda que siempre debes definir los primeros 2 parámetros ("elJugador" y "nombreDelComando"), porque de otra forma el comando no funcionará.

Nota: Tienes que poner el manejador de comandos DEBAJO de la función a llamar por el comando. ¡El orden de las ejecuciones es fundamental!

Escribiendo la función

Para llenar la función que hemos creado, primero hay que plantearse qué se debe hacer:

  • Conseguir la posición del jugador, así sabremos dónde crear el vehículo (queremos que aparezca al lado del jugador).
  • Calcular la posición donde crearemos el vehículo (no queremos que aparezca en el jugador).
  • Crear el vehículo.
  • Revisar si fue creado. Si no, mostrar alguna advertencia o algún mensaje de error.

Para conseguir estos objetivos, debemos usar ciertas funciones, las cuales se pueden ver visitando la Lista de Funciones de Servidor. Primero, una función para conseguir la posición del jugador. Si visitaste la Lista de Clases de MTA, sabrás que un jugador es un elemento, lo que nos lleva a buscar una Función de Elemento, la cual es getElementPosition. Haciendo click en ella, visitarás la documentación de ella, que contiene una descripción, el sintaxis (los argumentos necesarios en la función), y, generalmente, un ejemplo de cómo usarla.

Para la función getElementPosition, el sintaxis sería:


float, float, float getElementPosition ( elemento elElemento )


Los 3 float que aparecen, son los valores que regresa la función. Estos valores, en español, se llaman Número de punto flotante, y son números que pueden o no, poseer decimales (véase la Lista de tipos de valores). Como "x", "y" y "z" son coordenadas, por defecto siempre serán números de punto flotante. Ahora, fijándonos en los paréntesis, notaremos que sólo aparece "elElemento" como argumento de la función. Pues, aplicando la función a un jugador, tendríamos algo como esto:


function crearVehículoParaJugador(elJugador, nombreDelComando, modeloDeVehículo)
	--[[Aquí conseguiremos la posición del jugador, y la almacenaremos en 3 valores: "x", "y" y "z". Nota: "local" significa que las variables indicadas sólo pueden ser usadas en la función actual.]]--
	local x,y,z = getElementPosition(elJugador)
end


Ahora, para crear el vehículo al lado del jugador, debemos modificar alguna coordenada, en este caso, "x".


function crearVehículoParaJugador(elJugador, nombreDelComando, modeloDeVehículo)
	local x,y,z = getElementPosition(elJugador)
	x = x + 5 --Agregamos 5 a la posición "X" (¡esto no altera la posición del jugador!)
end


Nuevamente, necesitamos otra función para crear el vehículo. Buscándola en la Lista de Funciones de Servidor, la encontraremos. Ya que hablamos de vehículo, vamos a la subcategoría tal, en la que encontramos createVehicle. En esta función, el valor que regresa la función consta de 1 solo argumento (esto es lo más común en las funciones), y es el vehículo creado, o un valor "boolean" ("lógico" en inglés) de tipo "false", si el vehículo no fue creado.


function crearVehículoParaJugador(elJugador, nombreDelComando, modeloDeVehículo)
	local x,y,z = getElementPosition(elJugador)
	x = x + 5
	local vehículoCreado = createVehicle(tonumber(modeloDeVehículo),x,y,z)
end

Nótese que usamos "tonumber(modeloDeVehículo)" en vez de usar directamente "modeloDeVehículo". Esto es porque cuando entramos un comando, todos los argumentos salen en forma de "string" ("arreglo" en inglés), que es un tipo de valor textual. Por ello, no puede ser usado como número, y la función "tonumber()" nos permite dejarlo como un número.

Bueno, tenemos todo lo necesario para que nuestro script funcione, pero eso no indica que esté listo. Ya tenemos la función para conseguir la posición del jugador, modificarla, y crear el vehículo. Pero nos falta el mensaje. La función para esto se llama outputChatBox. Como dije antes, si el vehículo no fue creado, entonces regresa un valor "false". Así que creamos nuestra primera condición, en la que si el valor regresado es falso, entonces aparece un mensaje.

Veamos cómo luce el script final:


function crearVehículoParaJugador(elJugador, nombreDelComando, modeloDeVehículo)
	local x,y,z = getElementPosition(elJugador)
	x = x + 5
	local vehículoCreado = createVehicle(tonumber(modeloDeVehículo),x,y,z)
	if (vehículoCreado == false) then --"if" es la condición, siempre debe ir acompañado de la condición y un "then".
		outputChatBox("Error al crear vehículo.",elJugador) --Crea un mensaje de error simple en el chat.
	end
end
addCommandHandler("crearvehiculo", crearVehículoParaJugador) --Y aquí creamos el manejador de comandos.


Nada mal, ¿no? Ya te hemos introducido en la creación de 2 scripts sencillos. Si quieres más programación avanzada, entonces visita el Mánager de Mapas.


Lo que necesitas saber

Ya has leído un poco sobre resources, manejadores de comandos y funciones de búsqueda en la documentación (en el primer párrafo), pero aún queda mucho por aprender. En esta sección te daremos una vista rápida sobre esto, y si se puede, enlazar a otras páginas útiles.

Scripts de cliente y servidor

Quizás ya has notado los términos Server (o Servidor) y Client (o Cliente) en algún lado, mayormente en conjunción con las funciones. MTA no sólo soporta scripts que funcionan en el servidor y prevén comandos (como el que escribimos arriba) u otras características; también scripts que corren en el cliente (MTA en sí, el software que usas para conectarte a los servidores). Esto se debe a que algunas funciones tienen que estar del lado cliente (como el GUI; Graphical User Interface, Interfaz de Usuario Gráfica), si bien funcionan mejor o porque no se pueden hacer en el servidor.

La mayoría de los scripts que harás (modos de juego y/o mapas) probablemente serán de tipo servidor, como el que escribimos en la primera sección. Si tratas de hacer funcionar algo que no se puede hacer en el servidor, probablemente tendrá que ser de cliente. para un script de cliente, por ejemplo, podrías crear un archivo de Lua ordinario (como client.lua) y especificarlo en el archivo meta.xml, así:

<script src="client.lua" type="client" />

El atributo type por defecto es 'server' (servidor), por lo que no es necesario escribirlo cuando se trata de scripts de servidor. Si quieres, puedes leer más sobre scripts de cliente.

Resources más complejos

La seccion previa es de como poner scripts de modo clientside, pero hay cosas mas posibles. Como se menciona al principio de este texto, los resources pueden hacer casi cualquier cosa. Su proposito es definido de porque hacen. Veamos unos resources teoricamente, por ver los archivos que tienen, elmeta.xml y que podrian hacer:

Primer Ejemplo - Un script util

/admin_commands
	/meta.xml
	/commands.lua
	/client.lua
<meta>
	<info author="AlexD" description="Comandos de Admin" />
	<script src="commands.lua" />
	<script src="client.lua" type="client" />
</meta>
  • El commands.lua tiene comandos de administrador, como banear a un jugador, mutearlo o cualquier cosa que pueda usar un administrador
  • El client.lua tiene el GUI para poder ejecutar los comandos sencillamente.


Este ejemplo estaria corriendo todo el tiempo (talvez auto-empezado cuando el servidor empieza) Y es util durante toda la experiencia en el juego y tambien no interfiere con el Juego en general, al menos que un administrador decide de ejecutar algun acto, por supuesto.

Segundo Ejemplo - Un modo de Juego

/counterstrike
	/meta.xml
	/counterstrike.lua
	/buymenu.lua
<meta>
	<info author="AlexD" description="Recreacion de CounterStrike" type="gamemode" />
	<script src="counterstrike.lua" />
	<script src="buymenu.lua" type="client" />
</meta>
  • El counterstrike.lua contiene lo similar a las siguientes caracteristicas:
    • Dejar que los jugadores elijan su equipo y aparezcan en el
    • Darles armas, objectivos e instrucciones (talvez leer de un Mapa, vease mas adelante)
    • Definir las reglas del juego, ejemplo: cuando la partida acabe, que pasa cuando un jugador muere
    • .. y talvez algo mas
  • El buymenu.lua es un script Clientside y crea un menu para comprar armas

Este ejemplo puede ser llamado modo de juego, porque no solo interviene con el juego en general, pero actualmente define las reglas de el. El atributo type indica que este ejemplo sirve con el Map manager, si otro resource que fue escrito por el Equipo QA para gestionar modos de juego y carga de mapas. Es altamente recomendado que tu base tus modos de juego en las tecnicas que proporciona.

Esto tambien significa que el modo de juego no cargara sin el mapa. Los modos de juego tienen que ser tan genericos posibles. Un ejemplo de un mapa es mostrado en el siguiente ejemplo.

Tercer ejemplo - Un mapa

/cs-airport
	/meta.xml
	/airport.map
	/airport.lua
<meta>
	<info author="Someguy" description="Counterstrike airport map" type="map" gamemodes="counterstrike" />
	<map src="airport.map" />
	<script src="airport.lua" />
</meta>
  • El airport.map es un archivo XML que proporciona información sobre el mapa para el modo de juego, estos pueden incluir:
    • Donde deben spawnear los jugadores, con que armas, que equipos hay
    • Cuales son los objetivos
    • Clima, tiempo, tiempo limite
    • Proporcionar vehículos
  • El airport.lua puede contener funciones del mapa específicas, que pueden incluir:
    • Apertura de alguna puerta / hacer que algo explote cuando suceda algo específico
    • Crear o mover algunos objetos personalizados, o manipular los objetos que se crean a través del archivo de mapa.
    • .. cualquier cosa mapa-específicas que se pueda imaginar

Como puede ver, el atributo type cambió a 'map', diciéndole al Map manager que este recurso es un mapa, mientras que el atributo gamemodes indica para que tipos de juego o gamemode este mapa es válido, en este caso el modo de juego en el ejemplo anterior. Lo que puede venir como una sorpresa es que también hay script en el recurso de mapa. Por supuesto, esto no es necesario en un mapa, pero abre un amplio abanico de posibilidades para los creadores de mapas para crear su propio mundo dentro de las reglas del modo de juego que para el que crean.

El archivo airport.map debe tener un aspecto similar a este:

<map mode="deathmatch" version="1.0">
	<terrorists>
		<spawnpoint posX="2332.23" posY="-12232.33" posZ="4.42223" skins="23-40" />
	</terrorists>
	<counterterrorists>
		<spawnpoint posX="2334.23443" posY="-12300.233" posZ="10.2344" skins="40-50" />
	</counterterrorists>

	<bomb posX="23342.23" posY="" posZ="" />
	
	<vehicle posX="" posY="" posZ="" model="602" />	
	<vehicle posX="" posY="" posZ="" model="603" />	
</map>

Cuando se inicia un modo de juego con un mapa, los resources del mapa se inicia automáticamente por el mapmanager y la información que contiene puede ser leída por el recursos del modo de juego. Cuando el mapa cambia, el recurso de mapa actual se detiene y se inicia el siguiente recurso de mapa. Para una explicación más detallada y ejemplos de cómo se utilizan los recursos del mapa en el main script, por favor visite la pagina Writing Gamemodes.

Eventos

Los eventos son la manera en la cual MTA le informa a los scripts cuando las cosas estan ocurriendo. Por ejemplo cuando un jugador muere, el evento onPlayerWasted es llamado. De manera de realizar cualquier accion cuando un jugador muere, tienes que prepararlo tu mismo, de manera similar a como cuando añades un command handler enel primer capitulo.

Este ejemplo mostrara un mensaje con el nombre del jugador que murió.

function playerDied(totalAmmo, killer, killerWeapon, bodypart)
	outputChatBox(getPlayerName(source).." died!")
end
addEventHandler("onPlayerWasted",getRootElement(),playerDied)

Instead of showing what arguments are needed, the documentation page for Events shows what parameters are passed to the handler function, similiar to the way a command handler does, just that it is different from event to event. Another important point is the source variable, that exists in handler functions. It doesn't have to be added to the parameter list of the function, but it still exists. It has a different value from event to event, for player events (as in the example above) it is the player element. As another example, you can take a look at the basic spawning player script in the first section to get an idea how source is used.

¿Y ahora qué?

Deberías ya estar familiarizado con los aspectos básicos de los scripts de MTA, así como con la documentación. La Página Principal te provee de enlaces con mayor información, así como tutoriales y Referencias que permiten una vista más profunda a los temas que te interesan.

Recomendamos que leas el tutorial de debug (encuentro de errores). Es necesaria una buena habilidad con el "debug" cuando haces scripts. ¡Suerte en MTA!

Traductores

  • Benxamix2/The Kid
  • AlexD
  • Rockero