Here is my I7 source:
"test1" by codshead
Start room is a room.
"You're in the start room matey!"
some orange juice is an object in start room.
some grape juice is an object in start room.
a big orange is an object in start room.
i get this:
>look at the orange
Which do you mean, the orange juice or the big orange?
How should i fix this?
Thanks.
You donât have to fix it. A player who typed âX ORANGEâ might really have meant either object, and itâs reasonable to ask for disambiguation.
If youâre in a different situation and you want to address it, rename one of the objects (or use privately-named) and give it a two-word synonymâŚ
Some orange-juice is an object in start room.
The printed name is "orange juice".
Understand "juice", "orange juice" as the orange-juice.
Then âorangeâ alone will not match that object.
thanks. I prefer the second option.
However, if there was another adjective, say âfresh orange juiceâ would i have to list all permutations like this:
start room is a room.
"You're in the start room matey!"
some fresh grape juice is an object in start room.
a big orange is an object in start room.
Some orange-juice is an object in start room.
The printed name is "fresh orange juice".
Understand "juice", "orange juice", "fresh juice", "fresh orange juice", "fresh orange", "fresh" as the orange-juice.
thanks.
No. The way the parser works is that given n tokens that identify something, any sequence of any number of those tokens in any order will match the something. With
Understand "juice", "orange juice", "fresh" as the orange-juice.
all of
would match.
If there werenât limits on the size of the buffer and the number of words understood, then for anything that could be understood as some specific string, there would be an infinite number of sequences that could be understood as that thing.
Iâm somewhat abusing the word token above. Is there a discrete term that expresses âparticular fixed string that could end up being parsed as a token that could identify some given objectâ?
You can simplify things a bit by making parts of the word sequence optional:
Understand "orange/-- juice orange/--" or "orange/-- fresh orange/--" as the orange-juice.
which mean both âfreshâ and âjuiceâ alone match, or any combination of those followed and/or preceded by âorangeâ, in any order and/or multiple times, but not âorangeâ on its own or (generally) repeated- each âorangeâ must always be either preceded or followed by âjuiceâ and/or âfreshâ- so âfreshâ,âjuiceâ,âfresh juiceâ âorange juiceâ âjuice orangeâ âfresh orangeâ âorange freshâ, âfresh orange juiceâ âjuice fresh orangeâ etc. etc.all match- but not âorangeâ alone, or âorange orangeâ or âfresh orange orangeâ although âfresh orange orange juiceâ would match.
Ah! yes that works nicely. Although iâm a bit worried about it being able to work in any order. what if the words implied different objects.
I tried adding âa government officialâ and âan official governmentâ (a bit silly i know). Like this:
Start room is a room.
"You're in the start room matey!"
[some fresh orange juice is an object in start room.]
some fresh grape juice is an object in start room.
a big orange is an object in start room.
a government official is an object in the start room.
the player carries a thing called an official government.
Some orange-juice is an object in start room.
The printed name is "fresh orange juice".
Understand "juice", "orange juice", "fresh" as the orange-juice.
But it goes horribly wrong. here:
Start room
You're in the start room matey!
You can see some fresh grape juice, a big orange, a government official and some fresh orange juice here.
>i
You are carrying:
an official government
>drop all
(the official government)
Dropped.
>look
Start room
You're in the start room matey!
You can see two , some fresh grape juice, a big orange and some fresh orange juice here.
>x government official
You see nothing special about the official government.
That specific example could be resolved like others mentioned earlier, making both objects private-named and only allowing âgovernment officialâ and âofficialâ to describe the official and âofficial governmentâ and âgoernmentâ to describe the government.
You can also use âdoes the player meanâ to make disambiguation default to one or the other.
Like:
Does the player mean doing something with the orange juice:
it is likely;
Then the disambiguation will always pick the orange juice over the grape juice when disambiguating âjuiceâ and the orange juice over the orange when disambiguating âorangeâ.
But if you want a lot of objects in the same room with very similar adjectives and nouns, with each being equally important to the game, then it sounds to me more like a game design concern and could be fixed by changing the game rather than the programming. If you want to do something like have parts of things (like âEricâs Noseâ alongside âEricâ), then there are some tricks you can do with that, but it doesnât sound like what youâre looking for here.
Infocom had a distinction between adjectives and nouns, and if you typed a word like âorangeâ alone, it would prefer an orange-noun over an orange-adjective. Inform dispensed with this and relegated these things to âdoes the player meanâ rules.
The extension Disambiguation Control by Jon Ingold would let you write a rule that applies specifically âwhen also considering the orange juiceâ, but unfortunately it doesnât work with the latest version.
The official is a privately-named thing.
The printed name of the official is "government official".
Understand "government/-- official" as the official.
The order-insensitivity and mutual equivalence of all of the words are pretty fundamental. A good general solution for making some words optional but insisting that, if present, they have a particular position takes us into the territory of rewriting the parser.
But most players arenât even aware of the order-insensitivity. There have been many times the âitâs been good enough for thirty years so we shouldnât bother acknowledging it as a problemâ rationale has failed to persuade me, and Iâd prefer to have a distinction between adjectives and nouns in parsing, but I donât view this as a substantial problem and there are many things much higher on my wish list.
[ edited: I had started this before Mathbrush made the same point about how it could be addressed. ]
Annoyingly, this was relatively tractable in I6 â not trivial, but you could do it without much fuss. Itâs one of the few areas where I7 dropped functionality.
Yeah. What youâve done here is create two objects which as far as the parser (or for that matter the compiler- see later) is concerned have the same name (given that outside of multi-word âUnderstand⌠phrasesâ, the word order of names doesnât matter to the parser or compiler). So when theyâre in the room together, thereâs nothing the player could ever type to distinguish them and no other means for the parser to choose between them unless you provide extra guidance with a âDoes the player meanâŚâ rule. So the parser assumes that it has to not matter which it chooses, and it just picks one sort-of at random.
When the player is holding one, the fact that one is held by the person performing the action (âthe actorâ) and the other not allows the parser to make some distinctions- depending on the action it will choose the thing not held (e.g. TakeâŚ) or the thing held (e.g. DropâŚ). Or the player can make the distinction explicit by typing âExamine my government officialâ (held) or âExamine that government officialâ (not held).
Ultimately, the solution is never to have things that might ever be found together that are different in game terms yet are indistinguishable to the parser. This situation should be reserved solely for things which are also indistinguishable in game terms (such as the classic 5 gold coins) so that when after âtake coinâ the parser chooses one randomly, it genuinely doesnât matter which one it chose.
If you need to have an official government and a government official, then you should make them distinguishable to the parser and compiler. That means giving them names which are distinguishable to both parser and compiler.
To be distinguishable to the parser and compiler, you must get rid of the default situation where any combination in any order with or without repetition of the words âgovernmentâ and âofficialâ will match both things equally well. That means declaring them with different names- albeit ones the player is unlikely ever to type (The government-official is a thing. The official-government is a thing.) or no name that the parser can recognise at all (The government-official is a privately-named thing. The official-government is a privately-named thing.).
Note that when reading your source code, the compiler is also unable to distinguish between a thing called âgovernment officialâ and a thing called âofficial governmentâ, and when one is referred to will just pick the first one that was mentioned, so even if youâre going to provide new distinguishable names for the parser to recognise them by through âUnderstandâŚâ phrases, you still need to declare them with distinguishable names (such as âgovernment-officialâ, âofficial-governmentâ) for the compiler to recognise them by because the compiler doesnât have access to âUnderstandâŚâ phrases or âDoes the player meanâŚâ rules. And at the very least the compiler is going to need to recognise these as distinguishable things- e.g. â⌠as the government-officialâ vs ââŚas the official-governmentâ -in our upcoming âUnderstandâŚâ phrases and ââŚprinted nameâŚâ phrases.
So finally we just need to create a distinguishable means of parsing them through Understand... phrases and a player-friendly means of printing their names:
Understand "government/-- official" as the government-official.
Understand "official/-- government" as the official-government.
The printed name of the government-official is "government official."
The printed name of the official-government is "official government."
After all this, you might be thinking the best approach is not to create things with indistinguishable names. And youâd be right.
Thanks to everyone who has contributed information to this thread. Itâs been really interesting.
Iâve been investigating the Inform parser and there is definitely a weakness here. Of course, as pointed out by several people, this can be remedied with various âfix upsâ. But really this should not be necessary.
Overview:
The two things that appear weak are:
adjective noun confusion
âsome orange juiceâ and âan orangeâ is conflated by the word âorangeâ.
allowing noun phrase words in any order leads to confusion.
So, âthe old fat manâ is the same as âthe fat old manâ, which is fine but also the same is identified by âthe old man fatâ and âthe man fat oldâ
Now you might say, what is wrong with âthe fat man oldâ identifying âthe old fat manâ as it is a nonsense that serves no other purpose.
Yes indeed, but there are some cases when this reversal can mean something else.
Consider:
âthe killer whaleâ and âthe whale killerâ
These can be different objects which, without remedy, the Inform parser does not correctly distinguish.
Saying donât do it like that in your story, just choose other words, is a bit like the joke about the man who goes to the doctor and complains his arm hurts when he moves it in such-and-such a manner. Whereupon the doctor replies, well just donât do that then!
How to fix?
When you have a noun-phrase of the form, <list-of-adjectives> <noun>
you can allow the list of adjectives in any order, but you must discriminate on the noun which must be the end of the parse phrase.
so âorangeâ never matches âorange juiceâ by default, the word âjuiceâ must be present and last.
âfresh orange juiceâ is matched by âjuiceâ, âfresh juiceâ, âorange juiceâ, âfresh orange juiceâ and âorange fresh juiceâ but not by âfreshâ or âorangeâ alone (or even together).
âkiller whaleâ is never matched by âkillerâ or âwhale killerâ only âwhaleâ or âkiller whaleâ.
So insisting on the terminal noun is fix for all these problems.
Earlier, @Draconis suggested;
Infocom had a distinction between adjectives and nouns, and if you typed a word like âorangeâ alone, it would prefer an orange-noun over an orange-adjective. Inform dispensed with this and relegated these things to âdoes the player meanâ rules.
That the old Infocom parser did this appears to be lost in the Inform parser.
Notwithstanding that these problems can be fixed up by a number of somewhat ugly bodges, I feel the Inform parser way is a better one.
And instead of the non-terminal adjectives alone being an accepted match for an object, those are the cases that should be relegated to âunderstandâ or âdoes the player meanâ rules where deemed important.
Your views most welcome.
Itâs still the best solution, and one that has served Inform games reliably since 1993.
The general philosophy behind Informâs parser is that false positives rarely matterâno player is going to type âx fat man oldâ and then complain when the game understands it! But false negatives, like âx orangeâ producing âyou canât see any such thingâ because it wanted you to type orange juice, do impact playersâ experience. (And you can likewise tell the players âwell donât do that thenâ, but a few decades of tradition is hard to shake.)
If you want to require terminal nouns, I thought I had a good way to accomplish this (âa thing has a topic called the adjective. understand the adjective property as describing a thing.â) but Inform doesnât like using topic properties this way. Similarly you canât use an object property in a âdescribingâ statement like this.
So hereâs a mess of a solution. Iâm sure people can find ways to clean up the syntax.
First, something from future Inform:
A concept is a kind of object. A concept can be publicly-named or privately-named. A concept is usually publicly-named.
Now, we attach two concepts to every thing:
Adjective binding relates one concept (called the adjective) to one thing. The verb to a-bind means the reversed adjective binding relation. Every thing a-binds one concept.
Noun binding relates one concept (called the terminal) to one thing. The verb to n-bind means the reversed noun binding relation. Every thing n-binds one concept.
And the key, the understand lines:
Understand "[something related by reversed noun binding]" or "[something related by reversed adjective binding] [something related by reversed noun binding]" as a thing.
This means [adjective] [noun] or [noun] are valid ways to refer to something, but [adjective] alone is not.
And now, the part that I need to find a way to clean up. Thereâs no elegant way to access âthe adjective of the orange juiceâ at compile-time. So:
Some orange juice is a privately-named thing in the lab.
Understand "orange" as a concept when the item described is the adjective of the juice.
Understand "juice" as a concept when the item described is the terminal of the juice.
A large orange is a privately-named thing in the lab.
Understand "orange" as a concept when the item described is the terminal of the large orange.
And now:
>x orange
You see nothing special about the large orange.
No ambiguity!
A slightly more elegant syntax is to specify the concepts overtly, but itâs still not as nice as just being able to say âUnderstand [whatever] as the adjective of the juiceâ.
Parser theorists often tend to maximalism: Look how cool our parser is! You have to type âComputer, please go east.â because it only understands full sentences with punctuation! Look, it can understand âput the pear pruner on the pruned pear platter using the pair of prunesâ!
Meanwhile parser players love single letter abbreviations and typing as little as possible. âN. E. E. Get block. X blockâ. People have trouble typing or bad eyesight or are impatient.
Being able to type just the adjective helps make commands shorter. i had a game with orange juice and grape juice (the Magpie takes the train). Typing âx grape juiceâ is annoying. Typing âx grapeâ is easy.
(Actually I donât think I had orange juice. It was something else, I think)
If you lived through the 8-bit adventure era, you, frankly, expected adjectives. The vast majority of games couldnât handle RED BALL and BLUE BALL. They were programmed to work with you just typing RED or BLUE. This was the necessary design sensibility. I make all my games like this because (a) itâs what I grew up with, but probably more importantly (b) it also means you type the least and the game understands the most.
Admittedly it creates more disambiguation work!.. I have a lot of coloured things.
-Wade
Hereâs something that leverages the Subcommands extension by Draconis (which has many wonderful uses):
"Full Names"
Include Subcommands by Daniel Stelzer.
Definition: a thing is perfectly-referenced if the substituted form of printed name of it is the substituted form of subcommand of it.
Does the player mean doing something with something perfectly-referenced:
it is likely.
Does the player mean doing something with something when the second noun is perfectly-referenced:
it is likely.
Zone is a room.
A thing called an orange is in the Zone.
A thing called some orange juice is in the Zone.
test me with "x orange / x juice / x orange juice / take orange / drop orange / actions / put juice on orange / put orange on juice / put orange on orange".
The result of >PUT ORANGE ON ORANGE arguably makes the most sense, if one assumes that putting the juice on the orange makes more sense than putting the orange on itself.
EDIT: Note that thereâs a slight issue with Subcommands release 2 (which I think Draconis has already fixed but may not be publicly-available yet) such that some run-time errors can be thrown with the above. To fix that using release 2:
To decide whether (snip - snippet) is valid:
(- ({snip} % 100 ~= 0) -).
Definition: a thing is perfectly-referenced if the subcommand of it is valid and the substituted form of printed name of it is the substituted form of subcommand of it.
If you prefer that âorangeâ alone always means the orange, then you can add:
Does the player mean doing something to something perfectly-referenced when the second noun is perfectly-referenced:
it is very likely.
EDIT: This also might get you what you want, but note that the meaning of âgovernment officialâ and âofficial governmentâ to the I7 compiler is sensitive to the heading structure, and itâs really not possible for them to mean different things within the same section.
"Wishing for Adjectives"
Place is a room.
Other Place is east of Place.
Test me with "x official / x government / x government official / x official government / take government / e / drop government / x official / w / x government".
[Placing the objects in their own sections lets the compiler differentiate them.]
Section - Government Official
A privately-named thing called a government official is in Place. Understand "government/-- official" as the government official.
Section - Official Government
A privately-named thing called an official government is in Place. Understand "official/-- government" as the official government.
The solution from Zed (on which that is based) is the conventional option, i.e. using privately-named and the printed name property.
Iâd forgotten that neat point!
If you want to do this, this is another sneaky (aka hacky) alternative to Draconisâs method of implementing it:
The juice is a thing in the lab with printed name "delicious glass of fresh orange juice".
The delicious glass of fresh orange is a part of the juice.
Understand "[delicious] juice" as the juice.
Here the token [delicious] stands in for âany text that the parser recognises as referring to the âdelicious glass of fresh orangeâ objectâ
Making the list of adjectives the name of an object that is part of the described object invokes Informâs default âany number of name words in any orderâ method of referring to the adjectival object, while also ensuring the adjectival object is always in scope when the described object is in scope.
EDIT: to avoid the player referring to JUST the adjectival object (e.g. âx deliciousâ):
Before doing something when the current action involves the delicious:
say "You need to be more specific about the thing(s) you're referring to." instead.
EDIT2: This simple scheme will potentially run into awkward-sounding disambiguation questions from the parser if there is the possibility of objects in scope sharing one or more adjectives:
>x delicious
Which do you mean, the delicious glass of fresh orange or the delicious juicy red?
Also, any words typed at the disambiguation prompt will be inserted to the previously typed command BEFORE the word being disambiguated, so:
> x delicious
Which do you mean, the delicious glass of fresh orange juice or the delicious juicy red apple?
>juice
ends up with the command âx juice deliciousâ which, having reversed adjective/noun order, wonât be recognised as the juice. The following more elaborate scheme deals with both these issues- but with the caveat that it now wonât differentiate a government official from an official government!
Lab is a room.
A thing can be adjectival.
The juice is a thing in the Lab with printed name "delicious glass of fresh orange juice".
The delicious glass of fresh orange is an adjectival part of the juice. The printed name is "delicious glass of fresh orange juice".
Understand "[delicious orange] juice" as the juice.
Understand "juice [delicious orange]" as the juice.
The apple is a thing in the lab with printed name "delicious juicy red apple".
The delicious juicy red is an adjectival part of the apple. The printed name is "delicious juicy red apple".
Understand "[delicious red] apple" as the apple.
Understand "apple [delicious red]" as the apple.
Before doing something when the noun is adjectival or the second noun is adjectival:
say "You need to be more specific about the thing(s) you're referring to.[line break]Include the actual thing as well as any word(s) describing it." instead.
Test adjectives with "x delicious/red/x delicious/apple".
You can write Understand "[delicious glass of fresh orange] juice" as the juice. out in full, if you like, but the compiler will (as with all object names) happily recognise just [delicious] as long as itâs a unique name within the section heading.
That said, Iâm really with Zarf and others on this. The need or otherwise for adjectives as distinct from nouns is probably considered a solved problem in parser IF. The solution being that theyâre not necessary as a general concept. In very rare edge cases where the need canât be avoided (as discussed in this thread) the issue can be resolved by simple coding without hacking the parser.