Newsgroups: rec.arts.int-fiction
Path: news.duke.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!howland.erols.net!netnews.com!news2.euro.net!news.euro.net!uunet!ash.uu.net!world!buzzard
From: buzzard@world.std.com (Sean T Barrett)
Subject: Re: [Inform] Enterable objects
Message-ID: <GF8C84.Eu4@world.std.com>
Date: Wed, 20 Jun 2001 13:02:28 GMT
References: <KeUX6.337$lg.129043@newsrump.sjc.telocity.net> <slrn9j16eo.36.cerutti@fiad06.norwich.edu>
Organization: The World Public Access UNIX, Brookline, MA
Lines: 48
Xref: news.duke.edu rec.arts.int-fiction:88935

Neil Cerutti <cerutti@together.net> wrote:
>I think you have hit upon the right solution. Just make sure that
>you only trap Exit when the player is in the truck.
>
>Object truck
> with
>  react_before [;
>    Exit: if (player in self)
>      "You can't get out yet.";
> ],
>;

Yes, this is the way to go.

Having had to post here about my problem trying to do almost
the exact same thing, except wanting to trap 'after', which
turns out to be a bit harder since 'player in self' is no
longer a good way to test it--and given that it turns out to
be necessary to kludge it--I'm wondering, does anyone think
that this should be considered a *bug* and we should make 'before'
and 'after' call objects the player is in, instead of just the
room? Admittedly, that might be overkill (and it would no doubt
be incompatible with some existing code), since I've never
seen anyone have this problem except for 'exit'. It would be
possible to *only* call before/after for Exit, but that would
be wildly asymmetric.

The obvious problem with calling before/after for an object
you're in is that it will potentially interfere with before/after
when you're outside the object but it is 'noun'. This is essentially
the same problem as using 'description' for the description of
both rooms and objects--it leaves you with a special case for
how to print when you're inside an object. That's ok for descriptions,
which want to get printed in a pretty special way anyway. I think
it would be ok for before/after--you can always test 'noun == self',
but it would definitely break old code which doesn't normally need
to check it.  Or we could always coin something new, "in_before"
and "in_after" or some such.

Despite all that complexity, I personally think it's worth changing;
you can't even do the simple thing of writing a custom "you get
out of the BLAH" without writing hacked code as it stands, and while
that's not a bug it sure seems like a flaw.

(Of course it could be done as an add-on library rather than
as a change to the main library, but ugh.)

SeanB
