jaBote

Se não me engano, o client-side é universal para tudos os emuladores. Se ele é corretamente montado deverá funcionar sem problema no eAthena, rAthena, Hercules ou qualquer outro contanto que os pacotes estiverem no emulador e o PACKETVER corretamente configurado.

Se não me engano, o client-side é universal para tudos os emuladores. Se ele é corretamente montado deverá funcionar sem problema no eAthena, rAthena, Hercules ou qualquer outro contanto que os pacotes estiverem no emulador e o PACKETVER corretamente configurado.

Little compilation of what's were done since the last time:
 
Emoticons

 
Support @monsterbig / @monstersmall

 
Support for monster hp bar

 
Support for teleport / warp portal window (also identify and autocast skill).

 
Support for pet hunger bar

 
Add discount and overcharge (correct display)

  Can now open users shop

  Now supporting Party System (and friends /hi, /invite, /leave, /organize, change leader, expel, change configs, casting skill on names, everythings.).




  Awesome memory optimization (can now render 5x more monsters on screen).

 
And a lot of bugfixes and clean up.
Maybe others things I forget through.

Adicionando sua bgi_temp
 
1 - o que é bgi_temp
2 - Requerimentos
3 - Downloads 
4 - fazendo a bgi_temp
5 - adicionando na data
6 - créditos

1 - O que é bgi_temp:

Bgi_temp é uma imagem customizada que você adiciona na tela de login para seu servidor aparentar mais "profissionalismo"

 
Exemplo:
http://i.imgur.com/GDU544p.png

 
2 - Requerimentos

Para poder fazer seu bgi_temp personalizada você vai precisar de:

1: Uma imagem (personalizada sua) do tamanho 800x600 OU 1024x768 (recomendo a 1024x768) no formato de .BMP
2: ROLSG um programa que corta as imagens em 12 partes e renomeia automaticamente para que seu Hexed possa ler e executar!
3: Uma pasta Data (sua pasta data)

3 - Downloads

ROLSG Link 1 / Link 2 / Link 3

4 - Fazendo a bgi_temp

Depois de abaixar o ROLSG.rar extraia e execute o 1024x768 ( o que eu recomendo mais pode fazer o 800x600 ) clique em " Load " para assim abrir uma janela de busca aonde você terá que achar sua imagem que vai virar a tela de login.

LEMBRANDO:

A imagem deve ser no formato .BMP e ter o nome de bgi_temp !

Após carregar a imagem clique em Convert e aparecera 4 números 

( 1 , 2 , 3 , 4 )
"O que significa isso? "

Significa a ordem de tela de login: 1 é a principal 2 é a secundaria e assim por diante, se seu hexed estiver difado para aparecer mais de 1 tela de login faça uma imagem com o 1 e outra com o 2 se estiver apenas difado para aparecer 1 tela de login clique no "1"

Quando você clicar em um dos números ele vai mandar uma menssagem dizendo que a imagem foi repartida em 12 partes na pasta do ROLSG!
Pronto você tem sua tela de login:

5 - adicionando na data

Para adicionar a imagem na sua data é simples vá em ( data/texture/À¯ÀúÀÎÅÍÆäÀ̽º ) cole as imagens que você repartiu no ROLSG e pronto!

6- Créditos

EU por criar esse Tutorial!

I think it doesn't since mobs that are summoned by an amount of only 1 don't get affected by this conf value:
 
src/map/npc.c, line 3517
if (mobspawn.num > 1 && battle_config.mob_count_rate != 100) { if ((mobspawn.num = mobspawn.num * battle_config.mob_count_rate / 100) < 1) mobspawn.num = 1; }

En esta segunda parte, os mostrare como gatillar una función antes o después de que ocurra alguna de las funciones del emulador.
*Les voy a poner todo el código luego iré explicando:
 
