Better handling of AND

During recent Scroll Thief testing, some new players were frustrated when TAKE THE BOOK AND READ IT returned “you can’t see any such thing”: after all, the book was right there! Of course, what the parser saw was (take ((the book) and (read it))), failed to match “read it” against any world object, and returned that error message. But to the player this wasn’t at all clear.

Experienced I6 coders, if I wanted to change this parser behavior, where should I start? And how much would I be likely to break? My first thought was to modify the multiple-object parsing code to check if the first word of a supposed object name was a verb in the dictionary. If it is, and CANTSEE_PE would be returned, instead change the preceding COMMA_WD to THEN1_WD and reparse the entire command from scratch. But this could cause strange problems if the parser was looking at the wrong grammar line and a later one was actually going to match.

Not an I6 coder, but on the principle that the answer to “how much would I be likely to break?” is “everything”… why not write an After reading a command rule that checks whether “AND” is followed by a verb and changes it to “then”? You might have to duck into I6 for the part where you check whether it’s a verb, but it would probably be less messy than delving into the parsing code. Also, this would work even when the verb didn’t take multiple objects (“read the book and drop it”).

The meaning of “and” seems pretty hard-wired. You’re really asking for the parser to be able to understand it as either the “connective” of a multi token or as the equivalent of a THEN4_WD.

The “Parse Token Letter E” section of Parser.i6t is where it treats “and” as a connective for a multi-object list. I would think you would need to add a new parser state variable to track that it’s now checking for whether “and” was properly used as a connective here, then set some other state if it’s not, so that during the next retry you can, in section “Parser Letter G”, detect that and treat the problematic “and” as another instance of a “then” word.

Things could get trickier from there if you want to be consistent, e.g. >TAKE COOKIE AND DONUT AND PUT COOKIE ON PLATE needs to understand both senses of “and” to work.

You might be better off with a routine like you originally proposed that, instead of reparsing after detecting "and ", teaches the player about how to communicate their apparent intent in the “normal” way using “then” or a period.