Well, I suppose any change at all to the standard may confuse some people. The same argument could be used against any suggestion in this thread. But it in this particular case it seems more likely to clear up existing confusion, such as the example I gave from Bocfel, and prevent more such confusion in the future.
EDIT: To put it another way: Currently, the answer to the question “What is the name of control character 8?” is “Backspace, except in ZSCII, where it is called delete, not to be confused with the ASCII character 127 named delete or the character the original Infocom sources call DELETE-KEY.” After we make the change, the answer will become simply “Backspace.”
This is true. I don’t personally don’t think renaming the ZSCII characters to match ASCII is necessary, but if most others feel differently I wouldn’t object.
I think any confusion caused by changing ‘delete’ to ‘backspace’ would be fixed by adding a note that the standard previously called it ‘delete’. I think the standard would be clearer if the difference between ‘backspace’ and ‘delete’ were made more explicit (and that both 8 and 127 are treated by games as ‘backspace’).
ZSCII 127 is not valid, and compliant interpreters should not be returning it. I don’t think there’s any point in noting that an occasional game may have also accepted it.
When you are trying to understand the original Infocom sources with the help of the standards document, any differences between the Z-machine as originally implemented by Infocom and the Z-machine as defined by the standards document are of interest.
Very much agreed. There is very little reason to ever exclude anything, particularly if it provides context that might be interesting or that someone might run into or simply a question they may have. There is every reason, of course, to make sure that information that is incidental and/or historical – as opposed to implementation guiding – is appropriately situated to make it clear why it’s being included.
I forgot you said you’d found that Infocom’s Z6 games did check for 127 (not just rare post-Infocom games). That’s interesting, could be an unknown Z6 change. Did their interpreters also generate a 127?
A remark that some original Infocom games accepted characters which are now considered invalid is fine. This would be similar to the remark near the bottom of Section 3 that mentions “two consecutive Z-characters 4 or 5 as shift locks” as being a thing some of Infocom’s interpreters did, but standard interpreters should not do.
I don’t know how to test this. It might be possible to tell from the interpreter sources. At a glance, there seems to be a routine named char_in() which passes on raw keyboard input unfiltered, except for the arrow keys, but I don’t know what happens after that.
After compiling gntests to z6, I can confirm that at least the original Mac interpreters for Arthur, Journey, Shogun, and Zork Zero all return 127 for delete (and 8 for the backspace key.)
In fact, Bureaucracy (a z4 game) also checks for 127 and 8 as input codes and treats them both as backspace. This is already mentioned as a note in the Remarks for Section 3, although it says “‘Bureaucracy’ needs either 127 or 8 to be a delete code.”.
The source I looked at was for Infocom’s Apple II interpreters. I’m not very certain of my interpretation though. Testing each would be the only way to know for sure.
Even if the V6 games and interpreters accepted 127 (ascii delete), adding it to the standard now as anything more than a historical note would be a mistake in my opinion.
Curious question: If the single parameter for @input_stream (DIRIN in zil) were to be something other than 0 (keyboard) or 1 (external file), what should happen? I was curious as I wanted to make a bit in my game with actual timed text, but the only way to do that is to use a @read_char or @read, which allows you to skip the timer if you hit any key. How do I avoid this?
I don’t think the spec says anything particular about that, so a fatal error would be reasonable.
Yes, timed input is the only reliable way of doing timed text in the Z-Machine. Some games try to delay by running a loop a huge number of times, but you can’t be sure how long it will actually take, and some interpreters would also not send any output until keyboard input is requested, making the whole thing pointless. If you need more control than that you’d need to switch to a different VM, like Glulx.
Hmmm, I’ve got a recursive loop that contains an input that runs after 1/10 of a second, and it loops 20+ times. That way, it feels to the player as if hitting the input doesn’t do anything, although it really does speed it up.
(I can’t use Glulx since I’m writing in ZIL, sorry…)
You could make a loop containing the timed input that only breaks out when a variable reaches a certain value. Only increment the variable in the interrupt for the timed input. This means there is no way to speed it up. Pressing a key would theoretically only slow it down.
That might infuriate people though.