tada-s

Descripción: Mapa semi-realista

Titulo del mapa: de_bidepot

Tipo: de_

Slots: 16 TT - 16 CT

Tamaño: Grande

Descarga: http://gamebanana.com/maps/195681

 

Imágenes y comentarios: Encontré este proyecto abandonado que había iniciado hace años y dije: "Híjole, este map nunca la terminé.". Al inicio, la escencia de este map fué crear un mapa tan realista (a nivel gráfico), como se pueda llevando al límite el motor de juego GoldSrc que es del año 1998, tan realista que parezca un mapa para el motor Source. No pude lograr esa escencia, por la falta de experienca para este fin.

 

Tuve muchos factores en cuenta al diseñar este mapa.

 

En jugabilidad tuve en cuenta el balance, la forma del mapa, comprobando con cronometrado de tiempos de recorrido y pruebas de juego con bots. La prueba con bots no funcionaba correctamente porque en el primer reconocimiento del mapa, parecía que no detectaban los brushes CLIP y nunca pasaban el pasillo que conecta SpawnTT y Bomb Site 1.

 

Tuve limitaciones con el motor de juego como la cantidad y tamaño de texturas (no superar 4 MB) porque me tiraba el error de MAX_MAP_MIPTEX. Aunque podía utilizar el flag -texdata para aumentar esta capacidad y utilizar texturas de mayor esolución y mas variedades, preferí no modificarla para que sigan siendo compatibles con computadoras antiguas. Por lo tanto, se tuvo que achicar y reutilizar bastante las texturas para que caiga en el rango de 4 MB.

 

Intenté que las texturas sean completamente nuevas pero como las texturas de Paranoia son tan geniales, utilicé una gran parte de ella. Tuve en cuenta un poco en la estética y cuidar en no agregar tantos detalles para que no sea grotesca y mantener cierta simplicidad. No se utilizaron models para que se pueda jugar sólamente con el archivo .bsp y los sprites que vienen por defecto en el juego.

 

Se tuvo en cuenta el performance del mapa al diseñar aunque igual fue muy difícil controlarlas. Utilicé texturas Hint-Skip para intentar amortiguar el performance pero no tuve mucha suerte. Aunque hay un punto donde la vista es muy abierto, la mayoría de los lugares es más cerrado. Algunos sólidos se convirtieron en entities para mejorar el rendimiento.

 

No se si este sea mi último map (dentro de los pocos que había creado hasta ahora), pero probablemente no crearé mapas hasta que se me antoje hacer otra.

 

Saludos

 

Tadashi

 

Descarga alternativa:

https://mega.nz/#!upBDUC7Y!tCtxFNBMqULmyTshU8NQxfCdUGo85SP5z4EhdxQSC-g

http://gamebanana.com/maps/195681

 

Screenshot

 

 

En estos días estuve intentando resolver unos cuántos problemas de teoría de grafos.

Ahora que me topé con este artículo, me encontré que es interesante aplicar la teoría de grafos en los mapas para hacer un análisis matemático. Me puse a pensar y pude rescatar el siguiente análisis:

 

Se puede determinar que un mapa si es simple o no contando la cantidad de ciclos que tiene un mapa. Por ejemplo, de_torn es más laberinto que de_aztec y eso está reflejado en la cantidad de ciclos que tiene el map. El de_aztec tiene sólamente 5 ciclos y de_torn tiene 11 ciclos (véase la imagen de abajo). De paso conté que de_dust2 tiene 5 ciclos y de_inferno tiene más de 14 ciclos (y eso increiblemente mucho).

Cuando un mapa tiene muchos ciclos, habrá muchísimas formas que se puede ir de un punto en particular a otro punto en particular del mapa (desde base tt a base ct o desde bombiste B a largo, etc.). Y obviamente si el map tiene pocos ciclos, tendrá sólamente 1 o 2 formas de llegar hasta un lugar.

Podemos aprobechar este análisis para contruir otras formas (geometrías) de mapas que tenga la propiedad de pocos laberintos o simples: por ejemplo, crear mapas que sólamente tenga 5 ciclos (imagen de abajo).

Y estos mapas que no son muy "laberintosos" serán fáciles de aprender.

 

En resumen, cuanto más ciclos tiene el mapa, más complejo es el mapa y cuando más complejo es el mapa, más difícil de aprender. :'/

Este análisis que hice ya podría ser un simple criterio para ver si un map es complejo o simple. Cabe aclarar no es completo ni excato ya que falta más profundidad y abarcar más detalles.

 

Edit 2: No sé si se nota pero hice el esfuerzo para que el texto que escribí no sea muy... difícil de entender. ¿El texto sigue siendo difícil de entender?

Edit: Si no entienden algo de lo que escribí, pueden preguntar y con gusto lo explicaré. Si no entienden nada, igual les explico

Edit 3: Agh... Lo que hago cuando no me entran ganas para estudiar en la facu T_T. Bueno. Me iré a estudiar.

Antes de crear el mapa, me propuse que, pase lo que pase, no deberia pasar los 2 mb de peso total; para que un mapa triunfe en los server, el peso del mismo es fundamental

Fui tan exigente con el peso del mapa que tuve que usar en todas las cajas la misma textura para no pasarme de los 2 mb

 

Aunque no lo crean, tenia pensado agregarle unos buenos techo a las dos edificaciones e iba a quedar magnifico, pero tuve que optar por no hacerlo ya que el mapa se me iba como a 3 mb, y creo que era demaciado

Muy buen punto. Ese sacrificio creo que fue muy importante (y). Como el techo está un poco lejano a la vista del jugador, se podría reducir las texturas a tamaños mucho menores a 256x256

 

Respecto al map, ofrece una característica interesante: más divertido cuando más gente está jugando, a diferencia de aim_map: más divertido cuando menos gente está jugando.

 

La textura "{arbolada_trees" veo que perdió mucho la calidad cuando creaste. ¿Qué programa usaste para cambiar a 256 colores?

Mi primer map que comensé a crear fue mi colegio. Empecé a trabajar en marzo 2007 y terminé el noviembre 2009. Durante todos estos años, aprendí muchas cosas sobre el mapping y volví a crear en total 4 veces todo el map hasta que me convenciera (Fueron muy grandes la diferencia). Es enorme el map y no es apto para el motor de juego de Counter-Strike pero en ese momento no sabía sobre epolys ni wpolys. Igual, nos divertimos jugando el map hasta que la directora de mi cole me llamó, llamaron a mis padres, me explicó que el colegio me puede demandar por crear este map. Borré todas (excepto una oculta en mi PC).

 

de_sanjo (unas pocas imagenes y sin el .bsp por razones legales )

 

 

 

Mi primer map que terminé fue la que comensé y terminé el noviembre 2009 (antes del map del colegio).

de_radistation

Descarga: https://mega.co.nz/#!boJ0lJyC!gwnDaZiaIlIGcVYYHyzPtV5oWJvuQSYC8oa8-GubOj8

 

 

Muchas felicidades DanielMap, BetanSaim y Carnacleos! Sus mapas son muy lindos e interesantes, así como de los demás maps que se presentaron en este torneo. Cada una son diferentes y tiene se puede apreciar el estilo que tiene cada uno (y hace poco había visto un mapa muy muy similar al aim_decound de Carnacleos).

Es muy dificil apreciar un map atraves de las fotos (algunas no son muy descriptivas). Se podría publicar los maps para que se pueda descargar??

Cuando estuve preparando el map para el torneo tuve dudas sobre el critero de optimización: estaba definido por fps (como mínimo 60fps) y noté que dependiendo de la máquina y otros factores es muy diferente el fps que tendrá en los maps. Tengo una PC muy rápida, muy pocas veces llega a 70fps y eso hacía que fuese complicado imaginar el fps que podría tener los jurados. Tuve que ingeniar guiandome por los wpolys y epolys de los mapas oficiales.

Si un map funciona a 100fps en la PC del mapper, una cómun en estos días, y en la PC del jurado, una de hace 4 años, le corre con 50fps e influye a la calificación sería frustrante para el mapper.

 

Creo que el rendimiento del map es un factor decisivo muy crítico: un map innvoador con una jugabilidad excelente puede llegar a ser descartado completamente desde un comienzo si funciona a 20fps.

 

Propongo en debatir sobre "cómo determinar si el rendimiento de un map es bueno o malo".

PD: Después de escribir todo esto, estoy en dudas si ésto es innecesario (ya que tiendo a analizar profundo a las cosas y eso podría complicar las cosas).

La animacion original o darle un poco de movimiento para que no este inmovil como estatua

 

http://k46.kn3.net/6/9/D/D/F/5/926.jpg

 

Yo creo que trae el esqueleto para darle movimiento

 

Animación original... es el conjunto de animación que es caminar, saltar, agachar, disparar?

