I7 "Intelligent Hinting" extension -- open beta
Aaron A. Reed
"suggest" command which will recommend the next move to take, like
many popular chess programs.
Authors encode information about puzzles into their games, and
Intelligent Hinting is able to determine what the best next move is
from any prompt. In a sense, it's like the Reactive Agent Planner, but
for the player rather than NPCs.
The main goal of this extension is to help players who are unsure what
to do next or are stuck on a puzzle (or guess-the-verb trap), but it
also provides a number of benefits for authors as well, including a
self-updating walkthrough and an easy way to ensure a WIP is still
winnable.
Since this is a pretty complex piece of code (for me, at least) I
thought I would throw it out and let people start playing with it
before I officially submit a first version. To facilitate this, I have
created a version of the 350-point "Adventure" that makes use of this
extension. Try playing with it and, when you want a hint, type
"suggest". (The reason a particular move is made is not always
necessarily clear in isolation; you might want to repeat the command a
few times to see what it's up to.) Intelligent Hinting is able to
solve Adventure from start to finish in about 350-400 moves, depending
on random events, and should also be able to recover from nearly any
state you get it into that doesn't render the game unwinnable. Source
code and playable Glulx file are at:
http://www.aaronareed.net/if/advent-hint.txt
http://www.aaronareed.net/if/advent-hint.ulx
For I7 authors, the extension itself can be previewed at:
http://www.aaronareed.net/if/Intelligent Hinting
I welcome any bug reports or suggestions.
--Aaron
(P.S. The extension shows several odd issues when displayed in the Mac
Inform application: documentation changes color for no apparent reason
between black and red, the "paste" buttons don't work in the examples,
and the sections are numbered wrong. Not sure if these are bugs or if
something's wrong in the formatting; anyone know?)
Eric Eve
news:6a64a350-96df-44ba...@c19g2000prf.googlegroups.com...
> (P.S. The extension shows several odd issues when displayed in the
> Mac
> Inform application: documentation changes color for no apparent
> reason
> between black and red, the "paste" buttons don't work in the
> examples,
> and the sections are numbered wrong. Not sure if these are bugs or
> if
> something's wrong in the formatting; anyone know?)
I've seen similar problems with some of my I7 extension
documentation in the Windows IDE (for 5T18). In particular text
appears red after a chapter heading if there's no intervening
section heading, and sometimes chapter heading or example heading
isn't recognized. I reported all this to David Kinder who's passed
on a bug report to Graham Nelson, since apparently the formatting of
the documentation is done by the I7 compiler, not the IDE. But it
certainly looks like a bug to me.
-- Eric
Ron Newcomb
:: Spock eyebrow :: "Fascinating."
I poked around with it and this what struck me at first:
--------
The documentation says "you / your" instead of "we / our".
Typo: I think you meant "tchotchke". Lovely word choice, though!
----
So, when puzzles require other puzzles to be solved, I enter:
X requires Y, Z.
But when a puzzle requires the actual steps to be taken, I enter:
write A to X; write B to X;
Is that right? It is possible in Inform to put stored actions in a
table, so why aren't we doing it that way?
Table of Stuff
step puzzle
a stored action a thing
dropping the cloak Hanging-The-Cloak
Either way, if you -must- use a To phrase, I'm pretty you can still
use "requires" instead of "write". Inform will know the difference
between the To phrase and the Relation because the To phrase appears
in imperative code only, where the Relation would have a "now/change"
in front of it.
But seriously, use the table if at all possible. All the verbiage is
scary.
(SNAFU: In the above example, I think that "cloak" needs to be defined
as an object -before- its line in the table appears, so if you were
having problems with compiler errors, that may be because the Table
wasn't at the end of the source.)
----------------
So SUGGEST actually -does- the suggestion instead of just printing
it? This seems wrong, unless you call the command SOLVE. Especially
since it prevents SUGGEST from being out-of-world. I recommend
keeping SUGGEST out of world, but go ahead and let it fill-in a stored-
action variable for what it would have done. Then the author can
print it prettily in dialogue or execute it as she sees fit. I don't
even think this extension should by default print the action at all;
let the author do that in a After/Report Suggesting rule.
(I think you can make a Last Report Suggesting rule, but perhaps say:
The Report Suggesting rules have default success.
So if the author makes her own, your default one will silence itself
automatically. I think.)
----
Should fake-action really have an Understand clause? Why would any
player need to type it?
----
I don't suppose Eric Eve's Implicit Actions extension would be of any
help here? Especially since you can now replace Sections of it with
Inform's new ability.
-----
This example seems silly:
A task processing rule: if The Bar is visited, now Noticing-Dark-Room
is complete.
I say that because how is it possible for a task or puzzle to have a
stated venue that also -must- be -un-visited? If the venue isn't
important so that the task or puzzle can be completed while the venue
is still unvisited, then why are we stating a venue at all?
-------
Also, things of this nature:
A task processing rule: if cloak is hung, now Hanging-The-Cloak is
complete; otherwise now Hanging-The-Cloak is incomplete.
A lot of these task processing rules seem to cry out to be a
Definition rule instead:
Definition: Hanging-The-Cloak is complete: decide on whether or not
the cloak is hung.
And the extension can define "incomplete" for all puzzles so the
author never need to:
Definition: a puzzle is incomplete: if it is complete, decide no; else
decide yes.
This route seems easier and much less verbose for the author, and
saves runtime speed as well.
-------------
Re: the command sequence:
What use is "TAKE ALL" or "TAKE ALL BUT" or such commands in a puzzle
solution, since they are merely abbreviated forms of other commands?
I know of no solution that would require TAKE ALL but not accept the
individual TAKE commands. Am I missing a case here?
-------
I have issue with the concept of keying the extension on a list of
Actions that must be done instead of conditions that must become
true. For example, Attacking the Medusa shouldn't be there; "the
Medusa is dead" should be. The difference is because there may
(should) be other ways of killing the Medusa than by Attacking. In
this particular case SHOW MIRROR TO would get the job done.
The only reason I see this extension requiring actual Actions to be
named is so it has something concrete to suggest to the player. But I
don't like that it *requires* that particular action in order to
checkmark the Task "Done".
Am I missing some technicality here?
-----
I'm gonna stop here until I learn more.
-Ron
JDC
> I welcome any bug reports or suggestions.
Very cool.
You might be able to clean up the syntax for required actions a bit by
using a rulebook (a list would of course be better, but that doesn't
seem to work as you noted elsewhere). So, something like the following
for the Cloak of Darkness example:
<code>
[This code would be in the extension]
Requirement rules is an object-based rulebook.
Temp is a thing variable.
To specify (s - stored action): write s to temp.
When play begins:
repeat with item running through tasks begin;
change temp to item;
follow the requirement rules for temp;
end repeat.
[This part replaces the "write (action)" stuff in the game itself]]
Requirement for Hanging-The-Cloak: specify the action of putting the
cloak on the hook.
Requirement for Reading-The-Message: specify the action of examining
the scrawled message.
</code>
(You probably want better names for these things.)
By the way, you mentioned elsewhere that a drama Manager will be part
of the final version of Blue Lacuna; is this built on the stuff from
this extension (namely the part that tries to figure out what puzzle
the player is working on in order to offer a suggestion)?
-JDC
Aaron A. Reed
> So, when puzzles require other puzzles to be solved, I enter:
> X requires Y, Z.
> But when a puzzle requires the actual steps to be taken, I enter:
> write A to X; write B to X;
Right. It seemed like it was important to create a distinction between
"puzzles" and "tasks," as they really are different things; I thought
saying "require" in both situations might make it more difficult to
remember the difference for authors. "Write to" is perhaps not the
best syntax, though.
> Is that right? It is possible in Inform to put stored actions in a
> table, so why aren't we doing it that way?
>
> Table of Stuff
> step puzzle
> a stored action a thing
> dropping the cloak Hanging-The-Cloak
The main thing I dislike about this is that it puts the logic for a
single puzzle in different places in the code. You'd have to be
defining your task's rules, at the very least, somewhere else. Also,
looking at the table there'd be no way to see the hierarchy of which
puzzles are parents of which other puzzles-- I think the natural
language format makes this easier to grok.
If you mean defining a separate table for each individual task, it
seems like that would take up a lot more vertical space.
> So SUGGEST actually -does- the suggestion instead of just printing
> it? This seems wrong, unless you call the command SOLVE. Especially
> since it prevents SUGGEST from being out-of-world. I recommend
> keeping SUGGEST out of world, but go ahead and let it fill-in a stored-
> action variable for what it would have done. Then the author can
> print it prettily in dialogue or execute it as she sees fit. I don't
> even think this extension should by default print the action at all;
> let the author do that in a After/Report Suggesting rule.
Well, you can make it just print the suggestion and not act on it with
"Use passive suggestion." I could really go either way on which mode
is the default.
I can't remember at the moment what the other advantages of out-of-
world-ness would be.
Moving the printing stuff into a report suggesting rule is definitely
good.
One advantage of the auto-suggest version is that it's easy to write a
script that can play through the whole game and test it, so I do want
to keep that an option. (It also makes it very easy to quickly move
forward through a whole puzzle).
> Should fake-action really have an Understand clause? Why would any
> player need to type it?
I think that's an accidental remnant of a testing command; I'll remove
it.
> I don't suppose Eric Eve's Implicit Actions extension would be of any
> help here? Especially since you can now replace Sections of it with
> Inform's new ability.
I will look into it. Originally I'd planned on delegating the
unlocking/door opening stuff to Emily Short's Locksmith and requiring
that, but the logic of when to do what in what order became too
complex.
> This example seems silly:
>
> A task processing rule: if The Bar is visited, now Noticing-Dark-Room
> is complete.
>
> I say that because how is it possible for a task or puzzle to have a
> stated venue that also -must- be -un-visited? If the venue isn't
> important so that the task or puzzle can be completed while the venue
> is still unvisited, then why are we stating a venue at all?
I guess I'm confused by your question. Tasks are never marked as
complete automatically, so you have to specify that the completion
condition is when the Bar is visited. I suppose you could code
something that would automatically mark a task complete if all it
requires was a venue that's visited, but then the consistency of "you
must define completion conditions for all your tasks" would be broken.
Something I did a few times in "Adventure" was to define kinds for
similar tasks. In a game with lots of "visiting a location only"
tasks, it would be pretty easy for an author to define a kind that
marked them completed automatically when its location was visited.
> Also, things of this nature:
>
> A task processing rule: if cloak is hung, now Hanging-The-Cloak is
> complete; otherwise now Hanging-The-Cloak is incomplete.
>
> A lot of these task processing rules seem to cry out to be a
> Definition rule instead:
>
> Definition: Hanging-The-Cloak is complete: decide on whether or not
> the cloak is hung.
>
> And the extension can define "incomplete" for all puzzles so the
> author never need to:
>
> Definition: a puzzle is incomplete: if it is complete, decide no; else
> decide yes.
>
> This route seems easier and much less verbose for the author, and
> saves runtime speed as well.
This is intriguing. Rules and rulebooks have always been a weak spot
for me: I have a hard time wrapping my head around when they should be
used versus other methods and what their strengths and weaknesses are.
I'm all about making declarations easier for authors, so I'll
definitely look into this.
> Re: the command sequence:
>
> What use is "TAKE ALL" or "TAKE ALL BUT" or such commands in a puzzle
> solution, since they are merely abbreviated forms of other commands?
> I know of no solution that would require TAKE ALL but not accept the
> individual TAKE commands. Am I missing a case here?
Specifically, it came up for the Plover Room puzzle in Adventure,
where the player might be carrying any random group of items, so
there's no way to specify the specific ones to drop. Also, Blue Lacuna
(and other games, I think) has times where you need to type a word
that isn't a parsed command (in BL, you set a password at one point.)
There may be other situations I haven't thought of where this could be
useful (nonstandard conversation systems, maybe).
> I have issue with the concept of keying the extension on a list of
> Actions that must be done instead of conditions that must become
> true. For example, Attacking the Medusa shouldn't be there; "the
> Medusa is dead" should be. The difference is because there may
> (should) be other ways of killing the Medusa than by Attacking. In
> this particular case SHOW MIRROR TO would get the job done.
>
> The only reason I see this extension requiring actual Actions to be
> named is so it has something concrete to suggest to the player. But I
> don't like that it *requires* that particular action in order to
> checkmark the Task "Done".
I think you're misinterpreting it just a bit: a task is, in fact,
defined as complete or not based on the results (the task processing
rules). When a certain condition is met (in this case, Medusa being
dead) the task is marked as completed. The action-sequence just
specifies one possible way of making that condition true, so that, as
you say, it knows what to suggest to the player.
Teaching a game how to come up with its own actions to suggest, it
seems, would be vastly more difficult. Essentially, every "Instead"
rule would have to be supplanted by a library extension encoding that
knowledge. Meaning: rather than saying "Instead of attacking Medusa,"
you would have to define the action of attacking to be one that makes
certain characters dead, in certain circumstances, with certain
weapons, etcetera... it seems like tons more work for little gain.
Also, you could encode multiple puzzle solutions already if you wanted
to-- you'd just want to make sure your task processing rules made all
the solutions complete whenever one of them succeeded.
Thank you for the comments-- some very useful stuff in there.
--Aaron
Aaron A. Reed
> Requirement for Hanging-The-Cloak: specify the action of putting the
> cloak on the hook.
It doesn't seem like this would save all that much typing, unless I'm
missing something:
Requirement for Hanging-The-Cloak: specify the action of putting the
cloak on the hook.
versus:
When play begins: write the action of putting the cloak on the hook to
Hanging-The-Cloak.
...and considerably more for a task with multiple actions:
Requirement for Recharging-Lantern: specify the action of inserting
coins into vending machine. Requirement for Recharging-Lantern:
specify the action of taking fresh batteries. Requirement for
Recharging-Lantern: specify the action of inserting fresh batteries
into lantern.
versus:
When play begins: write the action of inserting coins into vending
machine and the action of taking fresh batteries and the action of
inserting fresh batteries into lantern to Recharging-Lantern.
Or am I missing something?
> By the way, you mentioned elsewhere that a drama Manager will be part
> of the final version of Blue Lacuna; is this built on the stuff from
> this extension (namely the part that tries to figure out what puzzle
> the player is working on in order to offer a suggestion)?
They're related, yes. Some of what I'm trying to do is rip out a bunch
of systems that had grown incestuously together over the course of the
project, and get them working properly in isolation, to make the
debugging process less headache-inducing.
--Aaron
JDC
>
> ...and considerably more for a task with multiple actions:
>
> Requirement for Recharging-Lantern: specify the action of inserting
> coins into vending machine. Requirement for Recharging-Lantern:
> specify the action of taking fresh batteries. Requirement for
> Recharging-Lantern: specify the action of inserting fresh batteries
> into lantern.
>
> versus:
>
> When play begins: write the action of inserting coins into vending
> machine and the action of taking fresh batteries and the action of
> inserting fresh batteries into lantern to Recharging-Lantern.
>
> Or am I missing something?
For multiple actions, the rulebook form could be shortened to:
Requirement for Recharging-Lantern:
specify the action of inserting coins into vending machine;
specify the action of taking fresh batteries;
specify the action of inserting fresh batteries into
lantern.
That is, multiple actions can be included in one rule (I really wish
I'd picked a different word than "specify"; also, maybe "Requirements"
would be better than "Requirement"). I think it's largely a matter of
personal preference (I'm quite fond of rulebooks, myself).
One possible advantage of a rulebook approach is when you have
multiple similar tasks with similar preambles. You could then do
something like the following (this is off the top of my head, so
probably not the best example):
An eating task is a kind of task. Eating-The-Pizza, Eating-The-Steak,
and Eating-The-Elephant are eating tasks.
First Requirement for an eating task:
specify the action of taking the knife;
specify the action of taking the fork.
Requirement for Eating-The-Pizza: specify the action of eating the
pizza. [etc.]
(I grew up in the Chicago area, where real pizza with is eaten with a
knife and fork...)
-JDC
Ron Newcomb
> On May 11, 1:38 pm, Ron Newcomb <psc...@yahoo.com> wrote:
> Right. It seemed like it was important to create a distinction between
> "puzzles" and "tasks," as they really are different things; I thought
> saying "require" in both situations might make it more difficult to
> remember the difference for authors.
I see.
> "Write to" is perhaps not the best syntax, though.
I was happy with "specify" as well. Or "solves". Or whatever.
> The main thing I dislike about [tables] is that it puts the logic for a
> single puzzle in different places in the code. You'd have to be
> defining your task's rules, at the very least, somewhere else. Also,
> looking at the table there'd be no way to see the hierarchy of which
> puzzles are parents of which other puzzles-- I think the natural
> language format makes this easier to grok.
Well as long as it was a deliberate choice. As a bone to throw for
some of us, can we use the Defining Objects With Tables in order to do
it the table-based way? (I.e., like the jockey jerseys in Inform's
documentation.)
> If you mean defining a separate table for each individual task
Ick, no.
> I can't remember at the moment what the other advantages of out-of-
> world-ness would be.
They don't mess with the author's timed events.
How about two verbs, SUGGEST and SOLVE? Suggest is out of world.
(Well, call it HINT or even HELP.) SOLVE does the auto-play thing and
so is in-world. No need to make the author choose a method for the
whole game as the use-option does.
> I guess I'm confused by your question. Tasks are never marked as
> complete automatically,
Nevermind; I think this question was moot anyway, if tasks are
considered Complete by a Definition phrase.
> Something I did a few times in "Adventure" was to define kinds for
> similar tasks.
Neat. Is this in one of the worked examples? (I couldn't run Kill Dr.
Lucky cause the documentation screws up the tabs (you used Python
style instead of begin/end). The Copy-Paste icon doesn't work at all
because you intersperse comments throughout the code.)
> > What use is "TAKE ALL" or "TAKE ALL BUT" or such commands in a puzzle
> Specifically, it came up for the Plover Room puzzle in Adventure,
I'm not familiar with that.
> where the player might be carrying any random group of items, so
> there's no way to specify the specific ones to drop. Also, Blue Lacuna
> (and other games, I think) has times where you need to type a word
> that isn't a parsed command (in BL, you set a password at one point.)
Oh, so, anything involving Topics and the [text] token, then? Hm.
> I think you're misinterpreting it just a bit: a task is, in fact,
> defined as complete or not based on the results (the task processing
> rules). When a certain condition is met (in this case, Medusa being
> dead) the task is marked as completed. The action-sequence just
> specifies one possible way of making that condition true, so that, as
> you say, it knows what to suggest to the player.
Ah, I did misinterpret. My bad. That makes sense.
Definition: Destroying-The-Medusa is complete: decide on whether or
not Medusa is dead.
> Teaching a game how to come up with its own actions to suggest, it
> seems, would be vastly more difficult.
True, I didn't mean to send you down that road; there's a Hydra and
being reflective doesn't impress her. :)
-R
PS: Man, I sure wish I7 could put conditions or lambda functions or
closures in a table.
Table of Solution Checks
puzzle check
Destroying-the-Medusa Medusa is dead
Aaron A. Reed
> > The main thing I dislike about [tables] is that it puts the logic for a
> > single puzzle in different places in the code. You'd have to be
> > defining your task's rules, at the very least, somewhere else. Also,
> > looking at the table there'd be no way to see the hierarchy of which
> > puzzles are parents of which other puzzles-- I think the natural
> > language format makes this easier to grok.
>
> Well as long as it was a deliberate choice. As a bone to throw for
> some of us, can we use the Defining Objects With Tables in order to do
> it the table-based way? (I.e., like the jockey jerseys in Inform's
> documentation.)
AFAIK this is definitely possible. I'll test and maybe throw in a note
in the docs explaining that you can define puzzles this way if you
prefer.
> How about two verbs, SUGGEST and SOLVE? Suggest is out of world.
> (Well, call it HINT or even HELP.) SOLVE does the auto-play thing and
> so is in-world. No need to make the author choose a method for the
> whole game as the use-option does.
I like this approach.
> (I couldn't run Kill Dr.
> Lucky cause the documentation screws up the tabs (you used Python
> style instead of begin/end). The Copy-Paste icon doesn't work at all
> because you intersperse comments throughout the code.)
Ahhh, *that's* why. Strange. Don't the examples in the documentation
use the interspersed comments all the time? They certainly look nicer
than using bracketed comments. I'll investigate.
> > > What use is "TAKE ALL" or "TAKE ALL BUT" or such commands in a puzzle
> > Specifically, it came up for the Plover Room puzzle in Adventure,
>
> I'm not familiar with that.
>
> > where the player might be carrying any random group of items, so
> > there's no way to specify the specific ones to drop. Also, Blue Lacuna
> > (and other games, I think) has times where you need to type a word
> > that isn't a parsed command (in BL, you set a password at one point.)
>
> Oh, so, anything involving Topics and the [text] token, then? Hm.
Actually, I may be wrong, but I believe you could encode something
with topics along the lines of:
write the action of telling landlady about "state housing regulations"
to Preventing-Eviction.
But sometimes you aren't even using topics. I'm thinking of something
like asking the player's name. Admittedly, this is a rare situation
and most people won't need it, but I couldn't think of a way to encode
something like "drop whatever you happen to be holding" without it.
Well, come to think of it, I suppose authors could define a custom
action that did that. Hmm. Maybe the command-sequence concept just
adds needless complexity. I'll think about it.
Thanks for all your comments, Ron (and everyone else). It's good to
have experienced eyes running over this.
--Aaron
Aaron A. Reed
> One possible advantage of a rulebook approach is when you have
> multiple similar tasks with similar preambles. You could then do
> something like the following (this is off the top of my head, so
> probably not the best example):
>
> An eating task is a kind of task. Eating-The-Pizza, Eating-The-Steak,
> and Eating-The-Elephant are eating tasks.
> First Requirement for an eating task:
> specify the action of taking the knife;
> specify the action of taking the fork.
> Requirement for Eating-The-Pizza: specify the action of eating the
> pizza. [etc.]
Okay, that makes more sense. But I still think you could do this
using the existing format:
An eating task is a kind of task. Eating-The-Pizza, Eating-The-Steak,
and Eating-The-Elephant are eating tasks.
First when play begins: repeat with X running through eating tasks
begin; write the action of taking the knife to X; write the action of
taking the fork to X; end repeat.
Hmm. Actually, your method would be a little cleaner, and easier to
adjust if the author wanted to dynamically alter rules during play.
I'll look into this.
Thanks!
--Aaron
Aaron A. Reed
> > (I couldn't run Kill Dr.
> > Lucky cause the documentation screws up the tabs (you used Python
> > style instead of begin/end). The Copy-Paste icon doesn't work at all
> > because you intersperse comments throughout the code.)
>
> Ahhh, *that's* why. Strange. Don't the examples in the documentation
> use the interspersed comments all the time? They certainly look nicer
> than using bracketed comments. I'll investigate.
Okay, upon further investigation I guess the examples *are* using just
bracketed code. Strange, I thought I'd tried that and it didn't work.
Will be fixed for the actual release.
--Aaron
Emily Short
> Okay, upon further investigation I guess the examples *are* using just
> bracketed code. Strange, I thought I'd tried that and it didn't work.
> Will be fixed for the actual release.
It doesn't work in extensions. The examples are able to do slightly
more sophisticated things because they don't have to have the paste
mechanism provided by the compiler. (Sorry. But I gather this is
actually already semi-painful to set up.)
Adam Thornton
Ron Newcomb <psc...@yahoo.com> wrote:
>PS: Man, I sure wish I7 could put conditions or lambda functions or
>closures in a table.
I just had a vision of a "Table of Callbacks" which used table row
replacement to register and unregister callback functions for GUI widget
actions.
Then I had to roll my loss of 2d6 SAN.
Adam
Aaron A. Reed
> Intelligent Hinting is an I7 extension that, in short, gives games a
> "suggest" command which will recommend the next move to take, like
> many popular chess programs.
Update: I've been reworking Intelligent Hinting to make use of the
excellent suggestions from this thread. A few complications have come
up, but I hope to release an improved version later this weekend or
early next week.
--Aaron
Aaron A. Reed
available. Thanks to suggestions from Ron and JDC, task definitions
are now more readable and Inform-like:
Requirements for Killing-The-Doctor: do the action of murdering Doctor
Lucky with lead trophy.
A task's completion conditions are now set by a pure definition,
rather than creating entries in the task processing rulebook (which
has been withdrawn). This is both much easier to write and to
comprehend at a glance.
Definition: Reaching-Inner-Sanctum is complete: if location is
Sanctum, yes.
Tasks can now be "reversible," meaning they can become incomplete
again after being completed. This means you only have to worry about
defining reversible completion definitions when you need to-- for
"irreversible" tasks, the definition is no longer consulted once the
task has been completed.
Returning-The-Jewels is a reversible task with venue Inside_Building.
Requirements for Returning-The-Jewels: do the action of dropping
jewels. Definition: Returning-The-Jewels is complete: if jewels are in
Inside_Building, yes; otherwise no.
There are now two commands: an out-of-world "suggest" which just
prints what it thinks you should do, and a "solve" which actually does
it.
Numerous other minor improvements and fixes have taken place. The
current version of the extension, and the Adventure game and source
code making use of it, are at:
http://www.aaronareed.net/if/Intelligent-Hinting.i7x
http://www.aaronareed.net/if/advent-hint.ulx
http://www.aaronareed.net/if/advent-hint.txt
In addition, a compiled version of the "Slay Doctor Lucky" example is
available; try typing "suggest" and "solve" to see the extension in
action:
http://www.aaronareed.net/if/slay-dr-lucky.z5
If no major issues are found with this, I will probably release it to
the I7 extensions page later this week.
--Aaron