@clone Exit creates broken exit

[GoogleCodeExporter]

On a clean database:

@clone Exit as a
a created.
.a
Exit a is broken...

On the log:
[TZ,0,127.0.0.1] Traceback (most recent call last):
[TZ,0,127.0.0.1]   File "/tzmud-r443/src/tzprotocol.py", line 412, in dispatch
[TZ,0,127.0.0.1]     func(self, rest)
[TZ,0,127.0.0.1] TypeError: 'NoneType' object is not callable
[TZ,0,127.0.0.1] Traceback (most recent call last):
[TZ,0,127.0.0.1]   File "/tzmud-r443/src/tzprotocol.py", line 412, in dispatch
[TZ,0,127.0.0.1]     func(self, rest)
[TZ,0,127.0.0.1] TypeError: 'NoneType' object is not callable

I'm not sure, but it is possible that it is by design that cloning an Exit will 
give us a broken exit (btw, if so, how can we unbreak it?), but either way, I 
guess that trying to use an exit on this state (if it is planned that objects 
like "exits in the state" might exits) shouldn't ever fire up a traceback...

Original issue reported on code.google.com by marcos.m...@optimus.pt on 30 Dec 2010 at 4:15

[GoogleCodeExporter]

The @clone is not causing the traceback. See issue 46 for more on that.

As it stands now, @clone Exit will create a broken exit. It is broken because 
it has no destination.

What do you recommend as the default destination? The current room? void?

Original comment by miss...@hotmail.com on 30 Dec 2010 at 4:19

• Changed title: @clone Exit creates broken exit

[GoogleCodeExporter]

I think that the objects cloneability should be conditional. For instance, you 
should be able to make "Exit" be an object that can only be cloned if a 
destination is given as parameter (@clone Exit nameofnewexit destination). 
Since this takes some time to implement, an easier thing to do is simply to 
mark objects as cloneable or not, since with @dig we don't really need to clone 
exits anyway.

Original comment by marcos.m...@optimus.pt on 30 Dec 2010 at 4:48

[GoogleCodeExporter]

Right. Since there is @dig, I don't think it is a major problem.

The reason I went back and made Exit a separate cloneable is because now you 
can have Exit subclasses that you may want to clone separately and then @dig 
through them. For instance, there is the PlayersOnly type of Exit.

So, you might do:

@clone PlayersOnly as west
@dig west to nomobzone

and @dig will use the existing PlayersOnly exit.

When the PlayersOnly is first cloned, though, it is "broken."

I wonder if maybe there should just be a different message when an Exit type 
does not have any destination. Instead of saying "Exit is broken...." it might 
say, "Exit is unfinished." or "Exit leads nowhere."

Original comment by miss...@hotmail.com on 30 Dec 2010 at 5:44

[GoogleCodeExporter]

Hmm, well, yes, the best thing would be to have a message like that "You try to 
go west but you don't seem to be able to find out how to" ;-)

Original comment by marcos.m...@optimus.pt on 30 Dec 2010 at 5:59

[GoogleCodeExporter]

This issue was closed by revision r445.

Original comment by miss...@hotmail.com on 31 Dec 2010 at 3:58

• Changed state: Fixed