For what it’s worth, I fixed it.
For TADS Adv3Lite users
For every door handle, I had procedurally added vocab from the door it was attached to. For some reason, if the door action was illogical, using the filterResolvedList method didn’t actually affect the final list of matches. So I nuked it all by adding the door vocab to the handle, but only after splitting the vocab and marking each word with [weak], in order to always force the door to have priority, unless the handle was specifically matched with “handle”.
Apparently, the [weak] token drops matches before filterResolvedList does, and will drop matches even when all actions are illogical. At least, this is how the behavior looks from the surface.
For everyone else who might still be curious (I tried to make this funny)
TADS Adv3Lite (and maybe Adv3?) lets an author review the nouns that matched against the player’s input, and use logical context to disqualify certain nouns, before the rest of the parser system tries to use disambiguation.
If an action fails, it sends an “illogical” signal back to the parser. Usually when this happens, the parser says “Hm. Okay. Maybe I did it wrong. Let’s try a slightly different approach just in case.” Time turns back, and it tries to interpret the player’s input differently this time. This continues until one of these branches either succeeds, or all of them fail.
Apparently, if there is no way for the player’s input to make any sense at all, the parser doesn’t even give the author the decency of disqualifying objects from matching. It simply decides that everything is equally-guilty of failure. However, this means that it will still send the player a disambiguation message, basically saying “Hello, player. I’m sorry, but would you prefer Failure A, or Failure B for this turn?”
Which—unfortunately—causes testers to write “why is it asking me if I want to open the door or the door handle?”
And then when the tester makes the choice, the parser reveals the true horror of the universe: All roads lead to failure!
So, I have a door matching to inputs like “freezer exit door”, and the handle matching to “freezer exit door handle”. The handle’s match words are actually generated procedurally (because I can’t be bothered to manually add handles to every door), and just slapped “handle” to the end of the door’s match words.
Unfortunately, when you have a cat that cannot open large doors, and is controlled by a player who types OPEN FREEZER, the parser will see nothing but doom and terror on the horizon, and it asks “Would you like to fail to open the door, or fail to open the door handle?”
Normally, I have it so all door handles will check the list of match nouns for doors, and if handles find a door in the list, then they all disqualify themselves, because it makes more sense for a player to refer to a door, unless the request is so specific that a door would fail to match, leaving only handles in the match list.
Unfortunately, as I explained before, the parser will not let this voluntary disqualification happen if every permutation of the player’s request will fail.
However, there’s another system in Adv3Lite, which lets you mark matching words of a noun as “weak”. This makes it so these words in other nouns will always be given match priority, and this seems to happen before the voluntary-disqualification stage. The difficulty is that for procedurally-generated door handles, I need to do some on-the-spot text editing to add the phrase [weak] after every match word in the handle, which also appears in the door’s match word list.
This way, the match words of the door are guaranteed to have match priority, long before the voluntary disqualification stage.
