MOO-cows Mailing List Archive
>I changed @move to check for owner both in dobj and iobj.
>What about @set me.location?
Try it. <grin>
>You mean that this can be solved adding set_task_perm at the beginning of
>@rename @set and @edit?
>I want people to be able of changing their objects names and so, but not
As far as I know, the only way for a non-wiz to change his or her name is
but if you want to keep players from using rename on themselves, well,
stick this at the beginning of $player:@rename...
if (dobj == player)
return player:notify("Sorry, you can't rename yourself...");
>The same problem appears with this verb, again set_task_perm???
yduJ is right, that's a bug in LambdaCORE. Fix it by sticking this at the
beginning of $builder:@chparent..
if (player != this)
>So I have three options I think...
>-Change owner of the players to a wizard (losing mail and so?)
>-Use $server_options (??????)
>-Edit or remove related verbs, adding ser-task-perm.
$server_options isn't what you want, and niether is changing player
ownership. It'll just take some coding. I think that the two fixes I said
above will be enough...
>> >Another one:
>> >Should I change the f bit of #1 to off and propagate to childs?
>> I'm not sure what you mean, but I'd suggest just keeping #1 fertile.
>I wanted to avoid building any but generics to builders, from now...
Okay... hmm... well... what about programmers? If you want programmers to
be able to build descendants of #1, then all you have to do is make a verb,
say, #1:is_generic, and have it return 1 if that object is a generic, and 0
if not. Then, the builder @create and @chparent will first check if that
object's fertile, and then call that object's is_generic() verb to make
sure that it's a generic object. Making #1 unfertile will also stop
programmers, which may not be what you want. (If that is what you want,
then go for it)
-----BEGIN PGP PUBLIC KEY BLOCK-----
-----END PGP PUBLIC KEY BLOCK-----
Subject Index |