In this example script below
test abcdef with "x me/i".
test abcdeg with "l".
test abcd-e-f with "x me/i".
test abcd-e-g with "l".
The first three work as expected in 6L. However, “test abcd-e-g” gives “x me/i” as the test command(s), suggesting it is being overwritten by abcd-e-f or the parser sees only “abcd-e-”.
The quick fix of
Use DICT_WORD_SIZE of 12 doesn’t work in Z-Machine, and it’s not needed in Glulx. And a quick perusal of tests.i6t turned up nothing.
This is another of those trivial things it’d be nice to understand if I can, but it’s not critical, as I was trying to have test cases labeled for readability as such:
test x-1-y-1 with ...
test x-1-y-2 with ...
test x-2-y-1 with ...
test x-2-y-2 with ...
Is there anything I can tweak to allow this, or is it just a z-machine limitation?
In the dictionary encoding of the Z-Machine, hyphens take up two ZSCII characters. You have nine ZSCII characters max, so avoid hyphens.
In Z-code version 5 and 8 (which is what you’re using), the dictionary resolution is nine characters. However, all characters but a-z take up more than one character slot. The common delimiters like “-” take up two character slots. So abcd-e-f would take up ten slots, which is one too many. Thus, the “f” is skipped.
Thanks to you both. It’s good to know that it’s not just hyphens.
I think a suitable solution would be to use alternating capital and lower-case letters. I don’t know how case-sensitive the test command is, but I do want to be able to look at it and not have the letters run together, and that seems like it would work.
The Z-machine interpreter turns everything into lowercase before handing over to the game/library. There is no way for the game/library to know if something was entered in uppercase or lowercase.
I don’t remember if is possible to select custom abbreviation in I7, but why don’t use some of the abbreviations for the long hypenated testcase names ?
something like this (I6):
Should allow to have a test name in the form tst-N-xy-Y to take eight zchars (two for the abbreviated tst-, two for the 1st number, two for the xy- and one for the 2nd number, eight physical chars (avoiding “the superhero gender issue” on both counts) and eight zchar, keeping one zchar free for impromptu variation of the type tst-X-xy-Y[a-z] (we’re talking debugging code…)
seem to me a fine idea, at least on I6 environment (I consider I7 the compiler for working in glulx, so I don’t looked much upon zcode related specifics of I7)
Best regards from Italy,
While you might be able to put texts with abbreviations into the game dictionary, all that would do is stop it from matching anything. When the input is converted into ZSCII, it is converted without abbreviations (section 3.7).
But with command replacements you can have arbitrarily long test names:
Test 000000000 with "look".
After reading a command:
if the player's command matches "test zeroth test":
change the text of the player's command to "test 000000000";
You might be able to come up with some schema where the first four characters of a test name are a category, and the last five are the specific test, and then you could combine them together in a rule without having to list every combination manually. Or you could use a table or something. Lots of possibilities!
PS: I added this to the list of bugs: Should warn or error when compiling test names to identical dictionary entries in Z-code · Issue #10 · i7/inform7-bugs · GitHub
Thanks for doing this! I don’t think I was aware of the inform-bugs site, or if I’d seen it, I’d forgotten it. I’m glad this all is at least worth a look.
It’s very useful to see how to get a lot of mileage using the parser to break things down when you have options/categories you want to list explicitly. I think at some point it would become easier to use Zarf’s regtest.py scripts for this, or to use a python/perl script to generate all the possibilities.