I7: Can I increase the maximal length of the player's command?

[MW]

I just threw this into the source of an Inform 7 story:

After reading a command:
Say the player's command;
continue the action.

I expected that the game would then repeat back whatever I typed, but
instead it repeated back only the first 120 characters of what I
typed. 120 characters are not enough for this game. No, I don't have
any items whose shortest possible names are longer than that, or any
such thing; I just want direct access, once in a while, to everything
the player typed--or, at least, to the first thousand characters or so
of same. Is it possible to specify this requirement in Inform 7?

[Roger]

I'm looking for it, but I don't see it listed in the Standard Rules.

If you compile in Glulx instead of Z-Code Version 5 (go to the
"Settings" tab in either pane), then the first 256 characters from the
player's command are stored rather than the first 120. Also note that
the default character length of indexed text (despite the
documentation suggesting 1000 characters as the default) is 192. At
193 characters, you will get a buffer overflow. You don't encounter
this when you are simply storing the player's command because all
characters after 120 (or 256) are being truncated BEFORE they are
stored. However, if you do this:

[code]
After reading a command:
let T be indexed text;
let T be the player's command;
now T is "[T][T][T][T][T][T][T][T][T][T]";
let N be the number of characters in T;
say "[N] characters: [T]";
[/code]

And then type in 20 characters, you will get a buffer overflow error.

You can fix THAT by adding this to your code:

[code]
Use maximum indexed text length of at least 2000.
[/code]

However, that doesn't alter the number of characters stored when
reading the player's command. I also don't see any "use" phrase
related to the player's command listed in the standard rules.

I'll keep looking, but I have a feeling there's a variable in I6 that
causes this limitation, one for which there is no "use" phrase.

[MW]

Whoops, I do usually use Glulx--this was just a little test program.

256 is better than 120! But I would still prefer a much higher
limit. Thanks for looking.

[Andrew Plotkin]

Here, Roger <roger.h...@gmail.com> wrote:
> On Nov 23, 12:41�pm, MW <giocondo.fulbri...@gmail.com> wrote:
> > I just threw this into the source of an Inform 7 story:
> >
> > After reading a command:
> > � � � � Say the player's command;
> > � � � � continue the action.
> >
> > I expected that the game would then repeat back whatever I typed, but
> > instead it repeated back only the first 120 characters of what I
> > typed. �120 characters are not enough for this game. �No, I don't have
> > any items whose shortest possible names are longer than that, or any
> > such thing; I just want direct access, once in a while, to everything
> > the player typed--or, at least, to the first thousand characters or so
> > of same. �Is it possible to specify this requirement in Inform 7?
>
> I'm looking for it, but I don't see it listed in the Standard Rules.
>
> If you compile in Glulx instead of Z-Code Version 5 (go to the
> "Settings" tab in either pane), then the first 256 characters from the
> player's command are stored rather than the first 120.

This all stems from the size of the I6 array called "buffer" (defined
in Glulx.i6t / ZMachine.i6t), whose size is the constant
INPUT_BUFFER_LEN. In Glulx, this array bound is used by the I/O layer
itself -- the interpreter won't even accept characters beyond the
limit. (Interpreters probably vary about whether you can keep typing
beyond that, but if you can, the excess is discarded before the game
even sees it.)

Increasing INPUT_BUFFER_LEN in the I6 code should be safe, for Glulx.
No bets for Z-code.

--Z

--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*

[MW]

On Nov 23, 1:02 pm, Andrew Plotkin <erkyr...@eblong.com> wrote:

Thanks, I've fixed my problem now (I think). I set INPUT_BUFFER_LEN
in Glulx.i6t to a high value; and also I had to increase
MAX_BUFFER_WORDS and PARSE_BUFFER_LEN to high values. I suspected
that PARSE_BUFFER_LEN was supposed to be 3 * MAX_BUFFER_WORDS + 1, so
I maintained that relationship. During my changes, I found a set of
values for these three constants that rendered the program unable to
accept a certain command containing many, many words and many, many
characters without crashing. But later I increased the values to the
point where, seemingly, this was no longer a problem. However, it's
unclear what requirements these constants must satisfy in order to
block that vulnerability.