pan

Long time no see!
I've been dabbling with adding multi-thread support to Hercules for quite some time and even started quite a few server projects from scratch, and having failed in most of my attempts - last year I tried again with a new core design and it seems to be working so far. A lot of the systems that the server core is reliant were reworked, I believe some of these changes can even be used upstream but they would need to be revised first. This is mostly a proof of concept.
I'm still planning on finishing the map-server but as of now only login and char servers have multi-thread enabled - I didn't test with multiple users yet. There's no linux / FreeBSD support because I want to have everything in working condition before trying to add another I/O paradigm, the architecture is very reliant on the way that this module works so I thought it'd better to implement the whole server before trying to add other paradigms.
Lately I haven't got much free time to finish the map-server, but sometime later this year I think I can finish it.
The code is at https://github.com/panikon/HerculesMT , I forked from stable v2021.08.04
 
Server architecture

Hercules employs a multi-server approach in order to better load balance player requests, so for each game world there'll be at least three separate program instances running at all times. These instrances are: login-server, char-server and map-server. Each of which can only access a subset of the world's SQL tables and is responsible for a different step of the game experience.

Authentication and account database changes are segregated to the login-server, while character selection and character specific information are to the char-server, and the actual gameplay to the map-server.
The login-server is the player entry-point and can be responsible for multiple different world instances, so it's possible to use the same account table (login) for multiple worlds (char-server + map-server) and to dynamically change their IP without needing to push a new patch. After authentication the player is queried for which service they'll use and then the server relays the proper address so the client can connect.
In the char-server the player usually is queried again for a four digit PIN (PACKETVER >= 20180124), after which they can select which playable character will be used to play. The server then relays the address of the proper map-server to the client.
A single world instance can have multiple map-servers where each is responsible for a zone (set of maps), all inter map connectivity is managed by the char-server. When the player requests to change character the char-server IP is then relayed.
A single map-server can be responsible for multiple different zones, and each will be a different thread.
 
Relationship of each of the possible server instances

 Brown - Game world | White - program instances
 
Core design
All servers are multi-threaded. Basic server functions are assigned to different threads:

Console (../src/common/console.c):
This thread is responsible for all console input operations. Timer (../src/common/timer.c):
The timer thread manages the `timer_heap` and dequeues timer actions from the `timer_queue`. Each timer can be ran in a different thread depending on the `timer_target`, this is accomplished by either queuing an action in one of the available action queues (`target_id`) or by running the specified function in the main timer loop (`do_timer`).
Other threads queue different timer actions (add, delete, set tick) to the `timer_queue`.
The timer module is also responsible for tick acquiral via (`timer->gettick` and `timer->gettick_nocache`). Message(../src/common/showmsg.c):
The message thread is used to synchronize the output of multiple different threads, each call to `Show*` instead of being directly outputted to `STDOUT` is queued in the `showmsg_queue` and then dequeued by the main thread function `showmsg_worker`. I/O Worker(../src/common/socket.c):
All I/O operations are asynchronous and implemented via I/O completion ports and a thread pool. The main workers are defined in `socket_worker` and after a operation is dequeued it's converted into an action (`socket_operation_process`) that is then queued to the proper action worker (each session has a responsible worker, and it's obtained by the I/O worker via `action->queue_get`).
These workers don't execute any "business logic" so we can minimize the time that they are blocked by any given operation, and also so we can better isolate different session groups without having to take into account in I/O operations (e.g. in map-server each zone has a different action worker and multiple actions can be queued simultaneously without having to block any of the threads for a longer period of time). Action Worker(../src/common/action.c):
Action workers perform all the "business logic" of each of the servers, and each is responsible for a different session group. After every action loop all send actions are queued to the completion port.

Login-server:
Each char-server connection has a different worker. Player connections are randomly assigned. Char-server:
Each map-server connection has a different worker. Player connections are randomly assigned. Map-server:
Player connections are assigned depending on the current map according to the different configured zones. The char-server connection is randomly assigned.



Thread relationships

Long time no see!
I've been dabbling with adding multi-thread support to Hercules for quite some time and even started quite a few server projects from scratch, and having failed in most of my attempts - last year I tried again with a new core design and it seems to be working so far. A lot of the systems that the server core is reliant were reworked, I believe some of these changes can even be used upstream but they would need to be revised first. This is mostly a proof of concept.
I'm still planning on finishing the map-server but as of now only login and char servers have multi-thread enabled - I didn't test with multiple users yet. There's no linux / FreeBSD support because I want to have everything in working condition before trying to add another I/O paradigm, the architecture is very reliant on the way that this module works so I thought it'd better to implement the whole server before trying to add other paradigms.
Lately I haven't got much free time to finish the map-server, but sometime later this year I think I can finish it.
The code is at https://github.com/panikon/HerculesMT , I forked from stable v2021.08.04
 
Server architecture

Hercules employs a multi-server approach in order to better load balance player requests, so for each game world there'll be at least three separate program instances running at all times. These instrances are: login-server, char-server and map-server. Each of which can only access a subset of the world's SQL tables and is responsible for a different step of the game experience.

Authentication and account database changes are segregated to the login-server, while character selection and character specific information are to the char-server, and the actual gameplay to the map-server.
The login-server is the player entry-point and can be responsible for multiple different world instances, so it's possible to use the same account table (login) for multiple worlds (char-server + map-server) and to dynamically change their IP without needing to push a new patch. After authentication the player is queried for which service they'll use and then the server relays the proper address so the client can connect.
In the char-server the player usually is queried again for a four digit PIN (PACKETVER >= 20180124), after which they can select which playable character will be used to play. The server then relays the address of the proper map-server to the client.
A single world instance can have multiple map-servers where each is responsible for a zone (set of maps), all inter map connectivity is managed by the char-server. When the player requests to change character the char-server IP is then relayed.
A single map-server can be responsible for multiple different zones, and each will be a different thread.
 
Relationship of each of the possible server instances

 Brown - Game world | White - program instances
 
Core design
All servers are multi-threaded. Basic server functions are assigned to different threads:

Console (../src/common/console.c):
This thread is responsible for all console input operations. Timer (../src/common/timer.c):
The timer thread manages the `timer_heap` and dequeues timer actions from the `timer_queue`. Each timer can be ran in a different thread depending on the `timer_target`, this is accomplished by either queuing an action in one of the available action queues (`target_id`) or by running the specified function in the main timer loop (`do_timer`).
Other threads queue different timer actions (add, delete, set tick) to the `timer_queue`.
The timer module is also responsible for tick acquiral via (`timer->gettick` and `timer->gettick_nocache`). Message(../src/common/showmsg.c):
The message thread is used to synchronize the output of multiple different threads, each call to `Show*` instead of being directly outputted to `STDOUT` is queued in the `showmsg_queue` and then dequeued by the main thread function `showmsg_worker`. I/O Worker(../src/common/socket.c):
All I/O operations are asynchronous and implemented via I/O completion ports and a thread pool. The main workers are defined in `socket_worker` and after a operation is dequeued it's converted into an action (`socket_operation_process`) that is then queued to the proper action worker (each session has a responsible worker, and it's obtained by the I/O worker via `action->queue_get`).
These workers don't execute any "business logic" so we can minimize the time that they are blocked by any given operation, and also so we can better isolate different session groups without having to take into account in I/O operations (e.g. in map-server each zone has a different action worker and multiple actions can be queued simultaneously without having to block any of the threads for a longer period of time). Action Worker(../src/common/action.c):
Action workers perform all the "business logic" of each of the servers, and each is responsible for a different session group. After every action loop all send actions are queued to the completion port.

Login-server:
Each char-server connection has a different worker. Player connections are randomly assigned. Char-server:
Each map-server connection has a different worker. Player connections are randomly assigned. Map-server:
Player connections are assigned depending on the current map according to the different configured zones. The char-server connection is randomly assigned.



Thread relationships

