jaBote

Ahora mismo no estoy en mi ordenador, pero los permisos y comandos que puede un jugador ejecutar se asignan, en su mayoría, desde el propio servidor. Si no me equivoco, te interesa mirar el archivo conf/groups.conf. Desde puedes asignar permisos y comandos a grupos de jugadores, según su ID de grupo.

Si el servidor de juego es remoto, debes especificar su IP WAN en conf/map_athena.conf y conf/char_athena.conf Asegúrate. Es posible que me bailen un poco los nombres de los ficheros porque no estoy en mi ordenador para comprobarlo.

Que tenga entendido, no puedes personalizar la fórmula de la ASPD per se a menos que toques algo en el código fuente (/src/map/status.c, dentro de la función status_base_amotion_pc si no me equivoco), aunque puedes alterar la ASPD máxima de forma fácil a través de la configuración max_aspd y max_third_aspd, ambas en /conf/battle/player.conf, alrededor de la línea 64. Sobre el instacast ocurre algo similar. Dependiendo de si usas Renewal o Pre-Renewal debes ir a un sitio u otro. Para cambiar el instacast de Pre-Renewal y el cast variable de Renewal tienes, respectivamente, las configuraciones castrate_dex_scale y vcast_stat_scale en /conf/battle/skill.conf, alrededor de la línea 40; y para modificar el cast fijo tienes que acceder a la base de datos de cast en skills y eliminarlo uno a uno, en /db/re/skill_cast_db.txt. ¡Espero que te sirva de ayuda!

Lance NO sigue con ese proyecto. Puedes intentar SecureGRF (creo que en la sección descargas hay uno de ellos, yo no tengo ninguno), aunque no sé si encripta un GRF entero o solo algunos archivos...

¿Les tienes asignados trajes de GM en tu clientinfo.xml?

Te recomiendo que tengas un poco de experiencia en cuanto a jugador antes de dar el salto, si no muy probablemente casi todo te sonará a chino mandarín. Las configuraciones básicas que puedes tocar sin riesgo a cargarte nada (salvo cosas muy específicas) las tienes todas en la carpeta /conf. Para el resto de cosas, te recomiendo que vayas curioseando por el emulador. Son demasiadas como para nombrarlas todas y están un pelín dispersas por todas partes. Siempre tienes la carpeta /doc para tener conocimiento de las cosas más generales del emulador, y /db y /npc para probar a hacer algunas cosas. Es lo que tocarás con más frecuencia. Usarás /src muy poco, principalmente cuando aprendas a manejarte con lenguaje C, que es algo más complicado, o sigas alguna guía que contenga ediciones del código fuente. Una cosa sí es segura, y tómala como consejo: para aprender puedes "romper" tantas instalaciones de rAthena como te sea necesario siempre que sepas restablecerlo a un instante estable. No tengas miedo de equivocarte manipulando cosas si lo haces en tu servidor casero, así es como aprenderás mejor Ni tampoco tengas miedo de preguntar sobre características sueltas que no entiendas del todo. Es que hacer una guía con todas las características del emulador es muy complicado porque desde el primer emulador Athena hasta hoy han pasado muchos años (¡casi diez!) y muchas revisiones de código (incluso hay trozos de código que los desarrolladores actuales no tienen conocimiento de su razón de ser o su utilidad real). Por eso es mejor preguntar por algo concreto que en general. ¡Un saludo y suerte!

Esta es una de las medidas de seguridad "recientes" de los clientes. Ahora para borrar un personaje tienes que esperar un tiempo, en vez de borrarse desde el servidor en el acto. Que tenga entendido la espera es de un día y no tienes que hacer nada más por tu parte, aunque en ese plazo puedes recuperar a tu personaje si decides arrepentirte. Dicha fecha se da en formato americano, que es así: mm/dd - hh:mm:ss. Conforme a esa captura de pantalla, el personaje se borraría el 4 de octubre (mes 10) a las 23:54:47 (según el reloj del servidor), hora que, en el momento de publicación de este mensaje, aún no se ha cumplido en ninguna parte del mundo.

Por supuesto que puedes, aunque esta guía no te sirve de nada porque es para compilar en Linux. Es más, esta guía solo descarga e "instalar" (más bien poner en funcionamiento) rAthena, aunque te faltaría la esencial parte de las bases de datos y quizá un poco de preconfiguración. Para tener rAthena bajo Windows, solo necesitas obtener su código fuente y compilarlo con Microsoft Visual C++. Luego faltaría la parte de la base de datos y la preconfiguración, como dije. Es muy rápido y sencillo, aunque parece que rAthena no tiene guías al respecto. Para compilar en Windows simplemente abre MSVC++, selecciona los proyectos y dale a "Generar selección". P.D.: Ziu, por supuesto que se puede tener rAthena en Mac. Ind, el admin de Hercules y otros desarrolladores lo usan de forma primaria, luego depuran errores en Windows y Linux. Aquí la prueba gracias a Haruna: http://d.pr/i/vo1T (aunque se producen unos cuantos warnings al compilar rA en Mac).

Que tenga entendido, dejó de haber instaladores de RO hace mucho tiempo. Intenta ver si ejecutando el setup.exe oficial de Ragnarok Online se te soluciona: hay amigos míos que no podían ejecutarlo hasta que lanzaron el setup oficial y les funcionó. ¿Por qué?, no tengo ni idea.

