Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000752Core InformTesting commandspublic2011-09-19 21:052011-09-21 16:54
ReporterRon Newcomb 
Assigned To 
StatusclosedResolutionno change required 
PlatformPPCOSMac OS XOS Version10.4
Product Version6G60 
Target VersionFixed in Version 
Summary0000752: TEST ME scripts break on "if the player consents" on Z-machine only (with possible solution)
DescriptionIf I run the attached source text and type TEST ME on the first turn, it will run correctly on Glulx, but on the Z-machine the test script is paused as it waits for typing. Even if the author types in responses, the test script with then apply the bare yes and no to a plain prompt, provoking "that was a rhetorical question" responses.

Responsible code is in YesOrNo of Parser.i6t, which begins thus:

[ YesOrNo i j;
    for (::) {
        #Ifdef TARGET_ZCODE;
        if (location == nothing || parent(player) == nothing) read buffer parse;
        else read buffer parse DrawStatusLine;
        j = parse->1;
        #Ifnot; ! TARGET_GLULX;
        KeyboardPrimitive(buffer, parse);
        j = parse-->0;
        #Endif; ! TARGET_

A possible solution is the following, which works as far as it goes. However, I'm unclear why the Z-machine's original code feels it important to update the status line(?) for reading a command mid-turn, but only if the player is off-stage. As in, why wouldn't Glulx need the same thing, and is it so important to render TEST ME scripts broken for it? In any event, the Z-machine needs to call KeyboardPrimitive() regardless any extra housekeeping it may need in addition.

[ YesOrNo i j;
    for (::) {
        KeyboardPrimitive(buffer, parse);
        #Ifdef TARGET_ZCODE;
        j = parse->1;
        #Ifnot; ! TARGET_GLULX;
        j = parse-->0;
        #Endif; ! TARGET_
Minimal Source Text To Reproduce
"Yes and No"

There is a room. 

After looking for the second time:
	say "Do you consent? ";
	if the player consents, do nothing;
	say "But it might be dangerous.  You sure? ";
	if the player consents, do nothing. 

Test me with "look / yes / no". 
TagsNo tags attached.
Effect(serious/mild) Game compiles but misbehaves
Attached Files

- Relationships
related to 0000267closedemshort Documentation, Examples, and Web Site The note on the test string in example 230, The Unexamined Life, is specific to the Z-machine. 

-  Notes
zarf (developer)
2011-09-20 09:47

That's redrawing the status line only if the player is *on*-stage, and I bet there were old Z-code status line bugs about displaying the location when the location is nothing. (I don't know if there are *still* such bugs.)

(That case would arise if the author called YesOrNo in the I6 initialise routine before setting a location.)

It is definitely desirable to update the status line before all inputs. (If an action moves the player and then does a yes-or-no prompt, you want the status line to reflect the move.) I don't know why it's not in the Glulx code. Probably an oversight on my part, dating to 1999 or whenever.
Ron Newcomb (reporter)
2011-09-20 14:55

Ah, I see. Well, since this is a template file for Inform 7, I don't think I need to worry about an author sticking stuff into I6's Initialize() since it isn't exposed to I7. I tested both versions of YesOrNo with both VMs by calling from a When Play Begins and got the same results all 4 ways.

While it's possible to stick rules "after starting the virtual machine" activity, sticking YesOrNo in there -- either version -- causes Z5 to crash and Glulx to hang.

Since I get the same behavior from both versions of YesOrNo in all cases, I'm inclined to suggest my fix is at least better than what's in Parser.i6t currently, though I agree with you Zarf for a DrawStatusLine call just before the KeyboardPrimitive. Only the j = should be within the #if.
EmacsUser (manager)
2011-09-21 16:54

After discussion, this report is being merged with the outstanding feature request at [^]

- Issue History
Date Modified Username Field Change
2011-09-19 21:05 Ron Newcomb New Issue
2011-09-20 09:47 zarf Note Added: 0001278
2011-09-20 11:28 EmacsUser Relationship added related to 0000267
2011-09-20 14:55 Ron Newcomb Note Added: 0001279
2011-09-21 16:54 EmacsUser Note Added: 0001289
2011-09-21 16:54 EmacsUser Status new => closed
2011-09-21 16:54 EmacsUser Resolution open => no change required

Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker