[announce] beta: Disambiguation Control (I7 extension)
jon.i...@gmail.com
---
>TAKE TREE
Which tree do you mean, the tree or the tree house?
>TREE
Which tree do you mean, the tree or the tree house?
>OAK
You can't take an oak!
---
>TAKE
(the oak)
You can't take the oak tree!
>GET OUT
(of the car)
You're not in the car!
>CLOSE
(the oak)
You can't close that.
---
>SIT ON CHAIR
Which chair do you mean, the wicker chair or the leather chair?
>LEATHER
But Mike is sitting there!
>SIT ON OTHER CHAIR
Which chair do you mean, the wicker chair or the leather chair?
---
>EXAMINE LEAVES
The pile of leaves is big enough to hide in!
>EXAMINE COINS
You can't use multiple objects with that verb.
>EXAMINE STATUES
You can't use multiple objects with that verb.
---
Announcing a new I7 extension that tackles disambiguation problems and
finally gives you control. The philosophy is "less guesses, more
questions". This extensions allows you to:
* resolve all and any namespace clashes ("tree" and "tree house",
"orange" and "orange jumper") simply and easily
* prevent the parser making guesses unless you want it to, or there's
only one sensible choice the player could possibly want
* provide smooth defaults for when an ambiguous output should be
diverted to one specific object without bothering the player with it
(but without causing those "guessing" errors, where the parser will
divert *everything* to that specific object)
* prevent the "multiple objects" error, replacing it with a "which
thing do you want specifically?" option asking for more input
This is in beta - it's rules need naming, and it needs a few more
rules about what to expect in the model world. But it should be fully
functional. Please give it a try, let me know if you have problems.
Eventually it will move to the Extensions site.
http://www.archimedes.plus.com/Disambiguation%20Control.i7x
Cheers
jon
David Kendal
So, what difference would installing this extension make?
Could we, please, have some examples of what might be produced when this
extension is actually in use?
-- David.
Ron Newcomb
> http://www.archimedes.plus.com/Disambiguation%20Control.i7x
I get a 404: Not Found. Did you take it back down?
-R
jon.i...@gmail.com
After a very horrible afternoon thinking through some very tangled
issues, Disambiguation Control has been raised to version 2. Thanks to
Eric Eve for his help! It's back up at:
http://www.archimedes.plus.com/Disambiguation%20Control.i7x
This version should be more reliable and produce less debugging
messages too! It should also remove entirely the difference between
"does the player mean inserting into something" and "does the player
mean inserting something into something..." as discussed in the thread
about left and right shoes.
I'll post some examples of what the extension does some-other-day-not-
today: however, the extension has got quite long documentation which
hopefully explains things more clearly.
cheers
jon
Ron Newcomb
I'm too lazy to talk pretty (beyond a "Inform really needs this so
thank you muchly!"), so here's a bare bullet-pointed list. The easy
stuff is first.
* "always impossible" should be renamed something like "unmentionably
impossible", since the difference is that such items are never
mentioned in disambiguation lists.
* "only also considering" or "also only considering"? You've got it
both ways in the docs, and no matter which way you choose, some of us
will guess wrong. I might suggest "also considering just", but you
might also consider (pun intended) supporting multiple syntaxes.
* The "when comparing" phrases: please expand the conjunctions to and/
or/vs/versus. (I doubt if vs. -- with the period -- would be allowed,
but if so, that too.)
* I can't see the difference between TAKE and TAKE RED and TAKE ALL:
all of them specify too many objects. I'm unclear on the reason for
the distinction. (As in, I'm unclear why the distinction must be kept
distinct at the author's level, rather than being swept under the rug
as an implementation detail.)
* The various rulebooks' names are a little too general; it's hard to
keep straight what does what! So...
* * Since one rulebook uses the "rate" phrase in lieu of outcomes, its
rulebook name needs to mention or imply that somehow, for our memories
are slippery and vague. For instance, instead of
Disambiguate when comparing...
Try:
Rate when comparing....
(I would have preferred something like "Rate between" or "Deciding
between", but the rule doesn't read well.) I'm pretty sure it's OK
to have the beginning of a To phrase look like a rulebook name.
(Also, instead of "rate" being used in both places, maybe some other
verb that is more specific to the situation of a parser weighing
common sense stuff. I don't know a good word for it off the top of my
head, but I bet it's not an everyday word, and that's a good thing, as
an author would be more likely to try to use the simpler words like
"rate" or "weigh" himself.)
* * The other two, "does the game prefer" & "does the game expect":
after reading and re-reading, are they necessary to keep separate? Is
it just a speed efficiency issue?
Presuming there are technical reasons that these must be kept
separate, perhaps we need to *name* the situations / phases of the
parsing pipeline, and tie the rulebook names to those phases. In
doing so, the documentation would be more understandable, because it
could "walk down the pipeline/timeline" of a parse.
* The various kinds of outcomes also are hard to keep track of what
set matches up with what rulebook. I would highly suggest the
rulebooks that use the "it is likely" type of outcomes all match up
with one another perfectly. Else we'll be ever trying to use
"extremely likely" in places it doesn't work. (I don't care what they
actually are, I just ask for consistency.)
* Please redo the ParserMessage() thing; Jeff Nyman says many of his
students' primary complaint of I7 vs. TADS is replacing default
messages is easier in TADS. So...
Make an I7 table, with the first column a "message ID" (the number
you're using anyway) and the second the "message text".
Make "the disambiguation message printing rule" to say the message
text corresponding to a message ID of <global variable>
The I6 function ParserMessage should:
1) stick n into a global variable for the purpose
2) call an I7 rule directly via syntax: (+ the disambiguation
message printing rule +)();
An I7 number variable can "translate into" that global variable so the
rule can use it.
Add Say phrases to directly invoke the I6 functions ActorOrPlayer()
and PrintOrConstruct() via the (- -) construct. (If those
functions aren't called from I6 code at all, then the Say phrase can
just implement them right there -- no need to make them a standalone
function.)
If that confused you, say so and I think I can write it.
* Finally, how about an "example" that, when included in a pre-
existing work, looks for those "straight namespace clashes", and
prints resulting runtime errors when play begins, much like Emily's
"Property Checking" extension does for any descriptions that are still
blank? I don't know if that's feasible, but it would be darn handy if
I could click the copy-paste icon to insert a paragraph of code to
auto-check for this.
I didn't look any farther into the extension than this because... I
was afraid. Very afraid. :) But I -would- like to know why TAKE,
TAKE RED, and TAKE ALL are treated so independently of one another.
Fascinating extension, BTW.
-Ron
PS most of this is quick n dirty surface issues stuff; i haven't
actually tried to compile much with it.
jon.i...@gmail.com
Thanks for taking a look. Rulebook names are sort-of influx while I
work out what they really mean! so thanks for your suggestions.
> * I can't see the difference between TAKE and TAKE RED and TAKE ALL:
> all of them specify too many objects.
Consider the following:
You are carrying your shoes and a straw hat. Lucy is here.
>WEAR SHOES
(your shoes)
You put on your shoes (and not Lucy's).
>WEAR
What do you want to wear: your shoes or your hat?
If we don't distinguish cases, then in both of these circumstances the
parser will default to "your shoes". Which is okay, but having the
parser offer options is (in my opinion) more helpful behaviour on its
part! (A lot of this comes from watching new players, who are
naturally unfamiliar with the commands, and also lazy. So they type
"wear" to see if the game understands the command.)
So the idea of separating the two is to allow for slick smooth default
(obviously your shoes, not Lucy's!) but without preventing more open-
ended suggestions for those players who aren't yet committed to shoes.
TAKE ALL - or rather, EXAMINE ALL, as TAKE ALL is unaffected by this
extension - is the same as "EXAMINE" in terms of what it produces, and
indeed, should produce the same output. However, from inside the
parser it's really quite different. So the change to multiple object
behaviour is more "this is what the game will now do" than "this is
what you the author need to do".
The rule of thumb is: general rules describe what the game "expects".
preference rules describe ways to prod the player in the direction you
expect he meant ... bearing in mind that all these rules only fire
when the player was being ambiguous in the first place, so we're not
taking anything away! And disambiguate rules are for when one object
shares a subset of another's name and nothing else (so there shouldn't
be too many of these.)
> Outcomes... else we'll be ever trying to use "extremely likely" in places it doesn't work.
The summary of the rulebooks at the end of the documentation lists all
the outcomes allowed - actually, all the rulebooks have (almost) all
the outcomes, they're just not documented. But I feel like I'd
probably rather make them specific so if the author gets it wrong he
gets told, rather than it compiles and then mysteriously rates one
thing fractionally above another.
> * Please redo the ParserMessage() thing;
<snip code>
Thanks, I'll put this in.
> * Finally, how about an "example" that, when included in a pre-
> existing work, looks for those "straight namespace clashes", and
> prints resulting runtime errors when play begins, much like Emily's
> "Property Checking" extension does for any descriptions that are still
> blank?
Aw, heck, that's a great idea but if I could do that I probably
wouldn't need the disambiguate rulebook - i could just check to see
which name was a subset of which and pick that one, like I7 does with
rule conditions. I'll think about it, but I suspect it's one of those
things you just have to playtest to find. One of my motivations here
was just that I find them myself and need a way of peeling them apart
that doesn't have the knock-on effects that a "does the player mean"
rule has.
I've got a couple more unlikely bugs to iron out; hopefully a version
3 will go up tonight sometime. Then I might submit it to the main
site.
cheers
jon
jon.i...@gmail.com
I've updated this: a substantial rewrite of some parts, other parts
simplified. Thanks for Ron and Eric for their helpful suggestions.
http://www.archimedes.plus.com/Disambiguation%20Control.i7x
Rather than spam the newsgroup with long (and quite boring-looking
output), I've also put up a short text-file showing a source code for
an example game + a transcript run with, and without, the extension
in play. You can read it here:
http://www.archimedes.plus.com/Disambig.txt
cheers
jon
Ron Newcomb
much better. Not sure how simply using "should" did that, but it just
makes more sense now.
Congrats on this extension -- it's a monster!
-R