Message-ID: <3B4EFE18.8A6E6DC@csi.com>
Date: Fri, 13 Jul 2001 09:56:40 -0400
From: John Colagioia <JColagioia@csi.com>
Organization: No Conspiracy Here...
X-Mailer: Mozilla 4.77 [en] (Win98; U)
X-Accept-Language: en,fr,ru,es,it,ga,de,ja,gd,eu
MIME-Version: 1.0
Newsgroups: rec.arts.int-fiction
Subject: Re: [Inform] Property Defaults and Infinite Hats
References: <20010712224649.19458.00003404@ng-ff1.aol.com> <20010713011950.12784.00002245@ng-fm1.aol.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: 208.34.37.104
X-Original-NNTP-Posting-Host: 208.34.37.104
X-Trace: excalibur.gbmtech.net 995032478 208.34.37.104 (13 Jul 2001 09:54:38 EST)
Lines: 55
X-Authenticated-User: jnc
X-Original-NNTP-Posting-Host: 127.0.0.1
Path: news.duke.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!howland.erols.net!newsfeed.fast.net!uunet!dca.uu.net!ash.uu.net!excalibur.gbmtech.net
Xref: news.duke.edu rec.arts.int-fiction:89742

OKB -- not okblacke wrote:
[...]

>      This is also not the case.  I traced the code and my findings confirm
> Zarf's hunch that the problem lies in RunRoutines on the line which tests
> obj.&prop==0.

Yep.  I got to the same spot thanks to that comment.


>      My first question is: why does this test exist?  I commented it out and
> recompiled the game file and everything worked exactly as it should.
> (Actually, I think I know the answer.  If prop is not a common property and is
> not provided by obj, this test could prevent an "obj has no property prop to
> read" error.  But -- well, see below.)

That does seem to be the case.  I actually weakened the condition, slightly, by
testing .&prop and .prop.  I can't think of any case where prop isn't an array, a
unique value, or nonexistant.  I should probably give that some more thought,
though.


>      My second (and less pertinent to this specific issue) question is: what
> kind of funky deal is this, where obj.prop can have a value that can be
> evaluated, yet the property address obj.&prop is zero?

Well, counterquestion:  Is obj.&prop definitely the address of the property?  All
the IDM has to say on the topic is that "magpie.&name" is "the array held in
magpie's name property," and identifies it in the table of operators as "property
array."

Ah.  I see.  It's defined as the address in the Technical Manual (and I'm pretty
sure I don't want to start hacking around in RA__Pr()...).  Darn.  You're right.
That makes no sense, then.


>      This confirms my belief that the library's use of cant_go is not good.  It
> appears that cant_go is the ONLY property which is handled in this way (i.e.,
> it is called no matter what and its default value is the default message) --
> other properties will "fall through" to a library message if the object in
> question does not provide the property.

In fact, it seems to be the only usage that ChangeDefault() is given, which is
somewhat odd, to say the least.


> The patch I submitted to the patch
> site makes cant_go work like all other properties in this regard -- it is only
> called if it is specifically provided by the object, otherwise the regular
> library message mechanism takes over.

Yes, that seems to attack it from a slightly different angle.  A question, though.
Why not just add a new message to LibraryMessages() for "You can't go that way"?