- Este plugin consiste en que cuando mueres, te suelta un cráneo, pero no como el del pk mode que se activa o en todos los mapas, o en mapas pvp, pero no solo cuando mueres entre pk, es siempre que mueres, este esta dedicado solo a si te mata un player.
/* * Pluing programado por Clein para que cuando un player muera * en modo Pvp suelte un craneo, y solo sea cuando esten dos player * peliando * v 0.1! */#include <stdio.h>#include <stdlib.h>#include <string.h> #include "../common/HPMi.h"#include "../common/malloc.h"#include "../common/mmo.h"#include "../common/socket.h"#include "../common/strlib.h"#include "../map/clif.h"#include "../map/pc.h"#include "../map/guild.h" #include "../common/HPMDataCheck.h" /* should always be the last file included! (if you don't make it last, it'll intentionally break compile time) */ HPExport struct hplugin_info pinfo = { "CraneosPlayer", // Plugin name SERVER_TYPE_MAP,// Which server types this plugin works with? "0.1", // Plugin version HPM_VERSION, // HPM Version (don't change, macro is automatically updated)}; uint16 GetWord(uint32 val, int idx) { switch( idx ) { case 0: return (uint16)( (val & 0x0000FFFF)         ); case 1: return (uint16)( (val & 0xFFFF0000) >> 0x10 ); default: ShowDebug("GetWord: invalid index (idx=%d)n", idx); return 0; }} int dead_event_skull(struct map_session_data *sd,struct block_list *src){ if( !map->list[sd->bl.m].flag.gvg_castle )  { //Vemos si es humano. if(src && src->type == BL_PC) { //Vemos que no sea el mismo struct map_session_data *ssd = (struct map_session_data *)src; if(sd->status.char_id != ssd->status.char_id ) { struct item item_tmp; memset(&item_tmp,0,sizeof(item_tmp)); item_tmp.nameid=ITEMID_SKULL_; item_tmp.identify=1; item_tmp.card[0]=CARD0_CREATE; item_tmp.card[1]=0; item_tmp.card[2]=GetWord(sd->status.char_id,0); // CharId item_tmp.card[3]=GetWord(sd->status.char_id,1); map->addflooritem(&item_tmp,1,sd->bl.m,sd->bl.x,sd->bl.y,0,0,0,0); } } } return 1;} HPExport void plugin_init (void) {  /* Para map-> */ map = GET_SYMBOL("map");  /* Se ejecuta antes del evento muerte */ addHookPre("pc->dead",dead_event_skull);}En esta ocasión comenzare de abajo, por el "HPExport void plugin_init (void) {"tomare el simbolo de map para poder verificar el mapa donde esta el player, que este mercado como WoE Map.
 
Luego le diré con "addHookPre" que PREVIO a que se gatille la función "pc_dead" de pc.c, ejecute la función "dead_event_skull"
Entonces de esta forma, paso y analizo la funcion "dead_event_skull"
 
Si se dan cuenta tiene los mismos parametros que la funcion pc_dead de pc.c, ya que requiero de los argumentos.
- pregunto si esta en mapa marcado como gvg cast "if( !map->list[sd->bl.m].flag.gvg_castle )", 
- Luego si mato a un humano "if(src && src->type == BL_PC)"
- Creo una estructura con la persona que muere la llamo ssd, y luego pregunto por sus char_id, en caso que sean distintos prosigo. "struct map_session_data *ssd = (struct map_session_data *)src; if(sd->status.char_id != ssd->status.char_id )"
 
Ahora, agrege la funcion "GetWord" solo para que el compilador no tirara advertencia de declaración implícita, pero no es 100% requerido (me parece D=! xD)
 
Bueno eso es todo, la gracia de este plugin es jugar con un evento que se gatilla antes del evento general de la muerte, pueden generar uno antes o después de cualquier función prácticamente.

Bueno chicos, yo vine a este emulador en exclusiva para esto!!, por lo que voy a hacer una guía a ver si me queda mas clara para los que quieran comenzar con este sistema, que esta genial!. xD
 
