Inform doesn’t see any need to disambiguate between the ‘book stand’ and the ‘huge encyclopedia’, since their internal names are perfectly distinct. (The understand assertion doesn’t change that.) Therefore, the does the player mean rules are not considered.
Adding “book” to the name of the huge encyclopedia (“the huge encyclopedia book”) means that the disambiguation machinery starts running.
However, that gives rise to another weird behaviour: the last word in the command “consult book about foo” influences the parser’s interpretation of “book”.
Even after putting “book” into the name of the encyclopedia, the parser will choose the book stand if the player types “consult book about foo” but the encyclopedia if the player types “consult book about huge”!
[code]The reference section is a room.
A book stand is a supporter. The huge encyclopedia book is a thing. It is on the book stand. The book stand is in the reference section. The printed name of the huge encyclopedia book is “huge encyclopedia”. Understand “encyclopaedia” as the encyclopedia.
Does the player mean doing something to the book stand:
It is unlikely.
Does the player mean doing something to the encyclopedia:
It is likely.
Does the player mean consulting the encyclopedia about the topic understood:
It is very likely.
Does the player mean consulting the book stand about the topic understood:
It is very unlikely.
Test me with “consult encyclopedia about foo / consult book about foo / consult book about huge / x book / x encyclopedia”.
[/code]
EDIT: Strangely enough the parser seems to choose the encyclopedia before the book stand as soon as one tries to “consult book about” something in scope …
Hmm, my game is inventoryless anyway, so maybe I should just have one object instead of 3 (the book stand, the encyclopedia, and an irrelevant object that’s part of the stand). But then parsing becomes a nightmare… Maybe I should just not call it a “book stand” in the first place (the word “stand” was already in use elsewhere, but I can just make it privately-named).
OK, I tested calling it a “book-stand” and then giving it the printed name “stand” and that worked. It’s close enough to what I wanted.
I obviously shouldn’t be too sure, but now I think this is what happens: does the player see rules apparently don’t run when the topic is not an object in scope; the parser therefore chooses the book stand rather than the encyclopedia, since the former is in the location with the player, whereas the latter is not (it is on the stand, not in the reference section).
Some such line as
Instead of consulting the book stand about anything when the player's command does not include "stand": if the player can see the encyclopedia, try consulting the encyclopedia about the topic understood; otherwise continue the action.
can be used as a fix.
Is this behaviour (ignoring does the player mean rules for actions applying to a topic whenever the topic understood is not also an object in scope) to be considered a bug?
I used the TRACE 5 testing command on the original source to figure this out. Inform scores objects by various criteria and only runs Does The Player Mean if the scores are equal. The stand got an extra 20 points than the encyclopedia due to the location: the stand is in the player’s location, while the encyclopedia is neither in his location nor in his pocket. Hence the stand is preferred.
If you put the encyclopedia in the room but not on the stand you’ll get the which did you mean question, as expected.
I don’t think so.
The score is calculated by the ScoreMatchL routine (§38 in the Parser Template), and objects score for does the player mean rules after scoring for location or not being a direction but before scoring for not being scenery.
(ScoreMatchL calls ChooseObjects which calls ScoreDabCombo (both at §62 in Parser) which calls CheckDPMR (Standard Rules ch.2 §20) which runs the does the player mean rulebook.)
X BOOK will run the does the player mean rules, even if the encyclopedia is in the stand; and so will CONSULT BOOK ABOUT ME, CONSULT BOOK ABOUT STAND, CONSULT BOOK ABOUT BOOK, etc. (where the topic is an object in scope), whereas CONSULT BOOK ABOUT FTHAGN, CONSULT BOOK ABOUT SVENSKA AKADEMIEN, or CONSULT BOOK ABOUT IF-COMP (where the topic is not an object in scope) will not run them.
I can’t tell you how many parsing problems I’ve had that are not solved by Does the Player Mean rules. They’re just not consulted enough. And even when they are, they don’t do any scoring between them - you have to be careful to order them so that exactly the right one fires. One day, one day I tell you, I’m going to rewrite that damn parser and expose all of its workings to I7!
I suspect you’re being a smartass, but I don’t quite understand your point…
What troubles me is that if only one DPMR can make a decision, why are there four different results? Why not just “yes” or “no?” Going the other way, why not make it like choosing notable locale objects activity, where you can have multiple rules in the After rulebook, each of which directly manipulate the score?
[code]Scoring the player’s command is an activity.
For scoring the player’s command: (- I6 Parser -)
After scoring the player’s command when the most likely action is consulting it about and a book is visible:
Set the noun score for the book-stand to 0;
Repeat with the tome running through visible books:
Increase the noun score for the tome by 10;[/code]
Yes, I’m being a smartass – the point is that the DTPM rules are a (probably too simplistic) attempt to solve an object precedence problem. Ordering rules in a rulebook is also a precedence problem; it’s exactly the same once you break it down to a mathematical model.
I still don’t have a solution, of course.
It’s not normally the case that only one rule decides the disambiguation outcome. The rulebook is run separately for each option (perhaps after the parser has pre-eliminated some options). Each option gets a score, and the option with the highest score wins.
Only one rule fires for each option. But it is (or can be) a different rule for each of the options.
Using a scoring activity as you suggest would be more flexible, yes. (But also slower, as the system would have to invoke an activity – three rulebooks – rather than one.)
So I know you (the OP) found a solution that works for you, and the discussion has moved somewhat away from this, but what about the workaround of just having consulting it about actions on the book stand call consulting it about on the encyclopedia? You never (I assume) want to consult the book stand about anything.
I don’t recall if consulting it about requires a held object, but I’ve been discovering more and more problems with redirecting actions to a different noun. Occasionally, you’ll run into something like this:
In this case it might work, because you’re confined to a single action, but if you want to redirect lots of actions, it gets really messy. Another alternative I’ve tried:
Before doing anything other than examining with the book stand:
now the noun is the dusty book
…runs into more problems, because rules that run before it and rules that run after it are dealing with different nouns - you don’t always get the full complement of action checks that you would expect with a “try”… but I think to use “try” in such a case you need to do some magic with stored actions.
It’s usually preferable to have the parser choose the right object in the first place.
I think I’ll try doing that this week. Not really with the intention that you’d really want to use it (as I’m pretty sure it will be slower than i6) but just as a learning/teaching tool. Besides, I made some really cool new Understand tokens and I’d like to show off how powerful the parser can be.
Someone asked why I didn’t simply redirect consulting actions from the stand to the encyclopedia. The answer is that I could, but then I’d also need to fix this:
CONSULT BOOK ABOUT FOO
(the book stand)
You discover nothing of interest in the encyclopedia.
That involves not only suppressing the “(the book stand)”, but also putting in a “(the encyclopedia)” to replace it. I simply felt it was not worth the effort.
EDIT:The bug in question. Apparently I’m not the first person to run into this…
Actually, that is not at all simple. You’d think you’d only have to write a rule for clarifying the parser’s choice of the book stand unders certain conditions (or a rule for printing the name of while clarifying … etc.). But, as it turns out, the activity of clarifying the parser’s choice of something does not happen at all when the action being processed applies to something else than one thing.
In
the message “(the book stand about)” can’t be intercepted by a rule for clarifying the parser’s choice of something.
Judging from the parser, this is very intentional; but I can’t see that it is mentioned in the documentation, so I suppose it belongs in the Inform bug tracker’s “errata list” for the documentation.
