Golthiryus

Podeis quejaros (y con razon) de que sea un coñazo el tener que expear para subir niveles. Uno de nuestros objetivos es que existan otras vias alternativas (oficios, dar xp al robar, pero sobretodo hace quest).
Sin embargo esto no es facil. Si se da demasiada xp por oficio o por habilidades como el robar, se desequilibra para otros, por lo que normalmente se tira por lo bajo. Y la que seguramente sea mejor alternativa (hacerlo via quest) requiere ingentes cantidades de tiempo.
Pero si bien podeis quejaros, lo que no podeis es hacer trampas para saltaros eso que no os gusta y, cuando os pillan, decir que lo haciais porque expear no mola y deberia cambiarse.
Es como si un tio mata a su vecino porque hace mucho ruido y le dice a la policia: «hoiga! uviera usté esho argo antes!»

Amos a ver, creo que hay un problema de concepto. Todos queremos que el mud tenga mas jugadores, pero nuestro objetivo no es estar en el top 10 de juegos online, compitiendo con wow, war, etc.
Como bien dice Dunkel en otro post, estos juegos masivos online «graficos» tienen un target distinto al nuestro. Alguien que quiera graficos y meterse en un bucle infinito de conseguir mejor equipo y subir mas niveles hasta un maximo permitido y esperar entonces a que lo suban, deberia ir al wow o al war.
Ahora bien, el mud tiene otras cosas. Dunkel decia que los graficos son a la vez una bendicion y una maldicion. Por un lado hacen el entorno hostil para los primeros acercamientos, pero por otro te permite jugar en practicamente cualquier pc y lugar (cuanto habremos robado al pib nacional!!), desarrollar tu imaginacion y, a la vez, saber que dentro de unos años el mud seguira ahi y no se habra tenido que empezar otra vez por haber cambiado el motor grafico.

Creo que ya lo dije alguna vez. Queremos ampliar la cantidad de jugadores porque creemos que el mud es divertido y lo seria mas con mas gente. Ahora bien, eso no quiere decir que lo hagamos a toda costa. Queremos nuevos jugadores de calidad que vengan para jugar al rol y no a un diablo2 online y por eso hay ciertos pilares (o filosofias), como el tema del equipo, que no se cambiaran para traer a mas gente.

Ademas sigo diciendo que no creo que el hecho de perder el equipo sea algo que aleje a los jugadores. Como digo, salvo contadas excepciones, llevar un equipo magico y otro normal no es algo vital. Puede que a un novato, al morir, le sea tan dificil conseguir equipo de N que acabe rallandose y deje el juego. Eso si hay que evitarlo, pero todos, siendo ya veteranos, hemos muerto y pedido equipo «de colores» y no hemos abandonado el mud por ello. Es mas, si se piensa un poco (o se lee lo que ya escribi), si no se perdiera el equipo nunca, acabariamos como en el wow, llegando a un limite del mejor equipo mundial y aburridos hasta que salga la siguiente expansion.

Yo lo que habria hecho para eso es hacer todos los aliases para todos los pokes y tenerlos en diferentes carpetas y luego segun que poke se detecta/invoca/loquesea coger y activar una carpeta y desactivar otra.

Asi lo tengo con los pjs, rula perfecto y no da complicaciones raras

Basicamente, un marinero es el unico con capacidad de navegar con algo mas grande que un bote. Los botes solo permiten viajar por aguas poco profundas (normalmente las cercanas a un continente), por lo que para ir a ciertas zonas del mud hace falta que sea un marinero el que lleve la embarcacion.

A parte de eso, como indica el finger marinero, tienen otras habilidades, como pescar, aunque no son tan avezados en este arte como los pescadores.

Ademas pueden abordar otras embarcaciones, lo cual en este momento puede parece poco util, pero en un futuro seguramente haya barcos npcs (por ejemplo, un barco pirata con un tesoro a bordo), por lo que si que es algo util.

La de cuando era jugador estaba bastante completita, pero configurada por pjs y no por clases, asi que veo chungo poder pasarla… tambien es cierto que estaba hecha a base de parches y posiblemente sea horrible de entender xD.

No creo que costase mucho hacer una configuracion algo standard y colgarla en algun lado, sobretodo para los novatos y de base para los que quieran adaptarsela mas.

