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