jaBote

You can already do this, but you'd have to reboot the server by using these settings located at login-server.conf: // Required account group id to connect to server.// -1: disabled// 0 or more: group idgroup_id_to_connect: -1// Minimum account group id required to connect to server.// Will not function if group_id_to_connect config is enabled.// -1: disabled// 0 or more: group idmin_group_id_to_connect: -1

Ind just leveled up today! Happy Birthday!

For most purposes, if not all, you should use the master branch the other branches are meant for development purposes except the rAthena branch, that is what we use for merging commits by its staff (if ever needed)

I don't know if after the last plugin ("afk" in this case, you should put either a colon (,) or semicolon ( for the plugins to work. Try with a semicolon first because it's what it sounds more logical for me.

This topic has completely fallen into oblivion. I suppose it'd be better to rely on our wiki for things like this because you won't depend on a given user for updatign the feature table. Anyone wants to make this on the wiki?

Only way to do that is changing the SRC config, (just the renewal ASPD config, #define RENEWAL_ASPD), or modifying the code the source in which that config appears so that it suits your needs.

Please, copy and paste here the compiler error reports so that we can figure out what's wrong.

I'm no expert on clients, but I suppose you could get better help if you post the diffs you've used to hex your client.

If you are sure that file hasn't been changed you can either revert the local changes and try to pull or just commit that and pull anyways. Be sure to have a backup before doing anything, just in case you break something. Or you can use git diff (just that, in the console) to see what is changed on the file. More info: http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository Hope this helps, nobody here is git expert but we'll try to do whatever we can for helping you

I think this one request could be a nice idea. I've already been for which features a particular client has and/or for reccomendations for choosing a client in the Spanish Section and I think I can extrapolate this to the rest of the people, which are just unsure what client version sits their needs best. Sadly, I'm not very good on the client side, so I usually end up reccomending 2012-04-18 (2012-04-10 if they don't like having to manage all items on LUA files) client when I'm asked for a particular client date and that mostly I don't know what's up on a client from a particular date. What do you think about tracking client features? This way we can easily refer to this (or whatever topic this feature tracker is made) and speed up support on clients. I mean, we start on a given ragexeRE date (maybe starting from 2011-08-17 ragexeRE clients onwards since this is the first client to support packet encription on Hercules?) listing its main capacities (text/LUA item database tables, mail system, etcetera) then noticing only the changes from previous clients and maybe individually noting the Hercules packet encription compatibility and/or if it's already supported by the emulator. And we'd also have another sort of a "timeline" for ragexe clients. For example: And quite the same for ragexe clients. I don't know if I have explained myself well. I hope someone with client knowledge could make this so that we could orient a bit better. Thanks!

Whops, my bad. I tried to nest some block comments and the first /* was gone with the very first */, so there was a lot of place for syntax errors on those lines. This, ladies and gentlemen, is what happens when you spend some years without using pure C and you haven't available any validating tool on reach. I'm so sorry about this. Edit: This has recently been fixed by a dev, so sorry again.

Y esto, señoras y señores, es lo que ocurre cuando llevas sin tocar C durante casi 3 años y no haces la modificación desde ningún programa que te coloree la sintaxis ni tienes herramientas para probar que lo que haces sea correcto. Mil disculpas.

La modificación más reciente de skill_tree.conf la hice yo hoy mismo, hace alrededor de 13 horas, en que simplemente añadí un poco de documentación al archivo, en un gran comentario en bloque en su "código". No sé si ese puede ser el problema, aunque si es así simplemente elimina mi información añadida e intenta iniciar de nuevo el servidor. En caso de que sea ese el problema, eliminaré la documentación in situ y la colocaré en la carpeta /doc/skill_tree.conf donde seguro no habrá problemas. En caso de ser ese el problema he de disculparme con total sinceridad, pues en estos días no tengo disponibles herramientas de Git ni de compilación y testeo del emulador y no he podido darme cuenta de ello. ¡Un saludo!

Which will only take out the bots not in constant surveillance by their respective owners

enablenpc/disablenpc don't do that. It just makes the target NPC (already loaded) visible or invisible to users so that they can trigger it. It doesn't load or unload an NPC to/from memory. The @loadnpc command (and the loadnpc script command if made) takes a route to a script file and loads all its mapflags, mob spawns, warps and/or NPCs. I'll try to make those commands as plugins whenever I have time for that.

Yeah, it could be a good idea, but its resource cost may result a bit high. Maybe someone could conduct some experimentation on this? Anyways, if you want to make new cutins (even from existing ones) you don't need to hex your client. You only have to take files from your GRF, edit them and put them back on your custom server's GRF. Read this piece of description from doc/script_commands.txt Just remember that and you'll be fine when making your 2 NPC sprites to be together. You can even use MSPaint for this.

What I can think of is like making an NPC event attached to the NPC that while speaking to it, just alternates between both cutins very quickly and when you press next or close it just stops. This way you get an illusion of having both cutins at the same time, but consumes a lot of resources.

Yeah, this could remove some cumbersomeness that makes trying to restrict that from your GMs by other means. On my side, I made an unequippable headgear which weighed 111% the original GM's weight capacity, and assigned it to the GM via the DB then removed any statpoint left. This way the GM had all those permissions applied because it was 1/1 novice without even basic skills.

If possible, I'd add a suggestion to this suggestion, and it's making an extra conf for the idle timers. It'd be a nice idea to choose whether self skills reset that timer or not. I've seen a lot of AFKchemists skip anti-idle systems with this.

I agree with it: Easier to use Easier to make new official and custom related items without needing to code and recompile

I've added that documentation myself. Thanks! Sorry for having to split that into 2 commits, but I haven't git tools atm. P.S.: Ind, if you see anything wrong, please edit me!

Aunque bueno, dada la tendencia a "pluginizar" todo, ya va siendo hora de hacer de esto un plugin, ¿no?

I'm on cellphone so I can't give you a full reply. As a temporary solution, you can just head to db/(pre-)re/item_db.txt then search for the Maya purple card. On its script field you should add a mapflag comparison. something like this: if (!getmapflag(strcharinfo(X), mf_pvp) && !getmapflag(strcharinfo(X), mf_gvg)) {original_Maya_purple_script;} I haven't the value of x right now, but I think it's 3. Go to /doc/script_commands.txt to look for the strcharinfo command help and take the value of the script command that returns char's current map. You should also chech if I used getmapflag correctly, of which I'm almost sure.

Hi! Could you please file a bug report on this? This way devs will get what's wrong on there faster. Thanks!

Moving to Accepted Suggestions since this has already been implemented.