Jump to content

  •  

Photo
implemented

[Feature] New GM System

source

This topic has been archived. This means that you cannot reply to this topic.
35 replies to this topic

#1 Maki

Maki

    Revolutionary

  • Administrators
  • 690 posts

Posted 04 January 2012 - 12:47 AM

http://rathena.org/b...7983#entry67983

As stated by Jonne:

Well, I would find it to be time to change the atcommand or GM system. So you actually group Users and not give them levels and like this you can better handle giving out atcommands and create a hierarchie which is not just drop-down. So the admin for example has all rights. He then creates a group called EventGM. Those have certain commands. Then he created a group called SupportGM. They have completly different commands, but they are not considered 'lower'. Also, EventGMs don't automatically have the commands of SupportGMs and so on.

This system was once introduced on eAthena as MOD and I think if someone could provide a fully working system for rAthena it should replace the old system officially.

Who's in?



Gepard:

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`



/me also thinks it would be nice to be able to add GM Commands to Guilds/characters, so it does not have to be account-specific giving you more control/freedom *-*

+∞!

#2 Arcenciel

Arcenciel

    Just me

  • Community Contributors
  • 1243 posts

Posted 04 January 2012 - 01:13 AM

Can we add this in?

http://rathena.org/b...administration/

=D

#3 Gepard

Gepard

    The Eyes of Truth

  • Community Contributors
  • 384 posts

Posted 04 January 2012 - 05:48 AM

Can we add this in?

http://rathena.org/b...administration/

=D




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.


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.

#4 KeyWorld

KeyWorld

    Stapo

  • Community Contributors
  • 379 posts

User's Awards

     

Posted 04 January 2012 - 06:07 AM

I was going to post in the other topic, but since there is one here... /no1

The group system is a good idea /wah
If it's base on account + guild + character + party (or others), can we have multiple group in same time (and what group name should we use in this case) ?...

But we have to keep the gmlevel (not for atcommand but) for gm permission (ex: GM 20 can't kick gm 99), trade and logs, old script compatibility (getgmlevel()), control panel (our problem ?), etc.

#5 Gepard

Gepard

    The Eyes of Truth

  • Community Contributors
  • 384 posts

Posted 04 January 2012 - 06:14 AM

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.

#6 Gepard

Gepard

    The Eyes of Truth

  • Community Contributors
  • 384 posts

Posted 05 January 2012 - 10:15 AM

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 :(

#7 Gepard

Gepard

    The Eyes of Truth

  • Community Contributors
  • 384 posts

Posted 01 February 2012 - 05:35 AM

To improve GM system, we'll need a better format for config files. I think we should choose one that is human-readable, easy to edit with text editor and provides some more functionality that simple .ini which only has sections and key-value pairs.

Maybe http://www.hyperrealm.com/libconfig/ ?

I also thought about YAML, but it seems too complex for our needs. XML is out of question, it's not really readable nor editable. LUA - bleeeh.
Writing own parser is reinventing the wheel.

#8 xazax

xazax

    Stapo

  • Community Contributors
  • 286 posts

Posted 01 February 2012 - 05:58 AM

Well, I don't really know if semicolons in a config file is desirable. Users may think it is a language and somehow interpreted and use experssions. And it does not support multi threading. Of course rA is not multi threaded right now, but at least do not create new obstacles for someone who decide to work on this area in the future. (Although probably we will not want to access a config file from multiple threads, so my first argument is more important.)

Anyways it would be awesome if the config lib we choose would natively support importing configs.

Edit: Just found out, it supports @include :D

#9 Gepard

Gepard

    The Eyes of Truth

  • Community Contributors
  • 384 posts

Posted 01 February 2012 - 07:40 AM

Trailing semicolons are optional. Users should not have to think/guess, because config file should be properly documented, so no problem here.

Multithreading is not an issue at the moment. rAthena in general is not thread-safe, so adding multithreading would be a great overhaul anyway. Proper handling of configuration, which is very rarely written to, would be the least problem.

#10 xazax

xazax

    Stapo

  • Community Contributors
  • 286 posts

Posted 01 February 2012 - 08:32 AM

Considering trailing semicolons are optional, I vote yes for libconfig.


It may also help to make new atcommand alias reading cleaner.

#11 Gepard

Gepard

    The Eyes of Truth

  • Community Contributors
  • 384 posts

Posted 02 February 2012 - 06:38 PM

Ok, I've started working on new GM system. As soon as I finish it, I'll post a diff here for other devs to review changes.

Progress:
  • libconfig - Visual Studio done, autotools & cmake - to do,
  • groups config file format - done,
  • reading groups config file - done,
  • group ihneritance - 50%,
  • allowed commands per group - done,
  • other permissions per group - 0%,
  • atcommand config file format & reading - 75%
  • command aliases - done
  • command logging - 0%
  • replacing gmlevel with group_id - 5%
Config files at the moment look like that:

groups.conf
groups: (
{
id: 0
name: "Players"
commands: {
  autotrade: false
  iteminfo: true
}
permissions: {
  can_trade: true
}
},
{
id: 1
name: "Supporters"
inherit: ( "Players" )
commands: {
  autotrade: true
  broadcast: true
}
permissions: {
  can_trade: false
}
},
{
id: 5
name: "testgroup"
inherit: ( "Supporters" )
commands: {
  kick: [true, false]
  ban: [false, true]
}
permissions: {
  can_trade: true
}
}
)

new atcommand.conf
// The symbol that will be used to recognize commands.
// You can set any one character except control-characters (0x00-0x1f),
// '%', '$' (party/guild chat speaking) and '/' (standard client commands).
// atcommand_symbol represents @commands used locally
// charcommand_symbol represents #commands used on other players.
atcommand_symbol : "@"
charcommand_symbol: "#"
// Command aliases
// <commandname> : [ "<alias>", ... ]
aliases: {
mobinfo: ["monsterinfo", "mi"]
iteminfo: ["ii"]
time: ["date", "serverdate", "servertime"]
autotrade: ["at"]
help: ["h"]
help2: ["h2"]
jumpto: ["goto", "warpto"]
mount: ["mountpeco"]
who: ["whois"]
npctalk: ["npctalkc"]
gvgon: ["gpvpon"]
gvgoff: ["gpvpoff"]
jobchange: ["job"]
load: ["return"]
mapmove: ["rura", "warp"]
dye: ["ccolor"]
hairstyle: ["hstyle"]
haircolor: ["hcolor"]
monster: ["spawn"]
blvl: ["lvup", "blevel", "baselvl", "baselvup", "baselevel", "baselvlup"]
jlvl: ["jlevel", "joblvl", "joblvup", "joblevel", "joblvlup"]
glvl: ["glevel", "guildlvl", "guildlvup", "guildlevel", "guildlvlup"]
allskill: ["allskills", "skillall", "skillsall"]
allstats: ["allstat", "statall", "statsall"]
block: ["charblock"]
unblock: ["charunblock"]
ban: ["banish", "charban", "charbanish"]
unban: ["unbanish", "charunban", "charunbanish"]
unjail: ["discharge"]
homlevel: ["hlvl", "hlevel", "homlvl", "homlvup"]
homevolution: ["homevolve"]
mutearea: ["stfu"]
monsterignore: ["battleignore"]
}


#12 xazax

xazax

    Stapo

  • Community Contributors
  • 286 posts

Posted 02 February 2012 - 06:45 PM

Is multiple inheritance supported? if so, [ ] should be used, to reflect it is a list actually (like aliases).

atcommand: true, atcommand: false? I assume all atcommands are off by default. Does false means disable an inherited command? In that case we can warn users if there is no such command enabled in the base groups ( because it may be a typo ).

I guess [False, true] is for atcommand, charcommand. If only one value present it is both at and charcommand I guess.

I like the concept so far.

Anyways server owners (don't need to be a core dev) out there. Someone who feels like working on default/recommended groups I'm bet Gepard would welcome if you'd share it /ok

#13 Gepard

Gepard

    The Eyes of Truth

  • Community Contributors
  • 384 posts

Posted 02 February 2012 - 07:06 PM

Yeah, multiple inheritance is supported, that's why it is
inherit: ( "othergroup" )
You can put more than one, so
inherit: ( "othergroup", "anothergroup" )
is ok.
Does not matter if () or [] are used. Both lists and arrays will work.

Recursive inheritance is also supported, ie in the example, group 5 will inherit from group 1 and - through group 1 - from group 0 as well.

All commands are off by default. True means enable this command for this group, false means disable (used to override inherited settings).

[false, true] is for atcommand, charcommand, yup. And no, one value is for atcommand only, because most commands will be either disabled for remote use (don't wanna players running commands on other players) or just don't have a remote version (that needs a cleanup on its own, by the way).

I'm also considering adding a special superuser (admin) group, that would have all commands enabled by default (so there would be no need to enable all of them one by one) or, alternatively, a setting "all_commands: true" that would do the same for any group.

#14 xazax

xazax

    Stapo

  • Community Contributors
  • 286 posts

Posted 03 February 2012 - 02:22 AM

Thanks for the clarifications, yeah, thinking about it, one value for atcommand only makes more sense. It would be a pain to manually disable charcommands for every command in players' groups.

Anyways does porting the whole conf folder to libconf involved in this project? It is not in the progress list.

#15 Gepard

Gepard

    The Eyes of Truth

  • Community Contributors
  • 384 posts

Posted 03 February 2012 - 03:44 AM

There are some problems with porting everything to libconfig.

Main issue is "import". Libconfig supports "include", but it's a bit different. Most importantly, it does not allow to include in a way that would create duplicate settings. In rAthena, duplicate setting from import file simply overwrites the previous default setting and it's intended behavior. With libconfig it would require an additional code to merge the imported settings into main settings and sadly, API does not provide such function.

rAthena conf files are really simple, it's just a bunch of scalar settings, all on the same level. No nesting, no lists, arrays, groups, nothing. To take advantage of libconfig, one requires a bit complicated configuration. It also explains why "include" works the way it works. "Importing" a list (like groups list in groups.conf) is not really possible, without overwriting it as a whole (there's no way to delete a member). But if we're overwriting it anyway, there's no need for import file that's specifically intended to change only some of settings while keeping other untouched. So actually there's no point in having rA-style import in libconfig, unless you use it .ini-style.

#16 Ind

Ind

    Hercules

  • Community Contributors
  • 847 posts

User's Awards

     

Posted 04 February 2012 - 02:11 PM

Looks excellent

#17 Gepard

Gepard

    The Eyes of Truth

  • Community Contributors
  • 384 posts

Posted 07 February 2012 - 09:45 AM

Time for more detailed description of changes I've done so far.

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.
  • 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, the same that is used in `login`.`group_id`
    • 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
  • Groups are configured in 'conf/groups.conf' file.
  • Each account belongs to exactly one group. In `login` table, `level` column has been renamed to `group_id`.
  • 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.
  • Atcommand configuration file no longer defines GM levels required to use the command. Permissions to use commands are defined for each player group separately in group configuration file.
  • GM configuration file (conf/battle/gm.conf) no longer defines GM levels required to get some privileges (like trading or partying). See full list:
    Spoiler:

    These permissions are defined for each player group separately in group configuration file.
  • Player title defined by 'conf/battle/gm.conf' settings "title_lvl1" to "title_lvl8" and 'conf/msg_athena.conf' (335~342) are replaced with group names.
  • 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
  • Modified GM whisper system to deliver messages basing on permissions, not level.
  • Remote trade request is now possible only if player is allowed to use @trade command as well.
  • Added a proper permission to use /changemaptype command.
  • clif_displaymessage is now capable of displaying multiline messages
  • all ACMD_FUNCs are static now, and the only way to invoke them is with is_atcommand(); all client commands (starting with /) are now translated into corresponding atcommands (with exception of /kick used on monster, as there is no atcommand to kill single monster). List of commands:
    Spoiler:
  • Removed nonsense "bot check" triggering when player blocked (/ex) Server.
  • Merged @monster, @monsterbig and @monstersmall.
  • Removed @adjcmdlvl command.
  • Replaced @adjgmlvl command with @adjgroup, which allows to temporarily move player to another group.
  • @help command requires "commandname" param and shows more detailed info about commands.
Technical details:
  • All occurences of GM level have been replaced either with Group ID (in login and char-server) or Group Level (in map-server). Login-server and char-server are not aware of player groups, they just know the group_id of the account.
    • In map-server group level is used only if there is a need to compare "level" of two players (to preserve the rule that low-level GM can not use commands like @kick on high-level GM), and in script command getgmlevel().
  • Player groups implementation
    • Player groups are implemented in separate source file and only provide functions to:
      • check if group can use command
      • check if group has permission to do something
      • get group name
      • get group level
      • initialize groups (for server startup)
      • finalize groups (for server shutdown)
    • Player groups use libconfig to load configuration from config file to memory.
      • group permissions are cached and packed in one unsigned int to faster lookup
      • group allowed commands are looked up by name by libconfig API directly from configuration struct
      • inheritance rules are evaluated once, at config load; there is a simple check against inheritance cycles
  • Atcommand changes
    • atcommands use libconfig to load configuration from config file to memory
    • atcommand aliases now use a separate DBMap that points to the same AtCommandInfo structs as original commands
  • "GM" permissions ("can trade", "can party" etc) are defined as enum now.
If you're interested in even more details, just ask or wait until I post a diff, which should be ready soon.

I need however an opinion on libconfig. It looks like libconfig package for Debian (dunno about other distros) has not been updated in a while, so users will have to compile it from source anyway. So maybe it's better to just link it statically in both Linux and Windows? It's LGPL, so we can include its code in rAthena and change it to GPL.

#18 Jman

Jman

    I AM INVINCIBLE!

  • Community Contributors
  • 959 posts

User's Awards

     

Posted 07 February 2012 - 10:37 AM

This looks like a ton of fun. One thing I don't like is the removal of the @adjgmlvl command, as it was always nice to promote a new GM from within the game without having to restart the server (well, edit SQL). Is there functionality to support this, or will we be stuck having them logout, adjusting the level and relogging?

#19 Gepard

Gepard

    The Eyes of Truth

  • Community Contributors
  • 384 posts

Posted 07 February 2012 - 10:44 AM

I could replace @adjgmlvl with @changegroup or smth like that. It would temporarily (until relog) move player to another group.

#20 xazax

xazax

    Stapo

  • Community Contributors
  • 286 posts

Posted 07 February 2012 - 11:11 AM

I vote for static linking. It hasn't got a big size.

Anyways I think a command instead of @adjgmlvl would be needed (well, not really needed, but it would be nice to not loose functionality), to add a player to a group.

group allowed commands are looked up by name by libconfig API directly from configuration struct

I hope this does not mean IO load on each atcommand.

I feel a bit sad, we can not port other confs to use libconfig =(.

Edit: jman and gepard was faster :( adjgmlvl concerns are answerd