[glulx] need help fixing a bug in Unified Glulx Input

As the title says, I am soliciting help tracking down and fixing a bug in Andrew Plotkin’s Unified Glulx Input Extension (which may be found here: github.com/erkyrath/i7-exts/blo … 0Input.i7x).

The bug is pretty straightforward. When the user attempts to combine two or more commands using THEN or a period (for example, GO EAST THEN GO WEST, or GET LAMP. TURN ON LAMP), the game enters an endless loop, executing only the first command over and over. This test code demonstrates the problem simply:

[code]Include Unified Glulx Input by Andrew Plotkin.

Test Chamber is a room.

The lamp is a device in the Test Chamber.

Test me with “get lamp then turn on lamp”.[/code]

This sort of problem is usually well out of my area of expertise, but UGI has become an essential component of a pretty important WIP, so I’m determined to figure it out. Any help at all, or even any insights into the parts of the parser that normally handle concatenated commands, would be profoundly appreciated.

Thanks in advance,

-M

In case this proves hard to fix and you want to slice the Gordian knot, I once did this to stop the player from chaining commands when my game couldn’t handle it:

[code]First after reading a command when the player’s command includes “then”:
say “Sorry, but it looks like you’ve chained more than one command together with the word ‘THEN.’ This game doesn’t support that feature.”;
reject the player’s command.

First after reading a command when the player’s command matches the regular expression “.”:
say “Sorry, but it looks like you’ve chained more than one command together with periods. This game doesn’t support that feature.”;
reject the player’s command.[/code]

I’m afraid I’m not able to reproduce this.

For an even smaller test:

[code]Include Unified Glulx Input by Andrew Plotkin.

Lab is a room.[/code]

(Using 6L38 and the linked version of the extension.)

If you do want to prevent multiple commands entirely, you can redefine the constants THEN1__WD, THEN2__WD, and THEN3__WD which will make the parser fail to recognize periods and “then”.

I reproduced it in 6M62, so maybe it’s working with 6L38 but not 6M62?

Hmm, I don’t speak I6, so my observations should be treated with a pinch of salt. But I see in the Parser code

and in the UGI code (at the start of the section replacing Parser Letter A)

Include (-
	parser_results_set = false;

	if (held_back_mode == 1) {
		held_back_mode = 0;
		VM_Tokenise(buffer, parse);
		jump ReParse;
	}

So to my untutored eye it looks like there’s a bunch of missing code here. Might this reflect a change in Parser.i6t between 6L38 and 6M62?

Excellent catch, jrb! Here’s the corresponding code from Parser Letter A in the 6L38 parser:

if (held_back_mode == 1) { held_back_mode = 0; VM_Tokenise(buffer, parse); jump ReParse; }

So it looks like there is a relevant difference there–and the difference was connected to an infinite loop on chained commands.

And pasting the relevant code back in seems to have fixed the problem! Here’s a fixed version that maybe will work with 6M62. Probably the thing to do would be to make some sort of conditional include that puts the right code in depending on which version of Inform you’re using, but, well, zarf can handle that if he wants.
Unified Glulx Input Debug.i7x (119 KB)

Oh, you guys are FANTASTIC. Tested this in my WIP and it’s working perfectly. Thanks so much!

Thanks for investigating this.