Jump to content

  •  

Photo

r15572: New GM, Commands & Permissions system


  • This topic is locked This topic is locked
74 replies to this topic

#1 Gepard

Gepard

    The Eyes of Truth

  • Community Contributors
  • 384 posts
  • Gender: Male
  • Location: Wroclaw, Poland

Posted 12 February 2012 - 08:14 PM

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.

  • 14

#2 EvilPuncker

EvilPuncker

    Deviling

  • Members
  • PipPipPipPipPipPipPipPip
  • 710 posts
  • Gender: Male
  • Location: not mars

Posted 12 February 2012 - 08:59 PM

very nice and flexible, btw what about a new alias to the getgmlevel() command, because seems like that is the only thing that "remained" from that update ;) I know that changing it would give some headache to some users, but creating an alias would be a nice idea, like getgroupid()
  • 0

#3 xXAkatsukiUchihaXx

xXAkatsukiUchihaXx

    Santa Poring

  • Members
  • PipPipPip
  • 87 posts
  • Gender: Male
  • Location: Canada

Posted 12 February 2012 - 09:05 PM

What's the difference?

  • commands settings — what commands can group members use
  • permissions settings — what other permissions group members have

  • 0

#4 EvilPuncker

EvilPuncker

    Deviling

  • Members
  • PipPipPipPipPipPipPipPip
  • 710 posts
  • Gender: Male
  • Location: not mars

Posted 12 February 2012 - 09:07 PM

What's the difference?

  • commands settings — what commands can group members use
  • permissions settings — what other permissions group members have

well, commands are commands, and permissions are those old settings i think:

lowest_gm_level, atcommand_gm_only, gm_all_skill, gm_all_equipment, gm_skill_unconditional, gm_join_chat, gm_kick_chat, gm_can_party, gm_cant_party_min_lv, gm_cant_drop_min_lv, gm_cant_drop_max_lv, disp_hpmeter, hack_info_GM_level, any_warp_GM_min_level, who_display_aid, gm_viewequip_min_lv, gm_check_minlevel
  • 0

#5 Matheus

Matheus

    Drops

  • Community Contributors
  • 38 posts
  • Gender: Not Telling

Posted 12 February 2012 - 09:22 PM

Good job dude ! I loved the new structure of config files. Congratulations.
  • 0

#6 simplynice

simplynice

    Santa Poring

  • Members
  • PipPipPip
  • 91 posts

Posted 12 February 2012 - 11:49 PM

is this required to be patched in our server?
  • 0

#7 Gepard

Gepard

    The Eyes of Truth

  • Community Contributors
  • 384 posts
  • Gender: Male
  • Location: Wroclaw, Poland

Posted 13 February 2012 - 04:41 AM

very nice and flexible, btw what about a new alias to the getgmlevel() command, because seems like that is the only thing that "remained" from that update ;) I know that changing it would give some headache to some users, but creating an alias would be a nice idea, like getgroupid()

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.

What's the difference?

  • commands settings — what commands can group members use
  • permissions settings — what other permissions group members have

It's like EvilPuncker explained. Please read conf/groups.conf, doc/atcommands.txt and doc/permissions.txt for a detailed explanation.

Good job dude ! I loved the new structure of config files. Congratulations.

Thanks!

is this required to be patched in our server?

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!
  • 0

#8 Wildcard

Wildcard

    Drops

  • Community Contributors
  • 28 posts
  • Gender: Not Telling

Posted 13 February 2012 - 06:19 AM

Good changes, but may I suggest adopting the import-tmpl/import logic for this file as well, since if one file violates the concept, it's pretty much moot ;)
  • 1

#9 Mr. No One

Mr. No One

    New Member

  • Members
  • Pip
  • 2 posts
  • Gender: Not Telling
  • Location: Hungary

Posted 13 February 2012 - 06:56 AM

How should I compile? It fails with a bunch of libconfig related output on OSX Server 10.5. I had no issues with compiling before.


  • 0

#10 Gepard

Gepard

    The Eyes of Truth

  • Community Contributors
  • 384 posts
  • Gender: Male
  • Location: Wroclaw, Poland

Posted 13 February 2012 - 08:23 AM

Good changes, but may I suggest adopting the import-tmpl/import logic for this file as well, since if one file violates the concept, it's pretty much moot ;)

Thank you for your suggestion. Libconfig which is the library used to parse these new, more complex configuration files does not allow to duplicate settings. I'm going to extend it so it would be able to merge default and imported settings.

How should I compile? It fails with a bunch of libconfig related output on OSX Server 10.5. I had no issues with compiling before.

I'm sorry, I don't have OSX to test. I suppose it might be xlocale.h not being detected, so please try with this configure script: http://pastebin.com/VSLLdPv5 If it works, I'll commit it to SVN.
  • 1

