[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tads3] UnderSurface - Second Thoughts
- From: "Mike Roberts" <mjr_@xxxxxxxxxxx>
- Subject: Re: [Tads3] UnderSurface - Second Thoughts
- Date: Wed, 10 Sep 2003 19:59:52 +0000
- To: tads3@xxxxxxxxxxx
"Eric Eve" <eric.eve@harris-manchester.oxford.ac.uk> wrote:
> What about a more general HiddenItem class?
> (Also, the object will never be listed if it has no sight-presence,
right?)
Wrong: at least when I experimented with your proposed class just now it
listed the hidden item when it shouldn't have done, while adding isListed =
nil to the definition of HiddenItem (and isListed = true;) to the
definition
of HiddenItem.discover() fixed it.
Right - the "presence" indicates active projection of sensory information.
This doesn't really apply to sight, because things are seen mostly by the
ambient light they reflect, which "presence" doesn't affect.
If you want to make an object invisible even when the ordinary "sense
physics" say otherwise, my guess is that the place to do it is the object's
canBeSensed(). I think HiddenItem could be made to work like this:
class HiddenItem: Thing
canBeSensed(sense, trans, ambient)
{
if (sense != sight || discovered)
return inherited(sense, trans, ambient);
else
return nil;
}
discovered = nil
;
You could leave out the 'sense != sight' test if you wanted the object to be
hidden for all senses, but presumbly you wouldn't want that. For example,
if you had a cell phone hidden beneath a sofa, and it started ringing,
presumably you'd want it to be audible.
I'm not sure if this is always better than the isListed approach, but it
strikes me as a bit cleaner, since it will tie in automatically with all
forms of listing, as well as with scope.
--Mike
_________________________________________________________________
Need more e-mail storage? Get 10MB with Hotmail Extra Storage.
http://join.msn.com/?PAGE=features/es