Gepard

http://www.mediafire.com/download.php?dca73g0o1gdpivg

Another idea is to add a `level` to group definition file. It would be a way to order groups, so that only higher level group could @kick lower level, but not the other way. This could also provide a backwards compatibility for scripts - most of the use something like if (getgmlevel()) or if (getgmlevel()>=99).Just set "level" = 99 for the top group and done

Next time just use http://www.downforeveryoneorjustme.com/eathena.ws

View New Content > Other > Filter by forum (bottom-left) > Mark all forums except the ones you don't want to follow > Save > Profit???

I assumed OP is just looking for the script or hints where to find the requested feature and not actual letter-by-letter instructions what to type and where. Sorry for confusion.

You mean the fankit_all.zip from kRO FTP? Here: http://www.mediafire.com/?3cc18go4qrjgxdi

Stock refiner has this feature.

I think only *.sql scripts should be organized in the same fashion as db folder. I don't see any reason to rename tables.

Error #1: There is missing script file defined in one of *conf files, probably npc/scripts_custom.conf. Either remove it from conf or copy the script to the correct path. Error#2: Most probably this error is because of error #1. NPC is missing because it was in the missing file.

try make clean

It would be reasonable to make a transition period, where GM level funcionality would be still available but marked as deprecated, throwing Warnings and stuff every time it's used.

This topic never intended to do this, but I think we are all in for this suggestion if anybody can provide a way to do this because at the momemt the GM levels are saved in login db which is account specific. For that purpose there would be another table needed to specify which account/character/guild should be aligned to which group. The only problem would be the compatibility to the Control Panels and stuff. No, that's bad idea. Things like that should not be saved in config file, but in SQL database. Solution is to add `GM_level` (or `group`) field to `guild` / `char` table. However I don't really see a scenario where adding it to single characters is necessary.

So yes, I think we could add this if it's reworked. And we also need to sort out possible license issue with that GeoIP data.

You need to announce the torrent on a tracker or few, eg http://publicbt.com/

Sorry for late response. It's the original setup executable, it's already said in opening post.

IMO at the moment it is not worth doing it. For those who want to protect their servers, there are paid solutions that do their job decently. This is harsh, but if you can't afford, it's not developers' fault. Most vulnerabilities can't be closed efficiently if you don't protect the game client too. It's not our job to fix Gravity's client. If there ever will be a decent opensource RO client, then we should reconsider providing security measures in conjunction with said client.

Proposal: config file to define groups <group_id>:<group_name>{:<inherit_from_another_group_id>} atcommand_conf - use group names instead of levels gm_conf - use group names instead of levels login table - `group_id` instead of `level`

1. It's atcommand_conf.txt, not atcommands. 2. Paste the exact error message.

And database (if you insist) doesn't mean "put me to SQL". TXT is easier to manipulate with. Using *.sql files will make it harder to develop, edit, compare merge into running servers etc. Editing SQL requires additional GUI tools (not everyone wants to open SQL connection or install pma) or lots of overhead (typing queries!). TXT files can be edited locally and copied over, can be put into svn and svn update will merge deploy them. SQL scripts must be manually imported into dbms - again more work... I can see absolutely no advantage of SQL over TXT in this case.

DB folder is a config. Nothing is written to it at runtime, so it's not a real database.

Sounds like one of a few features that are actually worth working on.

Here's my version of it. autolootitem.patch

Yes, it has BGM.

A bit off topic, but the easiest way to track abusers is to use some kind of shield/anti-cheat software/addon with Hardware ID recognition. Doing it by IP (or IP-range, which is essentialy how ip-geolocation works) won't be reliable anyway, so it looks like a waste of time to me.

I don't think it's cooked enough to be included in rAthena. There is no documentation for that GeoIP.dat file, the way it's handled (ip->country translation) looks quite awful (consider using built-in DB system maybe?), and I definitely would consider moving SQL queries to char-server.