Antes de nada, decir que para los pocos que usan cmud, hace tiempo subi a la biblioteca compartida de cmud algunos paquetes entre los cuales se encontraba uno para configurar el keypad, lo cual ahorra gran parte del trabajo de hacer lo que explico aqui.

La configuracion inicial de zmud (y de cmud) esta preparada para moverse mediante el teclado numerico, pero esta pensada para muds ingleses, por lo que las direcciones estan en ingles. Esto quiere decir que al pulsar el «6» envia un «e» y al pulsar «4» envia un «w». Nuestro mud no esta adaptado a las direcciones inglesas, lo cual hace que lo primero que haya que salvar es este problemilla. Para ello a mi se me han ocurrido dos opciones:

• La primera que se me ocurrio fue una bastante sencilla: si el zmud envia «w», pues que el mud entienda ese «w» como «o» y listo. Esto es, me creo un alias w o, alias sw so, alias nw no, alias u ar, alias d ab… Con hacer eso ya puedo moverme con el pad y, ademas, cuando use el map me movera correctamente. Ahora bien, tengo que definir esos alias para cada pj, lo cual puede ser un tanto toston. Ademas las salidas «raras» como de y fu no podran mapearse.
• La segunda opcion consiste en hacer el giro copernicano y que no sea el mud el que se adapte a zmud sino zmud al mud. Esto nos permite que, una vez tengamos una configuracion adaptada, todos nuestros pjs funcionen bien sin depender de aliases del mud.

Debido a que la primera opcion es trivial (parto de la base de que se sabe usar los aliases del mud), explico la segunda. A parte de alias, triggers, variables, etc, zmud tiene otro tipo de «cosa» (para quedar mas bonito llamemosle objeto) que identifica las salidas. Este objeto se llama direction y se caracteriza por cuatro cosas:

• caracter que la identifica (por ejemplo e,n,o,s)
• caracter que identifica la direccion (realmente sentido :P) contrario (por ejemplo o,s,e,n)
• texto asociado (por ejemplo e,este). Esto sera usado cuando nos movamos «manualmente» para que el mapa nos siga. Por ejemplo, al poner «este», el mapa interpretara que debe moverse a la room este de la actual
• direccion asociada en el mapa

Hay una pequeña pega, y es que como digo mas arriba, una direction se define por UN caracter, lo cual complica el describir por ejemplo la direccion «no». Sin embargo estos caracteres son usados a nivel interno por zmud, asi que podemos ponerle cualquier valor, que nosotros no lo usaremos.
A modo de ejemplo y a la vez de resolucion, poniendo esto en la linea de comandos deberiais tener ya configuradas correctamente las direcciones, apareciendo en una carpeta llamada «direcciones»

#DIR ns "n|norte" n direcciones

#DIR sn "s|sur" s direcciones

#DIR eo "e|este" e direcciones

#DIR oe "o|oeste" w direcciones

#DIR rf "no|noroeste" nw direcciones

#DIR fr "se|sudeste" se direcciones

#DIR pq "ne|noreste" ne direcciones

#DIR qp "sw|sudoeste" sw direcciones

#DIR vb "de|dentro" other direcciones

#DIR bv "fu|fuera" other direcciones

Sin embargo con esto no esta todo resuelto, ni mucho menos. Aun teniendo esto configurado, zmud seguira enviando «w» al pulsar «4», por tanto hay que configurar el keypad. Para ello creamos unos macros que suplanten a los por defecto. A modo de ejemplo:

#KEY ADD {ab} "keypad" {chain}

#KEY KEY0 {fu} "keypad" {chain}

#KEY KEY1 {so} "keypad" {chain}

#KEY KEY2 {s} "keypad" {chain}

#KEY KEY3 {se} "keypad" {chain}

#KEY KEY4 {o} "keypad" {chain}

#KEY KEY5 {de} "keypad" {chain}

#KEY KEY6 {e} "keypad" {chain}

#KEY KEY7 {no} "keypad" {chain}

#KEY KEY8 {n} "keypad" {chain}

#KEY KEY9 {ne} "keypad" {chain}

#KEY SUB {ar} "keypad" {chain}

