[r15572: New GM, Commands & Permissions system]

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.

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

[r15572: New GM, Commands & Permissions system]

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.

[r15572: New GM, Commands & Permissions system]

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.

[Convert to GIT]

You can make the changes, and "commit" it to project, and anyone involved with project (developers) can approve or reject it... better than uploading or sending a diff.

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

[Regarding usebasename flag of instancing system]

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.

[New GM System]

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
}

[Stylist - a less anoying one]

is this Stylist limited to the server number of sprite of haircolor and style?..

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.

and can you make it w/ payment example you need a hairstyle ticket to get dress up?

this stylist styles you for free, not payment option implemented atm

[Stylist - a less anoying one]

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

[Removal of TXT DBs]

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

[Removal of TXT DBs]

An Admin Control Panel would solve this

and/or we could make a description in the wiki for every table

[Removal of TXT DBs]

ok, if it's just a few milliseconds slower, then i'll change my vote to option 2 now

Lets move all settings to SQL , that way we can have a Admin Control Panel to adjust rAthena settings, from a website, restart from a web site

all except the mysql options

but a Admin Control Panel website is a very good idea

[New GM System]

+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...

[Removal of TXT DBs]

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

I would suggest option 3. Most of the people out there are already comfortable with text database. Option 3 you are also free to choose between text or sql database, its just a matter of free will.

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

If we go with Option 2 (convert all databases to SQL) option 1 or 2, anything where there is more than 4 item/mob tables,

I vote for a 3rd database connection/config.

Then people can have 3 SQL databases setup like:

1. rAthena database (item, mob, mob_skill, pet, produce_db, etc..)
   
2. player data (all the tables currently in main.sql, except log tables)
   
3. logs database (all the tables currently in logs.sql, plus charlog and interlog)
   

+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