[Reality] Exits

[Jp Calderone]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 17 Jun 2002, Christopher Armstrong wrote:

> >>>>> "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?

   Um, yea, mostly I was just listing some more examples.  The only real
difference most of these would have from ships is they'd be one room
areas.  They also demonstrate why being able to look through an entrance
might be nice.  eg, "look through flap on tent" after you "open flap on
tent" to see if anyone is inside (and of course, don't show anyone inside
the oil drum if the top is on).

  Hmmm.  One room areas.  Would it be worth it to specialize on that case?
Nah, probably not...

>
>     >> 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 :)

  Arg, implicit.  Okay, it fits with the rest of Reality, I guess I'll
just have to get used to it. :)

>
>     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.

    Okay.

>
>     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. :)
>

  Going back to the case of ships, say we have a hangar with 10 freighters
prepping for launch.  "go hatch" just doesn't cut it.  "go hatch on
Sunrise II" works a little better, though "go through the hatch on the
Sunrise II" is nicest ;)  Syntax aside, a way to disambiguate entrances is
a must.  You can't count on the names being unique since creators will
have no way of knowing in what company their ship will eventually end up.
Extending ambient_go to recognize "through" and/or "on" and then passing
the Thing that is matched by those prepositions to findExit() or
findDirection() makes sense to me.


  Jp

- --
Somewhere, something incredible is waiting to be known.
                -- Carl Sagan
- --
 2:11pm up 27 days, 14:53, 4 users, load average: 0.00, 0.00, 0.00
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9Di+qedcO2BJA+4YRAiEyAJwPjWs71yff2aPCPGUQh7ya2lOWqACfXSka
iehLXrmB0bCIytUHQzv/OEU=
=BM1A
-----END PGP SIGNATURE-----