As parser players, how would you feel if a z-machine game was released with z6 despite not making use of graphics or any z6 functions?
I am doing this for the very specific reasons regarding use of interpreters. The only interpreters that support z6 files that I am aware of are Frotz and Gargoyle. Those are the only two I know of that also support Z-machine Standards 1.1, which is the issue I am chasing. Many interpreters don’t support the non-prompted saving of external files in the z-machine, and it would screw up my game if you couldn’t save like that.
How many interpreters allow you to play z6 games? If interpreters such as Lectrote or others do, then I might discard this idea. Also in case anyone has any objections to the use of z6.
Not sure I understand your intent, but a z6 game that doesn’t use graphics is perfectly valid, just not as widely supported. Maybe if more games were released that way support would improve…so…I have no problem with it.
There is no 1.2 standard, but there is an old proposed 1.2.
Saving without prompting is part of the 1.1 standard. I’m don’t see how z6 affects this either way.
If I’m reading this right, your plan is to release your game as a Z6 story file strictly in order to restrict the target terps to Frotz and Gargoyle, because they incidentally also are the ones that support standard 1.2? If so, that seems very hacky.
Isn’t the correct way to detect which standard the terp supports to check the standard revision header?
I don’t object to the idea of system prerequisites. Sure, graphics can be prerequisites, but so can the features you rely on. But practically, I would prepare for some pushback from players who have gotten used to doing things their own way.
We have no data regarding interpreter preferences, though I imagine web play is on a growth trend due to its availability via unboxing at IFDB.
So I haven’t an objection, and philosophically I think you should be able to do what you want. It’s more of a concern I suppose.
I suspect that using z6 compatibility as a test in this way is not going to get you exactly the right answer.
I am currently working on a Discord bot for Zcode/Glulx games. (Perhaps more in the future, but I’m starting with those.) I use Bocfel, which is Gargoyle’s Z-code interpreter.
Bocfel supports z6, but the Discord bot doesn’t, because I haven’t implemented any support for graphics or z6’s multiple windows. (Again, I might in the future, but it’s not there now.) There’s no reason why your game shouldn’t be playable in a chat-session context, but using z6 would rule it out.
Standard interpreters write the version of the Standard they support into bytes $32 (major) and $33 (minor) in the header, so you can check for 1.1 support there. There’s been some discussion of adding a gestalt system to check for specific interpreter capabilities, but sadly it’s never caught on.
Full support of the Z-Machine’s @save function isn’t something you can programmatically test for. It actually isn’t even fully compatible with the Glk API (that’s part of why I didn’t add the non-prompting modes to ZVM. Also that no one used it, probably because it’s not reliably detectable).
So if you’re limited to what you can currently do in ZILF, use the player to test for you. Try writing to a file before the game properly begins, and inform the player that if a save dialog was shown that they’ll need to switch to a different interpreter.
Btw, Parchment now uses Bocfel, so I think its file support should be fully supported online now.
… Unfortunately, it still doesn’t support unprompted file saving, but one major problem is that even though this still is a problem, bytes $32 and $33 in the header of a Parchment game are 1 and 1, which, well wouldn’t be correct. Right?
Yeah, the iplayif.com version. I still get the prompt to save and restore files (which, if I understand correctly, you didn’t implement, but considering it does work in Gargoyle…)
I think what’s happening is that Bocfel’s save opcode is calling zterp_os_aux_file which is an OS-dependent function, and isn’t implemented for Emglken’s ZTERP_NO_STDIO mode.
These datafiles should be possible in Parchment, but I’m not sure exactly what zterp_os_aux_file needs to do. @cas would of course know better.
zterp_os_aux_file returns the full path of a file to create based on the incoming suggested filename. It’s meant to contain such files in a “safe” directory so that the game can’t, maliciously or accidentally, overwrite files it didn’t create. For example, on Unix, a path might be $HOME/.local/share/bocfel/auxiliary/save.z5-1-230505-e53e/hopcount.aux.
The default version of this function, when no OS is selected, returns null, which forces a prompt. For Parchment, you can either patch the default, or add a new OS type which supplies a Parchment-specific version of the function. In no-stdio mode, it’ll then pass this on to glkunix_fileref_create_by_name_uncleaned when creating the new IO object.
The requirements of the function are:
The Z-machine allow games to save and load arbitrary files. Bocfel confines these files to a single (per-game) directory to avoid games overwriting unrelated files. This function, given a filename, returns a pointer to a string containing a full path to a file which represents the passed-in filename. The file need not exist, but its containing directory must. A null pointer is returned on failure. The file must not escape its containing directory, which may require platform-specific methods, but at the very least means that a file containing directory separators (e.g. ‘/’ on Unix) must be rejected or sanitized. The incoming filename is guaranteed to consist of ASCII printable characters, i.e. in the range 32-126, but may need to be further sanitized depending on the needs of the target platform.
I’ve long thought that game-suggested filenames should be strictly limited to ASCII alphanumeric characters - no punctuation at all. You still need a separate directory to ensure something else doesn’t get overwritten, but it gives a cross-platform safe set.
Edit: Note that doesn’t mean any of those possible names will always work. Windows has some reserved names you can’t use at all.