Message-ID: <3BAC40FE.390A5C3E@attglobal.net>
Date: Sat, 22 Sep 2001 00:42:53 -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: Re: [Inform and NPC_Engine] ChangePlayer() really foils things.
References: <6ff8e8e2.0109202017.6733f9c3@posting.google.com> <3BAAD683.AC09AF77@attglobal.net> <6ff8e8e2.0109211926.34267e20@posting.google.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: 32.100.7.194
X-Trace: 22 Sep 2001 07:40:36 GMT, 32.100.7.194
Organization: Global Network Services - Remote Access Mail & News Services
Lines: 94
X-Complaints-To: abuse@prserv.net
Path: news.duke.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!cpk-news-hub1.bbnplanet.com!washdc3-snh1.gtei.net!news.gtei.net!newsfeed.us.prserv.net!prserv.net!news3.prserv.net!32.100.7.194
Xref: news.duke.edu rec.arts.int-fiction:92843



Al Biggone wrote:
>
> Chip, thanks for your input. I wasn't completely candid about the
> problem before, I'm afraid, because I wasn't quite sure how to explain
> it in full. The ChangePlayer() is kind of the least of the problems.
>
> It is true that changing the player causes trouble for NPC_Engine.
> However, player = whatever is trouble also. (If I add either of these
> calls to the Initialise() routine of the NPC Engine's bundled test
> game, it breaks that, too.) The solution, I discover, is that the
> player character has to be set concealed. Well, so now that part
> works.

Hmm.  In my game, player=whatever took care of the problem. And if you
look at the Deadline source code, Volker's use of player=detective
during initialisation seems to work fine as well.  But, yes, the player
(in whatever guise) should always be set to be concealed as far as I remember.

I'm not sure how or why, but for some reason, it appears that using
ChangePlayer() in Initialise makes Inform think that the NPC_Engine_main
object is IN the player, as the NPC_Engine_main object ends up with its
concealed attribute cleared, and the moved attribute set, both of which
are done to all of the player's possesions at the start of the game (in
InformLibrary).  It also ends up with the workflag attribute set, but
I'm not enough of a Library maven to know why that happens.  My
suspicions lie with MoveFloatingObjects() though.

> Anyway, the bigger problem is that if you have a door or the like that
> executes code or changes the state of anything other than itself in
> the default way, the player will see any resultant text many times
> over, multiplied by the number of  NPCs in the game, if even one of
> these NPCs is doing anything. Or something like this; I have not
> exhaustively tested this, but believe me, it's an impressive sight. So
> the player gets spammed with lots of stuff, sometimes many screenfuls,
> when an NPC causes even one line to print. This happens even if you
> set the text to only print on (actor == player) etc.
>
> As far as I could tell, if you want doors to do anything weird, NPC
> Engine breaks. I am sure it is my fault for having doors that don't
> merely open, close, lock, and unlock, but also move things around,
> toggle properties, etc. There is no doubt an NPC Engine-friendly way
> to do this which I am not hip to.

The NPC_Engine relies heavily on door_to properties to either directly
supply a room object or a routine that returns a room object.  If you
have any strange routines in your room objects that do anything more
exotic than that, yes, it'll probably mess up the engine.  It's VERY
fussy about doors, as it not only needs to be able to have its NPC's
open/close/walk through them during their travels, but also to plot out
their pathing.

A couple of questions:

Do you use the door_class as specified by Volker's docs?  i.e. do your
doors have an npc_open property?

Are you using the latest version (8.x I believe)?

I've only ever experimented with subway movement, not pathing, so if you
are using the latter, then there may be something there messing things
up that I'm not able to help you with.

Regardless, you should e-mail Volker with your bugs... I worked with him
on the last version and I'm sure he'd appreciate knowing about any new problems.

>
> But this story has a happy ending, even though I am still curious
> about the above, since NPC Engine is obviously quite powerful. The
> previous version of my WIP used "follower.h" to move NPCs around, and
> I handled passing messages and setting paths by hand, in daemons.
> Since it appears that NPC Engine is follower on steroids, I went back
> to follower and added a few cheap message-handling routines to it, so,
> if you so choose, it'll tell you who came and went, and in which
> direction. This lacks the fire-and-forget pathfinding of NPC Engine,
> but it has the distinct advantage of working with the rest of my game.
>
> Al

No doubt about it, the NPC_Engine is a complex, processor intensive
piece of work (In my game, I'm hoping to streamline the many, many calls
it makes to check whether NPC's are visible every turn).  But I really
like it, as it very cleverly duplicates Infocom's NPC movement from
their mystery series.  While it may not be state-of-the-art as far as
NPC IF is concerned (tipping hat in great admiration to Emily Short),
seeing your NPC's move around just like in the Infocom mysteries ("Mrs.
Robner is off to the north, heading towards you. Mr. Baxter, off to the
south, opens a door and ducks into a room to the west") sure is a lot of
fun.  Also, being able to quickly reprogram NPC movement by just
changing their destination via one statement, then letting the engine do
the pathing work, can be pretty handy as well.

Chip