Long time no see!
I've been dabbling with adding multi-thread support to Hercules for quite some time and even started quite a few server projects from scratch, and having failed in most of my attempts - last year I tried again with a new core design and it seems to be working so far. A lot of the systems that the server core is reliant were reworked, I believe some of these changes can even be used upstream but they would need to be revised first. This is mostly a proof of concept.
I'm still planning on finishing the map-server but as of now only login and char servers have multi-thread enabled - I didn't test with multiple users yet. There's no linux / FreeBSD support because I want to have everything in working condition before trying to add another I/O paradigm, the architecture is very reliant on the way that this module works so I thought it'd better to implement the whole server before trying to add other paradigms.
Lately I haven't got much free time to finish the map-server, but sometime later this year I think I can finish it.
The code is at https://github.com/panikon/HerculesMT , I forked from stable v2021.08.04
 
Server architecture

Hercules employs a multi-server approach in order to better load balance player requests, so for each game world there'll be at least three separate program instances running at all times. These instrances are: login-server, char-server and map-server. Each of which can only access a subset of the world's SQL tables and is responsible for a different step of the game experience.

Authentication and account database changes are segregated to the login-server, while character selection and character specific information are to the char-server, and the actual gameplay to the map-server.
The login-server is the player entry-point and can be responsible for multiple different world instances, so it's possible to use the same account table (login) for multiple worlds (char-server + map-server) and to dynamically change their IP without needing to push a new patch. After authentication the player is queried for which service they'll use and then the server relays the proper address so the client can connect.
In the char-server the player usually is queried again for a four digit PIN (PACKETVER >= 20180124), after which they can select which playable character will be used to play. The server then relays the address of the proper map-server to the client.
A single world instance can have multiple map-servers where each is responsible for a zone (set of maps), all inter map connectivity is managed by the char-server. When the player requests to change character the char-server IP is then relayed.
A single map-server can be responsible for multiple different zones, and each will be a different thread.
 
Relationship of each of the possible server instances

 Brown - Game world | White - program instances
 
Core design
All servers are multi-threaded. Basic server functions are assigned to different threads:

Console (../src/common/console.c):
This thread is responsible for all console input operations. Timer (../src/common/timer.c):
The timer thread manages the `timer_heap` and dequeues timer actions from the `timer_queue`. Each timer can be ran in a different thread depending on the `timer_target`, this is accomplished by either queuing an action in one of the available action queues (`target_id`) or by running the specified function in the main timer loop (`do_timer`).
Other threads queue different timer actions (add, delete, set tick) to the `timer_queue`.
The timer module is also responsible for tick acquiral via (`timer->gettick` and `timer->gettick_nocache`). Message(../src/common/showmsg.c):
The message thread is used to synchronize the output of multiple different threads, each call to `Show*` instead of being directly outputted to `STDOUT` is queued in the `showmsg_queue` and then dequeued by the main thread function `showmsg_worker`. I/O Worker(../src/common/socket.c):
All I/O operations are asynchronous and implemented via I/O completion ports and a thread pool. The main workers are defined in `socket_worker` and after a operation is dequeued it's converted into an action (`socket_operation_process`) that is then queued to the proper action worker (each session has a responsible worker, and it's obtained by the I/O worker via `action->queue_get`).
These workers don't execute any "business logic" so we can minimize the time that they are blocked by any given operation, and also so we can better isolate different session groups without having to take into account in I/O operations (e.g. in map-server each zone has a different action worker and multiple actions can be queued simultaneously without having to block any of the threads for a longer period of time). Action Worker(../src/common/action.c):
Action workers perform all the "business logic" of each of the servers, and each is responsible for a different session group. After every action loop all send actions are queued to the completion port.

Login-server:
Each char-server connection has a different worker. Player connections are randomly assigned. Char-server:
Each map-server connection has a different worker. Player connections are randomly assigned. Map-server:
Player connections are assigned depending on the current map according to the different configured zones. The char-server connection is randomly assigned.



Thread relationships

Elurair Patching Launcher
(RO Patcher Lite+ROCred Merge)
 

 
About
Universal auto-patcher for all your updating needs combined with a launcher, which is fully skinnable, highly customizable and easy on resources. It is free of any cost and works on every 32-bit and 64-bit Microsoft* Windows* platform. How this came to be: Future of ROCred and RO Patcher Lite
 
Known Issues
None.
 
