Message-ID: <3CB64740.A63E6206@attNOSPAMglobal.net>
Date: Thu, 11 Apr 2002 19:32:33 -0700
From: Chip Hayes <chiphayes@attNOSPAMglobal.net>
X-Mailer: Mozilla 4.72 (Macintosh; U; PPC)
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: rec.arts.int-fiction
Subject: Re: Puzzling Nitfol error
References: <3cb4f7e9_3@news3.prserv.net> <8df06e254b.kevin@bracey-griffith.freeserve.co.uk> <3CB5A7B4.382412BC@attNOSPAMglobal.net> <c85491254b.kbracey@kbracey.cam.pace.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: 32.100.7.122
X-Trace: 12 Apr 2002 02:30:11 GMT, 32.100.7.122
Organization: Global Network Services - Remote Access Mail & News Services
Lines: 47
X-Complaints-To: abuse@prserv.net
Path: news.duke.edu!newsgate.duke.edu!news-hog.berkeley.edu!ucberkeley!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!washdc3-snh1.gtei.net!news.gtei.net!newsfeed.us.prserv.net!prserv.net!news3.prserv.net!32.100.7.122
Xref: news.duke.edu rec.arts.int-fiction:102949



Kevin Bracey wrote:
>
> One thing I note is that the library has two 64-byte properties in the
> NPC_Engine class. They might be problematic on some old interpreters, but
> Nitfol appears to be coded to handle them correctly, so it's probably not
> that.

> Where exactly is the error appearing? You say that routine threw the error,
> but where? Before printing anything? If so, it could either be something
> else running before you, or maybe you've defined "npc_move_type" or
> "npc_stopped" as an array inadvertantly.

No, I've looked carefully at all calls to those properties, and I
haven't changed
them at all. I'm pretty sure its in NPC_Engine, as running Volker's
Deadline file using Niftol causes the same problem. I just can't
understand why, unless it's the 2 arrays in the NPC_Engine class you
mention above. But why that affects the describe routine, I have no idea.

>
> If you turn on tracing in Inform (so it prints every function called) it
> should be possible to pin down exactly in which routine the error appears.
> Alternatively, it should also be possible to correlate the PC value with the
> function in question, using TXD for instance. [Is there a way to get Inform
> to print out a symbol table?]
>
> For what it's worth, the "36" in the message is actually the number of the
> property being accessed. Infix should be able to tell you what its name is.
>

Infix didn't, but the compiler's -n switch did. I had already used the
trace funtion to pin down the error (which gets reported just before the
NPC describe routine's output is printed) to the describe function.
Using the -n switch confirms that routine 36 is describe. Very puzzling.
I still need to try it out on the PC using all of those interpreters.

Ooh, just thought of something...

Okay, I've tried using the small sample program included in NPC_Engine
and it does NOT give the same error. Something in his Deadline port and
in my code must be doing it... back to sleuthing some more.

Thanks for  your help.

Chip
