MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]
Re: #-1 owned a verb!
On Fri, 22 Mar 1996, Seth I. Rich wrote:
> So I was hacking on NewbieMOO (newbies.opal.org 8888), trying to compile
> a complete list of patches to make a LambdaCore database compatible with
> server release 1.8 (we're running 1.8.0p2, with the newest patch also
> installed).
>
> I have no clue how it happened, but we ended up with a verb owned by #-1.
> I tried to reproduce the problem:
> - Hard-recycling a verb owner does not change the verb's ownership.
> - Renumbering a verb (property, object) owner does appear successfully
> to change ownership of the verb (property, object).
> - add_verb, even when called by a wizard, will not permit a verb to be
> owned by #-1
> - set_verb_info, even when called by a wizard, will not permit a verb
> to be owned by #-1.
>
> So I couldn't reproduce how this verb came to be owned by #-1. But there
> it was:
> ;verb_code($wiz, "@copyobject")
> => {#-1, "rd", "@copyo*bject}
> (Yes, I know @copyobject isn't in the Core.)
>
The same thing happened on ForestMOO when #2 was hard recycled and I had to
fix it (I didn't have server access). Once I realized what had happened, I
figured I'd just have to renumber(create($wiz)) to get #2 back, and then set
it's player, programmer, and wizard bits, but this didn't seem to help all
the tracebacks. I eventually figured out the problem was because all of the
verbs been chowned to #-1. I'm not sure exactly how this happened, or if
it happened to the properties (I fixed them along with the verbs, but I
don't check if any of them were actually screwed up), but I didn't think
much of it at the time. Maybe it only happens when things with their player
bit still set are recycled?
(and no, I won't mention how #2 was recycled, but it wasn't my fault ;)
--Dark_Owl
References:
Home |
Subject Index |
Thread Index