[Reality] Exits

[Christopher Armstrong]

>>>>> "Jp" == Jp Calderone <exarkun@meson.dyndns.org> writes:

    Jp> On 17 Jun 2002, Christopher Armstrong wrote:

    >> Here's the use case: we need to be able to have a ship (which is made of
    >> multiple rooms) enter a spaceport entirely and make its entrances
    >> available to people in the spaceport. The ship may have multiple
    >> entrances: one for the cockpit and one for the cargo bay, f.e.

    Jp>   Other things that come to mind - temporary or permanant enclosures,
    Jp> such as a tent Thing that could be carried around and then unpacked,
    Jp> set up, and entered; ground vehicles; or "scenery" such as an oil drum.

What differing requirements do these have? I think it would be fine if we
just checked if any new objects entering a room have an "entrances" attribute
(or perhaps something a bit more explicit), and if so, update the room's
exits.

Is that all you meant? how about going a bit more in depth for these cases?

    >> Hrm, then again, we could just make the special Area-checking part of
    >> the Exit class, so that's no worry (i.e., add a set_source method that
    >> checks whether source is an area object, if it is, tell it to update its
    >> entrances).

    Jp>   Yea, movement hooks would do most of it, then exit can track the
    Jp> rest.  Area should have an interface for adding/removing these exits
    Jp> (as well as getting a list of them, of course).

That's what the 'entrances' attribute would be (A list of Exit objects meant to
be exposed to the containing room). adding and removing stuff from "entrances"
can probably be implicit -- that's the point of having Exit objects track what
their 'source' and 'dest' properties are. Unless you can come up with another
reason for an explicit API :)

    Jp>   It would be nice if this didn't break the existing exit code.  I

I don't personally care about breaking existing Reality code, especially since
there's so little of it. I think we need to come up with a good solution before
we generate a ton of code.

    Jp> guess these types of exits would only be accessable via a new ability?
    Jp> Enter/leave or something like that.  Could this be folded into the

No need, if we tell the containing room about the exits, it can add the exits
to its own internal exits until the thing leaves again. OR, it can simply look
up exits dynamically on any enterable objects inside of it (which may be able
to prevent some "woops, I accidentally left an exit back there" bugs, but then
again, if it doesn't rely on the "end-coder" to do anything it may not be a
problem).

Of course, if you wanted to make an explicit "enter" verb, I guess there's
nothing stopping you.

    Jp> existing interface on Thing, perhaps with an option "of" or "on"
    Jp> parameter to findDirection() that defaults to None?  Or maybe it makes
    Jp> sense to do the access in a new method..

You lost me there. :)

-- 
                                Chris Armstrong
                         << radix@twistedmatrix.com >>
                http://twistedmatrix.com/users/carmstro.twistd/