[ZIL] "You can't see any <blank> here."


I was going to e-mail this question to vaporware, but it occurred to me that it might be better to start posting these things here for the benefit of anyone else playing with ZIL.

So, it still bothers me that I can’t reproduce Infocom’s style of “You can’t see any here.” where is a word with more than 6 letters. I know we’ve discussed this several times, but I can’t remember if it was all on MUD and if it was one of the conversations I saved so I’m asking here again.

Is it possible to save the full noun phrase to some kind of string before parsing which I could then refer to when we get to “You can’t see any .”?

Barring that, is there some way to compare NOUN-PHRASE to other strings after the fact? So if my game has a magician and someone refers to him/her in another room, my code could check to see if the noun phrase is “magici” and then substitute the full word for it? This still deviates from Infocom’s behavior but would be close enough to appease me.


Yay ZIL questions!

First, some background: when you use a noun phrase to refer to an object that isn’t present, Infocom’s games repeat the noun phrase in the message, like You can't see any shiny metal sword here.

ZILF’s library gives the generic message You don't see that here. The message is printed by MATCH-NOUN-PHRASE, which reads a structure generated by PARSE-NOUN-PHRASE and tries to find a matching object in scope.

One approach to reproduce Infocom’s style would be to make PARSE-NOUN-PHRASE store the span of words it used, and make MATCH-NOUN-PHRASE print those words out of the input buffer using PRINT-WORD. (Word length shouldn’t be an issue there, since the input buffer has the full command; the interpreter just ignores the ends of the words when searching the dictionary.)

That much is straightforward: add new fields for start and end word to the NOUN-PHRASE structure (and update the routines that work with it). In PARSE-NOUN-PHRASE, fill them in: the first word number is passed in as .WN, and the last is .SPEC-WN at the end of the routine. In MATCH-NOUN-PHRASE, just loop between those numbers.

You might find that that doesn’t work during orphaning (a.k.a. disambiguation), because the original command is no longer in the buffer. I think you can see this bug in some Infocom games:

>get shiny metal sword
You can't see any shiny metal sword here.

>put shiny metal sword
What do you want to put the shiny metal sword in?

You can't see any    here.

You could try saving the buffer, but then you might run into the same problem when the second noun phrase (entered after the question) is the one that doesn’t match. ZILF never actually combines the two halves of the command in the same buffer.

So instead, during orphaning, you could fall back to printing an adjective/noun pair (from the NOUN-PHRASE's YSPEC), or a generic message if it isn’t clear which pair to print. I think that would still be consistent with at least some Infocom games. But that’s when you’re going to notice the 6 character limit.

The easy way around that limit is to add the <LONG-WORDS?> directive, which generates the LONG-WORD-TABLE mapping words to strings. If the word is listed in the table, PRINT the corresponding string; otherwise PRINTB the word.


Before Roodylib, Hugo went the route of saying “You don’t see that.” to everything. What I was eventually able to do was put places in the FindObject routine to make notes about whether the considered objects are living or plural so the “You don’t see that.” can use appropriate pronouns. As far as I understand the ZIL game loop, it doesn’t have an equivalent step (or at least, the parser limits grammar matching to objects in scope).

Anyhow, this <LONG-WORDS?> solution sounds intriguing.


Right. MATCH-NOUN-PHRASE uses MAP-SCOPE, which will eventually check every SCOPE-STAGE defined in scope.zil, but it’ll never consider an object in another room or a closed container.

If you wanted to do that, you could just loop over every object from 1 to ,LAST-OBJECT and reuse some of the logic from MATCH-NOUN-PHRASE to see if the NP refers to it.


Well, good to know that’s an option. I imagine down the road, I might want several “flavors” of parser.zil that do things a little differently. Also, not being a programmer, I have no idea what kind of processing overhead that’d add to playing a ZIL .z3 game on an Apple II emulator or something.