Realmente solo son necesarios los de so,o,no,ar y ab (y de y fu para quien los quiera), pues para el resto valen los por defecto. Sin embargo los pongo todos pues la opcion chain que he marcado permite hacer otros macros como el siguiente:

#KEY ALT-SUB {"abrir "} "keypad" {append|nosend}

Este macro lo que hace es escribir en la linea de comandos «abrir » (sin comillas) y entonces, al presionar «4» (que es un macro daisy chain) envia al mud «abrir o». Esto puede ser util para cosas como galopar, etc… tal vez algun dia haga alguna especia de tutorial para ello.

Volviendo al tema, una vez tenemos las configuraciones como he ido explicando, ya podemos movernos con el keypad y tambien con el movimiento automatico del zmap. Ahora pueden pasar dos cosas:

• Tenemos un mapa ya hecho como el colgado en la web. Este mapa ya tendra una configuracion puesta, lo cual hace que, si esta es correcta, ya hayamos acabado. Si no lo es hay que reconfigurar, lo cual se consigue con menu config->reconfigure y siguiendo los mismos pasos que configurandolo por primera vez.
• Si no tenemos mapa y vamos a crearlo, damos al menu config->new configuration o simplemente damos al boton del modo «edit» y saltara el menu de configuracion

En la ventana de configuracion se nos pide darle una direccion (que por defecto sera «south») y un numero de segundos (que por defecto son 5). Cuando demos a siguiente zmud enviara esa salida al mud y esperara el numero de segundos indicado, tras lo cual interpretara el texto recibido definiendo automaticamente que es cada cosa (secciones de nombre, de salidas y de descripcion). Asi pues cambiamos el south por una salida que exista en nuestra room y le damos a siguiente. Pasados esos segundos zmud nos pide que marquemos si hemos recibido el nombre, la descripcion y las salidas. Marcamos las correspondientes y seguimos, viendo a la izquierda el texto recibido y coloreado en distintos colores cada zona reconocida.

Lo primero antes de comenzar a mapear (o reconfigurar) es pensar como queremos hacer el mapa. Normalmente no nos importara la descripcion, asi que si mapeamos con el consentir detallado a off nos ahorramos guardar en la base de datos del mapa la descripcion de las rooms y hacemos que sea mucho mas eficaz la autoconfiguracion.
Ademas hay algunas situaciones en las que la autoconfiguracion no es correcta. Por ejemplo, si al moverme me muevo a una room llamada «Pueblo de Aethia», posiblemente zmud interprete ese «de» como una salida, lo cual es obviamente incorrecto. Ante esto yo siempre he optado por la solucion sencilla que es ir a una room con nombre no conflictivo y activar ahi el autoconfigurador. Una vez se ha configurado el mapa, si se entra en la room conflictiva anterior, zmud seguira funcionando correctamente.
La configuracion puede hacerse a mano, pero no es algo recomendado. Sin embargo si queremos hacer una configuracion fina si deberemos entrar a ver la configuracion interna del mapa para, por ejemplo, cambiar el comando que zmud envia para abrir y cerrar puertas. Para ello vamos al menu edit (de la ventana del mapa, no de la ventana de juego) y luego map properties.
Una vez ahi tenemos multitud de cosas que poder configurar, pero me centrare en las mas utiles:

• La parte de apariencia y configuracion podeis/debeis dejarla como esta.
• En interface podeis activar la autocreacion de enlaces, algo util si vais a mapear. Para activarla debeis poner el autoconnect a all directions y deseleccionar «only autoconnect using keypad», pero dejad el de «only autoconnect stub exits».
• En «strings and doors» cambiar «open %1» por «abrir %1» y «unlock %1» por «descerrojar %1». Ademas es importante desactivar el «auto door creation», pue suele ser un incordio a la hora de mapear. El comando look tambien podeis cambiarlo, aunque no suele usarse
• En speedwalking podeis configurar algunas cosas a vuestro gusto, pero lo mas importante puede ser el «maximum steps in safe mode», que fijado a 40 o asi os permitira moveros por el mapa sin tener que os pase lo de «demasiados comandos, se ha ignorado X»
• Tanto map como zone script es algo que nunca he usado y vosotros no deberiais 😛