MOO-cows Mailing List Archive
Re: Multiple ownership
At 5:00 22/1/96, Dee Goepel wrote:
>> (big =sigh= and wish for group ownership of objects, or even single
>> ownership with "tinkering" privileges).
>There may be many better ways of doing this, but I have implemented
>this in a MOO that I work on this way: (It gets the job done and
>requires little work/coding)
>1) create a .owners property on #1 of the type LIST
>2) do a little hacking in $perm_utils:controls to return ok if the user is
> *either* .owner or in .owners (and of course the wiz check)
>3) [optional] you might want to write verbs (mine are @add/rm-owner)
> to interface with the property for you.
>I don't know much about minimal db's or what exactly is contained
>in LambdaCore or JHCore, but I believe most MOO's would have
>$perm_utils:controls. So this would grant multiple ownership,
>assuming objects respected $perm_utils:controls properly and
>didn't hard code something like `if (player == this.owner)' everywhere.
Well, to be true, i have examined the system, but under which permission
programs a co-owner? under permission of himself?
That is not the goal of making things MO.
But when you grant people permission to hack under permission of other
people, they are infact a wizard over the .owner of that object. You don't
want that either...
I have setup a grouping system, with a general owner (child of $prog, with
a playerbit), who owns every object (eg, all objects within a theme).
When programming/editting, verbs will run under permission of the objects owner.
In this way hacking on other people is not possible..(and preferable above
the other system)
Builtins which are frequently called, have an alias on #0, where the check
comes in case of such an object....
(My english is bad, i know, don't mention;)
Subject Index |