So I decided, after getting a private message from here, to stick my nose into muds again and seeing as how I am most familiar with SWR I thought I'd stick to that.

As of now I've mostly concentrated on ripping mud.h apart and getting everything in there moved out to separate header files. While I'm not quite done with that yet I have made considerable headway.

In the process of doing so I remembered something I tried to do before and decided to do it again; replace player trust stuff with a new system whereby commands fall under certain groups and in order for a player to use a command they must belong to the appropriate group.

As an example, the basic movement commands might fall under a cmd_general_movement group. Player A has permission to use that group and therefore can move around the game. Player B does not and therefore not only can they not use the commands, but isn't even given an indication that they exist. Obviously Player B would know that they exist but the game itself wouldn't acknowledge their existence in any way for them.

So, with all that out of the way, does anyone have any thoughts on the subject? What would be some nice general permission groups and what types of commands would fall under them? At the moment I have the following groups defined: comms_general_ic, comms_general_ooc, comms_immortal, cmds_socials, cmds_general_player, cmds_general_immortal. Too general? Too specific? What else would you add?

Bring it!

Edit:
Reworked and expanded it some.

	// Applies to all players in general, including IMMs
	player_comms,		// Lets players use communication channels
	player_comms_ic,	// Lets players use IC channels
	player_comms_ooc,	// Lets players use OOC channels
	player_cmds,		// Lets players use player commands
	player_cmds_general,	// Lets players use general player commands: anything non-skill related
	player_cmds_socials,	// Lets players use socials

	// Immortal specific stuff
	immortal_comms,			// Lets players use IMM channels
	immortal_cmds,			// Lets players use IMM commands
	immortal_cmds_general,		// Lets players use general IMM commands: goto, transfer, etc.
	immortal_cmds_build,		// Lets players use IMM building commands: mset, oset, redit, etc.
	immortal_cmds_build_other,	// Lets players use IMM building commands on areas they aren't author of.
	immortal_cmds_build_player,	// Lets players use IMM building commands on players: usually mset. Transfer?
	immortal_cmds_admin		// Lets players use IMM admin commands: copyover/hotboot, etc.

The two part entries, player_cmds, player_comms, etc are intended to act as blanket toggles on a player, e.g. Player A has permission to use all available player comms channels, they get mouthy on OOC and that gets toggled so they can't use OOC communication anymore (OOC channel, osay, whatever), but they can still use talk, chat etc. Removing permission to player_comms disables both IC and OOC though, so even if a player had permission to both channel types, without permission to just use channels at all they're effectively silenced.

???

I actually think you'd be better off defining a proper security system for all commands, based on the conditions you want to use as restrictions... rather than trying to divvy them up into multiple lists.

Let's say you define a command structure (pseudocode):

struct {
    char *name,
    int permission_bits,
    HELP *help_entry,
    FUNC *function_pointer,
} command;

So, the interesting part is the permission_bits part. You could, of course, have elements for each permission directly, but I assume the rest of your code is riddled with EXT_BV stuff and all that jazz, so might as well make it work the same way.

Now, define your command restrictions..

PERM_ADMIN
PERM_IMMORTAL
PERM_CHANNEL
PERM_OOC
PERM_SOCIAL
PERM_SKILL

Each of those would be a bit, and you'd set them as appropriate.

So, a command like "shutdown" might be admin-level only, but useable in any state... PERM_ADMIN is all you need to set. A command like "kill" is a player command that is an in-game action, so PERM_SKILL would work. Maybe "shout" would be PERM_CHANNEL, but "chat" would be both PERM_CHANNEL | PERM_OOC, and "immchat" would be PERM_IMMORTAL | PERM_CHANNEL | PERM_OOC.

Doing it that way, all commands are in one list, which means you can use a unified parser and handle abbreviations or ordering however you like. It also means there's only one place for permission checking code, making it less fragile. It's of course, up to you to decide the permission groups and write code to check them.

You could also handle player states and whatnot as part of this. My own game has commands that can only work when you're awake (invalid for people who are dead, unconcious, or sleeping), and commands that only work while standing, or while not fighting.

Of course, if you want to be able to tweak these for individual players, just make an entry for the same permissions set in each player object, with them all enabled by default. So, a player can use OOC channels if all the conditions for OOC and CHANNEL are met *AND* they are not banned from either OOC or CHANNEL by having that bit disabled.

It would let you do cute things like disable a player's ability to use in-game commands like "kill" or "cast", but still be able to chat or emote... The could, of course, auto-attack back if somebody else attacks them... but they couldn't initiate the combat because all commands that would start combat are blocked.

That was the basic idea actually, though I was thinking each command would be part of only one set and players would have a list of what groups they're members of. That way the ability to use a particular group of commands could be enabled or disabled on a player by player basis.

As an example, the basic movement commands could be part of "player_cmds_general" or even a movement specific group, and every player by default would have permission to use the commands in the group but an individual player could have access to them revoked.

Part of what I want to do is basically remove the requirement for a player to be a specific level in order to use some specific types of commands. Need a new builder? Just set a flag on their character to give 'em permission to use builder commands.

As for player state issues many of the commands already have requirements for that. As an example you can't use kill to attack another target when you're already fighting something. Though now that I think about it most of the state handling stuff for commands are handled in the command code manually so that should get moved to the command structure as well.

One of the things I was hoping I could get some feedback on was the groups I could create. Do I currently have too many? Not enough? Too generic? Too specific? One thing I most definitely don't want, and refuse to do, is have a flag for every individual command a player has access to. That's just completely and utterly pointless.

I think trying to shoehorn every command into one (and only one) "group" is a mistake. That's my feedback.

Basic design says every thing has a set of things it IS, and a set of properties it HAS. A given verb IS a command, or a channel, or a social. A given channel HAS the properties of being an "IC" or "OOC" channel, and of being restricted to immortals or NOT restricted. A given command HAS the properties of being a "game" command, or a "info" command. You see what I'm getting at?

That's why I specifically phrased it as a set of permission bits for various attributes. To me, it's utterly pointless to have things like "player_comms_ic", because it's not a single thing. That captures THREE attributres that you want to have control over, namely, "rank" (guest/player/immortal/admin), "command type" (commands/channels), and "attribute" (ic/ooc for channels, general/social for commands).

You can certainly build up lists and categories the way you were describing, but the fact that you're unsure how many you need should be a hint that you'll never come up with a satisfactory solution. When you add new commands or socials or channels, you'll have to decide which one they best fit into, and sometimes you'll wish you could have them in more than one set... and then you'll end up making player_comm_ic_friendly, player_comm_ooc_friendly, player_comm_ic_sad, etc, etc...

Heh. Ok. I get what you're saying. I was trying to avoid doing bitwise manipulation but you do make a strong argument. Meh, maybe I'll go with a std::bitset.

Or even possibly a boost::dynamic_bitset...

Could let me, possibly though I'm rather leery of doing so, add and remove the stuff at runtime. Probably not though. Removal would have so many potential issues.

There's no real issue with using bits... I only suggested it because so many OTHER systems in Dikurivative codebases already use it. You could just as easily make each "bit" a boolean variable in the structures and test against it. It takes up more RAM, but big whoop... I dunno about your hardware, but my cheapo server has 16G of memory.