It wouldn't be a problem at all, I think, as long as it's done "right" (or at least what I'd consider right). Just change it from the current form of "list of allowed groups with the exception of these groups" to a more line-based mixed method with ALLOW or DENY. Then check the lines one by one, and the first one that matches is used (or the last one, depending on the taste of the implementor). It sounds complicated, but it's likely far more simple and definitely more powerful than todays system. I posted an example a bit earlier, in case you're curious how I'd picture it'd look.

It doesn't sound too complicated, and I believe I understand your idea completely. It's almost exactly what I meant by prioritization.

PERSON, for example, would immediately let any character on the list into the manse, without checking any other parameters. They get to enter even if, farther down the line, they would normally be denied. If someone's not on PERSON, the server then moves on to another set of parameters. If a character hasn't been specifically allowed by the time the server reaches DENY ALL, then they're denied anyway, DENY ALL being the default setting for all manses.

Of course, you could change DENY ALL to ALLOW ALL, meaning if someone hasn't been specifically denied by the time they reach ALLOW ALL, then they're allowed to enter. Or, you could simply place ALLOW ALL one priority level higher than DENY ALL, rendering DENY ALL a moot point.

The main difference (I think, unless I misunderstood you) would be that you could, theoretically, say "deny members of glomdoring;allow pectus" and she'd still not be allowed in with my solution. It'd be a silly thing to do, of course, but I always like options.

Right, that's why you put ALLOW checks above/at a higher priority than DENY checks. I guess one way would be to have a bunch of "permission blocks" that players can "stack". The blocks are checked in order from the very top of the stack to the very bottom. So if a player is ALLOWED by Block 3, Blocks 4-20 won't effect him or her, because he or she has already been let into the manse.

It would be like a one-dimensional Jenga tower:

(should probably always be the first block)
(should probably always be the second block)













Maybe that would be a good default arrangement. Unused blocks wouldn't matter, and each used block is defined by the manse owner's configuration.

Edit: Oh, and of course, the moment someone is DENIED by a block, they are automatically rejected from the manse and no further checks are made, just like with ALLOW.

Why force a certain order of execution? For instance, say I want to allow everyone in a certain clan except for the Magnagorans. How would I do that in your system?

You would place a block above the block in the stack. Like this:








(Filler blocks to show that there can be, and probably are, other blocks above and below these.)

Now, if you want to allow Magnagorans in general, except for people who are both Magnagoran AND a member of the clan... well, then, I don't know. That seems pretty outlandish, though. Don't think my block model would handle it.

Ah, I misunderstood you then. I thought that it would always parse it in the order of person-clan-etc. Then we're very much on the same page, yes.

In regard to my ninja edit above, if you only wanted to deny people who are BOTH 1.) Magnagoran AND 2.) Fruit Loops clan members — but yet allow Magnagorans in general and also allow non-Magnagoran Fruit Loops clan members — the blocks would perhaps need to be made more versatile, like this:









Sort of like a "I love Fruit Loops Clan members and I love Magnagorans, but I don't love you if you're both at once" kinda thing.

I don't think there's anything you couldn't do with perms if a block system like that were feasible/implemented.

Yeah, that block system is very similar (if not the same) as mine. As for the "allow fruitloops and magnagorans but not if they're both", I don't think my system could do that either.

It just took us a little while to realize we were fully on the same page, yeah.

What I do like about this theoretical "block system" is that it needn't be complicated unless you want/need it to be. That's where problems arise with the current system — to do something as (seemingly) simple as denying all Glomdorians other than Pectus, you need to add a whole ton of perms to work around the lack of exceptions to exceptions, and even then you can't get it to work quite right.

The complexity of the "block system" would scale in direct proportion to the complexity of your desired permissions scheme. Most people wouldn't need a very complex "stack" at all. It could end up being really complicated, but not because it's lacking in robustness (as is the case with the current system).

Yep. And even at its very most complex, it'd still be a heck of a lot more understandable than the current system.

Although with the various projects going on, odds are such a system won't be implemented for quite a while yet.

Just give us isMember() and isEnemy() functions and let us play with the logic straight up.

MANSE LIST FULCRUX PERMS:
if not isMember("Glomdoring") or not isEnemy("Serenwilde")
if ((isMember("Serenwilde") and isMember("SEG")) or (not isEnemy("Serenwilde") or isEnemy("Glomdoring"))) and not isEnemy("Sylphas")

Would be a lot easier to get really specific perms.

Sure, that'd be great. Although possibly a bit too complex for everyone to do without help, what with the nesting and all. It'd certainly be more powerful than the list (or block) method though.

Hmm, we'd want and xor function too.

Let's add loops to loop through known clans as well. forall (clans where clan="xyz", "xzy", "yxz") if not ismember(clan)

And before you complain about syntax, it's 7.15 over here and I've been awake for the last 24 hours.

Yes!