These two commands end up producing the same action, but one of them also produces an unnecessary disambiguation message, while the other doesn’t:
Since ‘look up’ is likely to be the command more players use, it would be nice if the unneeded message could be suppressed. How can I accomplish this?
Sorry to be slow getting back on this one, but my time has been a bit limited these past few days.
At the moment I think I can see what the problem is, but I don’t have an immediate solution (although I have a suggestion that may work - see below).
The problem is that the parser is understanding the command LOOK UP TRAINS IN BOOK not as look up the “trains” topic in a thing called “book” but look up a topic called “trains in book.” It’s then defaulting to the last used (or only) Consultable in scope, which happens to be the fat leather-bound book, and is displaying the message “(the fat leather-bound book)” to confirm which Consultable it has used (since it thinks you haven’t specified it).
This seems to be indicated by your debug trace which shows that LOOK UP TRAINS IN BOOK is triggering the ConsultWhatAbout action (instead of going straight to the expected ConsultAbout action).
I think the problem may be that the bracketing in VerbRule(LookUp) as gone awry. Once again I don’t have TADS 3 on the machine I’m using right now so I can’t try this yet, but in the meantime you could try:
modify VerbRule(LookUp)
'look' 'up' topicIobj 'in' singleDobj
:
;I’ll take another look once I get at home this evening and check whether this works. This isn’t a permanent fix since there are other combinations of words that need to be matched, but by reducing it to the simplest form we may be able to track down the source of the problem.
That makes sense. By now it’s become a non-issue in my game, because the book isn’t being used to look up topics. I’ve intercepted or hijacked the ‘look up’ grammar so that ‘look up page 47 in book’ works as desired.
I’m glad you’ve managed to find a solution that works for you, but I’m still anxious to track down the cause of the problem, which may well afflict other games.
I think I’ve now got there - it was a tweak I’d made to the parser to make it prefer input that matched a pre-existing topic to one that didn’t, but in a case like this it doesn’t work well, so I’ve now added another tweak which will hopefully make it work better. This will be included in the next release.