saithis

Isn't it missing 3rdparty/libconfig/CMakeLists.txt file? Cause I get CMake Error at 3rdparty/CMakeLists.txt:51 (add_subdirectory): The source directory /cygdrive/x/SERVER/RATHENA/svn/trunk/3rdparty/libconfig does not contain a CMakeLists.txt file. sorry, somehow "svn diff" doesn't include added files :/ here is the missing file: CMakeLists.txt

Wikipedia can explain it better than i could: http://en.wikipedia.org/wiki/CMake I use it because the normal "make clean && make sql" stops with an error all the time and i couldn't get it fixed. But compiling with the use of CMake works.

Here is an update for CMakeList: CMakeList.diff I have done it by trial and error (never used CMake bevore...), so I have no clue if it works on all systems, but at least it works on my server.

Doesn't the first part sound exactly like subversion? In addition, it has the diff option, but you're not forced to use it. Or do you mean that anyone, even without access to the CVS, can commit changes and the rAthena developers have to decide whetever a commit will be accepted or not? Yes, everyone can send pull requests (pending commits) and the developpers can either accept (commit), or refuse them. Here a example how this looks like: https://github.com/symfony/symfony/pulls

When the 3rd parameter of the script command instance_attachmap is set, the server sends the normal mapname to the client instead of <instance number>@mapname. This was implemented for 2 purposes: 1. make the instancing system usable on old clients, that lack the instancing support 2. to make custom scripts possible, which use normal maps as a instance (for example: instanciate prontera for a special event) Some time later the instance system was changed, so that users get redirected to their instance, when a script tries to warp them to the basemap. That change more or less made the usebasename flag useless for custom scripts, since the basemap would get unuseable when creating the instance. So I think this flag should either be removed, or it should be fixed. One possibility to fix this would be to disable the redirects, when the usebasemap flag got set. The custom scripts would have to use has_instance() to get the mapname before they warp the player. I would prefer to fix it, instead of removing it. Edit: I just realized, that you can workaround this issue by duplication the map and then instancing it. So i case someone uses this way, it shouldn't be removed for backwards compatiblity.

I think it would be better to have the commands and configs with true or false setting in the groups. That way we could revoke a permission from a inherited group. Example: gamemaster { permissions { can_trade: true, // ... } //... } supporter { commands { autotrade: true, iteminfo: true, // ... } permissions { can_trade: false, // overwrites 'true' of the gamemaster group // ... } inherit: gamemaster }

It reads the servers min_hair_style/max_hair_style, min_hair_color/max_hair_color, min_cloth_color/max_cloth_color configs for the min and max numbers, but you can also replace the getbattleflag calls with your custom numbers. this stylist styles you for free, not payment option implemented atm

Stylist This Stylist allows you to easily change your hairstyle, hair color or cloth color without spamming you with useless text and questions. You can either directly input the number of your prefered style, or go through them one by one. You can even go back in the list, if you want to see a previous style again. Download stylist.txt Mirror

With sql DBs it's much easier to integrate the data into websites. For example a PHP script to view the logs and join them with the killed mob, or the looted item, or a site where the users can view the available ptes and such stuff. At the moment you need to convert the data to a sql db to use them in a website

An Admin Control Panel would solve this and/or we could make a description in the wiki for every table

ok, if it's just a few milliseconds slower, then i'll change my vote to option 2 now all except the mysql options but a Admin Control Panel website is a very good idea

+1 for a new GM system, but please don't use that snippet xD That was one of the first things i coded in C and it is really ugly code. And I would prefer something without bitflags, as they aren't beginner friendly at all...

PRO SQL: - easier to edit - easier to use in websites/CPs [optional] CON SQL: - tool needed for editing (but since txt support for the player db gets dropped, you need that anyway) - slower serverstart (or i'm wrong here?) please correct me if i got something wrong i voted for option 1, but please with a 3rd database Agreed with him, it's better to choose Option 3 since not all of the users are in favor of SQL, they only want a plain TxT server and im one of them.. TxT servers can also used in testing new stuffs coz not all stuffs that can be added on rAthena needs SQL right? Free will guys, free will.. ~Lecks txt server support will get dropped (see here), so thats no excuse. you have to learn sql anyway, or stop hosting a ro server +1 to this, I only disagree to the ditching of mob_db,mob_db2,item_db,item_db2 text coz I dont want to expose the Item and Mob database that the server use in the website or in the CP. If the mob_db,mob_db2,item_db,item_db2 will be move to a separate database then I agree of ditching the text. i agree with a 3rd database, but you could also make a new mysql user for your website, that has only the rights for a subset of the tables. so even without a 3rd db, you don't have to expose all tables