Intro:
Hercules Plugin Manager (de ahora en adelante como HPM) es un sistema creado en Hercules para poder modificar el código fuente del emulador sin cambiarlo directamente, usando plugins que alteren el funcionamiento pero evitando que actualizaciones del emulador nos den problemas.
 
La documentación oficial pueden encontrarla en ingles en la wiki:
http://herc.ws/wiki/Hercules_Plugin_Manager
Y pueden encontrar plugins ya desarrollado por otros usuarios en la sección del foro "Downloads"
http://herc.ws/board/files/category/10-plugins/
 
* OJO!, que de ahora en adelante, YO voy a trabajar en Linux, por lo que la compilación es distinta, para Unix y Windows!
 
Puntos previos al código puro:
Antes de comenzar a explicar los duro, voy a dejarles un par de cosas claras, tiene que compilar para que los cambios sean efectuados.
* compilar el plugin que corresponde a "make plugins" en la carpeta del emulador.
* Los Plugins se encuentra en la carpeta plugins del src.
* Para que este sea compilado, tiene que estar anotado el nombre del archivo en src/plugins/Makefile.in en MYPLUGINS, sin .c y separado por espacios entre los que tengas.
* Para que este sea utilizado por el emulador, tendremos que agregarlo en el archivo conf/plugins.conf, en plugins_list.
 
Comenzando con nuestra creación:
** Estructura general:
<includes varios><struct de HPExport, con detalles del plugin><Funciones de todo tipo><Sistema de carga del plugins>   
Para comenzar, como lo dije anteriormente, tenemos que crear nuestro archivo en src/plugins "nombre del archivo.c", es recomendado incluir estos elementos antes de comenzar:
// Copyright (c) Hercules Dev Team, licensed under GNU GPL.// See the LICENSE file// Sample Hercules Plugin#include <stdio.h>#include <stdlib.h>#include <string.h>#include "../common/HPMi.h"#include "../common/malloc.h"#include "../common/mmo.h"#include "../common/socket.h"#include "../common/strlib.h"#include "../map/clif.h"#include "../map/pc.h"#include "../map/script.h"#include "../common/HPMDataCheck.h" /* should always be the last file included! (if you don't make it last, it'll intentionally break compile time) */ para poder ir trabajando.
 
