Plan for GM level renumbering

[o11c]

Justification: on the test server, it is causing problems that everybody is a GM and is not subject to certain limits (e.g. spam). Although commands could be .

Current levels as used on the main server:
@1: spam limits not checked
@40: the above, and totally safe commands that do not affect other players
@50: all of the above commands, greater hide, and summoning. Note: this level is listed but not really used; commands here can be merged up to 60 if need be.
@60: all of the above commands, and commands that affect other players. Note: This shows as GM by turning the name green (or red every 85690525 seconds) in the client.
@80: all of the above commands, and commands that are potentially disruptive. Note: does *not* currently show as a GM.
@99: all of the above commands, and commands that can break the server. Note: This also shows as a GM in the client.
@100: a command that is so dangerous even an admin shouldn't use it. (most commands that should be this, are actually @99)

Implementation change: instead of checking GM command permission with >, check with &. This will allow flexibility in that either the command or the account can have multiple bits set, and the bits are meaningless in and of themselves.

For simplicity it would be nice to implement it with only one bit for *one* of those data sets.

I know there are hard-coded places where 99 is sent as "with all permissions", and where 100 is used as "this is impossible". Although I could try to get rid of those it would be intrusive and let's see if that can be avoided:
99 is 0x63 = 0x40 | 0x20 | 0x02 | 0x01
100 is 0x64 = 0x40 | 0x20 | 0x04

99 & 100 is true, so to avoid the impossible at least one of those would have to change. Hmph. Well actually, I don't think there are any checks for an admin *being* 99 other than the "show as GM" which is going to become a bit. It would be nice to use bit 0x80 for that, but there's all sorts of code that assumes and/or enforces the limit of 99.
So, bit 0x80 is out, as well as bit 0x40 because with enough other bits it would overflow.

We need to make sure nobody gets bit 0x20 or 0x40 to prevent the apocalypse.
We need to make sure an execution with 0x63 will always succeed, *unchecked* (this is by scripts, not be people, so we don't care about 100 & 99 being true. Although I probably will fix one of those. Eh, screw this, an admin or script can break the server anyway if they try, so let's not care at all about 100 & 99).

Let 0x01 be "ignore limits", given to bots of necessity and those with any GM level for compatibility and respect (but not on the test server).
Let 0x02 be "show as GM". No commands will have this bit set, and accounts previously having @60 or @99 will get this bit.
Let 0x20 be "run anything". All commands should have at least this bit set. To prevent overcomplication, let's use only one bit for accounts then (other than the two above), and use multiple bits for commands.
Let 0x04 be "safe commands". Accounts with @40 get only this (and "ignore limits"); commands <= @40 get this.
Let 0x08 be "commands that affect other people". Accounts with @60 get this (as well as 0x01 and 0x02); commands <= @60 get this.
Let 0x10 be "somewhat dangerous commands". Accounts with @80 get this; all commands <= @80 get this.

If it helps you sleep better at night, this system is not hurt if somebody with "equivalent of @80" also has the bit for "equivalent of @60" or "equivalent of @40".

The only thing not handled in the above is commands that anybody can use, like @servertime and @wgm. I can just special-case those somehow. I *don't* want to leave them as a literal 0; that represents naturally the "this command cannot be used". I'll probably force one of the high bits for it ... hm, it can't be bit 0x40 until the 100 problem is solved, so let's try bit 0x80, which doesn't collide with anything, for that.

[Crush]

Sounds just like the role-based permission model on Manaserv. Having a role-based model is definitely superior to the hierarchical model on eAthena.

On Manaserv we initialize all players with a level of 0x01 for the standard access role. Here is some further background information:
http://doc.manasource.org/permissions.xml
http://doc.manasource.org/givepermission

[argul]

just do it in your fork, maybe somebody reviews and approves it for the official server

[o11c]

I'm working on this again, but with a slightly different approach. In particular, I am going to remove the 99/100 problem.

Also, now that I have ssh access to the server itself, I no longer have to worry about talking someone through the conversion.

I am currently planning on using the following values, where only 0x80 has hard-coded meaning but the rest are useful as defaults.

Code: Select all

GMLEVEL_BOT      = 0x01; // @1
GMLEVEL_UNUSED   = 0x02;
GMLEVEL_JUNIOR   = 0x04; // @40
GMLEVEL_SELF     = 0x08; // @60 commands that act on self
GMLEVEL_OTHER    = 0x10; // @60 commands that act on others
GMLEVEL_SENIOR   = 0x20; // @80
GMLEVEL_ADMIN    = 0x40; // @99
GMLEVEL_VISIBLE  = 0x80; // @60 or @99

[tux9th]

Just to get this straight for me:
You're going to assign Commands to those bitmasks and you can then add various bitmasks to a user.
Meaning you could if you want to just assign a user a green name without him having any rights besides the green name.

If this is correct I absolutely am for this change as this would make things much better.

[Crush]

Using bitmasks for role-based permission is exactly how Manaserv does it - it was a good idea to copy that concept.

I remember that someone once criticized it because it only allows to define up to 8 roles (or 16, or 32 when you use larger integers), but I don't think that games like tmwAthena or Manaserv really require that many roles.