FAQ
Q: Does the patcher support encrypted GRFs?
A: Yes, common GRF encryption schemes are supported.
Q: Can I use the Patcher part without the Launcher part?
A: Yes, the Launcher mechanics and UI can be disabled in configuration.
Q: Can I use the Launcher part without the Patcher part?
A: Yes, remove all Patcher sections from the configuration.
 
Download & Website
http://ai4rei.net/p/skal
 
License

This work is licensed under a Creative Commons Attribution-Noncommercial 4.0 International License.

Long time no see!
I've been dabbling with adding multi-thread support to Hercules for quite some time and even started quite a few server projects from scratch, and having failed in most of my attempts - last year I tried again with a new core design and it seems to be working so far. A lot of the systems that the server core is reliant were reworked, I believe some of these changes can even be used upstream but they would need to be revised first. This is mostly a proof of concept.
I'm still planning on finishing the map-server but as of now only login and char servers have multi-thread enabled - I didn't test with multiple users yet. There's no linux / FreeBSD support because I want to have everything in working condition before trying to add another I/O paradigm, the architecture is very reliant on the way that this module works so I thought it'd better to implement the whole server before trying to add other paradigms.
Lately I haven't got much free time to finish the map-server, but sometime later this year I think I can finish it.
The code is at https://github.com/panikon/HerculesMT , I forked from stable v2021.08.04
 
Server architecture

Hercules employs a multi-server approach in order to better load balance player requests, so for each game world there'll be at least three separate program instances running at all times. These instrances are: login-server, char-server and map-server. Each of which can only access a subset of the world's SQL tables and is responsible for a different step of the game experience.

Authentication and account database changes are segregated to the login-server, while character selection and character specific information are to the char-server, and the actual gameplay to the map-server.
The login-server is the player entry-point and can be responsible for multiple different world instances, so it's possible to use the same account table (login) for multiple worlds (char-server + map-server) and to dynamically change their IP without needing to push a new patch. After authentication the player is queried for which service they'll use and then the server relays the proper address so the client can connect.
In the char-server the player usually is queried again for a four digit PIN (PACKETVER >= 20180124), after which they can select which playable character will be used to play. The server then relays the address of the proper map-server to the client.
A single world instance can have multiple map-servers where each is responsible for a zone (set of maps), all inter map connectivity is managed by the char-server. When the player requests to change character the char-server IP is then relayed.
A single map-server can be responsible for multiple different zones, and each will be a different thread.
 
Relationship of each of the possible server instances

 Brown - Game world | White - program instances
 
Core design
All servers are multi-threaded. Basic server functions are assigned to different threads:

Console (../src/common/console.c):
This thread is responsible for all console input operations. Timer (../src/common/timer.c):
The timer thread manages the `timer_heap` and dequeues timer actions from the `timer_queue`. Each timer can be ran in a different thread depending on the `timer_target`, this is accomplished by either queuing an action in one of the available action queues (`target_id`) or by running the specified function in the main timer loop (`do_timer`).
Other threads queue different timer actions (add, delete, set tick) to the `timer_queue`.
The timer module is also responsible for tick acquiral via (`timer->gettick` and `timer->gettick_nocache`). Message(../src/common/showmsg.c):
The message thread is used to synchronize the output of multiple different threads, each call to `Show*` instead of being directly outputted to `STDOUT` is queued in the `showmsg_queue` and then dequeued by the main thread function `showmsg_worker`. I/O Worker(../src/common/socket.c):
All I/O operations are asynchronous and implemented via I/O completion ports and a thread pool. The main workers are defined in `socket_worker` and after a operation is dequeued it's converted into an action (`socket_operation_process`) that is then queued to the proper action worker (each session has a responsible worker, and it's obtained by the I/O worker via `action->queue_get`).
These workers don't execute any "business logic" so we can minimize the time that they are blocked by any given operation, and also so we can better isolate different session groups without having to take into account in I/O operations (e.g. in map-server each zone has a different action worker and multiple actions can be queued simultaneously without having to block any of the threads for a longer period of time). Action Worker(../src/common/action.c):
Action workers perform all the "business logic" of each of the servers, and each is responsible for a different session group. After every action loop all send actions are queued to the completion port.

