Message-ID: <3B6A37D0.13D94FAF@attglobal.net>
Date: Thu, 02 Aug 2001 22:34:08 -0700
From: Chip Hayes <jwhayes@attglobal.net>
X-Mailer: Mozilla 4.72 (Macintosh; U; PPC)
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: rec.arts.int-fiction
Subject: [Inform] add_to_scope and orphaned objects
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: 32.101.177.71
X-Trace: 3 Aug 2001 05:30:55 GMT, 32.101.177.71
Organization: Global Network Services - Remote Access Mail & News Services
Lines: 32
X-Complaints-To: abuse@prserv.net
Path: news.duke.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!news.maxwell.syr.edu!newsfeed1.cidera.com!news-reader.ntrnet.net!uunet!ash.uu.net!newsfeed2.us.prserv.net!prserv.net!news3.prserv.net!32.101.177.71
Xref: news.duke.edu rec.arts.int-fiction:90601

I'm not sure if the following is a problem with Inform's Adjudication
routines, or if I'm just not using proper programming practices in
dealing with orphaned objects that are brought into scope using
add_to_scope.

I have an object which can be wheeled around from room to room, and
which incorporates a number of component objects using the add_to_scope
property (see DM4 exercises 102 and 103 for examples -- the Nasal Twinge
nose and the sterilising machine).  These components are declared as
parentless objects for the reasons stated in the DM -- only brought into
scope when the primary object (i.e. the machine, or the player) is in scope.

The problem I've discovered is that (and this is so far only when i'm
using trace at a high enough level) I get a number of vile zero errors
during Inform's adjudication process, as ScoreMatchL tests the parent of
each object in scope -- including those component objects brought in by
add_to_scope which have no parent.

While I haven't run into any actual game problems with this (just the
ugly output on traced behavior), I certainly don't like getting those
programming error messages, and also don't know if this may possibly
trip me up down the line somewhere else.

Perhaps I should just give all such add_to_scope objects a special
limbo-room parent so they'll have >some< kind of parent to make
ScoreMatchL happy.  But that seems like a sloppy solution, and my gut
feeling is that ScoreMatchL should really test for nothing as a parent
before assigning it to the variable its_owner.

Any thoughts?

Chip
