intfiction.org

The Interactive Fiction Community Forum
It is currently Wed Oct 17, 2018 2:45 pm

All times are UTC - 6 hours [ DST ]




Post new topic Reply to topic  [ 20 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Fri May 25, 2018 6:43 pm 
Offline
User avatar

Joined: Sat Jun 25, 2016 12:13 pm
Posts: 245
That's really neat!

Presumably you can't ask about something you haven't seen even if you fully specify it, eg "ask marvin about the gold coin" before seeing it.

Sometimes you might want the latter to work (eg for replays), but if it doesn't do that, that's also fair enough.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Fri May 25, 2018 7:44 pm 
Offline

Joined: Tue Mar 09, 2010 2:34 pm
Posts: 5384
Location: Burlington, VT
Yep, this applies even to fully specified nouns.

To be clear there isn't anything special about something's having been seen here; the extension just sets the "known" property when you see something (I think it gets set the first time the name is printed, and then the "[any known thing]" token means that only things with the "known" property can be understood in that spot. ("Any" means that it totally ignores scope, so the things don't have to be currently visible.) I think what the parser does is loop over possible matches--so the known things--and check word by by word whether the words used do match those things.

Getting something where disambiguation only listed known things but you could fully specify an unknown thing seems like it'd be pretty challenging in Inform.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Tue Jun 19, 2018 1:52 pm 
Offline

Joined: Fri Oct 18, 2013 10:13 am
Posts: 2659
Location: The Midwest
jkj yuio wrote:
What kind of contextual clause resolution does I6/7 have out of the box. For example, if i say;

Code:
> put key in bag on table


Does it correctly resolve,

1 put (key in bag) on table
2 put key in (bag on table)

Where in (1) the key is in the bag and (2) where the bag is on the table. The hit man with stone is similar to this.


None at all, out of the box. It doesn't understand modifiers to nouns like that at all. You can add them, but it's not particularly smart about them.

I was curious, so I added parsing of "on [supporter]" and "in [container]" and tried this out, with a box on the table and a key in the box.

Quote:
>put key in box on table
(in the table)
(first taking the key)
That can't contain things.

>put key on table
You put the key on the table.

>get key
Taken.

>put key in box on table
You put the key into the box.

>get key in box
Taken.


So it didn't get the ambiguity right. It considered only the cases "put (key) in (box on table)" and "put (key in (box on table))", decided the first was unlikely because the key was already in the box, chose the second, realized it didn't have a second noun specified, and grabbed one effectively at random.

I'm not sure why it didn't consider "put (key in box) on table", which would have been the best option. But I assume it has to do with the internal workings of the parser.

It shouldn't, in theory, be too difficult to replace the Glulx parser in toto and build a new one from the ground up (using Earley, for instance). In practice, all sorts of things might break, and I'm not comfortable enough with the internals of the library to try this.

_________________
Daniel Stelzer


Top
 Profile Send private message  
Reply with quote  
PostPosted: Tue Jun 19, 2018 3:16 pm 
Offline
User avatar

Joined: Fri Jul 11, 2014 12:50 pm
Posts: 109
Draconis wrote:
I was curious, so I added parsing of "on [supporter]" and "in [container]" and tried this out, with a box on the table and a key in the box.

What "understand" lines did you write exactly? Shouldn't relations be used instead?
Code:
Understand "in [something related by reversed containment]" as a thing.
Understand "on [something related by reversed support]" as a thing.

Maybe Inform would parse better like that (especially if there are multiple identical things, not all inside a container), but I haven't tested.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Tue Jun 19, 2018 3:56 pm 
Offline

Joined: Fri Oct 18, 2013 10:13 am
Posts: 2659
Location: The Midwest
Ah, yep, that's basically what I did (though I used "containment" rather than "support" for "on", since they're the same under the hood).

Code:
The Lab is a room. There is a table in the Lab. There is a rock on the table. There is a box on the table. There is a key in the box. There is a bag on the table. The bag is a container.

Understand "on [something related by reversed containment]" as a thing. Understand "in [something related by reversed containment]" as a thing.

_________________
Daniel Stelzer


Top
 Profile Send private message  
Reply with quote  
PostPosted: Tue Jun 19, 2018 6:35 pm 
Offline

Joined: Tue Mar 09, 2010 2:34 pm
Posts: 5384
Location: Burlington, VT
It looks to me as though this fails even on a less complicated construction:

Quote:
Lab
You can see a table (on which are a rock, a box (in which is a key) and a bag (empty)) here.

>put key in box
(in the table)
(first taking the key)
That can't contain things.

>


I'd guess that when the parser is trying to parse "key" as a noun, it focuses exclusively on the noun place and does it greedily. That is, when it's trying to match "key" to the [something] spot in the grammar line, it processes every word that could possibly match the key without considering that it ought to be saving "in" to match the preposition in the grammar line, if possible. Then it's matched the key and used all the words, and it acts as though the command was "put key," and then goes and auto-chooses an object to put the key in, preferring the only thing that's directly in the room.

By the way, if you put another thing at the same level, you get a disambiguation loop. The parser asks "What do you want to put the key in," and if you answer "box," it decides that the new command is "put key in box in box," which is just three ways of referring to the key ("key," "in box," "in box" again), so it asks again, and the new answer tacks on another "in box," ad infinitum.

...so, minimal test case:

Code:
The Lab is a room. There is a box in the Lab. There is a key in the box. There is a rock in the Lab.

Understand "in [something related by reversed containment]" as a thing.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Tue Jun 19, 2018 11:40 pm 
Offline
User avatar

Joined: Tue Nov 08, 2011 8:11 am
Posts: 2639
Location: US - Central
With stuff like PUT KEY IN BAG ON TABLE that's tricky for the parser, but that's tricky for the brain to parse as well. It's an "eats shoots and leaves" type strange-loop meta phrasing.

One helpful thing is to ensure every specific thing has a unique adjective. I know that sounds pedantic but what I'm suggesting is an author can teach the player they don't need to come up with input that requires a descriptive infinitive such as "on the table". It's PUT KEY IN BLUE CLOTH BAG. [the bag which happens to be supported by the table but it doesn't matter]. If there are several bags and several supporters they could be resting on, you'd only run into problems if you're making lots of automatic kinds-of-kinds that don't get hand-named uniquely. I struggled with similar disambiguation extensively implementing kinds of working light switches in Transparent

_________________
http://hanonondricek.wixsite.com/pyramidif
https://pyramidif.itch.io/


Top
 Profile Send private message  
Reply with quote  
PostPosted: Wed Jun 20, 2018 6:55 am 
Offline

Joined: Tue Mar 09, 2010 2:34 pm
Posts: 5384
Location: Burlington, VT
Yeah, in natural language you'd say "put the key that's in the bag on the table" or "put the key in the bag that's on the table."

This reminds me of the old chestnut "The horse raced past the barn fell"; it's supposed to be a grammatical sentence that's impossible to parse, meaning "the horse that was raced past the barn fell," but I don't think it's grammatical; you can't use "the horse raced past the barn" as a noun phrase in other contexts either. For instance, you can't say "I'm going to ride the horse raced past the barn." (Other similar phrases can be used that way--you can say "Follow the man dressed in black!" but you can also say "The man dressed in black fell" and be understood more easily.) OK that's a pet peeve of mine that is not really related to IF.

You could solve the original issue by changing the understand statement to "that's in..." or "that is in...", but then you'd have to communicate that to the player.

Also I think most of this discussion is pretty theoretical--I can't think of too many cases where it's really important to let the player distinguish the key in the box from the key on the table, as such. But it's of interest to parser nerds!


Top
 Profile Send private message  
Reply with quote  
PostPosted: Wed Jun 20, 2018 10:20 am 
Offline

Joined: Fri Oct 18, 2013 10:13 am
Posts: 2659
Location: The Midwest
The case that led me to implement "in [container]" and "on [supporter]" in Scroll Thief was actually originally intended for rooms! When the player can see multiple rooms at once, players would try to disambiguate with "examine the door in the living room" or "examine the door in the kitchen". Unfortunately, this turns out to be a fundamental limitation of Inform 7: you can never understand a thing by the room it's currently in.

_________________
Daniel Stelzer


Top
 Profile Send private message  
Reply with quote  
PostPosted: Wed Jun 20, 2018 10:49 am 
Offline

Joined: Tue Mar 09, 2010 2:34 pm
Posts: 5384
Location: Burlington, VT
Yeah, I encountered that when I was trying to do something for the poster with the striped cat--turned out that you can't understand by relations that aren't related to things.

I guess in this case you could make dummy things offstage with the same name as the room, define a relation that relates a thing to the associated dummy thing of its room, and understand by that. Overly elaborate though.


Top
 Profile Send private message  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 20 posts ]  Go to page Previous  1, 2

All times are UTC - 6 hours [ DST ]


Who is online

Users browsing this forum: Google Feedfetcher and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group