#11 Mr. No One

Mr. No One

    New Member

  • Members
  • Pip
  • 2 posts
  • Gender: Not Telling
  • Location: Hungary

Posted 13 February 2012 - 08:52 AM

I'm sorry, I don't have OSX to test. I suppose it might be xlocale.h not being detected, so please try with this configure script: http://pastebin.com/VSLLdPv5 If it works, I'll commit it to SVN.


Success, I got the executables, thank you! Looking forward to give a try to your work, I'll set up a testing environment asap.
  • 0

#12 ngek202

ngek202

    Angeling

  • Members
  • PipPipPipPipPipPipPip
  • 542 posts
  • Gender: Male
  • Location: Philippines, Cavite

Posted 13 February 2012 - 11:05 AM

this new system is really nice more organized ;)

just one question setting a permission/command to false won't work unless if you delete the entry or state it as a comment?
ex:
all_skill: false
  • 0

#13 Gepard

Gepard

    The Eyes of Truth

  • Community Contributors
  • 384 posts
  • Gender: Male
  • Location: Wroclaw, Poland

Posted 13 February 2012 - 12:01 PM

All commands/permissions are disabled (false) as default. So no need to disable them manually. You might want to disable some inherited commands/permissions though, and then setting: false is useful.
  • 0

#14 netBug

netBug

    New Member

  • Members
  • Pip
  • 1 posts
  • Gender: Not Telling

Posted 13 February 2012 - 06:39 PM

Im getting this when i make sql in linux

libconfig.c: In function ‘__config_locale_override’:
libconfig.c:94: error: ‘locale_t’ undeclared (first use in this function)
libconfig.c:94: error: (Each undeclared identifier is reported only once
libconfig.c:94: error: for each function it appears in.)
libconfig.c:94: error: expected ‘;’ before ‘loc’
libconfig.c:95: warning: implicit declaration of function ‘uselocale’
libconfig.c:95: error: ‘loc’ undeclared (first use in this function)
libconfig.c: In function ‘__config_locale_restore’:
libconfig.c:115: error: ‘locale_t’ undeclared (first use in this function)
libconfig.c:115: error: expected ‘;’ before ‘loc’
libconfig.c:116: warning: implicit declaration of function ‘freelocale’
libconfig.c:116: error: ‘loc’ undeclared (first use in this function)
make[1]: *** [libconfig.o] Error 1


  • 0

#15 Brian

Brian

    Forum Administrator

  • Supporting Admin
  • 2080 posts
  • Gender: Male
  • Location: California

User's Awards

        

Posted 13 February 2012 - 07:18 PM

Looks like the same error as post=78414?

Gepard fixed it in r15573 ;)
  • 0

#16 EvilPuncker

EvilPuncker

    Deviling

  • Members
  • PipPipPipPipPipPipPipPip
  • 710 posts
  • Gender: Male
  • Location: not mars

Posted 13 February 2012 - 11:29 PM

ppl are having issues already with CP /hmm

http://code.google.c...es/detail?id=57
  • 0

#17 rafoka

rafoka

    Santa Poring

  • Members
  • PipPipPip
  • 53 posts
  • Gender: Male
  • Location: Brazil

Posted 14 February 2012 - 12:13 AM

very nice!
  • 0

#18 ngek202

ngek202

    Angeling

  • Members
  • PipPipPipPipPipPipPip
  • 542 posts
  • Gender: Male
  • Location: Philippines, Cavite

Posted 14 February 2012 - 04:04 AM

ppl are having issues already with CP /lv

http://code.google.c...es/detail?id=57

i think not only flux will have problem but even other cp's that still depend on the level column /hmm
  • 0

#19 simplynice

simplynice

    Santa Poring

  • Members
  • PipPipPip
  • 91 posts

Posted 14 February 2012 - 11:28 AM


ppl are having issues already with CP /lv

http://code.google.c...es/detail?id=57

i think not only flux will have problem but even other cp's that still depend on the level column /hmm





will this be handle? i'd like to update im afraid flux won't support this.
  • 0

#20 EvilPuncker

EvilPuncker

    Deviling

  • Members
  • PipPipPipPipPipPipPipPip
  • 710 posts
  • Gender: Male
  • Location: not mars

Posted 14 February 2012 - 02:50 PM



ppl are having issues already with CP /lv

http://code.google.c...es/detail?id=57

i think not only flux will have problem but even other cp's that still depend on the level column /hmm





will this be handle? i'd like to update im afraid flux won't support this.


just edit Flux/LoginServer.php accordingly, I think :)

Edited by EvilPuncker, 14 February 2012 - 02:50 PM.

  • 0




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users