Login-server:
Each char-server connection has a different worker. Player connections are randomly assigned. Char-server:
Each map-server connection has a different worker. Player connections are randomly assigned. Map-server:
Player connections are assigned depending on the current map according to the different configured zones. The char-server connection is randomly assigned.



Thread relationships

Long time no see!
I've been dabbling with adding multi-thread support to Hercules for quite some time and even started quite a few server projects from scratch, and having failed in most of my attempts - last year I tried again with a new core design and it seems to be working so far. A lot of the systems that the server core is reliant were reworked, I believe some of these changes can even be used upstream but they would need to be revised first. This is mostly a proof of concept.
I'm still planning on finishing the map-server but as of now only login and char servers have multi-thread enabled - I didn't test with multiple users yet. There's no linux / FreeBSD support because I want to have everything in working condition before trying to add another I/O paradigm, the architecture is very reliant on the way that this module works so I thought it'd better to implement the whole server before trying to add other paradigms.
Lately I haven't got much free time to finish the map-server, but sometime later this year I think I can finish it.
The code is at https://github.com/panikon/HerculesMT , I forked from stable v2021.08.04
 
Server architecture

Hercules employs a multi-server approach in order to better load balance player requests, so for each game world there'll be at least three separate program instances running at all times. These instrances are: login-server, char-server and map-server. Each of which can only access a subset of the world's SQL tables and is responsible for a different step of the game experience.

Authentication and account database changes are segregated to the login-server, while character selection and character specific information are to the char-server, and the actual gameplay to the map-server.
The login-server is the player entry-point and can be responsible for multiple different world instances, so it's possible to use the same account table (login) for multiple worlds (char-server + map-server) and to dynamically change their IP without needing to push a new patch. After authentication the player is queried for which service they'll use and then the server relays the proper address so the client can connect.
In the char-server the player usually is queried again for a four digit PIN (PACKETVER >= 20180124), after which they can select which playable character will be used to play. The server then relays the address of the proper map-server to the client.
A single world instance can have multiple map-servers where each is responsible for a zone (set of maps), all inter map connectivity is managed by the char-server. When the player requests to change character the char-server IP is then relayed.
A single map-server can be responsible for multiple different zones, and each will be a different thread.
 
Relationship of each of the possible server instances

 Brown - Game world | White - program instances
 
Core design
All servers are multi-threaded. Basic server functions are assigned to different threads:

Console (../src/common/console.c):
This thread is responsible for all console input operations. Timer (../src/common/timer.c):
The timer thread manages the `timer_heap` and dequeues timer actions from the `timer_queue`. Each timer can be ran in a different thread depending on the `timer_target`, this is accomplished by either queuing an action in one of the available action queues (`target_id`) or by running the specified function in the main timer loop (`do_timer`).
Other threads queue different timer actions (add, delete, set tick) to the `timer_queue`.
The timer module is also responsible for tick acquiral via (`timer->gettick` and `timer->gettick_nocache`). Message(../src/common/showmsg.c):
The message thread is used to synchronize the output of multiple different threads, each call to `Show*` instead of being directly outputted to `STDOUT` is queued in the `showmsg_queue` and then dequeued by the main thread function `showmsg_worker`. I/O Worker(../src/common/socket.c):
All I/O operations are asynchronous and implemented via I/O completion ports and a thread pool. The main workers are defined in `socket_worker` and after a operation is dequeued it's converted into an action (`socket_operation_process`) that is then queued to the proper action worker (each session has a responsible worker, and it's obtained by the I/O worker via `action->queue_get`).
These workers don't execute any "business logic" so we can minimize the time that they are blocked by any given operation, and also so we can better isolate different session groups without having to take into account in I/O operations (e.g. in map-server each zone has a different action worker and multiple actions can be queued simultaneously without having to block any of the threads for a longer period of time). Action Worker(../src/common/action.c):
Action workers perform all the "business logic" of each of the servers, and each is responsible for a different session group. After every action loop all send actions are queued to the completion port.

Login-server:
Each char-server connection has a different worker. Player connections are randomly assigned. Char-server:
Each map-server connection has a different worker. Player connections are randomly assigned. Map-server:
Player connections are assigned depending on the current map according to the different configured zones. The char-server connection is randomly assigned.



