MOO-cows Mailing List Archive

[Prev][Next][Index][Thread]

Re: Q: Adding another wizard class.



Ah.... the Archwizards dilemna...

Actually I considered this in my first attempt at NewCore which is still
somewhere at the back of my mind.

The problem is simply that you are trying to deal with this backwards.

Instead of trying to create a new archwizards object, and reduce the 
ability of the wizards, to match, you should be making a Super-Programmer
Object, and calling IT a Wizard.

In reality, the main difference between a wizard, and a programmer, is the
way that wizard perms are handled. Since you already have a perms object,
and a way to test for valid perms, all that is needed is to rewrite the
core in such a way as to make a Wiz bit act as an Arch bit, and the
Programmer bit, and a property called Wiz, that is owned by the archwizard
on each programmer, act as your wizard perms.

Then the Wizard has super-user, but not administrative powers.

In other words, instead of reducing the capabilities of your wizards,
increase a class of programmers, to be able to access everything you want
them too. If you do not explicitely give them the right to use certain
verbs, etc, then, they are locked out of using them, by the same method
that locks the players out.

If you want to get really fancy, then set up a wizcode instead of a flag,
and declare certain types of functions to be the rights of a certain class
of wizard.

For instance the wizard that designs verbs, doesn't need @toading
capabilities, or the ability to rewrite players mail, while the postmaster
wizard might need to rewrite players mail, but certainly doesn't need
@toading capabilities, or the ability to write verbs for the archwizard.

Thus your public administration workers can be minimally wizards, while
your Code wizards can be more wizardly, and your system admin can be
kept to a class of Archwizards.

				GREY

GRAEME SMITH                         email: grysmith@freenet.edmonton.ab.ca 
YMCA Edmonton             
(Back on line!>

On Thu, 10 Oct 1996, Mark A. Bainter wrote:

> I am a new moo admin, and normally wouldn't post a question to this list, 
> but when I posted it to the moo-calves list, they recommended I present it 
> before you.  First, some background:
> 
> The moo My co-admin and I were on before (as wizards) had a constant war 
> going on.  There were a few wizards who thought it fun to harass others, 
> wizards as well as players.  As wizards, he and I were plenty able to 
> defend ourselves from this, but we also had to protect the players from 
> being @toaded, or locked in a room, etc, for no reason.  Now, the obvious 
> solution in our moo is to just not wiz anyone who might have that kind of 
> attitude, and if a wiz develops one, to demote him.  But, what we'd _like_ 
> to do is make another level of wizards called archwizards who have 
> exclusive access to verbs like @toad and @newt and the black/red-list 
> verbs.  Basically, we want to have the wizards able to code universal verbs 
> for the players, and be able to help them with their problems, but not give 
> them unlimited access to the system.
> I've started by creating a new object called Generic Archwizard with a 
> parent of   Generic Wizard.  Then, I created a property called .arch on 
> Generic Wizard and set it to false.  Then, I moved all the verbs like 
> @toad/etc to the Generic ArchWizard object.  So far so good.  The trouble 
> is, that wizards have unlimited access.  So, all they have to do is change 
> their .arch property to true and @chparent to #97.  Or, they could edit the 
> verbs or  copy them to themselves or any one of a hundred other things.
> 
> Now to the real question:
> How do I create a new class with the same kind of differences in 
> permissions as there is between programmers and wizards.  I.e. I don't want 
> wizards to be able to touch an archwizard's stuff.   If the answer is 
> already out there, a pointer to it would be greatly appreciated.  I have 
> looked through just about anything I could get my hands on, but so far I 
> have been unsuccessful in finding a solution to this problem.
> 
> 
> Sparhawk
> 
> 
> 



References:

Home | Subject Index | Thread Index