Gepard

getgmlevel() will be kept as is to provide some backwards compatibility with existing scripts. And I totally forgot about getgroupid(). I'll add it later today. It's like EvilPuncker explained. Please read conf/groups.conf, doc/atcommands.txt and doc/permissions.txt for a detailed explanation. Thanks! It is not required to update now, since it is not a security patch. This update adds a new feature, while (partially) removing old one. I recommend you familiarize yourself with new configuration files, test your new configuration on a test server and only then update your production server. And remember: backup first!

The user running rAthena doesn't have permissions to change open files limit. Did you change your FD_SETSIZE?

I eventually added "filter by group", because it resembles the previous "log above GM lv X" approach. Filtering by command can be added at later time. Now I need to fix Make/CMake stuff and should be ready to commit. It is done (well, except CMake, but I won't update this "experimental" shit) http://rathena.org/b...issions-system/ r15572 While working on it, I've noticed a few things that need to be done: cleanup Makefiles, cause they still have remains of TXT version cleanup atcommands, cause there is some hardcore copypasta happening review conf/help.txt - I did not verify all of the contents, just updated syntax so it works with new system review doc/atcommands.txt - it's also copied from conf/atcommand_athena.conf, not verified whether descriptions are accurate The last two are tasks for documentation managers.

New GM, Commands & Permissions system has been added in r15572. Unfortunately, this update is not backwards compatible with previous revisions and requires reconfiguration of existing rAthena installations. This new approach is designed for easy maintenance, increased flexibility and readability. Hopefully it will make up for migration difficulties. General description The whole concept of GMs and non-GMs as well as GM levels has been abondoned in favor of more role- and privilege-oriented player groups. Each account belongs to exactly one group. Player groups are independent of each other, so unless you decide to do so, they don't have to share any privileges like it was with top-down GM level hierarchy. There is, however, a way to say which group is higher, and which is lower: it's group level. Each group has following atributes: ID — unique number name level — it can be interpereted as (GM) level of all group members commands settings — what commands can group members use permissions settings — what other permissions group members have inherited groups — permissions and commands from which groups are inherited log commands — should commands issued by this group be logged or not Groups are configured in conf/groups.conf file. The file itself is fully documented and contains default configuration that should be adjusted to your needs. Details Column `login`.`gmlevel` has been renamed to `group_id`. It now stores ID of the group player belongs to, so you need update your database accordingly. Atcommand configuration file conf/atcommand_athena.conf no longer defines GM levels required to use the command. Permissions to use commands are now defined for each player group separately in group configuration file conf/groups.conf. Command aliases are still being defined in conf/atcommand_athena.conf. File syntax has changed. Import is no longer supported for this file. File is fully documented and contains default aliases that were present in previous revisions. GM configuration file conf/battle/gm.conf no longer defines GM levels required to get some privileges (like trading or partying). See full list of removed settings:These permissions are now defined for each player group separately in group configuration file conf/groups.conf. Player titles defined by conf/battle/gm.conf settings title_lvl1 to title_lvl8 and conf/msg_athena.conf (335~342) are replaced with group names. Removed @adjcmdlvl command. Replaced @adjgmlvl command with @adjgroup, which allows to temporarily (until relog) move player to another group. In login-server configuration file conf/login_athena.conf min_level_to_connect setting has been replaced with group_id_to_connect setting, which allows you to define account group id that is required to connect to server. In char-server configuration file conf/char_athena.conf gm_allow_level setting has been replaced with gm_allow_group setting, which allows you to define group id that is allowed to bypass the server limit of online users. In log configuration file conf/log_athena.conf log_gm setting has been replaced with log_commands setting, which allows you to decide whether commands should be logged or not. Even with command logging enabled, only commands issued by groups that have log_commands set to true will be logged. About group level Group level is used only: when determining if player can override trade restrictions defined in db/item_trade.txt when determining if player can use @command on another player (existing rule that low-level player can not use some commands, eg @kick on high-level player has been kept) or see another player with @who commands (if they have "hide_session" privilege). as a return value for getgmlevel() script command when determining if player can use commands in a map with nocommand mapflag set Other CMakeLists were not updated. If you know cmake and want to contribute, just send me (or other dev) a diff. There were multiple minor changes in this revision. For full list, see rAthena Trac (r15572) or SVN log.

Oh, it works for me too, all of the sudden. In case it matters, servicetype is america, langtype 0, version 25

It's not a discussion about whether open source is better or not, but about whether this project should/could be open sourced.

Can you post the line from msgstringtable.txt, you're using?

I'm quite sure it's a bug specific to 20100730 client. I could be fixed by hex editing probably, but I recommend choosing another Ragexe, that is not bugged.

In Renewal (and rAthena too) there are no quests for 1-1 classes.

I did 2 of missing tasks: better default setting for conf/groups.txt and updated help.txt a bit (it'll have to be reviewed again). And @help displays a list of aliases now, eg > @help help Help for command @help: Available aliases: h Params: <command> Shows help for specified command. I wonder how should I filter atcommand logging... Should this be per group, per command or both?

688

680

If the SVN-deleted file is modified in your working copy, then SVN-update on your working copy will warn you about tree conflict. Then it's up to you to clean it up. File moves don't happen very often though, and IMO cluttering db folder with .<filename>2.txt files is not a way to go.

Well, you could implement it this way, but I seriously doubt it's what you want to get. Clicking on a mob means attacking it with a normal attack (either ranged or melee), optionally with a targeted skill. AFAIK there is no way to detect right clicks or mouseover on monster in a consistent manner. Please keep in mind that it would not display HP bars of monster attacked with AoE spells. So, you could change in this way: initially do not display HP bar optionally you could display HP bars if monster that comes in sight is damaged, so its HP bar wouldn't be full [*]display HP bar only when monster is "clicked" (ie attacked or skill-targeted) & keep track of monster ID for that player optionally, you could change it to display HP bar only when monster is damaged by the player (or even better, damage by any party member) [*]when updating HP bar (on damage etc) only send packet if HP bar of that monster ID is tracked by the particular player I think this would be kinda cool feature if improved in the way described. Sorry, but no implementation details from me, just a concept.

673

rAthena uses MyISAM tables.

Use rentitem instead of getitem. For rentitem syntax, see doc/script_commands.txt

To be able to iterate over original commands only. To be able to iterate over aliases only (will be used in @help <command> to display a list of all aliases to the command). To disallow configuration of commands in groups.conf via aliases. In short to have a quick and simple method do distinguish between commands and aliases. It probably could be achieve other way (like comparing key (search name) to AtCommandInfo.command every time), but adding a separate DBMap is really simple and efficient way. I like DBMaps, and don't know of any reasons to avoid using them.

Very nice.

There is no way to keep a fix for yourself, release binaries to players and follow GPL at the same time. But I guess you don't feel like fighting with some morons over GPL. Does it mean that you're looking for team members?

No need to copy anything. Just add your custom stuff at the top of the file. Adding it at the end can indeed lead to conflicts when rA team adds new stuff at the end of file as well.

I've updated previous post http://rathena.org/b...dpost__p__76920 with some more details. Promised diff file is attached. Unfinished stuff: atcommand logging (logs all of them now) conf/help.txt (I did ~10 commands, but rest is untouched) conf/groups.conf (needs better default setup) add libconfig to Makefiles, CMake and VS9 project (only VS10 for now) Please review/test changes. It's a big update and there are chances that smth is wrong. I'd appreciate help with Makefiles/CMake and help.txt/groups.conf. gmsystem.patch

According to post # it should be 645 now. So be it.

Me too. This "central tool" is called text editor.

Just calculate total time in atcommand_char_ban. Dunno, maybe use some time-related structure type for it, or just by hand (total = hours*3600 + minutes*60 + seconds +....). If total < 0 -> deny. If total == 0 -> "no change message", if total > 0 -> request char-server to (extend) ban.