Thread relationships

Nossa cara, tem que avisar em um bug report, esse dano está totalmente incorreto...
skillratio += (300 + 40 * skill_lv)/8;Fico pensando quem foi o gênio que pensou em dividir por 8 isso dai.Você sempre pode utilizar a source do Hercules com os scripts do cronus, não vai ter nenhum problema de incompatibilidade, já que eles estão seguindo a nossa source.

A sintaxe dos npcs do Hercules é basicamente a mesma do brAthena ou do Cronus, há algumas modificações no leitor de scripts daqui, mas qualquer incompatibilidade da para resolver bem facilmente c:

Nossa cara, tem que avisar em um bug report, esse dano está totalmente incorreto...
skillratio += (300 + 40 * skill_lv)/8;Fico pensando quem foi o gênio que pensou em dividir por 8 isso dai.Você sempre pode utilizar a source do Hercules com os scripts do cronus, não vai ter nenhum problema de incompatibilidade, já que eles estão seguindo a nossa source.

I don't know if I support this :/ considering this software is open source and free, to allow users to upload paid files to our forums would go against our own license in a sense imo. I'd say if you are making things like sprites, textures, etc and want to charge people for them, you should make your own website, with your own payment gateway and such and just link to it. I dunno. That's just my opinion though. I believe in things being shared for free (when it comes to sprites, scripts, textures, etc) out of the passion for wanting to contribute to the community, like how things were in the past. Too many people trying to profit off this community now a days.

Parece que esse comando não está seguindo a caixa necessária:
StrCharInfo(0)Deveria ser:strcharinfo(0)Idealmente você deveria utilizar strcharinfo utilizando algumas constantes que são definidas:PC_NAME NomePC_PARTY GrupoPC_GUILD ClãPC_MAP MapaFicando:strcharinfo(PC_NAME);Ou, se você tiver desativado a sensitividade à caixa, o que o evilpuncker disse estaria mais correto.

It sadly seems so :/ so many useful resources and information lost. Does anybody have a backup or maybe information gathered with a crawler?

Parece que esse comando não está seguindo a caixa necessária:
StrCharInfo(0)Deveria ser:strcharinfo(0)Idealmente você deveria utilizar strcharinfo utilizando algumas constantes que são definidas:PC_NAME NomePC_PARTY GrupoPC_GUILD ClãPC_MAP MapaFicando:strcharinfo(PC_NAME);Ou, se você tiver desativado a sensitividade à caixa, o que o evilpuncker disse estaria mais correto.

Sem problema nenhum Só achar a linha
set bvip_delay, gettimetick(0) + 20 * 1000; // Delay de 20sSubstitua o 20 pelo número de segundos desejado

Sem problema nenhum Só achar a linha
set bvip_delay, gettimetick(0) + 20 * 1000; // Delay de 20sSubstitua o 20 pelo número de segundos desejado

Prontinho http://pastebin.com/Vrhb4nP2

Acabei de testar, você deve ter esquecido de por algum TAB no header do NPC, pega ele aqui: http://pastebin.com/jVcBgrG8 copia e cola em um .txt
Ah, e o evento 'OnTouch' só é necessário quando você quer que o NPC funcione quando o jogador entre em alguma área, da uma olhada nesse post http://herc.ws/board/topic/3984-é-possível-utilizar-skills-via-servidor-para-efeitos-em-npcs/?p=25957 que ta explicado certinho

Movi o tópico para a seção correta.
 
O *showevent serve para avisar um jogador que há algo relacionado à uma quest em algum NPC portanto precisa que haja um jogador executando o script para que funcione. Basta executá-lo enquanto o jogador estiver falando com o NPC que ele continuará aparecendo enquanto o ele estiver no mesmo mapa, se você desejar que esse ícone apareça constantemente basta utilizar *questinfo, não se esqueça que esse comando só deve ser utilizado dentro de um OnInit.
 
