Reply-To: "Kent Tessman" <kent@remove-to-reply.generalcoffee.com>
From: "Kent Tessman" <kent@remove-to-reply.generalcoffee.com>
Newsgroups: rec.arts.int-fiction
References: <ec22c08e.0208090631.53e0fd06@posting.google.com> <rPR49.1242$WJ.335792@news20.bellglobal.com> <ec22c08e.0208110406.57fd72e9@posting.google.com>
Subject: Re: HUGO v.3.0 - Parsing problem - PLEASE HELP!!
Lines: 132
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <KbP69.5158$DO6.1444800@news20.bellglobal.com>
Date: Thu, 15 Aug 2002 10:49:49 -0400
NNTP-Posting-Host: 64.231.207.9
X-Complaints-To: abuse@sympatico.ca
X-Trace: news20.bellglobal.com 1029422954 64.231.207.9 (Thu, 15 Aug 2002 10:49:14 EDT)
NNTP-Posting-Date: Thu, 15 Aug 2002 10:49:14 EDT
Organization: Bell Sympatico
Path: news.duke.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!cyclone.bc.net!torn!webster!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail
Xref: news.duke.edu rec.arts.int-fiction:107511

Just in case anyone else is wondering about this, I've talked it over with
the poster in email, and we're working on a solution or two.

The immediate fix is probably to store verbroutine in a temp_verb local just
like object and xobject get temp_obj and temp_xobj, then restore it after:

 ! Allow the player object to override the parsing cycle completely
 temp_verb = verbroutine
 temp_obj = object
 temp_xobj = xobject
 verbroutine = &PreParse
 object = nothing
 xobject = nothing
 if player.before
 {
   verbroutine = temp_verb
   object = temp_obj
   xobject = temp_xobj
   return false
 }
 verbroutine = temp_verb
 object = temp_obj
 xobject = temp_xobj

At any rate, this will be properly fixed in the next release of the library.

"J.Pitchpine" <flimbo72@libero.it> wrote in message
news:ec22c08e.0208110406.57fd72e9@posting.google.com...
> Hi Kent.
>
> The routine I spoke about is actually a set of three simple routines
> whose purpose is to warn the player in case of incautios actions that
> may kill him or render the game unwinnable. It's up to the player
> whether to take it into consideration or reconfirm the command. To
> spice things up, it occasionally run with risky but correct actions.
>
> global WARNING
> global WARN_VERB
> global WARN_OBJ
> global WARN_XOBJ
>
> routine WarningOn
> {
> WARNING=1
> WARN_VERB=verbroutine
> WARN_OBJ=object
> WARN_XOBJ=xobject
> }
>
> replace PreParse
> {
> if WARNING = 1 and
> (verbroutine~=WARN_VERB or
> object~=WARN_OBJ or
> xobject~=WARN_XOBJ)
>
> WARNING=0
> }
>
> The first time the action is entered, "Warning On" is invoked from the
> after property of the object. It stores verb, object and indirect
> object of the action in some variables and set WARNING to 1 to signal
> that we are in "warning mode".
> When warning mode is enabled, PreParse checks if the subsequent action
> matches the previous. In case it doesn't, the WARNING variable is
> reset to exit the warning mode, otherwise the after property of the
> object will perform a proper routine.
>
> As example, let's say you're kicking a bomb...
>
> object bomb "bomb"
> {
> in courtycenter
> article "a"
> noun "bomb"
> pronoun "it"
>
> after
> {
> object DoHit
> {
> if WARNING=0
> { "Didn't Mom teach you not to play with bombs?"
> WarningOn
> return true
> }
> else
> {
> "The bomb explodes... and you with it."
> endflag=2
> }
> }
> }
> }
>
> With the new HUGOLIB.H version 3.0 verbroutine is automatically set to
> zero by the Parse routine, making PreParse's check always returning
> false. As result, the warning is issued again and again endlessly and
> the player is unable to perform the action.
>
> What I don't understand is... the addition seems to do exactly what
> PreParse stands for. I mean, if I want something to happen before
> Parse, I can just replace PreParse, no? Sounds easier to me.
>
>
> "Kent Tessman" <kent@remove-to-reply.generalcoffee.com> wrote in message
news:<rPR49.1242$WJ.335792@news20.bellglobal.com>...
> > What that addition does is to allow something like this in the player
> > object:
> >
> > before
> > {
> >     actor PreParse
> >     {
> >         ...Something to happen before parsing...
> >     }
> > }
> >
> > It allows you to write a before routine for the player object that will
get
> > checked by Parse before it actually does anything.  Returning false from
> > such a block would allow parsing to continue normally.
> >
> > What is it interfering with, and how?  It's possible it can be work
around,
> > or the above methodology could be refined.
> >
> > --Kent