Seguido, se suele agregar la descripción del plugin:
HPExport struct hplugin_info pinfo = { "NOMBRE DEL PLUGIN", // Plugin name SERVER_TYPE_MAP,// Which server types this plugin works with? "0.1", // Plugin version HPM_VERSION, // HPM Version (don't change, macro is automatically updated)}; Ahora puedes poner las funciones que os apetesca (RECUERDA QUE ESTO ES C!, y tienes o tendrías que tener algún conocimiento básico del lenguaje, ya que entre punteros y memoria mal asignada podrías hacer que el emulador se crache!!.
 
Existen 'funciones' básicas para trabajar (Para este ejemplo trabajare creando un comando, y a medida que pueda ire creando mas ejemplos).
Por ejemplo "ACMD" que agrega un comando (cuando digo comando, me refiero a lo de los GM @baselvup,@job, etc)
A esta función se suele poner el comando que deseemos ejecutar como parámetro,  y las versiones mas actuales permiten la sobre carga del comando, si existe en atcommand.c, la ultima cargada sera quien se quede como fija.
 
Para este ejemplo voy a trabajar con el primer plugin que realice, que consiste en modificar el comando @changegm para evitar que se utilice en medio de WoE.
 
La función original de este comando es la siguiente:
/*========================================== * @changegm by durf (changed by Lupus) * Changes Master of your Guild to a specified guild member *------------------------------------------*/ACMD(changegm) { struct guild *g; struct map_session_data *pl_sd; if (sd->status.guild_id == 0 || (g = sd->guild) == NULL || strcmp(g->master,sd->status.name)) { clif->message(fd, msg_txt(1181)); // You need to be a Guild Master to use this command. return false; } if( map->list[sd->bl.m].flag.guildlock || map->list[sd->bl.m].flag.gvg_castle ) { clif->message(fd, msg_txt(1182)); // You cannot change guild leaders in this map. return false; } if( !message[0] ) { clif->message(fd, msg_txt(1183)); // Usage: @changegm <guild_member_name> return false; } if((pl_sd=map->nick2sd((char *) message)) == NULL || pl_sd->status.guild_id != sd->status.guild_id) { clif->message(fd, msg_txt(1184)); // Target character must be online and be a guild member. return false; } guild->gm_change(sd->status.guild_id, pl_sd); return true;} Ahora, lo que yo quiero evitar es que me cambien el Guild Recaller en medio de WoE por lo que:
if (pc_get_group_level(sd) != 99) { if (map->agit_flag == 1 || map->agit2_flag == 1) { clif->message(fd,"Estamos en WoE!, usted no puede cambiar el lider"); clif->message(fd,"Now is WoE Time!, you can't edit Guild Leader"); return false; } } **Lo dejo para que si no pertenece al grupo 99, no puede cambiar el leader, esto lo agrego a mi nueva función lo que seria:
/*==========================================* ChangeGM no WoE now...*------------------------------------------*/ACMD(changegm){ struct guild *g; struct map_session_data *pl_sd; //Vanadium Edition if (pc_get_group_level(sd) != 99) { if (map->agit_flag || map->agit2_flag) { clif->message(fd,"Now is WoE Time!, you can't edit Guild Leader"); return false; } } //End Vanadium Edition if (sd->status.guild_id == 0 || (g = sd->guild) == NULL || strcmp(g->master,sd->status.name)) { clif->message(fd, msg_txt(1181)); // You need to be a Guild Master to use this command. return false; } if( map->list[sd->bl.m].flag.guildlock || map->list[sd->bl.m].flag.gvg_castle ) { clif->message(fd, msg_txt(1182)); // You cannot change guild leaders in this map. return false; } if( !message[0] ) { clif->message(fd, msg_txt(1183)); // Usage: @changegm <guild_member_name> return false; } if((pl_sd=map->nick2sd((char *) message)) == NULL || pl_sd->status.guild_id != sd->status.guild_id) { clif->message(fd, msg_txt(1184)); // Target character must be online and be a guild member. return false; } guild->gm_change(sd->status.guild_id, pl_sd); return true;} Ahora hace falta designarle como va a iniciar el plugin, existen 4 formas:
[*]void plugin_init (void) [*]Se inicia cuando se inicia el server.
[*]void plugin_final (void)
[*]Se inicia cuando el server se cierra a si mismo.
[*]void server_ready (void)
[*]Se activa cuando el server esta iniciado y online
[*]void server_post_final (void)
[*]Antes de que se cierre por completo, los controladores de memoria siguen activos.



Cada uno de estos puntos tiene sus funciones y dependiendo de lo que quieran hacer es como debe ser implementado.
Para este caso lo quiero cuando se inicie el server, por lo que, lo dejare de esta forma:
 
/* run when server starts */HPExport void plugin_init(void) { /* Para map-> */ map = GET_SYMBOL("map"); /* Para clif-> */ clif = GET_SYMBOL("clif"); /* Para para guild-> */ guild = GET_SYMBOL("guild"); /* Para msg_txt() */ atcommand = GET_SYMBOL("atcommand"); /* Agregamos el comando */ addAtcommand("changegm", changegm);} Como ya se habrán dado cuenta, deje 4 variables nuevas, map, clif, guild y atcommand, estas son tomadas de los procesos actuales, para poder usar las estructuras, una forma mas simple de verlo es que en mi codigo del comando, existen momentos en que uso "map->agit_flag" lo que tiene que hacer es llama al simbolo que tiene map, en este caso:
map = GET_SYMBOL("map"); y así con el resto.
 
Por ultimo, agregamos el comando, para eso utilizamos "addAtcommand("<comando>", <nombre función ACMD>);
OJO!, que si el nombre esta repetido lo sobrecarga.
addAtcommand("changegm", changegm); De esa forma, nuestro primer plugin esta listo:
 



** Esta Guia no esta lista, y pretendo ir agregando mas funcionalidades del sistema HPM a medida que yo mismo valla programando y creando lo que requiero.

For the records: this (still unaccepted) suggestion has also been requested on Spanish section: http://herc.ws/board/topic/6782-emblema-transparente-guild/
 
We've got Annie's implementation, so it shouldn't be quite hard to implement it if we eventually decide to include this script command. I'll refrain from voting since I see its usefulness but I don't see plenty of use cases for it.

I'm on phone right now, but maybe this will help you:
www.linux.com/learn/tutorials/760276-how-to-manage-file-and-folder-permissions-in-linux
 
You should have permissions in your home folder by default (I think, not Linux expert), dunno how you don't. You should add proper read, write and execute permissions on your home.

This could be a nice diff to get added in NEMO (/me rolls eyes)

You need to hex your client..
 
Find this:
4E 43 5F 43 61 73 68 53 68 6F 70and replace with00 00 00 00 00 00 00 00 00 00 00This would disable cashshop. 
* back up your client first just in case something goes wrong.

idea from here: http://herc.ws/board/topic/3257-aegis-showscript-command/?p=21640
 
*showscrpt("<message>"{,<GID>}); This script will display the output message on top of the units Head
If an optional GID is specified, msg will be shown on specified units head.
if GID isn't specified or target not exist, msg will be shown on the invoking character
if GID isn't specified and there is no player attached, msg will be shown on npc's head
 
example:
prontera,120,120,2 script bla 120,{ showscript("plz input an online player's name!"); input .@name$; .@tgid = getcharid(3,.@name$); showscript("this is a test!",.@tgid); close;OnInit: showscript "I m npc bla";end;}  

download:
 
showscript.c

Name of the compiled plugin is costumeitem, not customeitem. It seems you've screwed since you've made customeitem but the name is costumeitem.
 
Please check you've named it correctly in your src/plugins folder, makefiles and the conf, then retry.
 
If still not solved, please check that the plugin gets made in your /plugins directory.

Not possible in current scripting, but could be a neat plugin addition

It depends on what you want. Keep in mind that if you ask this here and in rAthena, you'll get here replies that say "Hercules is better" and in rAthena forums you'll be told that "rAthena is better". Correct reply is "Hercules is better in some ways, rAthena is better in some other ways".
 
We don't get any commission or whatever based on users, (unlike rAthena we don't even place adverts on our pages), but it's an administrator preference.
 
Here in Hercules we have the fastest and most optimized Ragnarok Online emulator to the moment and there's no possible argument to this: you can run the map server on 70 MB RAM, while rAthena consumes around 200 MB on an idle state. Anyways, this varies on the amount of maps and NPCs you load on your server, and in the amount of users you have. It's also a fact that Hercules consumes much less processing time than rAthena, but I'm not aware of how much. This also means Hercules boots faster than rAthena and has some caching system for even faster boot at the cost of some disk space. Note that these measures also vary depending on the OS you're using
 
Hercules has some features that rAthena doesn't, and vice versa. For example we have an anti WPE security system (depends on client version) and some unique features (some of them were also merged in rAthena). The same happens on rAthena side, but I'm not well informed on that.
 
Emulator stability is comparable, but since in Hercules we introduce and make more features it's quite obvious we are a bit riskier on that and may crash a bit more. Anyways, our bug fixing is way faster than rAthena. We're also comparable in emulator support, too, but I believe we've more answered topics in relation to our total amount that rAthena.
 
The biggest flaw I can see out there is on the scripting and db development side, since rAthena is more active than us on that side (in fact, we seriously lack on them). Anyways, you can generally import all of them here with very little to no effort, most cases it's just a copy and paste issue and they'll work. We're also lifting some IMPORTANT scripting limitations at the moment and have no information of rAthena doing that at the moment.
 
We've also support for the last 3rd job skills while rAthena doesn't (with good formulas but still not perfect), but neither of us have Rebellion yet.
 
And we've also have a plugin system that allow you to make new features without the need of creating conflicts in the source code when updating. Anyways I still don't know why third party devs like eAmod still don't want to support us because it's pretty damn easy to do that with the plugin system which was specifically designed for them. I prefer to think they're lazy bums and only want to sell, because in eAmod case they tell you they support Hercules but then when you buy it they tell you it's still in merging process (it's been like 3 months merging, seriously?). Anyways, it's not that I personally like that much people getting rich at the cost of our free emulator.
 
In short, if you want my opinion:
 
Performance: Hercules
Stability: If you mind it over all other things, use rAthena because it's slightly more stable but not much. Else it doesn't quite matter.
Support: Hercules for bug fixing, doesn't matter for forum support.
Development of new features: Hercules
Development of scripts: rAthena (but you can just copy them over here most of the cases).
Third party support: Still rAthena.

Eu não sei muito de português, mas espero que somente dizendo o nome dos arquivos você poderá fazer isso.
 
Adicione o nome do mapa ao final dos arquivos /conf/maps.conf e /db/map_index.conf conforme a estrutura existente.
 
Para refazer o mapcache utilize WeeMapCache e adicione o mapcache existente e o seu grf atual do cliente e salve e sobrescreva (faça um backup previamente). O mapcache existente é na pasta db/re se usa renovação ou no db/pre-re em outro caso.
 
O seu novo mapa deveria estar pronto para usar. Somente faltaria ter um mapa e a edição dos arquivos do cliente para evitar a aparição do mensagem "mapa desconhecido" usando /where e outros problemas leves.

Eu não sei muito de português, mas espero que somente dizendo o nome dos arquivos você poderá fazer isso.
 
Adicione o nome do mapa ao final dos arquivos /conf/maps.conf e /db/map_index.conf conforme a estrutura existente.
 
Para refazer o mapcache utilize WeeMapCache e adicione o mapcache existente e o seu grf atual do cliente e salve e sobrescreva (faça um backup previamente). O mapcache existente é na pasta db/re se usa renovação ou no db/pre-re em outro caso.
 
O seu novo mapa deveria estar pronto para usar. Somente faltaria ter um mapa e a edição dos arquivos do cliente para evitar a aparição do mensagem "mapa desconhecido" usando /where e outros problemas leves.

Just repair the table. Google how to repair a MySQL table for that.

It happens when forcing server quit while it's running a SQL query. Can happen with any table on any database, bit it's more frequent to happen with log tables since server logs lots of things.
 
PS: moving to General Server Support

Utilize screen.
 
Instalação (se não é já instalado):
apt-get install screen (se não usa CentOS)
yum install screen (em caso apt-get não funciona)
 
Você pode utilizar esse comando para iniciar o server:
screen -amdS <nome para a screen> <arquivo>
 
Para recuperar o processo aberto pela screen você pode utilizar:
screen -r <nome da screen>
 
E para fechar uma screen sem forzar o cierre do processo utilize:
Ctrl+A, después D (a regra mnemotécnica para mim é AD, um anúncio em inglês)
 
Você pode fechar uma screen e recuperar-la as vezes que deseje.
 
Por exemplo:
screen -amdS map ./map-server
screen -r map
 
Edito: tudo esto é obviamente para sistemas Linux.

It's better if you took your calculator (even Windows calc!), copy the number and paste it in decimal, then change representation to hexadecimal. You'll instantly have your bitmask in hexadecimal, making you easier to understand.

¿De la DB en SQL? Vaya, soy yo el que se ocupaba de eso. Hay un upgrade de eAthena a Hercules (simplemente actualiza la DB de eAthena al máximo, aplicar el upgrade y luego aplicar cada uno de los ficheros de upgrade desde el principio).
 
Para hacer upgrade de rAthena a Hercules (en verdad es un convertidor, aunque lo he llamado upgrade porque así se llama la carpeta inicial) simplemente tienes que ejecutar los convertidores que hice. No están actualizados, aunque tengo un par de horas de PC ahora mismo y trataré de actualizarlos ya si tengo tiempo.
 
¡Voy al lío!
 
P.D.: En verdad PC tengo, lo que no tengo es Internet de momento y parece que va para largo, tengo que moverme de mi casa a un sitio para poder robar utilizar conexión wifi amablemente cedida por los vecinos

Yea, and right now it's made the same way you make mobs on any other Athena based server.

It depends on what you want. Keep in mind that if you ask this here and in rAthena, you'll get here replies that say "Hercules is better" and in rAthena forums you'll be told that "rAthena is better". Correct reply is "Hercules is better in some ways, rAthena is better in some other ways".
 
We don't get any commission or whatever based on users, (unlike rAthena we don't even place adverts on our pages), but it's an administrator preference.
 
Here in Hercules we have the fastest and most optimized Ragnarok Online emulator to the moment and there's no possible argument to this: you can run the map server on 70 MB RAM, while rAthena consumes around 200 MB on an idle state. Anyways, this varies on the amount of maps and NPCs you load on your server, and in the amount of users you have. It's also a fact that Hercules consumes much less processing time than rAthena, but I'm not aware of how much. This also means Hercules boots faster than rAthena and has some caching system for even faster boot at the cost of some disk space. Note that these measures also vary depending on the OS you're using
 
Hercules has some features that rAthena doesn't, and vice versa. For example we have an anti WPE security system (depends on client version) and some unique features (some of them were also merged in rAthena). The same happens on rAthena side, but I'm not well informed on that.
 
Emulator stability is comparable, but since in Hercules we introduce and make more features it's quite obvious we are a bit riskier on that and may crash a bit more. Anyways, our bug fixing is way faster than rAthena. We're also comparable in emulator support, too, but I believe we've more answered topics in relation to our total amount that rAthena.
 
The biggest flaw I can see out there is on the scripting and db development side, since rAthena is more active than us on that side (in fact, we seriously lack on them). Anyways, you can generally import all of them here with very little to no effort, most cases it's just a copy and paste issue and they'll work. We're also lifting some IMPORTANT scripting limitations at the moment and have no information of rAthena doing that at the moment.
 
We've also support for the last 3rd job skills while rAthena doesn't (with good formulas but still not perfect), but neither of us have Rebellion yet.
 
And we've also have a plugin system that allow you to make new features without the need of creating conflicts in the source code when updating. Anyways I still don't know why third party devs like eAmod still don't want to support us because it's pretty damn easy to do that with the plugin system which was specifically designed for them. I prefer to think they're lazy bums and only want to sell, because in eAmod case they tell you they support Hercules but then when you buy it they tell you it's still in merging process (it's been like 3 months merging, seriously?). Anyways, it's not that I personally like that much people getting rich at the cost of our free emulator.
 
In short, if you want my opinion:
 
Performance: Hercules
Stability: If you mind it over all other things, use rAthena because it's slightly more stable but not much. Else it doesn't quite matter.
Support: Hercules for bug fixing, doesn't matter for forum support.
Development of new features: Hercules
Development of scripts: rAthena (but you can just copy them over here most of the cases).
Third party support: Still rAthena.

Vistos os dados, a consulta SQL você deveria fazer é a seguinte:
SELECT p.`name`, p.`kills`, c.`class` FROM `pvpm_data` p LEFT JOIN `char` c on p.`id` = c.`char_id` WHERE p.`type` = 0 ORDER BY p.`kills` DESC LIMIT 50  
Teste, e voçê me dizer.