MOO-cows Mailing List Archive

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

Messing up the DB ?




Hi there...

I could need some help in the following problem:
When I define a verb twice on an object, and try to remove one verb, I get
an error message. If then, you try to recycle the object, the DB gets messed up
for sure (log follows). Yes, I know one should not define a verb twice, but when
that happens accidently, I don't want to rebuild the DB from scratch...
If anyone could tell me how to 'clean' this obj, I'd be more than happy!

The LOG following was done on a CLEAN copy of LamdaCore using the 1.8.0p5 server.
------

connect wizard
>>>>Make sure we're #2 and logging in for the first time (no pwd)...

*** Connected ***
The First Room
This is all there is right now.

inventory
You are empty-handed.

>>>>This is to fix $frand's_player_class only.
@chmod $frand_class:moveto rx

>>>>Let's check if @create and @recycle work properly:
@create $thing named ball
You now have ball with object number #94 and parent generic thing (#5).
@recycle ball
ball (#94) recycled.
>>>>Everything is fine!

>>>>No let's come to the buggy object: We create a duck from #5
@create $thing named duck
You now have duck with object number #94 and parent generic thing (#5).

>>>>Now, let's add a dummy verb:
@verb duck:describe
Verb added (0).

>>>>Looking at the duck gives the following:
@show duck
Object ID:  #94
Name:       duck
Parent:     generic thing (#5)
Location:   Wizard (#2)
Owner:      Wizard (#2)
Flags:
Verb definitions:
    describe
Properties:
    key: 0
    aliases: {"duck"}
    description: ""
    object_size: {0, 0}
    drop_failed_msg: "You can't seem to drop %t here."
    drop_succeeded_msg: "You drop %t."
    odrop_failed_msg: "tries to drop %t but fails!"
    odrop_succeeded_msg: "drops %t."
    otake_succeeded_msg: "picks up %t."
    otake_failed_msg: ""
    take_succeeded_msg: "You take %t."
    take_failed_msg: "You can't pick that up."


>>>>Now, let's play stupid and we do duck:describe again :
@verb duck:describe
Warning:  Verb `describe' already defined on that object.
Verb added (1).

>>>>As expected, it's defined already. So let's check the duck again to
>>>>see the two verbs:
@show duck
Object ID:  #94
Name:       duck
Parent:     generic thing (#5)
Location:   Wizard (#2)
Owner:      Wizard (#2)
Flags:
Verb definitions:
    describe
    describe
Properties:
    key: 0
    aliases: {"duck"}
    description: ""
    object_size: {0, 0}
    drop_failed_msg: "You can't seem to drop %t here."
    drop_succeeded_msg: "You drop %t."
    odrop_failed_msg: "tries to drop %t but fails!"
    odrop_succeeded_msg: "drops %t."
    otake_succeeded_msg: "picks up %t."
    otake_failed_msg: ""
    take_succeeded_msg: "You take %t."
    take_failed_msg: "You can't pick that up."


>>>>Ok, now let's try to get rid of one verb:
@rmverb duck:describe
#58:verbname_match, line 2:  Type mismatch
... called from #58:find_last_verb_named, line 15
... called from #57:@rmverb (this == #2), line 18
(End of traceback)

>>>>ugh. Didn't work. Ok, let's check our inventory again...
inventory
Carrying:
 duck
>>>>Still works fine.

>>>>Everything is ok until now, expect that we have an obj with a double verb.
>>>>Now let's panic and start start that obj from scratch: To get rid of the old
>>>>one, we @recycle:
@recycle duck
#21:recreate, line 34:  Verb not found
... called from #62:_recycle, line 13
... called from #4:_recycle (this == #2), line 5
... called from #4:@recycle (this == #2), line 11
(End of traceback)

>>>>Here we go. @recycle didn't do the job anymore. And from now on, looking at
>>>>the location where the buggy obj resides will not work:
inventory
Carrying:
#6:tell_contents (this == #2), line 9:  Verb not found
... called from #6:i inv*entory (this == #2), line 2
(End of traceback)

>>>>Just to make sure we still have the damn thing:
@show me.contents
#2.contents
Built-in property.
Value:        {#94}

@show duck.location
#20:match_object, line 14:  Property not found
... called from #6:my_match_object (this == #2), line 2
... called from #57:@s*how (this == #2), line 7
(End of traceback)

_____ end of log.


Boah. If anyone could tell me how to get rid of this, let me know!

mooooh  - aeh, sorry:
  greets,
     patrick

-- 
------------------------------------------------------------------------------
The trick is to communicate bi-directionally in real time and high resolution!
------------------------------------------------------------------------------


Follow-Ups:

Home | Subject Index | Thread Index