Creo que MySQL Workbench no era tan sencillo de usar como PhpMyAdmin, aunque en situaciones es mucho mejor (por ejemplo para cargar los datos iniciales del servidor (PhpMyAdmin se satura con alguna de las tablas al ser éstas enormes. Aquí tienes un tutorial para crear una base de datos con MySQL Workbench. Simplemente hazlo casi de la misma forma que como si fuese la consola, aquí no hay botones ni accesos directos para crear bases de datos como sí ocurre en PMA, aunque el uso de uno u otro depende del gusto de las personas. Espero te sirva. Un saludo,

Complementando la respuesta de Ziu, puedes quitar el cast de renewal en src/config/renewal.h. Simplemente comenta la línea que define el cast de renewal (#DEFINE RENEWAL_CAST), en la línea 33 en la última revisión. Para comentar una línea simplemente coloca dos barras (//) al inicio de la línea y guarda el fichero. Es necesario volver a compilar el servidor para que funcionen los cambios que hagas en la carpeta src.

Realmente, M45T3R, yo jamás empezaría antes de tener una base de usuarios que se comprometan a ofrecer (al menos inicialmente) a entregar una estimación mínima de tiempo que puedan dedicar al proyecto, a menos que quieras arriesgarte a que 50 personas digan que quieren embarcarse en el proyecto y luego al final seáis 3 que luego abandonarán por falta de tiempo/compañía/ganas. Intenta disponer de al menos una dirección permanente de contacto (electrónica) de cualquier persona que se anime a ayudar antes que nada. Los scripts (que parece que serán el punto de comienzo de la traducción) en su mayoría son los mismos para ambos emuladores, por lo que de momento no hay que preocuparse de ello en demasía dado que la porción que habrá que adaptar será mínima. Tal como comenté antes, la mayor preocupación que se debe tener al comenzar una traducción es darle consistencia a la misma: hay que intentar que no se pueda diferenciar qué traductor ha traducido qué texto sino que todo parezca traducido de común acuerdo, o la diferencia sea mínima: que algunos scripts en un mismo contexto traten al usuario de tú, usted y vos (y también che, quillo, gachó y similares si alguien decide emplear vocativos de uso regional) es generalmente entendible para el lector, aunque un fallo grave de traducción. Antes de empezar, y para evitar caer en los mismos problemas que otras veces, reitero que lo mejor es exponer cuanto antes una serie de normas de obligatorio cumplimiento para las traducciones (incluyendo palabras que no se traduzcan o que se obliguen a traducir de una forma: como por ejemplo decir que guild -> gremio, nunca clan), así como nombrar a alguien que se dedique a revisar y tratar de normalizar en lo posible todos los textos. P.D.: Si tengo tiempo disponible y ganas, y además puedo observar un ambiente de trabajo correcto y suficientemente apropiado, no me importaría echar una mano en el proyecto de traducción de rAthena. Mi gran problema actual es el tiempo libre, que por desgracia no sobra, veré qué puedo hacer.

Realmente, si el problema no aparenta ser de cliente, lo mejor que podrías hacer para obtener soporte para items custom es publicar la entrada completa del objeto en db/item_db2.txt, así como cualquier posible error que aparezca a su lectura en la consola del map server si la hubiera. O probar a sobrescribir la ID de un objeto existente y probar suerte...

He tenido varias veces ese problema y lo resolví por azar sin saber muy bien lo que hice. ¿Prueba a poner en los bind_ip de la configuración de map y char server tu IP de Hamachi? Me suena a que era algo así, aunque estoy dando palos de ciego.

Whops, cierto Hideki. Sin el emulador a mano para mirar vivo en el pasado, y es que antes esa configuración estaba ahí (hace casi dos años de hecho ). Lo que tienes que hacer es dar un permiso, aunque el permiso que debes conceder es view_equipment (que permite al que posee el privilegio ver el equipo de los jugadores sea cual sea la configuración que tengan puesta para mostrarlos o no) en vez de all_equipment (que permite al que posee el privilegio equipar cualquier objeto sin ninguna restricción, salvo los posibles cierres de cliente inesperados que provoque usar un sprite inexistente). Mi compañero Hideki se ha confundido en cuanto al nombre, aunque el procedimiento es exactamente el mismo que él ha descrito. Si necesitas más ayuda sobre qué permisos asignar a cualquier grupo, puedes consultar el fichero de documentación destinado a tal efecto, en /doc/permissions.txt (en inglés). Es cuestión de gusto, aunque yo preferiría no hacer @reloadatcommand y simplemente reiniciar el servidor por motivos de seguridad (los comandos tipo @reloadloquesea nunca fueron pensados para ser usados en servidores abiertos al público y pueden contener alguna falla indetectada).

O para verlo de forma forzada sin importar que el usuario permita que veas su equipo, tienes que ser GM de como mínimo el parámetro destinado a tal efecto, que aparece en conf/battle/gm.conf Te diría el parámetro exacto pero no puedo mirártelo desde el teléfono móvil.

O también puedes desactivar por separado las mecánicas renewal en src/config/renewal.h Para desactivar alguna mecánica renewal en concreto solo debes comentar la definición en cuestión.

El lugar donde implementas un ACMD_FUNC en atcommand.c da realmente igual, siempre que no esté dentro de otro comando y se implemente después de la definición para dar a entender al compilador qué significa ACMD_FUNC realmente. Yo personalmente lo implementaría después del último comando, en estos momentos, suponiendo que tienes un rAthena actualizado lo haría después de langtype (o sea, después de la llave de cierre que termina el código de dicho comando). Luego el resto de la implementación del comando debería ser normal, aunque la definición del comando (eso de ACMD_DEF2), lo pondría al final de su respectiva lista también, esa en que están ACMD_DEF y ACMD_DEF2 juntos. Por cierto, dado que esta modificación de source ya tiene un tiempo cabe la posibilidad de que no funcione en una versión actual de rAthena, pero si realmente quieres implementarlo sí merece la pena intentarlo. Aunque en realidad no sea muy bueno con el source no veo ningún motivo por el que no debería funcionar.

Suponiendo que estés usando las bases de datos de mobs en texto, como suele ocurrir a menos que las cambies expresamente a yes el valor use_sql_db en inter_athena.conf (al final): La MDef de cada mob aparece en la decimocuarta posición de cada fila, dentro de db/re/mob_db.txt. Simplemente cambia su valor al que quieras, aunque deberás cambiar el valor de la MDef de cada mob uno a uno. En caso de que tengas las bases de datos en SQL, busca la mob_db entre las tablas SQL que debes tener en la base de datos de juego, (por defecto `ragnarok`). Espero haber sido de ayuda.

Hideki tiene razón: para mover un NPC por un mapa, lo que se suele hacer es en verdad crear varias instancias del mismo y para simular su movimiento lo que se hace es simplemente activar una copia y desactivar la otra rápidamente. Aún así, si realmente quieres mover el NPC a toda costa, puedes probar los siguientes script commands:

Tucsus, en tu script solo se comprueba que la party esté conformada por 4 integrantes. Te ha faltado la parte "difícil" que es comprobar los requisitos que pide Nanashi y requiere un poco de ciencia, que es lo que creo que realmente se le está dificultando a Nanashi. Este trozo de código, que no he probado ni tengo por el momento medio alguno para validarlo (por lo que puede tener errores), te puede solucionar el problema: set .@fail, 0; getpartymember getcharid(1),0; getpartymember getcharid(1),1; getpartymember getcharid(1),2; if ($@partymembercount == 4) { for (set .@i = 0; .@i < $@partymembercount; set .@i, .@i + 1){ if (!isloggedin($@partymemberaid[.@i], $@partymembercid[.@i]) || readparam(BaseLevel,$@partymembername$[.@i]) < 40) { set .@fail, 1; break; } } if (!.@fail) { // Aquí tu código una vez la party ha superado con éxito la comprobación. // Procura terminar el script al final de este bloque, también. } } // Aquí el código relativo al fracaso del cumplimiento de los requisitos en la comprobación de la party. En el ejemplo 2 de la descripción del comando getpartymember casi tenías la solución ya hecha . P.D.: Las malas costumbres, he escrito y redactado todo en inglés hasta que me he dado cuenta de que aquí puedo hablar en español .

Según la calculadora de iROWiki, para nivel máximo 160, si eres un 3rd class no renacido hay un total de 1273 puntos para repartir, mientras que si el personaje es renacido, éste tendrá un máximo de 1325. Es posible que estos cálculos no sean del todo correctos dado que rAthena trata de emular kRO, no iRO (servidor para el que está pensada la calculadora), aunque se conoce que iRO mantiene gran parte de las mecánicas y características de kRO.

De lo que tienes que asegurarte es de que el perímetro cierre para que no haya problemas. También te digo, yo haría un perímetro gordo por los que tienen esas malditas skills tipo backstab o high jump. Te darán problemas si su uso no está desactivado o no las tienes bajo control.

No es posible hacer un script fiable para eliminar el doble login cuando la mejor herramienta base que se tiene es la IP del usuario, dado que puedes exponerte a muchos falsos positivos.

Bueno, yo no sé hacerlo aunque sí hacer trucos baratos para que parezca que hay ese perímetro invisible usando varios NPC. Observemos script_commands.txt ¿Y cuál es la idea de esto? Muy sencilla: se trata de crear un NPC que tenga esa característica: poder ser tocado en una dirección. Por ejemplo, si queremos una "barrera" horizontal que al "tocarla" te haga warp a otro punto de un mapa cualquiera, habría que hacer un NPC con un triggerX de cuantas celdas se desee cubrir a izquierda y derecha del NPC en que cuando se ejecuta 'OnTouch:' ejecute el código correspondiente. Para una "barrera" puramente horizontal el triggerY debe ser 0 (eso creo, aunque si no funciona prueba con un valor de 1). En caso de querer una "barrera" vertical simplemente triggerX debe ser 0 (o uno, repito que no sé) y triggerY el valor que sea necesario. Como sé que la explicación no es del todo clara, este es un script de ejemplo sobre lo que me refiero: mapa,x,y,0 script barrera_horiz_1 -1,5,0,{ // El NPC es invisible, su orientación da igual. // Los dos valores después del sprite definen un área x,y centrada en el NPC. // En este ejemplo la "barrera" es horizontal y funciona en la coordenada del NPC, 5 celdas a su izquierda y 5 a su derecha. // Cuando "tocamos" al NPC la "barrera" activa el evento OnTouch en el jugador. // Para hacer una "barrera" vertical, simplemente hay que intercambiar los dos valores después del -1. Así nuestro NPC responderá a su celda, 5 celdas arriba y 5 abajo. OnTouch: warp "mapa_destino",x_destino,y_destino; end; } ¿He sido claro? Espero que sí