New GM System

[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?

Edited January 2, 2012 by Jonne

[Gepard]

Sounds like one of a few features that are actually worth working on.

[Jonne]

Sounds like one of a few features that are actually worth working on.

I found the snippet, but it is in German Athena (http://www.eathena.ws/board/index.php?showtopic=193551). Anyway, the idea was to use the "GM Level" as bit-flag and every bit has certain commands with them. And the admin has for example all bits set and so on. I hope you get the idea.

[saithis]

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

[Jonne]

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

I wouldn't recommend it either, I just thought it would be good to understand the system for those with knowledge in C.

And for the thing whether to use bitflags or not:

That's what this discussion is for, isn't it?

I think we could use a system like Bukkit(the minecraft server emulator) where they create groups and they can inherit rights of others groups and you can assigm rights to every group and so on.

P.S. If we don't use bitflags, then it will get pretty messy. You would need one file for each group that coups any command or at least every command they have access to. But that might be more user-friendly in the end.

Edited January 2, 2012 by Jonne

[xazax]

Well, grouping command would not be that hard however.. There are configs like from which level can a gm trade etc.

We also need those configs to be set on each group. I think it would increase the complexity of the GM system greatly, unless you have a good idea how to handle this.

[Jonne]

Well, grouping command would not be that hard however.. There are configs like from which level can a gm trade etc.

We also need those configs to be set on each group. I think it would increase the complexity of the GM system greatly, unless you have a good idea how to handle this.

I don't have quite a good solution. It's a complex topic. Maybe having one root GM group which can be inherited and which says that this group can't trade. If somebody were to want changes, they could just copy&paste the group and alter it or just alter the original. Not sure if it is possible to add this system with all our GM configs without adding this much complexity.

Edit: Or just forbidding it by default and having a "root" GM group which allows GMs to do it if they are in. I also think we need to discuss the GM titles, if they can be in more than one group.

Edited January 3, 2012 by Jonne

[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`

[Jonne]

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`

About that, yes. Also inherit what they inherit and multi inheritance.

<group_id>:<group_name>{;<inherit_from_group_id>,<inherit_from_group_id>,...}

[vBrenth]

+1 to this! can't wait to see this

[Natsu Dragneel]

this will reduce the abuse in gm power!

[Hybrid]

Sounds like a plan

For the GM configurations, such as "What level GM can trade", etc etc, then how about making it so the admin will define groups in which trading is allowed/disallowed. That way, there wouldn't really need to be a root GM group which is allowed to trade, and it might simplify coding, though I might just be sorely mistaken on the matter

[Maki]

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

[Jonne]

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

This topic never intended to do this, but I think we are all in for this suggestion if anybody can provide a way to do this because at the momemt the GM levels are saved in login db which is account specific.

[Toshiro]

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

This topic never intended to do this, but I think we are all in for this suggestion if anybody can provide a way to do this because at the momemt the GM levels are saved in login db which is account specific.

For that purpose there would be another table needed to specify which account/character/guild should be aligned to which group. The only problem would be the compatibility to the Control Panels and stuff.

[Gepard]

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

This topic never intended to do this, but I think we are all in for this suggestion if anybody can provide a way to do this because at the momemt the GM levels are saved in login db which is account specific.

For that purpose there would be another table needed to specify which account/character/guild should be aligned to which group. The only problem would be the compatibility to the Control Panels and stuff.

No, that's bad idea. Things like that should not be saved in config file, but in SQL database. Solution is to add `GM_level` (or `group`) field to `guild` / `char` table. However I don't really see a scenario where adding it to single characters is necessary.

[CalciumKid]

^ many servers only allow one character to retain GM powers. This could help to enforce that.

[Realusion]

Yep, I've also seen servers where only one character was given GM powers. A re-design of the system would provide a lot more flexibility in cases like that and perhaps grant various other possibilities as well.

[Jonne]

Yep, I've also seen servers where only one character was given GM powers. A re-design of the system would provide a lot more flexibility in cases like that and perhaps grant various other possibilities as well.

Give whole account rights and limit account to one player. Why should he have legit chars on the rest of his account, but this is not up to me to decide.

Anyways, I think it might be time for the team to give a statement (yay or nay) and then start a poll or drop the topic, as I can see from this topic lots of agreement.

Edited January 5, 2012 by Jonne

[Realusion]

None said that he would have legit characters on the other slots. I was just saying there would be an increase in flexibility, which is essentially true.

[SkzBR]

I vote for something more complex, but in my mind, give more controls to server owners.

group <UNIQUE_ID> {

<KEY>:<VALUE>,

inherit: <GROUP_ID>{,<GROUP_ID>,<GROUP_ID>,<GROUP_ID>,<GROUP_ID>,...},

}

example:

group admin {

can_drop_items: 1,

can_do_something: 1,

can_do_anything: 1,

inherit: gamemasters, players

}

group supporters {

can_do_anything_that_gm_not: 1,

}

command configuration:

hide: gamemasters

rates: players

jumpto: supporters

If we do rewrite the system, lets make a stable and consistent system. With this, you solve the problem with items and others configurations... and others will just need to edit 2 files (groups and commands), so permissions will go in the groups, and not around 1000 config files.

[Jonne]

I vote for something more complex, but in my mind, give more controls to server owners.

group <UNIQUE_ID> {

<KEY>:<VALUE>,

inherit: <GROUP_ID>{,<GROUP_ID>,<GROUP_ID>,<GROUP_ID>,<GROUP_ID>,...},

}

example:

group admin {

can_drop_items: 1,

can_do_something: 1,

can_do_anything: 1,

inherit: gamemasters, players

}

group supporters {

can_do_anything_that_gm_not: 1,

}

command configuration:

hide: gamemasters

rates: players

jumpto: supporters

If we do rewrite the system, lets make a stable and consistent system. With this, you solve the problem with items and others configurations... and others will just need to edit 2 files (groups and commands), so permissions will go in the groups, and not around 1000 config files.

Somehow for it. I do really want a more complex system. But you'd need some more info in each group:

group <group_id> {
 name: <name>
 rights: <key>{,<key>{,...}}
 inherit: <group_id>{,<group_id>{,...}}
}

What I think of is, that group_id really is a number (the old GM level) and name is what is displayed as his "rank". All rights the group has will be after rights, like:

rights: can_drop,can_bypass_statmax

etc.

I would also go along with SkzBR's suggestion.

Like this we can create redundant groups that are just patterns to inherit for other groups.

Edited January 5, 2012 by Jonne

[saithis]

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
}

[Jonne]

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
}

True. And all not mentioned commands and permissions are automatically true or false? Or true for group_id = 0(user?) and false for group_id != 0 (GM?)...

[Toshiro]

True. And all not mentioned commands and permissions are automatically true or false? Or true for group_id = 0(user?) and false for group_id != 0 (GM?)...

Group 0 would be the default group with predefined settings (as everything else has predefined settings as well).