The most recurring problem I have these days is getting the right turn of phrase for two-noun actions, especially when sorting out Does The Player Mean’s. A lot of phrases compile or are close but don’t produce the effect you want.
I’ve made an action ‘pouring it into’.
pouring it into is an action applying to two things.
Understand "pour [something preferably held] into/in/on/onto/over [something]" as pouring it into.
Understand "pour [something preferably held] in/on to [something]" as pouring it into.
Understand "pour [something preferably held]" as pouring it into.
Things can be liquid or non-liquid. I don’t want the liquid token in the grammar.
I want a DTPM to favour pouring nouns which are liquids, so that POUR favours any liquids present if we just type POUR (EDIT: yeah, just POUR). I’ve tried about ten variations on the following and none have worked
Does the player mean pouring into something when the noun is a liquid thing:
it is likely;
Pouring into, pouring into something, pouring a liquid thing, pouring something liquid, putting the preamble after the colon. What’s the phrase that will work here?
Would you mind saying a bit more about your desired outcome? I think I see what you’re getting at with the liquid, but I’m wondering how you’d want the target of the pouring (2nd noun) to be selected if the player only typed in POUR.
lab is a room.
A thing can be liquid.
The player carries the frozen water.
The player carries the tepid water.
The tepid water is liquid.
The jug is a thing in the lab.
pouring it into is an action applying to two things.
Understand "pour [something preferably held] into/in/on/onto/over [something]" as pouring it into.
Understand "pour [something preferably held] in/on to [something]" as pouring it into.
Understand "pour [something preferably held]" as pouring it into.
does the player mean pouring liquid into something: it is likely. [`something` is optional]
test me with "pour water into jug"
lab
You can see a jug here.
>test me
(Testing.)
>[1] pour water into jug
(the tepid water into the jug)
>
@Zed Great! I mean… argh! The only thing I didn’t try was the adjective ‘liquid’ on its own, because I assumed it wouldn’t work. I kept going with stuff like ‘something liquid’, ‘a liquid thing’ etc.
Sure. The biggest goal is that when the player just types POUR in the presence of liquid, they will not receive the message ‘What do you want to pour?’ That’s now achieved.
For the purposes of general fobbing, the 2nd noun becomes the location if the player doesn’t give a second noun. I can then detect that and understand that the player has typed ‘POUR (LIQUID)’ (but not into any particular thing.) At which point, check rules can also pour the drink into the obviously right second noun if need be. Or, in a situation like we’re a customer in a bar (yeah, this was the situation that started all this…) POUR DRINK and POUR DRINK INTO BLAH may be very different things. And the player may have to specify the second noun for me to be satisifed with what they wanted.
What this was really all about was cutting out another pointless question or disambiguation from the parser in my WIP, which is down on such things.
does the player mean pouring a liquid thing into something: and does the player mean pouring a liquid thing into: work in 10.1. They don’t work in 6M62?
Actually I spoke too soon. I didn’t test first the solution because I was mentally celebrating.
This -
does the player mean pouring liquid into something: it is likely
didn’t work, either. The rules response on it says ‘(doesn’t apply / wrong action)’.
I know there’s accessible liquid in the room because if I add ‘Does the player mean pouring harbour water into when (current-chapter is 1 or current-chapter is 4): it is likely’, it picks the harbour water for a raw POUR.
EDIT - Just checked @Zed 's demo ini 6m62, as well. If I just type POUR, it says WHAT DO YOU WANT TO POUR?
Your setup is pretty complicated, as far as parsing details go. You’ve got:
The [something preferably held] token, which prioritizes things directly held in a way that bypasses does the player mean rules.
A “short grammar” that allows parsing for a two-noun action with only one noun.
Some does the player mean rules to help with automatic disambiguation but which may not be consulted.
Can you provide a functional scenario that is a “lookalike” for the problem situation? I have a feeling that everything is working as designed but in a non-obvious (and not well-documented) way.
Right. Reproducing the most basic version of my grammar and scenario suggests the liquid-favouring rule is not coming into play at all.
I made a test project with this grammar, and a backdrop liquid in room one, and a non-backdrop & portable liquid in room two (two common situations in their most simplified forms). Then I throw a non-liquid prop into each room (apple and banana respectively.) So the demo types POUR in room one, then goes east and types POUR in room two.
Summary
Water-test is a room. "There's a deep pool of water here.".
A thing can be non-liquid or liquid. A thing is usually non-liquid.
pouring it into is an action applying to two things.
Understand "pour [something preferably held] into/in/on/onto/over [something]" as pouring it into.
Understand "pour [something preferably held] in/on to [something]" as pouring it into.
Understand "pour [something preferably held]" as pouring it into.
Rule for supplying a missing second noun while pouring (this is the default target for pouring is the location rule):
now second noun is the location;
Does the player mean pouring liquid into something:
it is very likely;
Water is a liquid backdrop. Water is in Water-test.
an apple is in Water-test.
Cola-test is east of Water-test.
a cola is in Cola-test. cola is liquid. "There's a glass of cola here.".
a banana is in Cola-test.
Test me with "pour/e/pour".
In room one, the game favours the non-liquid apple, not the backdrop liquid water.
In room two, where both the cola (liquid) and banana (non-liquid) are just sitting in the room, it can’t decide. In neither case is the liquid-favouring rule being applied. I see this when I type RULES ALL then examine the Does The Player Mean outcomes during the test. This explains why the apple wins in room one. It’s not a backdrop.
So something’s not gel-ing even in this simplified version. I also experimented with removing the ‘rule for supplying a second noun…’ that didn’t affect things. Nor did changing ‘something preferably held’ to just ‘something’.
The first non-obvious part is that for the command >POUR you’re depending on “inference,” which I don’t want to get into in detail. The relevant part is that the parser has gotten as far as knowing that it has to match a grammar line starting with “pour” and is trying to auto-complete the command with the first applicable grammar line, which will be your “short” grammar line in this case.
The second non-obvious part is that there are some “secret” rules about the way the parser operates that give a preference to things which aren’t scenery. These secret rules are not author-modifiable by default, and require I6 work to change. Since Water is a liquid backdrop. and (per the Standard Rules) A backdrop is usually scenery., the water is given less preference than the apple in the first room. Both the cola and banana are given preference in the second.
The third non-obvious part is that the DTPM rules will be run every time an ambiguous noun phrase is encountered while parsing. Here “ambiguous” means that, per the words typed by the player, at least two objects have equal likelihood of being the correct match according to the low-level built-in rules of selection. Since the command >POUR specifies no words at all, in the first room the parser looks around and decides that the apple is the highest-scoring qualifying object. In the second room, two objects (cola and banana) both score equally highly, but there are still no player-entered noun words to work with, so it defaults to the “What do you want to…” prompt instead of using DTPM.
Jon Ingold’s Disambiguation Control extension may be of value to you here, as it provides new rulebooks that allow better control over inference.
To expand on what Otis posted, both the use of the “preferably held” token and the DTPM rules only apply to disambiguation. That is they are only consulted if the parser is trying to decide among multiple options. In the first case, there is only one non-scenery thing in the room, the apple, so Inform just picks that, whether it’s being held or not. This is a known and oft-complained-about default behavior and results in weirdeness like the parser attempting to unlock a door with itself.
If you are missing a noun and you haven’t made that acceptable syntax via an “understand” line, Inform will just ask, as you see with “What do you want to pour?” You can get fix by adding this to your posted code (EDIT: this only works as depicted, but won’t work as a general solution. See my post further down.)
Understand "pour" as pouring it into.
Rule for supplying a missing noun while pouring (this is the default noun for pouring is a liquid rule):
if a liquid is in the location:
now the noun is a random liquid in the location.
Also, note that preferably held means just that - preferably. If you want it to be mandatory, that is, if you want an implicit take to be performed, you need to put that restriction in the action definition itself:
pouring it into is an action applying to one carried thing and one thing.
However, since it looks like you’re implementing at least some of your liquids as scenery, you won’t want to do this here.
Sorry, but the code I posted above isn’t really useable. The use of “in” means carried liquids will be ignored, but if we change it to “enclosed by,” backdrops get ignored (for reasons I’m not clear about). This updated rule will choose a missing noun in this order: liquid things enclosed by the player, liquid things enclosed by the room, liquid backdrops in the room.
Rule for supplying a missing noun while pouring (this is the default noun for pouring is a liquid rule):
[say "'enclosed by': [the list of objects enclosed by the location].";]
[say "'in': [the list of objects in the location].";]
if a liquid thing is enclosed by the location:
if a liquid thing is enclosed by the player:
now the noun is a random liquid thing enclosed by the player;
otherwise:
now the noun is a random liquid thing enclosed by the location;
rule succeeds;[stops looking]
otherwise if a liquid thing is in the location:[this will cover backdrops]
now the noun is a random liquid in the location.
@severedhand: Part of the answer may come from the way you’ve defined your DTPM rule. You could (as mentioned by Zed) try:
Does the player mean pouring liquid into:
it is very likely;
By saying into something in your current version, you’re indicating that the second noun should be a thing, but it seems like you want it to be a room.
I hadn’t tested the pour water or pour cases before but this (making a second single-noun action) works in 10.1.
lab is a room.
A thing can be liquid.
The player carries the frozen water.
The player carries the tepid water.
The tepid water is liquid.
The jug is a thing in the lab.
pouring it into is an action applying to two things.
Understand "pour [something preferably held] into/onto/over [something]" as pouring it into.
Understand "pour [something preferably held] in/on to/-- [something]" as pouring it into.
does the player mean pouring a liquid thing into something: it is likely.
location-pouring is an action applying to one thing.
Understand "pour [something preferably held]" as location-pouring.
Before location-pouring: instead try pouring the noun into the location.
does the player mean location-pouring a liquid thing: it is likely.
test me with "pour water into jug / pour water / pour"
In case it’s not clear from what others have said (I, at least, didn’t think it was very clear): the “Did the player mean” rules apply in a case like this:
Lab is a room. Banana shake is in lab. Banana bread is in lab.
A thing can be liquid. A thing is usually not liquid. Banana shake is liquid.
Add all your rules for the pouring action, go to Lab, and type “pour banana”. The “did the player mean” rule should conclude that you want to pour the banana shake, rather than the banana bread.
And this is why I think inference should be removed from the parser and put in the author’s hands! The people typing verbs without nouns are often newer players, and for newer players, the parser picking a random object is generally worse (and looks buggier) compared to just saying “you need to supply a noun”.
Agreed, and for anyone else who feels this way, here’s @otistdog’s deciding whether to infer activity (which Daniel already knows about 'cause they were there, but for everyone else…)
That experiment was pretty much a hack job, unfortunately, since I was just beginning to look at inference. I think I discovered Disambiguation Control shortly after, which does a better job of solving the problem by far.
I think I worked out a better version, too, more stripped down than Disambiguation Control but still potentially useful. I’ll see if I can dig it up.
First, thanks everyone for experimenting and for the observations.
I remember @otistdog helped me with a specific two-noun moment earlier in this game (could now be a year+ ago) and talked about the inference / disambiguation thing there, but it didn’t stick. After today’s case, I think I’ll remember the basic split.
I remember @aschultz made me aware of that in the earliest days of this project, but my recollection is it wouldn’t compile with Unified Glulx Input present, and the latter’s fundamental to this game.
Demonstrating the agonising sensitivity of the wording of this phrase, which was sort of the original interest point of this topic, and which I may have repeatedly typed incorrectly, thinking ‘Yeah, that’s what it said’… by changing it to exactly what you wrote here, that alone creates the desired POUR effect in some locations, which is a considerable advance on nothing.
In other locations, liquids just get beat by other objects that have higher scores in general at that moment.
As @BadParser said, his ‘supplying a missing noun’ didn’t work as a general solution, at least with my grammar as is. It was unable to get better than the now-correctly-worded liquid-favouring rule.
I have or am definitely considering this. But I am increasingly reticent this far into the project to add new actions which are really two actions. It was okay back in the beginning for prominent actions I’d be working on all the time. For instance I have TALK TO (NOUN), which is Talking, and TALK on its own, which is Talking Generally.
When I add a new double action, I then either have to police both in future, or subgroup them (e.g. BEING TALKY) and remember the variations. And I have to retcon this to 11 chapters worth of game, too. Also, there are a lot of sensitive turns in this game which check for almost every action going, separately.
@Draconis did point out I can protect against such moments by redirecting from the variant to a policed-for action with a Before rule redirect, but this still takes working out.
I mean if we step back, I really don’t even like adding any genuinely new actions to the game at this point It is an 11-chapter retcon each time. That will only get worse. However, in testing, POUR just looked too significant. There’s water all through this game. And I already had a (in retrospect) silly-small SPLASH action. So I’m half piggy-backing off SPLASH to add POUR.