What are these input codes for?

I’m trying to fix up an old extension (Hidden Prompt). At one point, it gets a keypress from the user; certain keypresses are taken to mean “keep the prompt hidden”, while anything else means “I want to type a command, give me the normal prompt back”.

This is the code from the previous version:

let X be the chosen letter;
unless X is 13 or X is 31 or X is 32 or X is -6 or X is 127:

13 is newline (so presumably enter?), 32 is space, and -6 is the Glk code for backspace. But I can’t figure out what these other ones are in here for. As best I can tell, neither Glulx nor the Z-machine should ever send 31 or 127, and Glulx should send -5 instead of 13 for the enter key.

Does anyone recognize what these other numbers are in here for?

2 Likes

Oh, wait. The Glk special key codes aren’t allocated in the order they’re described in the specification: UNKNOWN is -1, meaning -6 is enter and -7 is backspace. That’s one mystery solved.

Still confused about 31 and 127 though.

2 Likes

127 is DEL in ASCII, but it shouldn’t be returned by an interpreter.

2 Likes

Yeah, and ZSCII deliberately doesn’t specify a meaning for 127 (like most of the ASCII control characters). If the intent is to capture delete, it should look for the Glk delete code as well…

According to DM4 Table 2A, ZSCII code 31 is for the escape key.

… but according to the errata for the DM4, this is an error and the actual code is 27.

And ASCII code 127 is for delete, and ZMS says:

It is now defined that the input character codes for return and delete are 13 and 8 respectively. (10 and 127 have been suggested as alternatives in the past).

though per ZMS 3.8.3.1:

ZSCII codes 127 (“delete” in some forms of ASCII) and 128 are undefined.

and the remarks for ZMS Table 1 mention:

‘Bureaucracy’ needs either 127 or 8 to be a delete code.

3 Likes

I think even I included 31 in a function in Basic Screen Effects, so sometimes it’s just a mistake.

1 Like

Very possible! I wrote the original version of this extension ages ago, and it was based on earlier code by Ron Newcomb, so plenty of places where errors could get introduced over the years.

Looking at Newcomb’s original, he checks for ' ' (32), 13, 10, -6, and 127. 10 is LF in ASCII, which should never be sent to the game in either Z-machine or Glulx, which is probably why my past self removed that. But then my past self added 31, for reasons unknown.

I think I’m going to cut it down to 13, 32, and -6, which should cover ENTER and SPACE on both Z-machine and Glulx.

The purpose of this extension is to handle actions that take several turns, but which you might want to interrupt at some point (like a GO TO command). When you start one of those actions, the command prompt changes to ], and you can press ENTER or SPACE to keep doing what you were doing, or start typing something else to stop and put in your own command instead. Are there any other keys apart from those two that you’d expect someone to press for “keep doing that”?

1 Like

Maybe a down or right arrow?

1 Like

Basic Screen Effects (whose “get a keypress” routine I’m using) specifically doesn’t pass arrow keys through to the game, because people might be using them to scroll and will be annoyed if that makes things happen in the game.

1 Like

I’ve been informed by testers that certain mobile keyboards have separate buttons for “line break” and “submit”, in which case the former sends 13 and the latter -6. So even in Glulx, it’s important to test for both!

Other testers have said their newline key sends something other than 13, which I suspect is going to be 10; working to confirm that now.

It’s the interpreter’s responsibility to convert the true key codes into VM appropriate codes. So you shouldn’t worry about any of that.

Perhaps, but if my game says to press ENTER and pressing enter doesn’t work, players are going to blame me rather than the interpreter authors :stuck_out_tongue:

Every game will break in that case, so you really would be right to point the blame back on the interpreter. Include it if you want, but make sure the interpreter authors know they need to fix their stuff.

Less facetiously, when there are keyboards that separate out “new line” and “submit”, it’s not clear to me that sending 10 or 13 for “new line” is wrong. The Glk spec doesn’t seem to prohibit it:

On the other hand, the library may be very clever and discriminate between tab and control-I. This is legal. The idea is, however, that if your program asks the player to “press the tab key”, you should check for a keycode_Tab event as opposed to a control-I event.

Note that the linefeed or control-J character, which is the only printable control character, is probably not typable. This is because, in most libraries, it will be converted to keycode_Return. Again, you should check for keycode_Return if your program asks the player to “press the return key”.

Some more details, per my testers:

  • Fabularium sends -6 for both
  • Text Fiction sends 10 for new line and 13 for submit

So right after posting that whole spiel, the latter seems distinctly not spec-legal; a game watching for keycode_Return (-6) will never see it. But from a “I want my game to work” standpoint I’m still going to recognize both 10 and 13; I doubt the IFComp judges will care about the finer points of Glk character input.

Yeah, that’s what I would do. As a spec writer I’d like to be a hardass about it, but interpreters (Glk libraries) are updated slowly these days and some code isn’t going to change soon.

1 Like

Those interpreters are both very old and unlikely to be updated. It’s surprising it has such an easily triggered bug.

However isn’t Text Fiction only Z-Code, not Glulx? In which case it should only be returning 13.