Es para que un jugador tenga ese model? o es para colocar en alguna parte del mapa? qué parte del mapa?

Qué quiere que haga el zombie? Esta enjaulado? Está caminado en cualquier dirección? camina lentamente como zombie? o camina como supermodelo? xD

Son algunas cosas que no entiendo bien.

Puedo hacerlo pero lo ideal sería que tú lo hagas. ¿Sabes cómo animar un model y compilar?

Puede ser que este models tenga animacion ?

 

http://www.mediafire.com/download/y4rux5s0he3wl01/zombie_dmap.rar

Se puede hacer eso. Qué tipo de animación quieres que tenga??

Hola todos! Como no he podido terminar el map a tiempo para el primer torneo de mapping, escribo este tutorial con el fin de transmitir la idea de no quedar encerrado con viejas teorías y herramientas y extender los brazos a nuevas ideas y conceptos.

 

En este tutorial utilizaremos el programa tree[d] 3.0 para generar el árbol y kHED 1.1.5 para aplicación de textura, compilación y otros ajustes. Este tutorial supone que usted tiene el manejo básico del programa kHED. De lo contrario puede aprender en el siguiente link: http://www.mundo-mapping.net/foro/showthread.php?174-GU%C3%8DA-Crear-modelos-3d-en-kHED-%28PARTE-1%29.

 

 

 

Link de descarga del programa tree[d] 3.0 (actualmente, 26/04/2015, ya no existe la pagina oficial)

Link: https://web.archive.org/web/20130915030534/http://www.frecle.net/treed/tree%5Bd%5D-

 

setup310.exe

 

Navegación:

• Click derecho: Zoom
• Click izquierdo: Rotación de la cámara

 

Proceso

 

Generar y exportar el árbol

Ejecutamos el programa tree[d] y generamos nuestro árbol deseado.

Para tener un buen rendimiento (fps) en el juego, hay que estar atento en la cantidad de triángulos! Se sugiere que esté mas o menos dentro del rango de 300 a 800 triángulos (sí, muy poco). Pero

 

éste rango puede variar mucho (incluso más que 800 triangulos), dependiendo del máximo wpolys y epolys que tendrá cada map (está relacionado con la cantidad de triangulos visibles desde cualquier

 

lugar. Véase "r_speeds 1"), y también del motor de juego y la GPU de cada máquina.

 

Algunos ajustes rápidos para reducir la cantidad de triángulos:

• Utilizar textura que continene varias hojas en vez de utilizar texturas de unsa sola hoja. Para eso, cantidad de "Leaf" colocamos 0 y activamos los "Cross Horizontal Geometry" y "Cross Vertical
   
  Gemoetry". (Reduce drásticamente)
• Reducir la subramificación o "Sub Branches" a 1 o 2. (Reduce drásticamente)
• Reducir la ramificación o "branch". (Reduce moderadamente)
• Reducir la segmentación en longitud y perimetral o "Length Segs" y "Radial Segs" en el tronco "Trunk" y ramificación "Branch". (Reduce suavemente)
• Otras combinaciones de ajustes.
• Modificación directa sobre el model en kHED. Este proceso se puede realizar en cualquier momento después de exportar a .obj.

Recuerda! Al reducir la cantidad de triángulos se obtiene mejor rendimiento pero se sacrifica el aspecto del árbol.

 

Luego de generar nuestro árbol, exportamos como archivo .obj

 

 

Editar el archivo .obj

Como kHED no carga los datos .mtl (la información del "material" o textura) al importar los archivos .obj, debemos separar en dos (o tres) archivos .obj.

Abrimos el archivo .obj con bloc de notas (o cualquier editor de texto) y encontraremos una extensa lista de numeros. Básicamente tiene esta estructura:

 

mtllib Save OBJ.mtl

o trunk

# verts

v 0.228363 0.00198195 -0.00269278

v 0.0887559 -0.00124904 -0.157965

:

:

 

# normals

vn 0.984815 0.0336342 0.170316

vn 0.542289 -0.111007 -0.832826

:

:

 

# texcoords

vt 0.0 0.0 0.0

vt -0.166667 0.0 0.0

vt -0.333333 0.0 0.0

:

:

 

g

usemtl wood03png

f 2/2/2 8/8/8 1/1/1

f 2/2/2 9/9/9 8/8/8

f 3/3/3 9/9/9 2/2/2

:

:

 

g

usemtl leaf08png

f 76/76/76 79/79/79 77/77/77

f 76/76/76 78/78/78 79/79/79

f 80/80/80 83/83/83 81/81/81

:

:

 

 

La primera parte "roja" está almacenada la información de los vértices y alineación de texturas entre otras cosas. Esa parte no tocamos.

La segunda parte "rosa" con "verde", comienza con una "g" minúscula y luego una extensa información de caras. Ésta nos interesa.

Lo que haremos es crear dos (o tres) copias de este archivo .obj y lo renombramos (como ejemplo, ramas.obj y hojas.obj).

En la primera copia eliminamos un bloque, o sea, la primera "g" y la extensa lista de caras "f numero/numero/numero ..." (Este proceso podemos agilizar utilizando el "Buscar" de bloc de notas buscando la palabra "g").

En la segunda copia eliminamos el otro bloque desde el segundo "g" y la extensa lista de caras.

Así, tenemos dos archivos, una con hojas y la otra con ramas.

 

Nota: Sólamente necesitamos dos copias si utilizamos hoja chiquita y ramas o cúmulo de hojas ("cross geometry") y ramas. Si utilizamos hoja chiquita, el cúmulo de hojas y ramas, debemos hacer tres copias y cada una debe contener un sólo bloque de caras.

 

Texturizar, combinar y otros detalles.

1) Ejecutamos el programa kHED e importamos uno de los archivos .obj.

 

2) Seleccionamos todas las caras .

 

3) En la ventana de Groups , agrupamos y renombramos .

 

4) Abrimos la ventana de material , creamos un nuevo "material", renombramos y cargamos una imagen (la

 

imagen debe cumplir varios requisitos).

 

5) Asignamos el material al model (debe estar seleccionado el objeto).

 

6) Verificamos el UVmap del material (el objeto debe estar seleccionado). Si está completamente afuera de la imagen, reacomodamos los vértices de

 

manera adecuada para evitar un bug en las texturas. Puede o no estar el poligono completamente adentro pero por lo menos una parte de ella debe estar encima de la imagen.

 

7) Guardamos como un archivo .khe

 

? Repetimos este proceso con el otro archivo .obj.

 

9) Luego, combinamos los dos models en el menú [File]->[Merge... Ctrl+Shift+O].

 

10) Redimensionamos agrandando (o achicando) y damos los toques que deseamos

 

Resultado

 

 

Voilà! Ya está listo para compilar!

Ya tengo la idea! Me anoto

Hola todos!

Hoy les traigo otro tutorial fantástico creado exclusivamente para mapping-zone.net! XD

Bueno. Este tutorial consiste en crear una textura animada (que se mueve) y utilizaremos este model como ejemplo:

+0lab1_cmpm3

Como se crea?

Es fácil!

Primeramente, las texturas que se mueven tiene un “+”, “un numero” y “nombre de la textura” al principio del nombre de la textura. El “+” indica que es una textura que se mueve y “un numero” significa que frame es. Ejemplo: +0mapping-zone.net. La textura de Half-Life, se mueve a 10fps (10 frames per second) o mejor dicho, se cambia las imágenes cada 0.10 segundos.http://img444.imageshack.us/img444/4532/2lab1cmpm3.png

Por ejemplo, la textura +0lab1_cmpm3 que hay en halflife.wad, está compuesto así:

+0lab1_cmpm3

+1lab1_cmpm3

+2lab1_cmpm3

+3lab1_cmpm3

+4lab1_cmpm3

+5lab1_cmpm3

Y cuando aplicas esta textura (solo una de la lista), esta se mueve cuando juegas!

Cuando agregas a un wad, tenes que poner todas las texturas (en este caso los 6) en el wad.

Importante

El número de frame máximo es de 0 a 9. Por lo tanto, no funcionará las texturas como +01screen_1.

Pero no creo que tengan problema con eso, porque no usarán mucho.

Espero que les sirva!

Hay otras diferencias entre el archivo .rmf y .map

Como dijo Dario, el rmf se puede abrir solamente con Valve Hammer Editor y los archivos estan codificados binariamente. En cambio, el archivo map esta guardado como un texto plano, o sea que se puede abrir con un bloc de notas. Hay veces que al guardar en el archivo .map se pierde presicion en los vertices y sale ligeramente deformado. En el rmf no suele tener este problema. Y hay otras diferencias un poco mas complicadas...

Si tu archivo map pesa 100kb y no puedes abrir, hay posibilidad de arreglarla para recuperar tu map.

Si quieres, te puedo arreglar!