<header>,{ OnInit: questinfo <Quest ID>, <Icon> {, <Map Mark Color>{, <Job Class>}}; end; Os valores para 'Job Class' podem ser encontrados em npc/const.txt, são os primeiros valores.
 
Mas se você quiser que um NPC tenha esse tipo de marcador para todo jogador que logue no servidor, independente de qualquer quest, basta utilizar um OnPCLoginEvent, algo como:
 
<header>,{ OnPCLoadMapEvent: if( strcharinfo(3) == strnpcinfo(4) ) showevent <icon>{,<mark color>}; end;} Não se esqueça de marcar o mapa com a mapflag loadevent.

Movi o tópico para a seção correta.
 
O *showevent serve para avisar um jogador que há algo relacionado à uma quest em algum NPC portanto precisa que haja um jogador executando o script para que funcione. Basta executá-lo enquanto o jogador estiver falando com o NPC que ele continuará aparecendo enquanto o ele estiver no mesmo mapa, se você desejar que esse ícone apareça constantemente basta utilizar *questinfo, não se esqueça que esse comando só deve ser utilizado dentro de um OnInit.
 
<header>,{ OnInit: questinfo <Quest ID>, <Icon> {, <Map Mark Color>{, <Job Class>}}; end; Os valores para 'Job Class' podem ser encontrados em npc/const.txt, são os primeiros valores.
 
Mas se você quiser que um NPC tenha esse tipo de marcador para todo jogador que logue no servidor, independente de qualquer quest, basta utilizar um OnPCLoginEvent, algo como:
 
<header>,{ OnPCLoadMapEvent: if( strcharinfo(3) == strnpcinfo(4) ) showevent <icon>{,<mark color>}; end;} Não se esqueça de marcar o mapa com a mapflag loadevent.

Just updating, dbghelp was never removed, some time ago it was ported to HPM but it wasn't fully operational, I re-ported it (https://github.com/HerculesWS/Hercules/commit/fcaef90fd4f92d78be230f6b9f40005ced72a415) and now it's working normally, all you have to do is build the dll and add the plugin.
http://herc.ws/wiki/Building_HPM_Plugin_for_MSVC

Veja https://github.com/HerculesWS/Hercules/blob/master/conf/atcommand.conf
e: https://github.com/HerculesWS/Hercules/blob/master/conf/groups.conf
 
Sobre o @AFK, até onde me lembro, este não é um comando default do emulador, por tanto, será necessário o diff dele e compatível ao emulador Hercules

File Name: GRF Editor
File Submitter: Tokeiburu
File Submitted: 20 Jun 2014
File Category: Client Resources
 
** This program has been orignally uploaded on rAthena; it's been uploaded on Hercules due to multiple requests. If you have suggestions or feedback and you want a quick response, please contact me via rAthena. I will respond on Hercules' forum as well, but it'll take a bit longer .
 
Hey everyone,
 
This is a GRF tool I started to develop for my own personnal use, but I thought I'd share it since I've upgraded the UI. Its primary goal is to be easy to use while offering a wide variety of options and customizations. The software is quite stable and can handle large operations easily.
 
How to install
Download the zip archive provided from the download link at the bottom of this description or directly from there : http://www.mediafire.com/?aflylbhblrzpz0h
Install the application with GRF Editor Installer.exe; if you are missing a .NET Framework you will be prompted to download it.
Once you are done, you can start the program from the link on your desktop.

Key features
Overall speed is faster (or at least equal) than any GRF tool.
Common operations : add, delete, merge, extract, preview, save.
Undo and redo for any operation.
It can open any GRF file.
Clean and very interactive interface.
Saving formats supported : 0x200, 0x103 and 0x102 (through the Settings page).
Instant filter and search options (example : "map .gat").
File association and context menus integration for .grf, .gpf and .rgz (through the Settings page).
Can rebuild separated images into one file easily.
Lub decompilation (in beta, but it can decompile almost any lub file so far).
Drag and drop (with the ALT key, can be modified in the Settings page). This is a big part of the software; most of the items can be moved around within the application itself or from/to Windows Explorer.

Tools
Sprite editor : a simple sprite editor with powerful features. Semi-transparent images can be added, you can easily change the order or replace images, etc. This tool can convert images in the wrong type by showing you multiple solutions (merging a new palette, dithering the image by using current palette, using the closest color, and a few more).
Grf validation : allows you to validate a GRF with multiple settings. It can detect corrupted GRF entries, invalid sprites, empty files, non-GRF files, duplicate files and a lot more.
Flat maps maker : generates flat maps from .gat and .rsw files. Useful to generate WoE maps or to fasten up the loading time.
Patch maker : generates a GRF patch based on two different GRFs.
Hash viewer : shows the hash code (both CRC32 and MD5) for files.
Image converter : converts an image to any format requested (BMP, PNG, JPG, TGA).
GrfCL : used to create batch files (.bat) which can automate tasks on GRF files. See the content in GrfCL.rar in the download for more information. This tool can be customized from the sources as well.
Palette recolorer : creates new sprites by changing their colors (this tool is now deprecated).
Client database editor : allows modifications of the database client files (txt and lua) with easy and simple tools. Work in progress.

Grf encryption
 

The encryption feature has been enabled again. It's similar to what it used to be and it has been tested on client versions ranging from 2012-08-01 to 2014-02-05. Some error messages will be displayed if necessary. If you have an issue, copy the error message (with the code, if there's one) and send me the client executable with the cps.dll file generated by GRF Editor. There shouldn't be compatibility issues anymore though!  
Technical stuff
Requires .Net Framework 3.5 (SP1) Client Profile to run (3.5 or more will work as well).
Automatically converts file name encoding to their proper values (you can change the encoding).
Data virtualization is used as much as possible to preview files, meaning the files aren't completely loaded.
Right-clicking an item will bring up the available options with that file.
Preview file formats : txt, log, xml, lua, lub, bmp, png, tga, jpp, db, ebm, pal, gnd, rsw, gat, rsm, str, spr, act, imf, fna and wav.
Services are "crash ready", meaning that you will be warned about a failed operation and no work will be lost (the application won't close and crash). It tries to continue operating even if it meets unsual conditions.
Operations can be cancelled by clicking on the button near the progress bar.
The warning level can be changed to avoid messages like "Please select a folder first."
When prompted with an error, use Ctrl-C to copy the current dialog's content.

Some screenshots!
1) Previewing an act file, while showing the search feature

 
2) Preview of a model file (rsm)

 
3) Preview of GrfCL with the MakeGrf command

 
4) Preview of the Client Database Editor

 
5) Preview of Grf validation

 
6) Search feature (press Ctrl-F or Ctrl-H to bring up within a text editor)

