[Artículo]El Proceso de Compilación (ZHLT)

[S34Qu4K3]

El Proceso de Compilación (ZHLT)

 

Bueno, este es el articulo que busqué yo hace bastante tiempo, no lo había en ningun sitio asi que tube que hacerlo yo mismo y hubiera dado lo que sea en su momento por tenerlo .

Todo buen mapper ha de saber que ocurre cuando su .rmf, exportado ya a .map, es compilado; que hace que de tener un .map, todo lleno de coordenadas de los solido, entidades y demas pase a ser un un archivo llamado Binary Space Partition (Espacio de Particion Binario) o comunmente llamado .bsp.

Espero que este articulo, satisfaga las ansias que yo tube en su momento por saber que ocurria exactamente cuando ordenaba al ZHLT la compilacion de mi .map.

 

El tema va a estar dividido en 5 partes en las que se tratarán las 5 principales aplicaciones del la suite de compilación para el Half-Life, Zoner´s Half-Life Tools; que es constituido por:

 

-HLCSG.EXE

-HLBSP.EXE

-HLVIS.EXE

-HLRAD:EXE

-RIPENT.EXE

 

Quizas mucha gente no haya oido hablar del ultimo o solo lo haya visto en su carpeta del ZHLT pero no haya hecho nada mas, pero les aseguro que es una herramienta bastante útil.

 

Sin mas preámbulos comienza este humilde articulo para los que gozen de las cosas mas "extrañas", por decirlo asi, de este gran mundo que es el Mapping.

 

HLCSG

 

hlcsg.exe; la primera de las herramientas del ZHLT que usamos para compilar nuestro .map.

¿Qué significa HLCSG? Pues significa Half-Life Constructive Solid Geometry ( Construcción de la Geometría Solida)

Que es un .map? LA gente curiosa ya habrá descubierto que son un "simple" archivo de texto; por qué digo simple? Esto es un cubo en un .map

 

