I’ve been wrangling with a weird parser issue and the example called “Misadventure” (#295) from the documentation is a pretty good test case for the problem. In Misadventure, it’s possible to use numbers to trick the parser into assuming you want to fast travel to your current location. Consider this:
Plover Room
You’re in a small chamber lit by an eerie green light. An extremely narrow tunnel exits to the west. A dark corridor leads northeast.
1
That noun did not make sense in this context. ← Makes sense
2
That noun did not make sense in this context. ← Also fine
You can’t use multiple objects with that verb. ← Strange
(Plover Room)
You’re already in Plover Room. ← Really unexpected
I’ve managed to track the misbehaviour down to line 1666 of Parser.i6t. If I change the offending line from:
allow_plurals = true; desc_wn = wn;
to
allow_plurals = verb_wordnum > 0; desc_wn = wn;
That’s an adequate “fix” for the problem. I’m basically telling it to NOT swallow up any numbers as descriptors and instead parse them as nouns if there was no verb (verb_wordnum). It makes sense to me as it seems very unlikely someone would want to “no verb” a quantity of a noun action. e.g.
3 Plover Room
I spent a while tracking this down and I really want to make sure I’m not doing something dumb, so a few questions:
Is there a better variable than verb_wordnum to use here? Like, is this incompatible with some obscure command syntax I haven’t tried?
Can anyone see any odd side effects I might introduce by patching this for my game?
Most important, I don’t really want to actually modify the i6t file. Is there a way for me to patch this one line as an include in my game, rather than replicating a modified version of the entire ParseToken function?
This is the same chunk of code mentioned in bug inform7.com/mantis/view.php?id=976 . (That bug is filed against the I6 library, but the same code exists in I7’s parser, obviously.)
On the other hand there’s inform7.com/mantis/view.php?id=835 , which is a similar problem (period after a number causes trouble) but possibly not in the same part of the parser.
This is all horribly messy and I’m certain there are side effects, but I have no idea what they are.
The template system allows you to replace parts of Parser.i6t at a granularity of chunks, but not individual lines. Looks like this is the “Parse Token Letter C” chunk. See manual 25.25.
Even with the proposed fix, you will get different behaviour, if your command ends in a number with and without a period respectively, as in cases like these:
A solution might be to strip any full stops from the end of a player’s command.
But even if you do, a full stop between commands will still make the first command misbehave in such cases – as will a THEN:
Thanks, Zarf. This is probably the neatest and most comprehensive solution to the problem. As Felix mentioned, it’s still possible to confuse the parser in other situations if I modify the initialisation of allow_plurals. With the patch suggested in bug 835, those situations go away too (at least as far as I’ve tested).
I only ran into this parser bug because I have a verbless action for a person “[any person]” and a separate verbless action for a number “[number]”.
I did try searching the bug database for this problem before posting here. It seems tough to find a bug with such systems unless you know what you’re looking for.
Yeah, the bug system can take some digging through. I wound up searching for “allow_plurals” and “numbers” (the latter only turned up fifty results, but I knew the bug was in there because I filed it. )
)