Puede ser que te falta crear el otro lado. Cuando creas un triangulo, esta se ve sólamente de un lado. Si quieres que una superficie se vea de los dos lados, tendrás que crear dos triángulos, una que mira al frente y otro atrás.

Si esa fuese el caso, una solución simple sería duplicar toda la superficie, girar 180º y la colocas en donde debe quedar.

Hola Dario

Me parecen muy buenas tus maps, aunque nunca jugué los mapas death run o jail break!

El deathrun_different me llamó mucho la atención thumbs up (y) por ser diferente y lindo

el skybox es cuando hago muy grande el solido con el sky? y no el mapa no lo he terminado me falta mucho solo queria saber si todos esos cuadritos podrian causar bajos fps, igual todas las partes q no se miran los quito con el NULL..

Si! El skybox es eso.

 

Tengo un mapa que todavía está en desarrollo y quiero testear para ver si todo va OK (y el FPS).

Le coloco unos "paredes" temporales para probar el rendimiento de una sección (tapando la parte superior también).

Verifico si no tiene leak y compilo. Ahí recien veo el fps para verificar (me sale 100 fps, muy buena).

Si compilo sin esas "paredes" me sale 13 fps porque el map tiene leak. (leak, causa de bajos fps).

asi lo tengo yo http://imgur.com/7CU0lJ2 todos esos sos cuadritos y todos tienen 40w 48l 40h y la escala esta en 1.00 en x y y..

Tu mapa tiene leak?

Por lo que veo en la imagen, todavía no has terminado todo. En caso que no hayas terminado, crea solidos auxiliares con texturas sky y otras texturas para cerrar el map de tal forma que no tenga leak (intenta evitar el skybox) y luego verifica tu fps.

Para comprobar si realmente funciona lento o no, es importante compilar exitosamente el proceso VIS y RAD (porque éstos mejoran el fps). Teniendo leak, siempre te tirará el peor fps.

Si este no es el caso, tendríamos que hacer un análisis un poco más complejo como el que dice LeaN. Avísanos que tal te fue.

e leido por ahi que trae bugs es verdad?

Y gracias por esa breve explicacion

No hay de queso nomas de papa. Desconozco la estabilidad del programa pero no me parece raro que tenga bugs ya que es medio nuevo y todavia en desarrollo. Si te aparecen bugs, simplemente reportala explicando detalladamente en el foro ruso de donde se creo y asi, ellos arreglaron para que cada vez mejore su level editor. Si no te animas a registrarte en ese foro para reportar (con google traductor apenas me registre xD) podes avisarme para que le escriba en ingles.

Tenia en mente crear un level editor... se adelantaron T_T.

Hasta ahora, no tuve problemas y todavia es estable (3 horas de uso).

No manejo muy bien los entities pero se podría tener un efecto similar creando:

Dos cajas

*una móvil, transarente y salida

*una estetica, opaca e imaginaria

Creas los dos en el mismo lugar y cuando activas el botón, la caja móvil se mueve a donde conviene para que caiga el jugador.

Eso se podría hacer pero no se si hay otras alternativas. Te sirve?

En que es mejor? xD

Acabo de encontrar y no podre explicarte en detalle y tampoco coloque en este thread hasta que me familiarice. Ahora estoy utilizando creando un map y lo que noto inmediatamente es:

*Las texturas especiales como aaatrigger, clip se ven semi-transparentes como el valve hammer editor 4.0

*Proyeccion de models en vista 2D como el valve hammer editor 4.0 (se ven los models en vista 2D)

*Se ven los nombres de los entities.

*Las texturas que tienen el prefijo "{" (las transarentes) se ven transparentes las partes "azules".

*Muestra la camara como un rombo en vista 2D, igual que el editor GTK Radiant.

*Es posible abrir y ver el archivo .prt (muy util para analizar la visibilidad).

*3 tipos de texture lock

*Texturas animadas (como las que tiene el prefijo "+0")

*No tener que reiniciar el editor al agregar y quitar las texturas

*Posibilidad de agregar plugins (La que me vino por defecto y me paresca interesante fue "Round coordinates", redondeo de las coordenadas a enteros)

*Tiene autosave

 

PD:La imagen, el helicoptero coloque porque necesitaba colocar un model en el map como un ejemplo xD

 

Editor de mapa, alternativa a Valve Hammer Editor mejorado disponible para Windows y Linux. Desarrollada por los rusos.

Wanna try?

Link:

 

