ES/Resources: Difference between revisions
(MUCHOS errores corregidos.) |
(corregidas algunas incongruencias) |
||
| Line 1: | Line 1: | ||
Los recursos son una parte clave de | Los recursos son una parte clave de MTA. Un recurso es básicamente una carpeta o archivo zip que contiene una colección de archivos - incluyendo archivos de script, además de un archivo ''meta'' que describe cómo el recurso debe ser cargado. Un recurso puede ser en parte equivalente a un programa que se ejecuta en un sistema operativo - que puede ser iniciado y detenido, y múltiples recursos se pueden ejecutar al mismo tiempo. Es necesario recordar, sin embargo, que a diferencia de los programas en un sistema operativo, no hay multitarea entre los recursos.'' | ||
== Terminología == | == Terminología == | ||
*''Resource'' - Un archivo zip o carpeta que contiene un archivo meta.xml y una serie de elementos de recursos. Estos se colocan en la carpeta "%Archivos de Programa%/%MTA San Andreas%/server/mods/ deathmatch/resources/''. | *'''Resource''' - Un archivo zip o carpeta que contiene un archivo meta.xml y una serie de elementos de recursos. Estos se colocan en la carpeta "%Archivos de Programa%/%MTA San Andreas%/server/mods/ deathmatch/resources/''. | ||
*''Archivo'' - Un archivo contenido dentro de un recurso,esto puede ser un mapa, musica, imágenes, etc | *'''Archivo''' - Un archivo contenido dentro de un recurso,esto puede ser un mapa, musica, imágenes, etc | ||
== El Archivo Meta == | == El Archivo Meta == | ||
| Line 40: | Line 40: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
Mientras que un mapa CTF puede tener un meta.xml parecido a esto: | |||
<syntaxhighlight lang="xml"> | <syntaxhighlight lang="xml"> | ||
<meta> | <meta> | ||
| Line 51: | Line 51: | ||
Los atributos Script/type, Config/type y File/type especifican si el script/recurso se debe enviar a los clientes o no, este valor por defecto es "server". | |||
Las etiquetas incluyen especificaciones como recursos que se deben iniciar antes de un | Las etiquetas incluyen especificaciones como recursos que se deben iniciar antes de un recurso se ha iniciado. | ||
Por ejemplo, si su | Por ejemplo, si su recurso tiene dependencia a otro, puede incluirlo en meta.xml para que el recurso, al que el suyo depende, se inicie primero. | ||
Cada recurso tiene su propia máquina virtual (VM). | Cada recurso tiene su propia máquina virtual (VM). Esta contiene todos los scripts en el recurso. Esto significa que las variables no se comparten con otros recursos. La mejor manera de comunicarte con otros recursos es mediante las etiquetas de ''exportación'' y exportar una función. Esto permitira que otros recursos puedan activar esa funcion con el comando de scripting [[call]] | ||
Los scripts se envían a los clientes para que se inicien tan pronto como hayan sido descargados. | Los scripts se envían a los clientes para que se inicien tan pronto como hayan sido descargados. | ||
Los scripts son capaces | Los scripts son capaces que se pueden leer y escribir en su propia carpeta de recursos con funciones tales como [[xmlCreateFile]] y [[fileCreate]]. También pueden leer y escribir dentro de otros recursos, pero debe tener permisos de [[Access_Control_List | ACL]]. | ||
Cada recurso sólo puede ser cargado una vez, | Cada recurso sólo puede ser cargado una vez, el servidor se asegura de esto. Si un recurso se incluye más de una vez, la misma instancia será utilizada por cada recurso que incluya. | ||
== Archivos almacenados == | == Archivos almacenados == | ||
Los archivos ''Resources'' pueden ser almacenados en un .zip o un directorio. Se | Los archivos ''Resources'' pueden ser almacenados en un .zip o un directorio. Se encuentran en: | ||
server/mods/deathmatch/resources/ (Si tienes el server instalado con el cliente) | server/mods/deathmatch/resources/ (Si tienes el server instalado con el cliente) | ||
| Line 75: | Line 75: | ||
mods/deathmatch/resources/ (para server dedicados) | mods/deathmatch/resources/ (para server dedicados) | ||
Cada recurso puede tener un archivo zip, un directorio o ambos. En el caso de | Cada recurso puede tener un archivo zip, un directorio o ambos. En el caso de que ambos existan, el directorio tiene preferencia sobre el archivo zip, así, los archivos pueden ser puestos en directorios para pasar por encima de los archivos dentro del archivo zip. Esto permite que los directorios sean usados para pruebas y desarrollo de mapas/scripts y los archivos zip sean usados por los usuarios dinales | ||
==Otras cosas a notar== | ==Otras cosas a notar== | ||
*Los nombres de los resources no pueden contener puntos. | *Los nombres de los resources no pueden contener puntos. | ||
*Si el recurso | *Si el recurso guarda algún archivo, los nombres de archivo utilizados no deben aparecer en el archivo meta.xml | ||
*Los archivos mostrados en meta.xml sólo deberían ser leídos por tus scripts. No los modifiques con [[xmlSaveFile]], [[FileSave]] etc. | *Los archivos mostrados en los meta.xml sólo deberían ser leídos por tus scripts. No los modifiques con [[xmlSaveFile]], [[FileSave]] etc. | ||
*Cuando hagas la versión ZIP de tu resource, no incluyas archivos de guardado. Si tu resource los usa, que los cree cuando sea necesario. | *Cuando hagas la versión ZIP de tu resource, no incluyas archivos de guardado. Si tu resource los usa, que los cree cuando sea necesario. | ||
*Y cuando hagas la versión ZIP, sólo incluye a los archivos que se muestren en meta.xml. No incluyas "archivos de ejemplo", o cosas malas | *Y cuando hagas la versión ZIP, sólo incluye a los archivos que se muestren en meta.xml. No incluyas "archivos de ejemplo", o podrían pasar cosas malas... | ||
*Y evita usar espacios o caracteres raros en los nombres de tus resources. | *Y evita usar espacios o caracteres raros en los nombres de tus resources. | ||
==Script | ==Functiones de Script== | ||
Actualmente, los resources pueden ser manipulados por medio de scripts. | Actualmente, los resources pueden ser manipulados por medio de scripts. Más abajo se muestran las funciones correspondientes: | ||
{{Resource functions}} | {{Resource functions}} | ||
| Line 99: | Line 99: | ||
== Traductores: == | == Traductores: == | ||
*Kzman, corregidas algunas incongruencias | |||
*Corregido por The Kid | *Corregido por The Kid | ||
*F4ST3R | *F4ST3R | ||
Revision as of 19:36, 5 March 2011
Los recursos son una parte clave de MTA. Un recurso es básicamente una carpeta o archivo zip que contiene una colección de archivos - incluyendo archivos de script, además de un archivo meta que describe cómo el recurso debe ser cargado. Un recurso puede ser en parte equivalente a un programa que se ejecuta en un sistema operativo - que puede ser iniciado y detenido, y múltiples recursos se pueden ejecutar al mismo tiempo. Es necesario recordar, sin embargo, que a diferencia de los programas en un sistema operativo, no hay multitarea entre los recursos.
Terminología
- Resource - Un archivo zip o carpeta que contiene un archivo meta.xml y una serie de elementos de recursos. Estos se colocan en la carpeta "%Archivos de Programa%/%MTA San Andreas%/server/mods/ deathmatch/resources/.
- Archivo - Un archivo contenido dentro de un recurso,esto puede ser un mapa, musica, imágenes, etc
El Archivo Meta
El archivo de Meta es el núcleo de cada recurso. En él se describe exactamente los archivos que el recurso debe utilizar y cómo. El siguiente es un ejemplo que cubre todas las opciones que hay, los archivos de metadatos puede tener tantas o tan pocas de estas etiquetas como tú quieras:
<meta>
<info author="eAi" description="Ejemplo basico de Script" version="4"/>
<include resource="radarblips"/>
<include resource="markermanagement" />
<script src="ctf.lua" />
<script src="flag.lua" />
<script src="ctf_client.lua" type="client" />
<file src="model.dff" />
<file src="quitbutton.png" />
<file src="killed.png" />
<html src="test.htm" default="true"/>
<html src="logo.png" raw="true" />
<export function="multiply" http="true" />
<export function="getPlayerList" />
<export function="getElementOwner" type="client"/>
<config src="vehicle-list.xml" type="client" />
<config src="markerconfig.xml" type="server" />
<map src="somestuff.map" dimension="99" />
</meta>
Mientras que un mapa CTF puede tener un meta.xml parecido a esto:
<meta>
<include resource="ctf" />
<map src="myuberl33tctfmap.map" />
<info author="Tom" instructions="this is uber l33t !!!!!1111111" type="map" />
</meta>
Los atributos Script/type, Config/type y File/type especifican si el script/recurso se debe enviar a los clientes o no, este valor por defecto es "server".
Las etiquetas incluyen especificaciones como recursos que se deben iniciar antes de un recurso se ha iniciado. Por ejemplo, si su recurso tiene dependencia a otro, puede incluirlo en meta.xml para que el recurso, al que el suyo depende, se inicie primero.
Cada recurso tiene su propia máquina virtual (VM). Esta contiene todos los scripts en el recurso. Esto significa que las variables no se comparten con otros recursos. La mejor manera de comunicarte con otros recursos es mediante las etiquetas de exportación y exportar una función. Esto permitira que otros recursos puedan activar esa funcion con el comando de scripting call
Los scripts se envían a los clientes para que se inicien tan pronto como hayan sido descargados.
Los scripts son capaces que se pueden leer y escribir en su propia carpeta de recursos con funciones tales como xmlCreateFile y fileCreate. También pueden leer y escribir dentro de otros recursos, pero debe tener permisos de ACL.
Cada recurso sólo puede ser cargado una vez, el servidor se asegura de esto. Si un recurso se incluye más de una vez, la misma instancia será utilizada por cada recurso que incluya.
Archivos almacenados
Los archivos Resources pueden ser almacenados en un .zip o un directorio. Se encuentran en:
server/mods/deathmatch/resources/ (Si tienes el server instalado con el cliente)
o
mods/deathmatch/resources/ (para server dedicados)
Cada recurso puede tener un archivo zip, un directorio o ambos. En el caso de que ambos existan, el directorio tiene preferencia sobre el archivo zip, así, los archivos pueden ser puestos en directorios para pasar por encima de los archivos dentro del archivo zip. Esto permite que los directorios sean usados para pruebas y desarrollo de mapas/scripts y los archivos zip sean usados por los usuarios dinales
Otras cosas a notar
- Los nombres de los resources no pueden contener puntos.
- Si el recurso guarda algún archivo, los nombres de archivo utilizados no deben aparecer en el archivo meta.xml
- Los archivos mostrados en los meta.xml sólo deberían ser leídos por tus scripts. No los modifiques con xmlSaveFile, FileSave etc.
- Cuando hagas la versión ZIP de tu resource, no incluyas archivos de guardado. Si tu resource los usa, que los cree cuando sea necesario.
- Y cuando hagas la versión ZIP, sólo incluye a los archivos que se muestren en meta.xml. No incluyas "archivos de ejemplo", o podrían pasar cosas malas...
- Y evita usar espacios o caracteres raros en los nombres de tus resources.
Functiones de Script
Actualmente, los resources pueden ser manipulados por medio de scripts. Más abajo se muestran las funciones correspondientes:
- abortRemoteRequest
- addResourceConfig
- addResourceMap
- call
- callRemote
- copyResource
- createResource
- deleteResource
- fetchRemote
- getRemoteRequestInfo
- getRemoteRequests
- getResourceACLRequests
- getResourceConfig
- getResourceDynamicElementRoot
- getResourceExportedFunctions
- getResourceFromName
- getResourceInfo
- getResourceLastStartTime
- getResourceLoadFailureReason
- getResourceLoadTime
- getResourceMapRootElement
- getResourceName
- getResourceOrganizationalPath
- getResourceRootElement
- getResources
- getResourceState
- getThisResource
- isResourceArchived
- isResourceProtected
- refreshResources
- removeResourceFile
- renameResource
- restartResource
- setResourceInfo
- startResource
- stopResource
- updateResourceACLRequest
Los siguientes eventos también están ligados a los resources:
Traductores:
- Kzman, corregidas algunas incongruencias
- Corregido por The Kid
- F4ST3R