{
"classname" "worldspawn"
"MaxRange" "4096"
"mapversion" "220"
"wad" "\archivos de programa\valve\valve\halflife.wad"
{
( -64 -128 -64 ) ( -64 0 -64 ) ( 64 0 -64 ) AAATRIGGER [ 1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1 
( -64 0 -192 ) ( -64 -128 -192 ) ( 64 -128 -192 ) AAATRIGGER [ 1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1 
( -64 -128 -192 ) ( -64 0 -192 ) ( -64 0 -64 ) AAATRIGGER [ 0 1 0 0 ] [ 0 0 -1 0 ] 0 1 1 
( 64 0 -192 ) ( 64 -128 -192 ) ( 64 -128 -64 ) AAATRIGGER [ 0 1 0 0 ] [ 0 0 -1 0 ] 0 1 1 
( -64 0 -192 ) ( 64 0 -192 ) ( 64 0 -64 ) AAATRIGGER [ 1 0 0 0 ] [ 0 0 -1 0 ] 0 1 1 
( 64 -128 -192 ) ( -64 -128 -192 ) ( -64 -128 -64 ) AAATRIGGER [ 1 0 0 0 ] [ 0 0 -1 0 ] 0 1 1 
}
}
{
"classname" "info_player_start"
"angles" "0 0 0"
"origin" "0 -256 -128"
}
{
"classname" "info_target"
"targetname" "soy_un_info_target"
"origin" "-256 -256 -128"
}
{
"classname" "trigger_push"
"angles" "0 0 0"
"speed" "100"
{
( -320 -128 -64 ) ( -320 0 -64 ) ( -192 0 -64 ) AAATRIGGER [ 1 0 0 16 ] [ 0 -1 0 16 ] 0 1 1 
( -320 0 -192 ) ( -320 -128 -192 ) ( -192 -128 -192 ) AAATRIGGER [ 1 0 0 16 ] [ 0 -1 0 16 ] 0 1 1 
( -320 -128 -192 ) ( -320 0 -192 ) ( -320 0 -64 ) AAATRIGGER [ 0 1 0 -16 ] [ 0 0 -1 -16 ] 0 1 1 
( -192 0 -192 ) ( -192 -128 -192 ) ( -192 -128 -64 ) AAATRIGGER [ 0 1 0 -16 ] [ 0 0 -1 -16 ] 0 1 1 
( -320 0 -192 ) ( -192 0 -192 ) ( -192 0 -64 ) AAATRIGGER [ 1 0 0 16 ] [ 0 0 -1 -16 ] 0 1 1 
( -192 -128 -192 ) ( -320 -128 -192 ) ( -320 -128 -64 ) AAATRIGGER [ 1 0 0 16 ] [ 0 0 -1 -16 ] 0 1 1 
}
}

Analicemos esto, cada solido o entidad va entre { }, al principio de cada map simpre estará la entidad worldspawn, la entidad primaria sobre la que se basa el map y que le da parametros como el MaxRange, version del map, texturas que utiliza,etc.

Aunque el mapa esté vacio, siempre habra una entidad worldspawn, que como se deduce por su nombre es la que "spawnea" el map, es decir, lo crea, y a partir de esta entidad se colocan todos los solidos y entidades.

 

 

A continuación se crean los solidos, siguiendo este patron

{
( -64 0 -64 ) ( 64 0 -64 ) ( 64 -128 -64 ) AAATRIGGER [ 1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1 
( -64 -128 -192 ) ( 64 -128 -192 ) ( 64 0 -192 ) AAATRIGGER [ 1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1 
( -64 0 -64 ) ( -64 -128 -64 ) ( -64 -128 -192 ) AAATRIGGER [ 0 1 0 0 ] [ 0 0 -1 0 ] 0 1 1 
( 64 0 -192 ) ( 64 -128 -192 ) ( 64 -128 -64 ) AAATRIGGER [ 0 1 0 0 ] [ 0 0 -1 0 ] 0 1 1 
( 64 0 -64 ) ( -64 0 -64 ) ( -64 0 -192 ) AAATRIGGER [ 1 0 0 0 ] [ 0 0 -1 0 ] 0 1 1 
( 64 -128 -192 ) ( -64 -128 -192 ) ( -64 -128 -64 ) AAATRIGGER [ 1 0 0 0 ] [ 0 0 -1 0 ] 0 1 1 
}

 

Como podemos deducir, es un cubo, cada linea corresponde a una cara del solido, por lo tanto al tener 6 lineas es un cubo

Al comienzo de cada linea estan colocadas las coordenadas del solido, seguidamente la textura usada (aaatrigger en mi caso)

Todos los numeros que siguen son las propiedades de la textura, posicion, tamaño, etc, pueden en el VHE seleccionar un sólido, darle a Shift + A y ven arriba las inbox donde meter los parametros que corresponden a los numeros anteriormente mencionados

 

 

Seguidamente las entidades creadas con el Enitity Tool

{
"classname" "info_player_start"
"angles" "0 0 0"
"origin" "0 -256 -128"
}
{
"classname" "info_target"
"targetname" "soy_un_info_target"
"origin" "-256 -256 -128"
}

 

Primero el nombre de la entidad, info_player_start y mas abajo un info_target, seguidamente sus propiedades, el PITCH YAW ROLL del info_player_start y el name del info_target; como ultimo el origin de la entidad, que viene siendo las coordenadas donde están ubicadas las entidades.

 

Y por ultimo los solidos con una entidad

{
"classname" "trigger_push"
"angles" "0 0 0"
"speed" "100"
{
( -320 -128 -64 ) ( -320 0 -64 ) ( -192 0 -64 ) AAATRIGGER [ 1 0 0 16 ] [ 0 -1 0 16 ] 0 1 1 
( -320 0 -192 ) ( -320 -128 -192 ) ( -192 -128 -192 ) AAATRIGGER [ 1 0 0 16 ] [ 0 -1 0 16 ] 0 1 1 
( -320 -128 -192 ) ( -320 0 -192 ) ( -320 0 -64 ) AAATRIGGER [ 0 1 0 -16 ] [ 0 0 -1 -16 ] 0 1 1 
( -192 0 -192 ) ( -192 -128 -192 ) ( -192 -128 -64 ) AAATRIGGER [ 0 1 0 -16 ] [ 0 0 -1 -16 ] 0 1 1 
( -320 0 -192 ) ( -192 0 -192 ) ( -192 0 -64 ) AAATRIGGER [ 1 0 0 16 ] [ 0 0 -1 -16 ] 0 1 1 
( -192 -128 -192 ) ( -320 -128 -192 ) ( -320 -128 -64 ) AAATRIGGER [ 1 0 0 16 ] [ 0 0 -1 -16 ] 0 1 1 
}
}

 

Se agregan al final del .map, colocando primero la entidad, trigger_push en mi caso, y sus parametros y a continuación el solido y sus propiedades.

 

Qué es lo que hace entonces el HLCSG.EXE? El HLCSG.EXEhace los cálculos de geometría del espacio constructivos al mapa, "rompe" los solidos complejos en otros mas simples y crea 5 archivos para el posterior uso del HLBSP.EXE

 

Nota: Esto no pretende ser un articulo para explicar que ocurre cuando hay un error en el map, para ello habra otro artículo

 

Lo primero que hace el HLCSG es cargar su configuración (comandos, log ativo, developer, etc)

Seguidamente chequea el si se ha añadido alguna wad con el -wadinclude, lo que se dice "añadir la textura al mapa".

Un ejemplo:

Using mapfile wad configuration
Wadinclude list :
[zhlt.wad]

Como se puede ver, el HLCSG incluye automaticamente la .wad zhlt.wad que contiene las texturas:

-HINT

-SKIP

-NULL

-BEVEL

-CLIP

-AAATRIGGER

-SKY

-ORIGIN

Las llamadas "texturas especiales" por sus funciones "especiales" que sirven desde para crear un cielo hasta setear el eje de rotacion de un solido

 

Seguidamente, el HLCSG comienza a "pasar" las lineas de texto el .map a objetos solidos, cabe aclarar que en este momento no existe el .bsp, dado que este archivo es generado por el HLBSP.EXE, por lo tanto lo que hace el HLCSG es escribir estos solidos en los archivos con extension *.p0, *.p1, *.p2 y *.p3 para el posterior uso del HLBSP.EXE ( " * " indica el nombre del mapa)

 

Nota: No he comprobado si usando un .map de gran tamaño se crean mas archivos .p* donde * puede ser cualquier numero.

 

Ademas de estos 4 archivos, se crea un 5 archivo con el formato *.wic en el que se muestran las texturas incluidas en el mapa

 

Esta archivo con formato .wic se crea en la parte final del HLCSG , en le denominado Texture Usage (Uso de Texturas) que ademas muestra las wads añadidas en el .map, el numero de texturas usadas de un .wad, el porcentaje del mapa usando esa .wad y la cantidad de texturas qu etiene la .wad; aqui un ejemplo:

 

Using Wadfile: \archivos de programa\valve\valve\liquids.wad
- Contains 0 used textures, 0.00 percent of map (32 textures in wad)
Using Wadfile: \archivos de programa\valve\valve\decals.wad
- Contains 0 used textures, 0.00 percent of map (222 textures in wad)
Using Wadfile: \archivos de programa\valve\valve\halflife.wad
- Contains 3 used textures, 75.00 percent of map (3116 textures in wad)
Using Wadfile: \archivos de programa\valve\cstrike\de_piranesi.wad
- Contains 0 used textures, 0.00 percent of map (160 textures in wad)
Using Wadfile: \archivos de programa\valve\cstrike\cs_747.wad
- Contains 0 used textures, 0.00 percent of map (143 textures in wad)
Using Wadfile: \archivos de programa\valve\cstrike\cs_assault.wad
- Contains 1 used texture, 25.00 percent of map (22 textures in wad)

Texture usage is at 0.06 mb (of 4.00 mb MAX)
0.08 seconds elapsed

 

Como pueden ver, estoy usando 7 wads (las que estan añadidas en el VHE, lo que hace el .map es tomar esas texturas y si se fijan hay algo que suele tener mucha gente pero que no se fijan en ello, hay 4 .wad que no estoy usando:

- liquids.wad

-decals.wad

-de_piranesi.wad

-cs_747.wad

 

Es recomendable quitarlas, en el VHE o a mano en el .map (aunque no lo hagas si no sabes lo que haces), para reducir el peso del mapa y demas errores que se puedan producir, por ejemplo colocando mas de 8 wads en el .map

Al final de todo nos dice el uso en .mb de texturas y si colocamos mas de 4.Mb (el maximo) se producira un error impidiendonos compilar.

 

Por ultimo, añade la parte del HLCSG a archivo *.log, que es el log de la compilación

 

Con esto último se acaba el HLCSG.EXE y pasamos al HLBSP.EXE

 

HLBSP

 

hlbsp.exe, la pregunta del millón que hacen todos los recien llegados al Mapping: "¿Como paso mi mapa a .bsp?"

La respuesta, compilando el .map con las herramientas del ZHLT, todas y cada una de las herramientas precisa de las otras para su funcionamiento, aunque alguien me dirá: "¿Como es eso si puedo compilar perfectamente usando solo el HLCSG o usando todas menos el HLVIS?"

Muy sencillo, puede compilar solo con el HLCSG porque puede compilar un map por partes, imagina que no tienes muhco tiempo, compilas primero usando solo el HLCSG y el HLBSP y cuando puedas, haces el HLVIS y el HLRAD

¿Por que puedo compilar sin el HLVIS? Porque el HLVIS podríamos decir que es "prescindible", porque si, puede compilar el mapa sin el .HLVIS y podrás cargarlo en tu CS, pero haz la prueba y mira que pasa; mala iluminacion, no hay sombras, bajos FPS (Frames Per Second o en español Imagenes Por Segundo)

 

¿Que significa HLBSP? Significa Binary Space Partition ( Espacio de Partición Binario)

 

Comenzemos pues el HLBSP, aqui dejo una compilacion exitosa del HLBSP

SolidBSP [hull 0] 25 (0.00 seconds)
BSP generation successful, writing portal file 'C:\zhlt\zhlt253\maps\articulo_zhlt\armasastaAWP.prt'
SolidBSP [hull 1] 25 (0.00 seconds)
SolidBSP [hull 2] 25 (0.02 seconds)
SolidBSP [hull 3] 25 (0.00 seconds)
0.06 seconds elapsed

 

El HLBSP toma los archivos *.p0, *.p1, *.p2 y *.p3 y los escribe en el *.bsp, hace que el GoldSource (el Engine del Half-Life) "entienda" las coordenadas y demas datos de los *.p0, *.p1, *.p2 y *.p3 y pueda renderizarlos, hacerlos solidos, agregar las funciones de las entidades, etc.

Genera ademas 3 archivos:

- *.lin

-*.pts

-*.ptr

 

Son los llamados portal files que crean los leafs, los leafs definen un "sector" de superficies visibles en del mapa

Generalmente los archivos están vacios menos el .ptr que es donde estan lo archivos de los portales

Los archivos *lin y *.pts se llenan cuando hay un LEAK .

 

Nota: Un LEAK es un agujero en el mapa, cuando haces un mapa y no queda cerrado totalmente o hay alguna entidad fuera del mapa, en el "negro" del VHE cuando el HLBSP esta construyendo los solido detecta esta parte no cerrada o la entidad fuera del mapa y se produce este error que provoca una sobreiluminación, no haber sombras en el mapa y bajar completamente los FPS (hay mas causas para el LEAK como por ejemplo un solido de gran complejidad que requiera de la textura ORIGIN).

 

Se acabó el HLBSP.EXE por lo tanto toca ver el HLVIS.EXE

 

HLVIS

 

HLVIS.EXE quiere decir VISIBLE INFORMATION SET (Establecedor de la Información Visible) y su trabajo es el de generar la matriz de visibilidad (especifica que polígonos que el jugador no puede o no podría ser capaz de ver) para el mapa y ayuda a acelerar su interpretación.

Es el que se encarga de calcular las sombras y demás efectos luminosos

Aquí muestro el proceso del HLVIS completo:

BasePortalVis:
(0.11 seconds)
LeafThread:
(2.75 seconds)
average leafs visible: 63
g_visdatasize:2035  compressed from 2261
2.92 seconds elapsed

 

El HLVIS también usa el archivo.ptr para leer los portales, los descomprime y al acabar los vuelve a comprimir, por eso dice g_visdatasize (la variable del tamaño del VIS) :2035 compressed from 2261

 

Lo siento mucho pero esta es la utilidad de la que menos información dispongo, en cuanto tenga más información la pondré, si alguien sabe más y quiere añadirlo que responda a este Tema o por MSN: S34Qu4K3.CS@hotmail.com

Nota: Esto último no es del todo exacto, se que es lo que ocurre en cada momento en el HLVIS, lo que no se es como expresarlo para su entendimiento, lo que seria dar una buena definición de ello)

 

Goto HLRAD:EXE

 

HLRAD

 

La penúltima herramienta del ZHLT y mi favorita: el RADiosity (radiosidad en españo), se encarga de generar y aplicar todos los efectos de luz para el mapa, como las entidades light y el cielo y haceque el mapa se vea bien. Este es por lo general es la herramienta más lenta del ZHLT debido a la gran cantidad de información que debe volcar en el .bsp

Seguidamente muestro una compilación completa del HLRAD:

[Reading texlights from 'C:\zhlt\zhlt253\lights.rad']
[59 texlights parsed from 'C:\zhlt\zhlt253\lights.rad']

88 faces
Create Patches : 1312 base patches
0 opaque faces
25258 square feet [3637248.00 square inches]
1 direct lights

BuildFacelights:
(0.19 seconds)
BuildVisLeafs:
(0.69 seconds)
visibility matrix   :   0.3 megs
MakeScales:
(0.95 seconds)
SwapTransfers:
(0.17 seconds)
Transfer Lists :     1378816 :    1.38M transfers
      Indices :        8576 :    8.38k bytes
         Data :     5515264 :    5.26M bytes
GatherLight:
(0.25 seconds)
FinalLightFace:
(0.41 seconds)
2.83 seconds elapsed

 

Paso a explicar que es cada cosa:

 

[Reading texlights from 'C:\zhlt\zhlt253\lights.rad']
[59 texlights parsed from 'C:\zhlt\zhlt253\lights.rad']

 

En la carpeta del HLRAD tenemos un archivo llamado lights.rad, en el se encuentra el RGB de ciertas texturas que estén agregadas y el brillo, modificando el brillo podemos hacer que la textura se más o menos luminosa, llegando a la posibilidad de poder verla sin que haya ninguna luz en la habitación (cosa absurda por cierto); el HLRAD lee este archivo y carga la configuración de cada textura que tenga en el lights.rad, en mi caso hay 59

 

XX Faces: Cantidad de caras de los sólidos de todo el mapa

 

Create Patches : 1312 base patches

Crea los "parches" del mapa

Nota: No info sorry , si alguien quiere añadir...

 

0 opaque faces : Nada que decir, son las caras opacas sin luz alguna

 

25258 square feet [3637248.00 square inches]

Nota: No info sorry , si alguien quiere añadir...

 

1 direct lights

Entidades light, light_enviroment y light_spot del mapa, en mi caso solo una light

 

 

BuildFacelights:
(0.19 seconds)

 

Construye la luz que irradia sobre las caras de los solidos

 

BuildVisLeafs:
(0.69 seconds)

 

Construye los Leafs del HLVIS, obviamente si no compilamos con HLVIS no va a hacer esto.

 

visibility matrix   :   0.3 megs

 

Determina que pathces pueden ver a los otros, no tengo más info(necesario HLVIS)

 

MakeScales:
(0.95 seconds)

 

Uno de los procesos que más memoria requiere, creo que crea la escala de las luces del mapa(necesario HLVIS)

 

SwapTransfers:
(0.17 seconds)
Transfer Lists :     1378816 :    1.38M transfers    -----> Lista de Transferencias
      Indices :        8576 :    8.38k bytes                   ----->Indices
         Data :     5515264 :    5.26M bytes               ----->Data(información)

 

Mi proceso favorito, Swap Transfers, el primero que vi y me "enamoré" de el ^^; cambia las transferencias de las luces enviadas a fuera a las luces colectadas dentro. En un mundo ideal, estas luces serían simétricas pero por culpa de los factores son unicamente aproximadas, despues son normalizadas y finalmente serán un poco diferentes

 

GatherLight:
(0.25 seconds)

Toma las luces le da variable g_patches

 

FinalLightFace:
(0.41 seconds)

 

Añade la iluminación indirecta encima de la luz directa y lo guarda en el archivo final del mapa

 

 

Y con esto acaba mi amado y a la vez odiado HLRAD.EXE y nos vamos a la última parte de este articulo

 

 

RIPENT

 

Probablemente la mayoría de la gente no lo conozca, poca que lo conozca pero que no lo use y muy poca gente que lo use.

Pero, ¿qué es el Ripent?

Gran definición por un gran amigo:

 

El Ripent comprueba los limites de todo lo que puede ser colocado en un mapa

models, caras, solidos, entidades, luces y demás

 

Seguidamente dejo como es el ripent

 

Object names  Objects/Maxobjs  Memory / Maxmem  Fullness
------------  ---------------  ---------------  --------
models              1/400           64/25600    ( 0.3)
planes             20/32767        400/655340   ( 0.1)
vertexes           90/65535       1080/786420   ( 0.1)
nodes               6/32767        144/786408   ( 0.0)
texinfos            3/32767        120/1310680  ( 0.0)
faces              88/65535       1760/1310700  ( 0.1)
clipnodes          18/32767        144/262136   ( 0.1)
leaves              2/8192          56/229376   ( 0.0)
marksurfaces       88/65535        176/131070   ( 0.1)
surfedges         352/512000      1408/2048000  ( 0.1)
edges             177/256000       708/1024000  ( 0.1)
texdata          [variable]         48/4194304  ( 0.0)
lightdata        [variable]      49608/4194304  ( 1.2)
visdata          [variable]          3/2097152  ( 0.0)
entdata          [variable]       2343/524288   ( 0.4)
1 textures referenced
=== Total BSP file data space used: 58062 bytes ===

 

Como pueden ver, al usar un mapa casi vacio los niveles son muy bajos, esta herramienta es de gran utilidad y sirve desde para detectar errores, saber si vamos a poder compilar el map y hasta hacernos una idea de como será el peso de nuestro mapa

 

No diré nada más de ella porque es autoexplicativa, si hay alguan duda ya saben

 

Y S34cabó Ripent

 

Notas/Comentarios/Conclusiones

/Agradecimientos

 

Esta es un artículo que le había pedido a Emi hace bastante tiempo (1 año al menos) si podía hacerlo, me dijo que lo intentaría pero que le llevaría bastante tiempo pero al final, por olvido, falta de tiempo, ganas o lo que fuera no salió adelante. Ahora, con mi añito y 3 meses de experiencia puedo hacer un humilde articulo que aunque no sea del mismo tema en concreto, puede que tenga la mitad de calidad de los articulos de Emi:

-Mapa vs. Mapper

-Como progresar en el Mapping

 

Espero que les guste y lo más importante, que aprendan; yo tengo la creencia de que absolutamente nadie puede llegar a ser un buen mapper si conocer el proceso de compilación a fondo y espero que este articulo les ayude, me parece algo extraordinario el saber que está ocurriendo cada vez que hago click en compile en mi Batch Compiler, que es lo que hace el VHE cuando le doy a exportar a .map, etc

 

Nota: Por si a alguien se le da por preguntar si, se puede hacer un mapa a mano con el bloc de notas, pero es muy difícil además de ser una pérdida de tiempo

 

Agradecimientos:

 

-A mi mentor, tutor, amigo, compañero, maestro, definidor del Ripent, el quien aguanta todas mis preguntas y soporta mi pesadez , quien va a ser, Emi claro está

-A cierta frutira, que tiene forma de P'erita por hacer la página nº 1 en toda Sudamérica

y gracias a él, hoy pueden leer este articulo. Gracias por Aguantar (L)

-De este no hablo, solo digo que le doy la tabarra todo el día, más que a Emi, via MSN o Skype de igual, gracias por ayudar a MZ cuando lo necesitaba

-NemeS!S....WTF? Este no se qu ehace aqui no pregunten, apoyo moral y un HLDS cuando lo necesito

-Resto de usuarios, Incrusser, iLY, sonrisa, varchar(no este está repe ), DmC.Bleacj, valen, Swata, Oxi, ezeh, ezequieel, howard, CHris, Rewolf, SHun, aagguuu, Faqqu & Poola Cumbia Inc, PCCLone, Ciio, El Juanixxx y mogollón de gente de la que me olvido pero que pienso igual en ella

 

 

Licencia

 

Se autoriza la libre distribución de este articulo siempre y cuando haya mención al autor, yo (S34Qu4K3) y esta maravillosa comunidad que es Mapping-Zone (http://www.mapping-zone.NET)

 

Aun asi, este articulo fue creado para Mapping-Zone usando como fuentes, mi pequeño cerebro, el codigo fuente del ZHLT y la experiencia de Emi

 

 

Saludos

Editado septiembre 27, 2010 a las 15:26 por S34Qu4K3

[Perita]

Bue!! que sarpado!!, gracias s3!! te vas al joraca interesante información y muy buena gracias por los créditos y gracias a vos por el esfuerzo de traer cosas nuevas!

[Emi]

Gracias S34 super completo te quedo de 10 .. esto es algo muy importante que todos tendrian que leer!! super super gracias, alto laburo.

[Santi]

Che te quedo muy prolijo y es muy util para los que quieran saber mas acerca de las herramientas de compilacion. Hay muchas cosas que no sabia y me parece un muy buen aporte, muchas gracias ;D.

[PCclone]

Muy bueno

[S34Qu4K3]

Gracias a todos

 

#UPDATED: Añadida una pequeña información a Swap Transfers que explica por que la transeferencia de las luces

[Percival]

sos re groso

[Diegrox]

Me lo leí casi todo es muy bueno se agradece una re banda sea sos un groso que bueno ver post asi en esta comunidad que esta en abundante crecimiento...

[KeyLoggeR]

Buenisimoo!!

 

Segui asi !

[xRivas]

Buenisimoo!!

 

Segui asi !

 

por favor...

no revivas post's D: