jaBote

Do you remember the many advantages Git has against Subversion (SVN)? One of those many advantages is the fact that in Git, you can send pull requests in order to directly collaborate with the community, without even the need of being an official Hercules dev, and if you contribute enough you can surely become a dev if you want. Well then, this is an – as detailed as possible – guide on how to make them.
 
First of all: What is a pull request? It's a way of telling the original devs of a (commonly open-sourced) project what changes you've made yourself on their project supposedly for the better, and kindly ask them (request) to merge it (pull). In short, it's a way of collaborating to a project without the need of being related at all to it. Obviously, your pull request may be rejected if it doesn't meet some requirements, but this is another story.
 
Git does also offer its own tools for pull requests (more info), but they're incompatible with the ones GitHub has. Moreover, GitHub pull request tools are easier to use than Git's.
 
What steps are required in order to do a pull request? In abstract, you'll have to:
Sign up for a GitHub account, if you don't have it already. Fork Hercules project in GitHub, if you haven't done this already. Clone your previous fork to a local repository in your computer, if you haven't done this already. Work on your fork. Commit your changes to your local repository. Push the changes you've previously committed to your remote repository on GitHub. Make the aforementioned pull request to the Hercules official repository. Steps 3 and 5 have already been shown on the Obtaining Hercules guide by @Ind (Obtaining Hercules through Git on *insert OS here* and Troubleshooting sections). These two steps will be slightly reviewed, but expect a fully detailed how-to in the others.
 
