Multiple inheritance for groups (and optionally players)

[14mRh4X0r]

This is useful when you have multiple "paths of promotion", e.g. if you have donor ranks and staff ranks.

Rationale

Let's say you have 2 staff ranks and 5 donor levels. In the current set-up you'd have to create 17 groups, one "standalone" and one for each combination, and enter all of the needed permissions to each group (slightly reducible by single inheritance). This grows exponentially with more "paths of promotion", and seems really silly.

If this were implemented for groups only, you wouldn't have to specify the permissions multiple times, but you'd still have to have 17 groups. Therefore I recommend implementing it for players as well.

Proposal

Player-related proposal in italics
Allow multiple inheritance for groups (and players), by pluralizing the group's "parent" (the player's "group") and making it a list of groups.

Conflict resolution

The list of groups is checked for the permission in order, bubbling up after having checked its own permissions, and the first encountered permission is used. (Player permissions are, of course, checked first)

Command syntax

/groupmod

• /groupmod addgroup <newgroup> <supergroup>[,<supergroup>[,...]]

/playermod

Only if the player-specific part gets implemented

• /playermod group set <player> <group>[,<group>[,...]]
• /playermod group add <player> <group> - adds the group to the end of the list
• /playermod group insert <player> <group> <position> - adds the group at the specified 1-based position
• /playermod group remove <player> <group> - after the last group gets removed, auto-add the player to the "default" group

Implementation details

These are suggestions, and in no aspect required (but recommended)

• Instead of a Group parent, have Group have a Set<Group> parents
• Instead of a Group group, have Player have a Set<Group> groups

[14mRh4X0r]

I've looked at the code again (this feature request was based on the admin guide), and saw that player already has multiple groups, only in the way of a main group and subgroups. I propose that difference be taken away if the player part would be implemented.

[BluXDragon]

I have actually needed this ever since I first started Canaryi- hMod'ing.