Sources : http://www.mediafire.com/download.php?7z6hkdag4ayj8rs
 
Got a feedback? I'd gladly hear you out and fix issues you have with the program. If you want new features to be added, don't hesitate to ask!
 
Click here to download this file

I was looking through things on kRO's website and I noticed something in the client's interface that ive never seen before. Check it out and scroll down to the first pic that shows a in-game screenshot showing a blue box at the top that appears to have a timer and counter in it. Check it out....
 
http://ro.gnjoy.com/news/update/View.asp?seq=153&curpage=1
 
After looking a bit I was able to mostly figure out what it is.
 
Original Text
 
 
Google Translated
 
 
So it sounds like this. Certain maps are marked as Gold Rooms and if you go into one of those maps that blue box will appear on your client's interface. While in the room you gain 1 point for every hour that your in there, but currently its 2 points instead due to a event going on. What im wondering about is the points being translated to Mileage. Maybe its because you have to keep moving around on the map for a full hour to get the point (Ive seen something like this in private servers already). The next line says up to a max of 300 mileage points can be stacked (hey my nintendo 3DS does the same thing with a max 300 coins limit which is gained from walking while its in my pocket).
 
The next line appears to say that you can click on the mileage tracker while in the gold room to summon the Gold Point Manager NPC. Then the last line says you can buy items from this npc using your mileage points (Mileage Points....Gold Points....make up your mind). This is something interesting and hopefully this info will be helpful with future development to add this in.

The trade system is now implemented in roBrowser (and fully working).
 

I guess what he means is that he wants pin-code to be optional, only players that request this system would have to input a PIN every time they log-in. I don't think we have such system, but it seems like a good idea...