By the way, GitHub also has its own (generic) guides on how to fork a repo and then make a pull request, which also explain the toughest parts of this guide (though they're not so tough) and cover steps 2-6 (supposing you have a Git console). You're encouraged to go and read them if you want.
 
Well, here we go with the guide!
 
Step 1: Sign up for a GitHub account



Step 2: Fork Hercules project in GitHub



Steps 3 to 6: Local computer work



Step 7: (Finally) submitting the pull request


 
Congratulations! You have successfully made your first pull request on Hercules! This is a reason to be proud of yourself, isnt it?

¡Vaya! Parece que hay gente deseosa de colaborar directamente con Hercules pero que no sabe cómo. Me parece estupendo. Además, a petición de los administradores, esta guía también tendrá una versión en inglés porque nuestros compañeros anglosajones así lo necesitan.

¿Recuerdan cuando en mi guía de cómo obtener Hercules les comenté que una gran ventaja de usar Git frente a usar Subversion (SVN) es que existe la posibilidad de participar de forma activa en la comunidad enviando pull requests? Pues aquí les traigo una guía detallada para que puedan hacer cuantos pull request quieran sin problema.

Ante todo, ¿qué es un pull request? Se trata de un envío de un cambio o mejora de un determinado proyecto a los desarrolladores del mismo, junto a la petición (request) de tal forma que ellos mismos puedan determinar y valorar si es conveniente para el proyecto y "tirar" (pull) de dicho cambio para que aparezca en el repositorio, o simplemente declinar la petición.

Git ofrece sus propias herramientas para hacer pull requests (más información), pero no serán estas herramientas las que usaremos (porque tampoco son compatibles), sino las que nos ofrece GitHub, que sirven para algo parecido pero es más visual y puede hacerse también desde cualquier plataforma.

¿Qué pasos hay que realizar para hacer un pull request a Hercules? Pues, a grandes rasgos, son los siguientes:
[*]Registrar un usuario en GitHub, si aún no tienes. [*]Hacer un fork (una "bifurcación" en la línea de desarrollo: generalmente se hacen para contribuir al proyecto original o decidir tomarlo como base para un futuro proyecto) de Hercules en GitHub, si aún no la hiciste. [*]Clonar el nuevo repositorio en nuestra máquina, si aún no lo tienes (no sirve trabajar en el repositorio original de HerculesWS). [*]Trabajar en el nuevo repositorio local. [*]"Enviar" (Commit) los cambios a nuestro repositorio local en el fork. [*]"Empujar" (Push) los cambios recién enviados a nuestro repositorio remoto en GitHub. [*]Hacer el propio pull request al repositorio original de Hercules, desde la web de GitHub.

Los pasos 3 y 5 se han visto en mi anterior guía sobre la obtención de Hercules (el paso 5 en la sección Preguntas Frecuentes), y el resto de pasos son suficientemente sencillos aunque se detallará exhaustivamente su realización. Se juntarán algunos apartados de la guía bajo un mismo epígrafe (3, 4, 5 y 6) para trabajar más cómodamente.

GitHub también provee sus propias guías paso a paso (en inglés) para casos generales sobre cómo hacer un fork y posteriormente hacer un pull request, aunque en la presente guía nos centraremos en hacer todo paso a paso para poder hacer pull requests a Hercules.

Para esta guía se usará la interfaz de TortoiseGit en inglés. Ya comenté en mi anterior guía lo poco adecuada que era la traducción de la interfaz al español, y además podré reutilizar las imágenes para la traducción de la presente guía al idioma anglosajón.

Bueno, comencemos ya con la propia guía. He decidido cubrir con spoilers cada paso de la guía, dado que además de su explicación vienen con sus buenas imágenes informativas.

Paso 1: Registrar un usuario en GitHub



Paso 2: Hacer un fork de Hercules



Pasos 3 a 6: Trabajo en la máquina local



Paso 7: Hacer (por fin) el pull request


 
 
Y ya está. No es tan complicado todo, ¿verdad? Esta pregunta parece irónica, pero es un proceso realmente simple. Una vez hayas hecho un par de pull requests verás que es un proceso increíblemente simple.

Preguntas frecuentes:

He colocado la sección en otro post para facilitar su redacción y búsqueda.

Aunque espero que no haya prácticamente ninguna pregunta en esta sección porque me gustaría creer que he sido suficientemente claro, es obvio que las cosas no son así y es normal "atascarse" en alguna parte de la guía, inauguro esta sección. Como es usual en estas secciones de Preguntas y Respuestas, las preguntas las marcaré con una P y las respuestas las marcaré con una R, ambas bien grandes para que se vean en condiciones.

Lista de preguntas:
 
Preguntas y respuestas:

P: No puedo hacer Pull Request en Github y me sale un mensaje de advertencia. ¿Qué ocurre?
R: Vaya. Estos mensajes de advertencia siempre salen por algún motivo. No puedes hacer pull request mientras alguna advertencia esté activa. No soy un maestro en estos problemas, aunque generalmente los mensajes dan suficiente información en inglés. Estos son los mensajes de advertencia que me han llegado a salir a mí y las posibles soluciones de que dispongo. Recordad que en cualquier caso deberéis cambiar HerculesUser por vuestro nombre de usuario:
[*] Oops! HerculesWS:master  is already up-to-date with HerculesUser:master  Try a different branch? [*]Has intentado hacer pull request sin haber hecho algún cambio frente al repositorio original en tu fork. Asegúrate de haber hecho push (con al menos algo de contenido) correctamente a tu repositorio en GitHub.
[*]Oops! There's already a pull request for HerculesUser:master Try a different branch or view the pull request?
[*]Ya tienes un pull request activo en el proyecto al que intentas contribuir. Espera a que sea aceptado o rechazado, o si quieres añadir más cosas mientras dicho pull request está activo siempre puedes cancelar la petición, añadir tu nuevo trabajo y volver a hacer pull request.



P: ¿Cómo actualizo mi fork a la última versión de Hercules?
R: Es bastante sencillo, aunque menos directo que actualizar una versión de Hercules directamente obtenida del repositorio original. Como siempre, para esto es necesario hacer distinción de cómo se haría en cada sistema operativo:
Para Windows: (No veo necesaria una imagen a menos que mucha gente se atasque aquí)Haz click derecho en la carpeta de tu fork de Hercules y selecciona la opción Fetch... (Recuperar... en la interfaz española) dentro del menú desplegable que aparece al mantener el puntero del ratón unos instantes sobre la opción TortoiseGit. Se abrirá una nueva ventana. En esa ventana debemos escoger la opción que nos permite indicar una URL arbitraria (Arbitrary URL) y en el campo de texto asociado, colocar la URL del repositorio original de Hercules, o sea, esta: https://github.com/HerculesWS/Hercules.git. Posteriormente hacemos click en OK (a menos que quieras cambiar alguna de las opciones disponibles, que no es frecuente) para que empiece la actualización. Se abrirá una ventana en la que empezará la actualización de tu fork. Ciérrala una vez hayas acabado.
[*]Para sistemas Unix: Como siempre, se trata simplemente de ejecutar un único comando (aunque esta vez son dos comandos unidos en una misma orden de shell):
git fetch upstream && git merge upstream/master  


Simplemente recuerda que para que esta actualización también se refleje en tu repositorio hospedado en GitHub has de hacer push. En caso contrario solo se reflejará en el repositorio local.
 
P: Al intentar hacer push me sale un error aunque ponga las credenciales correctas. ¿Qué ocurre?
R: A mí hasta ahora solo me ha ocurrido este error cuando por accidente intenté hacer push en la carpeta que tenía del repositorio original de Hercules, sobre el que no tengo permisos de escritura. Asegúrate de que estás haciendo push al repositorio de tu fork de Hercules y no al original: si no jamás lograrás hacerlo con éxito.
 
¡Ah, por cierto! Aunque esto es de sentido común, para hacer push y actualizar tu repositorio hospedado en GitHub es obligatorio disponer de conexión a Internet en el momento en que se intente efectuar.
 
P: No puedo hacer commit a mi repositorio local. ¿Qué ocurre?
R: Lo más seguro es que intentes hacer un commit a tu repositorio local sin haber modificado ningún archivo. No es posible hacer commits vacíos, así que el fallo estará por alguna otra parte. ¿Quizá modificaste los archivos a los que fueras a hacer commit pero se te olvidó guardarlos?
 

Do you remember the many advantages Git has against Subversion (SVN)? One of those many advantages is the fact that in Git, you can send pull requests in order to directly collaborate with the community, without even the need of being an official Hercules dev, and if you contribute enough you can surely become a dev if you want. Well then, this is an – as detailed as possible – guide on how to make them.
 
First of all: What is a pull request? It's a way of telling the original devs of a (commonly open-sourced) project what changes you've made yourself on their project supposedly for the better, and kindly ask them (request) to merge it (pull). In short, it's a way of collaborating to a project without the need of being related at all to it. Obviously, your pull request may be rejected if it doesn't meet some requirements, but this is another story.
 
Git does also offer its own tools for pull requests (more info), but they're incompatible with the ones GitHub has. Moreover, GitHub pull request tools are easier to use than Git's.
 
What steps are required in order to do a pull request? In abstract, you'll have to:
Sign up for a GitHub account, if you don't have it already. Fork Hercules project in GitHub, if you haven't done this already. Clone your previous fork to a local repository in your computer, if you haven't done this already. Work on your fork. Commit your changes to your local repository. Push the changes you've previously committed to your remote repository on GitHub. Make the aforementioned pull request to the Hercules official repository. Steps 3 and 5 have already been shown on the Obtaining Hercules guide by @Ind (Obtaining Hercules through Git on *insert OS here* and Troubleshooting sections). These two steps will be slightly reviewed, but expect a fully detailed how-to in the others.
 
By the way, GitHub also has its own (generic) guides on how to fork a repo and then make a pull request, which also explain the toughest parts of this guide (though they're not so tough) and cover steps 2-6 (supposing you have a Git console). You're encouraged to go and read them if you want.
 
Well, here we go with the guide!
 
Step 1: Sign up for a GitHub account



Step 2: Fork Hercules project in GitHub



Steps 3 to 6: Local computer work



Step 7: (Finally) submitting the pull request


 
Congratulations! You have successfully made your first pull request on Hercules! This is a reason to be proud of yourself, isnt it?

¡Vaya! Parece que hay gente deseosa de colaborar directamente con Hercules pero que no sabe cómo. Me parece estupendo. Además, a petición de los administradores, esta guía también tendrá una versión en inglés porque nuestros compañeros anglosajones así lo necesitan.

¿Recuerdan cuando en mi guía de cómo obtener Hercules les comenté que una gran ventaja de usar Git frente a usar Subversion (SVN) es que existe la posibilidad de participar de forma activa en la comunidad enviando pull requests? Pues aquí les traigo una guía detallada para que puedan hacer cuantos pull request quieran sin problema.

Ante todo, ¿qué es un pull request? Se trata de un envío de un cambio o mejora de un determinado proyecto a los desarrolladores del mismo, junto a la petición (request) de tal forma que ellos mismos puedan determinar y valorar si es conveniente para el proyecto y "tirar" (pull) de dicho cambio para que aparezca en el repositorio, o simplemente declinar la petición.

Git ofrece sus propias herramientas para hacer pull requests (más información), pero no serán estas herramientas las que usaremos (porque tampoco son compatibles), sino las que nos ofrece GitHub, que sirven para algo parecido pero es más visual y puede hacerse también desde cualquier plataforma.

¿Qué pasos hay que realizar para hacer un pull request a Hercules? Pues, a grandes rasgos, son los siguientes:
[*]Registrar un usuario en GitHub, si aún no tienes. [*]Hacer un fork (una "bifurcación" en la línea de desarrollo: generalmente se hacen para contribuir al proyecto original o decidir tomarlo como base para un futuro proyecto) de Hercules en GitHub, si aún no la hiciste. [*]Clonar el nuevo repositorio en nuestra máquina, si aún no lo tienes (no sirve trabajar en el repositorio original de HerculesWS). [*]Trabajar en el nuevo repositorio local. [*]"Enviar" (Commit) los cambios a nuestro repositorio local en el fork. [*]"Empujar" (Push) los cambios recién enviados a nuestro repositorio remoto en GitHub. [*]Hacer el propio pull request al repositorio original de Hercules, desde la web de GitHub.

Los pasos 3 y 5 se han visto en mi anterior guía sobre la obtención de Hercules (el paso 5 en la sección Preguntas Frecuentes), y el resto de pasos son suficientemente sencillos aunque se detallará exhaustivamente su realización. Se juntarán algunos apartados de la guía bajo un mismo epígrafe (3, 4, 5 y 6) para trabajar más cómodamente.

GitHub también provee sus propias guías paso a paso (en inglés) para casos generales sobre cómo hacer un fork y posteriormente hacer un pull request, aunque en la presente guía nos centraremos en hacer todo paso a paso para poder hacer pull requests a Hercules.

Para esta guía se usará la interfaz de TortoiseGit en inglés. Ya comenté en mi anterior guía lo poco adecuada que era la traducción de la interfaz al español, y además podré reutilizar las imágenes para la traducción de la presente guía al idioma anglosajón.

Bueno, comencemos ya con la propia guía. He decidido cubrir con spoilers cada paso de la guía, dado que además de su explicación vienen con sus buenas imágenes informativas.

Paso 1: Registrar un usuario en GitHub



Paso 2: Hacer un fork de Hercules



Pasos 3 a 6: Trabajo en la máquina local



Paso 7: Hacer (por fin) el pull request


 
 
Y ya está. No es tan complicado todo, ¿verdad? Esta pregunta parece irónica, pero es un proceso realmente simple. Una vez hayas hecho un par de pull requests verás que es un proceso increíblemente simple.

Preguntas frecuentes:

He colocado la sección en otro post para facilitar su redacción y búsqueda.

Aunque espero que no haya prácticamente ninguna pregunta en esta sección porque me gustaría creer que he sido suficientemente claro, es obvio que las cosas no son así y es normal "atascarse" en alguna parte de la guía, inauguro esta sección. Como es usual en estas secciones de Preguntas y Respuestas, las preguntas las marcaré con una P y las respuestas las marcaré con una R, ambas bien grandes para que se vean en condiciones.

Lista de preguntas:
 
Preguntas y respuestas:

P: No puedo hacer Pull Request en Github y me sale un mensaje de advertencia. ¿Qué ocurre?
R: Vaya. Estos mensajes de advertencia siempre salen por algún motivo. No puedes hacer pull request mientras alguna advertencia esté activa. No soy un maestro en estos problemas, aunque generalmente los mensajes dan suficiente información en inglés. Estos son los mensajes de advertencia que me han llegado a salir a mí y las posibles soluciones de que dispongo. Recordad que en cualquier caso deberéis cambiar HerculesUser por vuestro nombre de usuario:
[*] Oops! HerculesWS:master  is already up-to-date with HerculesUser:master  Try a different branch? [*]Has intentado hacer pull request sin haber hecho algún cambio frente al repositorio original en tu fork. Asegúrate de haber hecho push (con al menos algo de contenido) correctamente a tu repositorio en GitHub.
[*]Oops! There's already a pull request for HerculesUser:master Try a different branch or view the pull request?
[*]Ya tienes un pull request activo en el proyecto al que intentas contribuir. Espera a que sea aceptado o rechazado, o si quieres añadir más cosas mientras dicho pull request está activo siempre puedes cancelar la petición, añadir tu nuevo trabajo y volver a hacer pull request.



P: ¿Cómo actualizo mi fork a la última versión de Hercules?
R: Es bastante sencillo, aunque menos directo que actualizar una versión de Hercules directamente obtenida del repositorio original. Como siempre, para esto es necesario hacer distinción de cómo se haría en cada sistema operativo:
Para Windows: (No veo necesaria una imagen a menos que mucha gente se atasque aquí)Haz click derecho en la carpeta de tu fork de Hercules y selecciona la opción Fetch... (Recuperar... en la interfaz española) dentro del menú desplegable que aparece al mantener el puntero del ratón unos instantes sobre la opción TortoiseGit. Se abrirá una nueva ventana. En esa ventana debemos escoger la opción que nos permite indicar una URL arbitraria (Arbitrary URL) y en el campo de texto asociado, colocar la URL del repositorio original de Hercules, o sea, esta: https://github.com/HerculesWS/Hercules.git. Posteriormente hacemos click en OK (a menos que quieras cambiar alguna de las opciones disponibles, que no es frecuente) para que empiece la actualización. Se abrirá una ventana en la que empezará la actualización de tu fork. Ciérrala una vez hayas acabado.
[*]Para sistemas Unix: Como siempre, se trata simplemente de ejecutar un único comando (aunque esta vez son dos comandos unidos en una misma orden de shell):
git fetch upstream && git merge upstream/master  


Simplemente recuerda que para que esta actualización también se refleje en tu repositorio hospedado en GitHub has de hacer push. En caso contrario solo se reflejará en el repositorio local.
 
P: Al intentar hacer push me sale un error aunque ponga las credenciales correctas. ¿Qué ocurre?
R: A mí hasta ahora solo me ha ocurrido este error cuando por accidente intenté hacer push en la carpeta que tenía del repositorio original de Hercules, sobre el que no tengo permisos de escritura. Asegúrate de que estás haciendo push al repositorio de tu fork de Hercules y no al original: si no jamás lograrás hacerlo con éxito.
 
¡Ah, por cierto! Aunque esto es de sentido común, para hacer push y actualizar tu repositorio hospedado en GitHub es obligatorio disponer de conexión a Internet en el momento en que se intente efectuar.
 
P: No puedo hacer commit a mi repositorio local. ¿Qué ocurre?
R: Lo más seguro es que intentes hacer un commit a tu repositorio local sin haber modificado ningún archivo. No es posible hacer commits vacíos, así que el fallo estará por alguna otra parte. ¿Quizá modificaste los archivos a los que fueras a hacer commit pero se te olvidó guardarlos?
 

¡Vaya! Parece que hay gente deseosa de colaborar directamente con Hercules pero que no sabe cómo. Me parece estupendo. Además, a petición de los administradores, esta guía también tendrá una versión en inglés porque nuestros compañeros anglosajones así lo necesitan.

¿Recuerdan cuando en mi guía de cómo obtener Hercules les comenté que una gran ventaja de usar Git frente a usar Subversion (SVN) es que existe la posibilidad de participar de forma activa en la comunidad enviando pull requests? Pues aquí les traigo una guía detallada para que puedan hacer cuantos pull request quieran sin problema.

Ante todo, ¿qué es un pull request? Se trata de un envío de un cambio o mejora de un determinado proyecto a los desarrolladores del mismo, junto a la petición (request) de tal forma que ellos mismos puedan determinar y valorar si es conveniente para el proyecto y "tirar" (pull) de dicho cambio para que aparezca en el repositorio, o simplemente declinar la petición.

Git ofrece sus propias herramientas para hacer pull requests (más información), pero no serán estas herramientas las que usaremos (porque tampoco son compatibles), sino las que nos ofrece GitHub, que sirven para algo parecido pero es más visual y puede hacerse también desde cualquier plataforma.

¿Qué pasos hay que realizar para hacer un pull request a Hercules? Pues, a grandes rasgos, son los siguientes:
[*]Registrar un usuario en GitHub, si aún no tienes. [*]Hacer un fork (una "bifurcación" en la línea de desarrollo: generalmente se hacen para contribuir al proyecto original o decidir tomarlo como base para un futuro proyecto) de Hercules en GitHub, si aún no la hiciste. [*]Clonar el nuevo repositorio en nuestra máquina, si aún no lo tienes (no sirve trabajar en el repositorio original de HerculesWS). [*]Trabajar en el nuevo repositorio local. [*]"Enviar" (Commit) los cambios a nuestro repositorio local en el fork. [*]"Empujar" (Push) los cambios recién enviados a nuestro repositorio remoto en GitHub. [*]Hacer el propio pull request al repositorio original de Hercules, desde la web de GitHub.

Los pasos 3 y 5 se han visto en mi anterior guía sobre la obtención de Hercules (el paso 5 en la sección Preguntas Frecuentes), y el resto de pasos son suficientemente sencillos aunque se detallará exhaustivamente su realización. Se juntarán algunos apartados de la guía bajo un mismo epígrafe (3, 4, 5 y 6) para trabajar más cómodamente.

GitHub también provee sus propias guías paso a paso (en inglés) para casos generales sobre cómo hacer un fork y posteriormente hacer un pull request, aunque en la presente guía nos centraremos en hacer todo paso a paso para poder hacer pull requests a Hercules.

Para esta guía se usará la interfaz de TortoiseGit en inglés. Ya comenté en mi anterior guía lo poco adecuada que era la traducción de la interfaz al español, y además podré reutilizar las imágenes para la traducción de la presente guía al idioma anglosajón.

Bueno, comencemos ya con la propia guía. He decidido cubrir con spoilers cada paso de la guía, dado que además de su explicación vienen con sus buenas imágenes informativas.

Paso 1: Registrar un usuario en GitHub



Paso 2: Hacer un fork de Hercules



Pasos 3 a 6: Trabajo en la máquina local



Paso 7: Hacer (por fin) el pull request


 
 
Y ya está. No es tan complicado todo, ¿verdad? Esta pregunta parece irónica, pero es un proceso realmente simple. Una vez hayas hecho un par de pull requests verás que es un proceso increíblemente simple.

Hercules Console Input Update
Hello~! What?
Yet another super-mega-special update brought to you by Hercules Sometime ago we re-introduced "Console Input", and then I mentioned about changing the syntax (which was horrible), well thats what this is about. Changes
Console Commands now make full use of the Hercules Renewal Phase One, there are global commands and there are per-server commands The new commands
server server malloc_usage displays total memory (in MB) being used by the server's memory manager server ers_report displays the ERS (entry-reuse-system) report server exit shuts down the server (equivalent to @mapexit) server plugins lists all plugins being used by the server help lists all available commands and their subcommands, this is a special command and you can use it after a command section to list its specific subcommands e.g. "server help" Map-Server specific gm gm info changes the console's virtual character position (this data is used by @commands), e.g. "gm info 150 150 prontera" gm use uses a command in the game server, e.g. "gm use @broadcast HERCULES IS AWESOME" or "gm use #heal player" Hercules Plugin Mananger
This update also makes console commands "HPM-FRIENDLY", it is incredibly easy to add new console commands, example: // Copyright (c) Hercules Dev Team, licensed under GNU GPL. // See the LICENSE file // Sample Hercules Plugin CPCMD(sample) {     ShowInfo("Hercules is awesome!n"); } CPCMD(sample2) {     ShowInfo("Hercules is incredible!n"); } CPCMD(sample2) {     ShowInfo("Hercules is efficient!n"); } HPExport void plugin_init (void) {     HPMi->addCPCommand("hercules:is:awesome",CPCMD_A(sample));     HPMi->addCPCommand("hercules:is:incredible",CPCMD_A(sample2));     HPMi->addCPCommand("hercules:is:efficient",CPCMD_A(sample3)); }The above creates 3 commands "hercules is awesome","hercules is incredible" and "hercules is efficient", you can do pretty much anything you want with them, it also makes use of the "help" key, for example "hercules help" or "hercules is help" will output all its respective subcommands. Links
Hercules Plugin Mananger Commit

Introducing Hercules Plugin Manager
Hello~! What?!
I can't express how awesome this is. It's awesome, so awesome. ...Incredibly awesome, yet another awesome feature brought to you by Hercules Thoughtfully Designed
This features' design began long ago, a precursor to this feature, which demonstrates for how long we've been planning it, is the Hercules Renewal Phase One Usage Example
Can be used to create @commands Can be used to create script commands Can be used to create console commands Can be used to replace core functions with your ownA example of how handy this can be: when any RO emu updates a section of the code that is used by a user's modifications, e.g. Harmony, no matter how silly the edit is (e.g. a tab alignment update) the user has to wait for his modification's developer to update his patch (unless he manages to update it on his own), if the developer in question starts to use the HPM for his hercules users instead of a patch file, his users using hercules will no longer have to wait for updates unless the way the code works changes on hercules' end. All About It - Documentation
Its being done, most of it is already available in our wiki Hercules Plugin Mananger Building HPM Plugin for MSVC Building HPM Plugin for GCC Links~!
Hercules Console Input Update (HPM Friendly) Commit Visual Studio 2010 2 Notes
The plugin "sample" is currently missing projects for msvc2010 and msvc2012, thats because I dont have them, this will be solved asap, once one of our developers who possesses them logs in. Login/Char server plugin support is currently disabled, it should be enabled by the next release, which will also include Hooks support (as an alternative to overloading)

¡Hola! En esta guía vamos a tratar de forma rápida una pregunta muy frecuente: cómo activar y desactivar Renewal, y ligeramente se tratarán otras configuraciones más o menos igual de "ocultas" que funcionan de forma similar. No se entrará en el detalle de para qué sirve cada configuración: solo se indicará el camino y deberá ser el lector quien se enfrente a ellas, en inglés. Su lectura es recomendada a quien ignore la existencia de estas configuraciones, aunque no pretenda desactivar Renewal.

Una vez se ha obtenido Hercules y antes de su compilación y puesta en marcha (guía aún en proyecto y redacción), es posible tocar unas configuraciones que no están tan a la vista que las de la carpeta /conf (donde están todas las configuraciones normales) pero que sí afectan al resultado de la compilación (es decir, para alterarlas efectivamente es necesario recompilar el emulador): se trata de la carpeta /src/config.

¿Qué hay en la carpeta /src/config que la hace tan importante? Pues, a fecha de publicación de la presente guía, esto:
 

 
Todos los ficheros de esta carpeta contienen configuraciones importantes, salvo por el momento const.h. Todos siguen una estructura parecida: al abrirlo se ven mucho texto y algunas sentencias que empiezan por #, que de forma sencilla podría decirse que son órdenes para el compilador, que no forman parte del programa final. Nos interesan especialmente los #define (definiciones), pero no debemos tocar nada en las primeras (por el momento 5) líneas, ni el #endif del final al ser definiciones de control imprescindibles.
 
Centrémonos en el fichero renewal.h, que es el principal de la guía. Este fichero contiene las siguientes definiciones, y cada una de ellas maneja algún tipo de mecánica Renewal (todas juntas para ahorrar espacio):
#define RENEWAL#define RENEWAL_CAST#define RENEWAL_DROP#define RENEWAL_EXP#define RENEWAL_LVDMG#define RENEWAL_EDP#define RENEWAL_ASPD ¿Cómo desactivarlas? Muy sencillo: se desactivan una a una anteponiendo una doble barra (//) delante de cada definición. A la doble barra, en el lenguaje del código fuente de Hércules © se le llama comentario de línea, y lo que hace el compilador es ignorar todo lo que esté en la misma línea a su derecha. O sea, si queremos eliminar todo rastro de Renewal de nuestro servidor tenemos que comentar (hacer comentario) todos esos #define, de tal forma que queden tal que así:
//#define RENEWAL//#define RENEWAL_CAST//#define RENEWAL_DROP//#define RENEWAL_EXP//#define RENEWAL_LVDMG//#define RENEWAL_EDP//#define RENEWAL_ASPD Así pues, al (re)compilar nuestro servidor Hercules, éste será totalmente pre-renewal pero dispondrá de todas las características únicas de Hercules.
 
¿Hay más que hacer? Pues no con renewal.h, pero sí se recomienda revisar cualquier configuración contenida en esta carpeta. Además del tipo de #define arriba descrito hay otros dos tipos:
Unos que vienen comentados pero puedes descomentar si quieres: siguen el mismo procedimiento que el ya descrito, pero a la inversa. Unos que van acompañados de un espacio y posteriormente un número (o una constante, que en este caso también actúa como un número): Si te interesa, puedes cambiarle el número con el que vienen acompañados (¡Importante: estos #define no debes comentarlos!). Es posible que te indiquen los valores posibles, como la única configuración actualmente disponible en /classes/general.h o te permitan elegir un valor numérico a tu gusto. Se recomienda no usar 0 salvo que se indique expresamente como valor posible (como el ejemplo anterior en /classes/general.h), porque no significará "ilimitado" como alguien puede estar acostumbrado a que así sea en otras configuraciones, sino que es literalmente 0(*). Ejemplo de este tipo de #define es el ya mencionado en /classes/general.h o este, situado en core.h:/// Max number of items on @autolootid list#define AUTOLOOTITEM_SIZE 10(*) No estoy seguro, pero todo indica a ello. Igualmente no deberíais ni probar a hacerlo, ya que es potencialmente peligroso para el servidor que dicho ajuste no funcione bien.

Si queréis profundizar más en qué son y para qué sirven estas órdenes que se dan al compilador, estas que empiezan por #, podéis visitar este enlace en la Wikipedia que os proveerá de información completa sobre ello (se recomienda leer como mucho hasta el apartado 3, sin comenzar el 3.1)
 
Por último, no te olvides de que después de modificar cualquiera estas configuraciones, es necesario (re)compilar el servidor para que los cambios surtan efecto. Eso es todo.

Preguntas frecuentes:
He colocado la sección en otro post para facilitar su búsqueda y escritura.

Aunque espero que no haya prácticamente ninguna pregunta en esta sección porque me gustaría creer que he sido suficientemente claro, es obvio que las cosas no son así y es normal "atascarse" en alguna parte de la guía, inauguro esta sección. Como es usual en estas secciones de Preguntas y Respuestas, las preguntas las marcaré con una P y las respuestas las marcaré con una R, ambas bien grandes para que se vean en condiciones.

Lista de preguntas:
 
Preguntas y respuestas:

P: ¿Puedo desactivar todas las mecánicas Renewal pero usar NPCs y bases de datos Renewal y viceversa?
R: Hay un pequeño truco para ello. Siempre se leen las carpetas /db y /npc, y además si Renewal está activo (#define RENEWAL) se leen las carpetas /db/re y /npc/re, en lugar de /db/pre-re y /npc/pre-re; mientras que si no lo está se leen las carpetas con nombre de pre-re en lugar de las re. Si quieres que se lean las otras carpetas que originalmente no correspondería, simplemente puedes intercambiarles el nombre, o intercambiar los valores de la definición #define DBPATH de const.h. Cuidado con la anterior definición porque es algo distinta a las vistas en el post principal de la guía, aunque no deberá daros mucho problema. Eso sí, mucho ojo: el juego no está preparado para trabajar con unas bases de datos y unos NPCs que no les corresponde y puede haber enormes fallos de equilibrio en el servidor.

P: ¿Por qué al desactivar Renewal sigue habiendo 3rd Jobs?
R: Al desactivar Renewal solo se desactivan las mecánicas, las bases de datos y los NPCs de Renewal (lo cual incluye las quests de Renewal, a menos que cambies los NPCs como se indica en la pregunta de arriba). De esta forma se hace imposible cambiar a Third Job a menos que se ejecute @job o haya algún NPC custom que cambie el job a uno de los 3rd Jobs. Ten cuidado al usar el NPC jobmaster que viene con Hercules, pues por defecto admite el cambio a 3rd Job:
 
npc/custom/jobmaster.txt, línea 184 (observad mi comentario)
OnInit:setarray .Rebirth[0],99,50; // Minimum base level, job level to rebirth OR change to third classsetarray .JobReq[0],10,40; // Minimum job level to turn into 1st class, 2nd classset .ThirdClass,1; // Enable third classes? (1: yes / 0: no) ¡Cambiad esto a 0 si pensáis usarlo y no queréis 3rd Jobs!set .SNovice,45; // Minimum base level to turn into Super Noviceset .LastJob,1; // Enforce linear class changes? (1: yes / 0: no)set .SkillPointCheck,1; // Force player to use up all skill points? (1: yes / 0: no)set .Platinum,1; // Get platinum skills automatically? (1: yes / 0: no)end;  
P: ¿Por qué tras cambiar una de estas configuraciones no noto ningún cambio?
R: Ya se ha comentado por lo menos tres veces en la presente guía: para que estos cambios surtan efecto, es obligatorio y necesario recompilar el emulador. De no hacerlo, no habrá ningún cambio en él hasta que se recompile.

Well, Inkfish originally worked in Athena projects but this is the same as what happened to eAmod about a year ago.
 
You can freely modify the emulator and charge whatever you want for it, but you can't re-release the software under more restrictive license the original software has. So as long as the GPL license is intact and he doesn't threat people without a "legal" copy of his software as eAmod owner did (under GPL licenses it's legally impossible to pirate a software) it's completely legal.
 
But if any customer pays for the modification then decides to redistribute it for free, he's in the absolute right to do so.

Preguntas frecuentes:
He colocado la sección en otro post para facilitar su búsqueda y escritura.

Aunque espero que no haya prácticamente ninguna pregunta en esta sección porque me gustaría creer que he sido suficientemente claro, es obvio que las cosas no son así y es normal "atascarse" en alguna parte de la guía, inauguro esta sección. Como es usual en estas secciones de Preguntas y Respuestas, las preguntas las marcaré con una P y las respuestas las marcaré con una R, ambas bien grandes para que se vean en condiciones.

Lista de preguntas:
 
Preguntas y respuestas:

P: ¿Puedo desactivar todas las mecánicas Renewal pero usar NPCs y bases de datos Renewal y viceversa?
R: Hay un pequeño truco para ello. Siempre se leen las carpetas /db y /npc, y además si Renewal está activo (#define RENEWAL) se leen las carpetas /db/re y /npc/re, en lugar de /db/pre-re y /npc/pre-re; mientras que si no lo está se leen las carpetas con nombre de pre-re en lugar de las re. Si quieres que se lean las otras carpetas que originalmente no correspondería, simplemente puedes intercambiarles el nombre, o intercambiar los valores de la definición #define DBPATH de const.h. Cuidado con la anterior definición porque es algo distinta a las vistas en el post principal de la guía, aunque no deberá daros mucho problema. Eso sí, mucho ojo: el juego no está preparado para trabajar con unas bases de datos y unos NPCs que no les corresponde y puede haber enormes fallos de equilibrio en el servidor.

P: ¿Por qué al desactivar Renewal sigue habiendo 3rd Jobs?
R: Al desactivar Renewal solo se desactivan las mecánicas, las bases de datos y los NPCs de Renewal (lo cual incluye las quests de Renewal, a menos que cambies los NPCs como se indica en la pregunta de arriba). De esta forma se hace imposible cambiar a Third Job a menos que se ejecute @job o haya algún NPC custom que cambie el job a uno de los 3rd Jobs. Ten cuidado al usar el NPC jobmaster que viene con Hercules, pues por defecto admite el cambio a 3rd Job:
 
npc/custom/jobmaster.txt, línea 184 (observad mi comentario)
OnInit:setarray .Rebirth[0],99,50; // Minimum base level, job level to rebirth OR change to third classsetarray .JobReq[0],10,40; // Minimum job level to turn into 1st class, 2nd classset .ThirdClass,1; // Enable third classes? (1: yes / 0: no) ¡Cambiad esto a 0 si pensáis usarlo y no queréis 3rd Jobs!set .SNovice,45; // Minimum base level to turn into Super Noviceset .LastJob,1; // Enforce linear class changes? (1: yes / 0: no)set .SkillPointCheck,1; // Force player to use up all skill points? (1: yes / 0: no)set .Platinum,1; // Get platinum skills automatically? (1: yes / 0: no)end;  
P: ¿Por qué tras cambiar una de estas configuraciones no noto ningún cambio?
R: Ya se ha comentado por lo menos tres veces en la presente guía: para que estos cambios surtan efecto, es obligatorio y necesario recompilar el emulador. De no hacerlo, no habrá ningún cambio en él hasta que se recompile.

¡Hola! En esta guía vamos a tratar de forma rápida una pregunta muy frecuente: cómo activar y desactivar Renewal, y ligeramente se tratarán otras configuraciones más o menos igual de "ocultas" que funcionan de forma similar. No se entrará en el detalle de para qué sirve cada configuración: solo se indicará el camino y deberá ser el lector quien se enfrente a ellas, en inglés. Su lectura es recomendada a quien ignore la existencia de estas configuraciones, aunque no pretenda desactivar Renewal.

Una vez se ha obtenido Hercules y antes de su compilación y puesta en marcha (guía aún en proyecto y redacción), es posible tocar unas configuraciones que no están tan a la vista que las de la carpeta /conf (donde están todas las configuraciones normales) pero que sí afectan al resultado de la compilación (es decir, para alterarlas efectivamente es necesario recompilar el emulador): se trata de la carpeta /src/config.

¿Qué hay en la carpeta /src/config que la hace tan importante? Pues, a fecha de publicación de la presente guía, esto:
 

 
Todos los ficheros de esta carpeta contienen configuraciones importantes, salvo por el momento const.h. Todos siguen una estructura parecida: al abrirlo se ven mucho texto y algunas sentencias que empiezan por #, que de forma sencilla podría decirse que son órdenes para el compilador, que no forman parte del programa final. Nos interesan especialmente los #define (definiciones), pero no debemos tocar nada en las primeras (por el momento 5) líneas, ni el #endif del final al ser definiciones de control imprescindibles.
 
Centrémonos en el fichero renewal.h, que es el principal de la guía. Este fichero contiene las siguientes definiciones, y cada una de ellas maneja algún tipo de mecánica Renewal (todas juntas para ahorrar espacio):
#define RENEWAL#define RENEWAL_CAST#define RENEWAL_DROP#define RENEWAL_EXP#define RENEWAL_LVDMG#define RENEWAL_EDP#define RENEWAL_ASPD ¿Cómo desactivarlas? Muy sencillo: se desactivan una a una anteponiendo una doble barra (//) delante de cada definición. A la doble barra, en el lenguaje del código fuente de Hércules © se le llama comentario de línea, y lo que hace el compilador es ignorar todo lo que esté en la misma línea a su derecha. O sea, si queremos eliminar todo rastro de Renewal de nuestro servidor tenemos que comentar (hacer comentario) todos esos #define, de tal forma que queden tal que así:
//#define RENEWAL//#define RENEWAL_CAST//#define RENEWAL_DROP//#define RENEWAL_EXP//#define RENEWAL_LVDMG//#define RENEWAL_EDP//#define RENEWAL_ASPD Así pues, al (re)compilar nuestro servidor Hercules, éste será totalmente pre-renewal pero dispondrá de todas las características únicas de Hercules.
 
¿Hay más que hacer? Pues no con renewal.h, pero sí se recomienda revisar cualquier configuración contenida en esta carpeta. Además del tipo de #define arriba descrito hay otros dos tipos:
Unos que vienen comentados pero puedes descomentar si quieres: siguen el mismo procedimiento que el ya descrito, pero a la inversa. Unos que van acompañados de un espacio y posteriormente un número (o una constante, que en este caso también actúa como un número): Si te interesa, puedes cambiarle el número con el que vienen acompañados (¡Importante: estos #define no debes comentarlos!). Es posible que te indiquen los valores posibles, como la única configuración actualmente disponible en /classes/general.h o te permitan elegir un valor numérico a tu gusto. Se recomienda no usar 0 salvo que se indique expresamente como valor posible (como el ejemplo anterior en /classes/general.h), porque no significará "ilimitado" como alguien puede estar acostumbrado a que así sea en otras configuraciones, sino que es literalmente 0(*). Ejemplo de este tipo de #define es el ya mencionado en /classes/general.h o este, situado en core.h:/// Max number of items on @autolootid list#define AUTOLOOTITEM_SIZE 10(*) No estoy seguro, pero todo indica a ello. Igualmente no deberíais ni probar a hacerlo, ya que es potencialmente peligroso para el servidor que dicho ajuste no funcione bien.

Si queréis profundizar más en qué son y para qué sirven estas órdenes que se dan al compilador, estas que empiezan por #, podéis visitar este enlace en la Wikipedia que os proveerá de información completa sobre ello (se recomienda leer como mucho hasta el apartado 3, sin comenzar el 3.1)
 
Por último, no te olvides de que después de modificar cualquiera estas configuraciones, es necesario (re)compilar el servidor para que los cambios surtan efecto. Eso es todo.

from my cellphone:
supposing you're running debian or similar:
 
run: top
look for the processes ID you want to kill. Press Q to exit top.
run: kill -9 <process_id>
 
Hope I helped

Preguntas frecuentes:
He colocado la sección en otro post para facilitar su búsqueda y escritura.

Aunque espero que no haya prácticamente ninguna pregunta en esta sección porque me gustaría creer que he sido suficientemente claro, es obvio que las cosas no son así y es normal "atascarse" en alguna parte de la guía, inauguro esta sección. Como es usual en estas secciones de Preguntas y Respuestas, las preguntas las marcaré con una P y las respuestas las marcaré con una R, ambas bien grandes para que se vean en condiciones.

Lista de preguntas:
 
Preguntas y respuestas:

P: ¿Puedo desactivar todas las mecánicas Renewal pero usar NPCs y bases de datos Renewal y viceversa?
R: Hay un pequeño truco para ello. Siempre se leen las carpetas /db y /npc, y además si Renewal está activo (#define RENEWAL) se leen las carpetas /db/re y /npc/re, en lugar de /db/pre-re y /npc/pre-re; mientras que si no lo está se leen las carpetas con nombre de pre-re en lugar de las re. Si quieres que se lean las otras carpetas que originalmente no correspondería, simplemente puedes intercambiarles el nombre, o intercambiar los valores de la definición #define DBPATH de const.h. Cuidado con la anterior definición porque es algo distinta a las vistas en el post principal de la guía, aunque no deberá daros mucho problema. Eso sí, mucho ojo: el juego no está preparado para trabajar con unas bases de datos y unos NPCs que no les corresponde y puede haber enormes fallos de equilibrio en el servidor.

P: ¿Por qué al desactivar Renewal sigue habiendo 3rd Jobs?
R: Al desactivar Renewal solo se desactivan las mecánicas, las bases de datos y los NPCs de Renewal (lo cual incluye las quests de Renewal, a menos que cambies los NPCs como se indica en la pregunta de arriba). De esta forma se hace imposible cambiar a Third Job a menos que se ejecute @job o haya algún NPC custom que cambie el job a uno de los 3rd Jobs. Ten cuidado al usar el NPC jobmaster que viene con Hercules, pues por defecto admite el cambio a 3rd Job:
 
npc/custom/jobmaster.txt, línea 184 (observad mi comentario)
OnInit:setarray .Rebirth[0],99,50; // Minimum base level, job level to rebirth OR change to third classsetarray .JobReq[0],10,40; // Minimum job level to turn into 1st class, 2nd classset .ThirdClass,1; // Enable third classes? (1: yes / 0: no) ¡Cambiad esto a 0 si pensáis usarlo y no queréis 3rd Jobs!set .SNovice,45; // Minimum base level to turn into Super Noviceset .LastJob,1; // Enforce linear class changes? (1: yes / 0: no)set .SkillPointCheck,1; // Force player to use up all skill points? (1: yes / 0: no)set .Platinum,1; // Get platinum skills automatically? (1: yes / 0: no)end;  
P: ¿Por qué tras cambiar una de estas configuraciones no noto ningún cambio?
R: Ya se ha comentado por lo menos tres veces en la presente guía: para que estos cambios surtan efecto, es obligatorio y necesario recompilar el emulador. De no hacerlo, no habrá ningún cambio en él hasta que se recompile.

¡Hola! En esta guía vamos a tratar de forma rápida una pregunta muy frecuente: cómo activar y desactivar Renewal, y ligeramente se tratarán otras configuraciones más o menos igual de "ocultas" que funcionan de forma similar. No se entrará en el detalle de para qué sirve cada configuración: solo se indicará el camino y deberá ser el lector quien se enfrente a ellas, en inglés. Su lectura es recomendada a quien ignore la existencia de estas configuraciones, aunque no pretenda desactivar Renewal.

Una vez se ha obtenido Hercules y antes de su compilación y puesta en marcha (guía aún en proyecto y redacción), es posible tocar unas configuraciones que no están tan a la vista que las de la carpeta /conf (donde están todas las configuraciones normales) pero que sí afectan al resultado de la compilación (es decir, para alterarlas efectivamente es necesario recompilar el emulador): se trata de la carpeta /src/config.

¿Qué hay en la carpeta /src/config que la hace tan importante? Pues, a fecha de publicación de la presente guía, esto:
 

 
Todos los ficheros de esta carpeta contienen configuraciones importantes, salvo por el momento const.h. Todos siguen una estructura parecida: al abrirlo se ven mucho texto y algunas sentencias que empiezan por #, que de forma sencilla podría decirse que son órdenes para el compilador, que no forman parte del programa final. Nos interesan especialmente los #define (definiciones), pero no debemos tocar nada en las primeras (por el momento 5) líneas, ni el #endif del final al ser definiciones de control imprescindibles.
 
Centrémonos en el fichero renewal.h, que es el principal de la guía. Este fichero contiene las siguientes definiciones, y cada una de ellas maneja algún tipo de mecánica Renewal (todas juntas para ahorrar espacio):
#define RENEWAL#define RENEWAL_CAST#define RENEWAL_DROP#define RENEWAL_EXP#define RENEWAL_LVDMG#define RENEWAL_EDP#define RENEWAL_ASPD ¿Cómo desactivarlas? Muy sencillo: se desactivan una a una anteponiendo una doble barra (//) delante de cada definición. A la doble barra, en el lenguaje del código fuente de Hércules © se le llama comentario de línea, y lo que hace el compilador es ignorar todo lo que esté en la misma línea a su derecha. O sea, si queremos eliminar todo rastro de Renewal de nuestro servidor tenemos que comentar (hacer comentario) todos esos #define, de tal forma que queden tal que así:
//#define RENEWAL//#define RENEWAL_CAST//#define RENEWAL_DROP//#define RENEWAL_EXP//#define RENEWAL_LVDMG//#define RENEWAL_EDP//#define RENEWAL_ASPD Así pues, al (re)compilar nuestro servidor Hercules, éste será totalmente pre-renewal pero dispondrá de todas las características únicas de Hercules.
 
¿Hay más que hacer? Pues no con renewal.h, pero sí se recomienda revisar cualquier configuración contenida en esta carpeta. Además del tipo de #define arriba descrito hay otros dos tipos:
Unos que vienen comentados pero puedes descomentar si quieres: siguen el mismo procedimiento que el ya descrito, pero a la inversa. Unos que van acompañados de un espacio y posteriormente un número (o una constante, que en este caso también actúa como un número): Si te interesa, puedes cambiarle el número con el que vienen acompañados (¡Importante: estos #define no debes comentarlos!). Es posible que te indiquen los valores posibles, como la única configuración actualmente disponible en /classes/general.h o te permitan elegir un valor numérico a tu gusto. Se recomienda no usar 0 salvo que se indique expresamente como valor posible (como el ejemplo anterior en /classes/general.h), porque no significará "ilimitado" como alguien puede estar acostumbrado a que así sea en otras configuraciones, sino que es literalmente 0(*). Ejemplo de este tipo de #define es el ya mencionado en /classes/general.h o este, situado en core.h:/// Max number of items on @autolootid list#define AUTOLOOTITEM_SIZE 10(*) No estoy seguro, pero todo indica a ello. Igualmente no deberíais ni probar a hacerlo, ya que es potencialmente peligroso para el servidor que dicho ajuste no funcione bien.

Si queréis profundizar más en qué son y para qué sirven estas órdenes que se dan al compilador, estas que empiezan por #, podéis visitar este enlace en la Wikipedia que os proveerá de información completa sobre ello (se recomienda leer como mucho hasta el apartado 3, sin comenzar el 3.1)
 
Por último, no te olvides de que después de modificar cualquiera estas configuraciones, es necesario (re)compilar el servidor para que los cambios surtan efecto. Eso es todo.

Preguntas frecuentes:
He colocado la sección en otro post para facilitar su búsqueda y escritura.

Aunque espero que no haya prácticamente ninguna pregunta en esta sección porque me gustaría creer que he sido suficientemente claro, es obvio que las cosas no son así y es normal "atascarse" en alguna parte de la guía, inauguro esta sección. Como es usual en estas secciones de Preguntas y Respuestas, las preguntas las marcaré con una P y las respuestas las marcaré con una R, ambas bien grandes para que se vean en condiciones.

Lista de preguntas:
 
Preguntas y respuestas:

P: ¿Puedo desactivar todas las mecánicas Renewal pero usar NPCs y bases de datos Renewal y viceversa?
R: Hay un pequeño truco para ello. Siempre se leen las carpetas /db y /npc, y además si Renewal está activo (#define RENEWAL) se leen las carpetas /db/re y /npc/re, en lugar de /db/pre-re y /npc/pre-re; mientras que si no lo está se leen las carpetas con nombre de pre-re en lugar de las re. Si quieres que se lean las otras carpetas que originalmente no correspondería, simplemente puedes intercambiarles el nombre, o intercambiar los valores de la definición #define DBPATH de const.h. Cuidado con la anterior definición porque es algo distinta a las vistas en el post principal de la guía, aunque no deberá daros mucho problema. Eso sí, mucho ojo: el juego no está preparado para trabajar con unas bases de datos y unos NPCs que no les corresponde y puede haber enormes fallos de equilibrio en el servidor.

P: ¿Por qué al desactivar Renewal sigue habiendo 3rd Jobs?
R: Al desactivar Renewal solo se desactivan las mecánicas, las bases de datos y los NPCs de Renewal (lo cual incluye las quests de Renewal, a menos que cambies los NPCs como se indica en la pregunta de arriba). De esta forma se hace imposible cambiar a Third Job a menos que se ejecute @job o haya algún NPC custom que cambie el job a uno de los 3rd Jobs. Ten cuidado al usar el NPC jobmaster que viene con Hercules, pues por defecto admite el cambio a 3rd Job:
 
npc/custom/jobmaster.txt, línea 184 (observad mi comentario)
OnInit:setarray .Rebirth[0],99,50; // Minimum base level, job level to rebirth OR change to third classsetarray .JobReq[0],10,40; // Minimum job level to turn into 1st class, 2nd classset .ThirdClass,1; // Enable third classes? (1: yes / 0: no) ¡Cambiad esto a 0 si pensáis usarlo y no queréis 3rd Jobs!set .SNovice,45; // Minimum base level to turn into Super Noviceset .LastJob,1; // Enforce linear class changes? (1: yes / 0: no)set .SkillPointCheck,1; // Force player to use up all skill points? (1: yes / 0: no)set .Platinum,1; // Get platinum skills automatically? (1: yes / 0: no)end;  
P: ¿Por qué tras cambiar una de estas configuraciones no noto ningún cambio?
R: Ya se ha comentado por lo menos tres veces en la presente guía: para que estos cambios surtan efecto, es obligatorio y necesario recompilar el emulador. De no hacerlo, no habrá ningún cambio en él hasta que se recompile.

It seems it could be a nice idea to remodel this for also checking the destination of the skill or even the pair caster-receiver. But I think it's quite good as is, especially if most uses of this mods will surely be for PvP or WoE.

Hanbok & Costumes Update

So What?~!little time ago I started to implement it as Shakto brought the topic up in IRC, I started to work on it from scratch thanks to Yommy for providing me with all ids, and while doing so I found the cause to Bug #7067, and thats what this topic is actually about, to let you know what changed with that bug being fixed. Changes Applying costumes can no longer be done with setoption (update your item/scripts!), it must be done via status change (check item #2776 change on the commit) With Habok being implemented, @mount2 (new mounts) are now working again for 2013 and newer clients. @costumeSince @job doesn't work with costumes I had to create a new command, with it you can go in and out wedding, xmas, summer and hanbok. Hanbok Hanbok's sprite is the one in the picture above, it is only available in 2013 and newer clients. Hanbok also has received its own 'ignore palette' config, as other costumes possess. conf/battle/client.conf// Do not display cloth colors for the Hanbok costume?
// Set this to yes if your cloth palettes pack doesn't has Hanbok palettes (or has less than the other jobs)
hanbok_ignorepalette: no Link~u!Commit

Antes de empezar aclaro que esta guía esta hecha en base a Ubuntu Server 12.10, con una instalación limpia, sin ningún paquete. Para otras distribuciones la cosa es muy parecida, en muchos casos simplemente es cambiar el apt-get por el gestor de paquetes que disponga el sistema operativo, lo más normal es yum que son de distribuciones basades en redhat(centos,fedora)
 
Partimos de la base que el sistema ya esta instalado y tenemos un usuario creado, en esta guia no vamos a tocar el usuario root, ya que por temas de seguridad es mejor hacerlo así.
 
 
Primero de todo tenemos que actualizar los paquetes de nuestro sistema operativo.
 
sudo apt-get update && sudo apt-get upgrade  
Una vez esta actualizado, tenemos que instalar los paquetes necesarios para compilar el emulador Hercules.
Primero instalamos git, que es necesario para tener la última versión del código fuente.
 
sudo apt-get install git  
Una vez tenemos el programa git tenemos que obtener el código fuente:
 
git clone https://github.com/HerculesWS/Hercules.git ~/Hercules  
Una vez tenemos el código fuente, necesitaremos algunos programas extras para compilarlo. Ejecutamos
 
sudo apt-get install mysql-server mysql-client mysql-common gcc libmysqlclient18 screen make zlibc zlib1g zlib1g-dev libmysqlclient-dev zlib1g-dev libpcre3-dev  
Durante la instalación nos pedirá la contraseña de root de mysql. Ponemos una contraseña y continuamos.
 
Antes de terminar tecleamos para configurar
 
./configure --enable-packetver=YYYYMMDD  
Si tenemos un sistema operativo de 64 bits
 
./configure –enable-64bit --enable-packetver=YYYYMMDD  
Y para terminar, ponemos
 
make  
Como veis esto es una guia bastante basica, con lo minimo para tener un servidor funcionando, recomiendo leer la wiki http://herc.ws/wiki/Main_Page
 
Tenemos más información en el post #2 de jaBote
 
 
PD: La guia la he hecho mientras probaba todos los comandos y la seguia paso a paso en una maquina virtual con Ubuntu Server 12.10, así que todas las ips, usuarios y datos "críticos" no son reales, son de una maquina virtual creada expresamente para hacer esta guia.

There is a problem with last revisions. Be careful
 
Related: http://herc.ws/board/tracker/issue-7182-item-delay-issue/

Hercules April 22 Patch
Hello~! - What?!
1st, most of these things were meant to be released separately but as I started to work with them one thing hooked up to another and I ended up deciding to get all out at once No second today! The all-long, all-mighty list
New Map Zone DB Updates Added New "All" Zone, easy way to add modifiers to all maps in the game. Automatically inherited by all existent zones. Added new zone setting disabled_commands, can disable any command in any zone "command-name: min-group-lv" also supports min group level to override, to enable back a command disabled by inheritance just use "command-name: 0" Added new zone setting skill_damage_cap (as requested by the community), can cap any skill damage to any range of unit types, and also a new core config "HMAP_ZONE_DAMAGE_CAP_TYPE" that controls how the cap is applied (before or after modifiers) New target-type support (used by skill_damage_cap and disabled_skills): PET (special thanks to frenzmu06 for bringing it up!), CLONE and MOB_BOSS Added support to ids! item and skill ids may now be employed in all sections of the file in the place of item/skill names Detailed Map Zone DB Update Hercules Channel System Update Added a IRC bridge as requested by the community, allows users outside of the game (but in a irc network e.g. thru mobile/cel app) to communicate with anyone in-game that is within a specific #channel, and vice-versa Detailed Channel System Update Added Beret and Yommy's suggestion on cash shop file format, also added support for item ids Added Ryuuzaki's kafra point support to the new cashshop Updated map-server's save_setting, added new option: 128, to save buyingstore transactions on the fly Revisited bindatcmd feature, dropped level support, added group level support and added a new flag capable of deciding whether calls to that command should be logged in the atcommand log. Performance Improvement Added a in-memory list to store existent shops (saves iterating through all online players) Modified searchstore to use said db above, making its queries faster Improved pc_groups processing, decreased runtime ram usage by a about 1mb. Improved @command log processing through groups, now caching the state (no longer does dbmap lookup). Improved atcommand.conf file processing (was doing a extra lookup instead of using atcommand_exists already-performed lookup result) Improved atcommand's help file processing (no more lookups! string is now cached directly in the atcommandinfo struct of each command) and data management Improved @help's processing: dropped the huge config file lookup and replaced by using the caches. Improved atcommand logging, added option to not log specific commands (so you dont waste log room with stuff such as @iteminfo/@mobinfo/etc) -- atcommand.conf nolog group Sightly improved zone inheritance processing. Speeded up mvp drop processing Speeded up item log processing Speeded up mob item drop processing Misc With map_zone_db's new clone support, flag 0x8000 (no-clone-use) in the skill db was dropped With map_zone_db's new way to block commands, mapflag nogo was dropped. Fixed a number of discrepancies between unsigned and signed variables in many packets. Fixed loading messages for exp_db, attr_fix, statpoint, mob_chat_db, mob_pouch, mob_branch, mob_classchange, mob_boss, mob_poring and item_group_db pets from gms who cant drop items no longer can loot items (prevents exploit where gm kills something, pet loots, then drops and action is not logged nor blocked). Fixed combo bonuses that used getrefine on weapons/cards that affect weapons. Added @searchstore as to offer same availability to gms as @auction/@mail does Improved 2013 client charselect procedure, all thanks to Yommy! Links~!
Commit

¡Hola a todos! Parece que han aceptado la proposición que hice al Staff de Hercules sobre la creación de esta sección para que podamos disfrutar de soporte en español. Sé que no todos somos muy duchos en la lengua de Shakespeare, por lo que en estos foros podréis preguntar cosas sobre Hercules. Eso sí, en español.
 
Como muchos de nosotros sabemos, Hercules proviene de Athena (el primer emulador jamás creado de RO, con disculpas de AEGIS, que es el emulador oficial), que es también la raíz de donde provienen todos los demás emuladores actuales de Ragnarok Online. Hercules bebe especialmente de rAthena, pero el emulador ya ha sido intensamente modificado en los pocos meses que tiene de vida. Al parecer en Hercules se ha decidido dejar de lado el típico *Athena que muchos hispanos estamos acostumbrados a tratar, pero no ha sido el primero en hacerlo: con anterioridad han existido y existen emuladores que no tienen Athena en su nombre, como pueden ser Freya, Nezumi o Cronus (actualmente de ellos solo Cronus continúa en desarrollo, aunque está en portugués).
 
En lo que a mí respecta, no soy especialmente bueno dando soporte en emuladores de esto: empecé a jugar al RO hace relativamente muy poco, mucho menos que el jugador medio de este juego, y he tenido menos tiempo aún para saber qué es lo que hace toda la magia que mueve nuestro mundo virtual, y le da consistencia e integridad sin que apenas nos demos cuenta de ello. Muchos (y me incluyo) no sabemos qué hay "bajo el capó" de nuestros servidores.
 
Trataré de dar la mejor (y más amplia) ayuda que me sea posible, aunque es obvio que esto no es un foro en que solo yo ayudo: hay campos enteros del soporte a este emulador (y cualquier otro *Athena) que por desgracia aún se me escapan. Yo no sé todo sobre el emulador y podéis estar seguros que también acabaré preguntando bien aquí o en las secciones de soporte en inglés, pero se ha creado esta comunidad en español con un propósito, y es que todos nosotros podamos colaborar con un granito de arena, de tal forma que todos podemos salir enriquecidos compartiendo nuestros conocimientos.
 
Sin mucho más que decir por el momento, os doy mi más cálida bienvenida a nuestra aún pequeña comunidad en español de Hercules.
 
¡Nos leemos!

Sí, la verdad es que es una buena idea ir haciendo guías o posteando parte de nuestro conocimiento general y lo tengo en plan, aunque ahora mismo tengo más asuntos en mano de los que puedo manejar. Lo que no podemos hacer es entrar a cualquier comunidad hispana de RO y empezar a robar guías a menos que sean de nuestra autoría, por mucho que las más conocidas no me hagan especial gracia.
 
No hace falta escribir guías de algo muy específico aún, aunque sería buena idea comenzar a escribir guías de carácter básico o incluso traducir parte de la documentación de Hercules y postearlo como guía. No debo imponer ninguna limitación a esto aún.
 
 
 
¡Muchas gracias por el recibimiento! Pero creo que Wolf no hace uso de GTranslate. Más que nada porque ha cometido un error ortográfico muy común que GTranslate no habría hecho.