A la hora de crear un overview se coloca algo como:

 

global 
{
ZOOM	2.67
	ORIGIN	647 	-732	-1110
ROTATED	1
}

layer
{
IMAGE	"overviews/as_oilrig.bmp"
HEIGHT	0
}

 

En ese momento pensé: "Layer!? Será que soporta multiples capas de overview!??". Inspeccionando el código fuente de Half-Life me dio mas esperanzas! Una porción del codigo fuente, específicamente en el archivo hud_spectator.cpp decía (traduciendo el lenguaje C++ a nuestra lengua):

Al abrir el archivo "overviews/as_oilrig.txt" (como ejemplo), se verifica si la cantidad de layers no sobrepasa el valor de "OVERVIEW_MAX_LAYERS".

 

Mi sospecha era correcta. Half-Life está diseñado como para crear varias capas de overview, por lo tanto, Counter-Strike también ya que es una modificación de ésta.

Entonces se tendría que poder modificarse de la siguiente forma:

global 
{
ZOOM	2.67
	ORIGIN	647 	-732	-1110
ROTATED	1
}

layer
{
IMAGE	"overviews/as_oilrig_up.bmp"
HEIGHT	0
}

layer
{
IMAGE	"overviews/as_oilrig_down.bmp"
HEIGHT	-30
}

 

Este nuevo código no funciona porque tristemente, el valor de OVERVIEW_MAX_LAYERS es 1. Pruebo en el Counter-Strike y también... no me carga el segundo layer y en la consola me aparece "Error parsing overview file as_oilrig_down.bmp. ( too many layers )".

 

Está diseñado pero está deshabilidado multicapas en overview.

Por qué diseñan para que funcione multicapas y al final colocan una restricción que arruina todo... Me ha roto el corazón...

Me apunto

Oh, yeeeah!! Conoces esa exquisita comida que tiene forma de un toroide En estos días no he comido, aunque me diste las ganas de saborear de nuevo También había notado que la yerba es dulce! Algo inusual, era raro al comienzo pero me fuí acostumbrando un poco. Sería muy interesante hacer algún día un intercambio de cultura para conocer nuevas cosas (y jugar truco o el póker).

Normalmente, al utilizar el azul (RGB: 0 0 255) en una imagen, luego colocar el sufijo { ya es suficiente para colocarlo directamente en el WAD usando el Wally.

Podés intantar crear la imagen en 24bit de profundidad y luego cuando pasar a Wally. Convertía directamente a una imagen de 256 color con la indexación del azul en la posición correcta. (siempre el azul debe estar en la primera posición en la paleta de los 256 colores, o sino, no funciona). Obviamente, el objeto que se coloca la textura, debe ser un entity con sus respectivos parametros.

Puntito ;1085']Bievenido a la comunidad tada!

 

Para nada se tiene que volver polemico que seas oriundo de otro pais' date=' una parte de mi familia(mi abuela y mi tia) son de paraguay y tengo algunos familiares alla y mas ahora que estoy de novio hace 5 meses con una paraguaya y me llevo lo mas bien y se que como argentino somos de romper las bolas a todos los que nos sean diferentes pero eso aca en el foro no estara aceptado porque somos mas como una familia en donde nos ayudamos con los problemas que nos surgan y asi ir creciendo.

 

Estoy de acuerdo con lo que dijo lean, no tiene nada de malo nombrar a MZ. Es mas, no te voy a mentir que me gustaria ser lo que una vez fue esa gran comunidad con mucha actividad y buena onda. Pero se que si le ponemos muchas ganas y motivacion podemos quizas superar lo que fue MZ y seguir brindandole la mejor ayuda a los que recien se inician en el tema mapping.

 

Se puede apreciar en la primera imagen que el mapa de_algo parece estar copado[/quote']

Antes que nada, Me encanta tu nick!!!!!(Tenía que decirlo) Y por la respuesta, bien dicho La última vez que me fuí por Argentina era por la Regional de la ICPC que se hizo en Universidad de Buenos Aires, conocí las gentes de ahí, comí bife de chorizo (xD) y cuando volvíamos en el bus, un muchacho, creo que de buenos aires, me enseño a jugar el truco y la pasamos de maravilla. Decía polémico por otra razón, pero creo que la pasaré bien en el foro

Intentaré terminar el de_algo para ver como queda.

Espero que sea una gran comunidad, aunque se necesitará de esfuerzo para ir extendiendo.

Un gusto conocerte, Puntito. Saludos a la familia.