Confused and Perplexed - Inform?
John D Hourihane
sha...@interaccess.com ( S.P.Harvey) wrote:
>: >i
>: You are carrying:
>: a bottle (which is open but empty)
>
>: >fill bottle
>: noun=bottle source=water second=nothing
>: There's no nothing here.
>
>Hmmm. Sounds like your "second" is losing its meaning
somewhere
>during the parse. It would be more helpful to see the entire
code,
>including whatever verb routine you've written for Fill.
>It sounds like the parser is expecting "fill bottle with
water".
Well, since you asked, I'll show you the fill function, or at
least
the start of it. But first, the grammar I'm using for fill
looks
like this...
Extend "fill" replace
* noun -> Fill
* noun "with" noun -> Fill;
(So that the parser will accept "fill bottle" or "fill bottle
with
wine"; if you switch the order of the lines, it will always
ask
what you cant to fill the bottle with.)
Now that means its possible for the Fill routine to be called
with
second not set (or, more acurately,, set to zero). So the first
few
lines look like this...
[ FillSub old;
if (noun notin player)
{ print "You need to be holding "; DefArt(noun); "."; }
if (location.&source_of == 0)
"There's no liquid here.";
if (second == 0)
{ old = location.source_of; << Fill noun old >>; }
if (second hasnt liquid)
{ CDefArt(second); " isn't a liquid."; }
if (noun hasnt container) "That's not a container.";
if (noun hasnt open) "That's not open.";
if (noun hasnt watertight) "That's not watertight.";
...etc...
];
The property source_of is given to rooms that you can collect
liquid in,
as set to the type of liquid you can get there.
eg. Object Barrel_Room "Barrel Room"
with description
"You are in an old cellar. One barrel remains,
full to the \
brim with bright red wine!",
source_of wine,
has light;
So if you're in a room with some sort of liquids there and just
say "fill
bottle" the routine assumes you mean the one that's available.
If you talk
about a liquids that's not here, the parser won't let you get
this far (it
will say "You can see no such thing" or something).
Nothing in the code has a before or after routine that responds
to Fill, or
indeed one that changes second.
It seems that you just can't assign to second quite like a
normal variable.
Why this should be, I don't know. Rather than find out, I swept
the
problem under the carpet with the following work around...
if (second == 0) {
old = location.source_of;
<< Fill noun old >>;
}
in the obvious place above, and it works fine. You need to
store the
new location.source_of in a variable since the compiler rejects
<< fill noun location.source-of >> as having too many
arguments.
> Have you been tinkering with the libraries?
No. I haven't. That response to "go north" really does come up,
because the libraries wind up trying to "enter north" - the
only
place the word "surreal" occurs in verblib.h is in EnterSub!
S.P.Harvey
: > Have you been tinkering with the libraries?
: No. I haven't. That response to "go north" really does come up,
: because the libraries wind up trying to "enter north" - the
: only
: place the word "surreal" occurs in verblib.h is in EnterSub!
What I meant when asking if you've been modifying the libraries was to
ask about changing the handling of n_obj or something like that. The "A
surreal idea" should only come up if you try to enter an object that
isn't enterable.
> enter coffee cup
A surreal idea.
One of my projects is to print out the libraries for easy reference.
Haven't quite managed that yet.
Sounds like you managed to solve the liquids-handling rather cleverly.
Good luck.
Scott
--
----------------------| S.P. Harvey |--------------------------
"If my answers frighten you, Vincent,
you should cease asking scary questions."
- Jules, "Pulp Fiction"
----------------------| sha...@interaccess.com |--------------------------
Mathematical Institute, (0865) 2-73525
> In article <39ahvr$3...@finnegan.iol.ie>,
> John D Hourihane <hour...@iol.ie> wrote:
>
>>Extend "fill" replace
>> * noun -> Fill
>> * noun "with" noun -> Fill;
>
> programming.
>
> Is there any way to have the parser do the following?
>
> Before Door
> You stand before a locked door.
>
>> i
> You are carrying a fruitcake and a key.
>
>> unlock door
> (With the key)
> Unlocked.
> ---------------------------------------
> Before Door
>
>> i
> You are carrying a fruitcake.
>
>> unlock door
> What do you want to unlock the door with?
>
>> fruitcake
> Don't be absurd!
> ---------------------------------------
> Before Door
>
>> i
> You are carrying a fruitcake, a small key, and a large key.
>
>> unlock door
> What do you want to unlock the door with?
>
>
> That is, it would be nice to have actions use default objects, but still
> be able to use disambiguation when necessary. Is this possible?
>
> - Damien
Certainly, but the parser does not ordinarily do so by itself because
it's bound to lack the specific game knowledge. For instance, it doesn't
know that the key is more sensible than the fruitcake. Now you might say,
aha, but it should, because the key unlocks the door! But then the problem
is that it doesn't want to reveal this to a player who might not know which
of the ten or so keys she's holding is the right one.
Anyway, that's why the feature is not built in. You can add it as follows:
[ GuessUnlock;
if (iron_key in player)
{ print "(with the iron key)^"; <<Unlock noun iron_key>>; }
"You'll have to say what to use for a key.";
];
Extend "unlock" first
* noun -> GuessUnlock;
That's a first approximation. If that isn't clever enough for you, you
can always code the Unlock grammar even more cunningly to allow the empty
string, so to speak, to mean the iron key... but the above will do nicely
enough, I think.
Graham Nelson
Oxford, UK
Damien P. Neil
Mathematical Institute, (0865) 2-73525 <nel...@vax.oxford.ac.uk> wrote:
>[ GuessUnlock;
> if (iron_key in player)
> { print "(with the iron key)^"; <<Unlock noun iron_key>>; }
> "You'll have to say what to use for a key.";
>];
This is easy enough to do, of course. However, it doesn't allow for
disambiguation. Currently, I can type something like:
>unlock
What do you want to unlock?
>cabinet
What do you want to unlock the medicine cabinet with?
>keys
(first taking the set of keys)
You unlock the medicine cabinet.
Adding a GuessUnlock routine would change this to:
>unlock
What do you want to unlock?
>cabinet
You'll have to say what to use for a key.
(Assuming the player has two keys.)
- Damien
Gareth Rees
> [wants to know how to make the parser choose a default object when
> there's only one plausible possibility, but to ask for disambiguation
> when there are several.]
The example game below shows how to do this. You'll need to write test
routines for each case when you want to choose a default object (the
function OneKeyTest check to see if the player is carrying excatly one
key and if so returns true).
--
Gareth Rees
-----------------------------------------------------------------------------
Constant Story "SHELL";
Constant Headline "^An Interactive Skeleton^";
Include "Parser";
Include "VerbLib";
Attribute is_key;
Object RoomA "Antechamber"
with description "An empty room. There is a red door to the north.",
n_to RedDoor,
has light;
Nearby RedKey "red key" with name "red" "key", has is_key;
Nearby BlueKey "blue key" with name "blue" "key", has is_key;
Object RoomB "Chamber"
with description "An empty room. There is a red door to the south.",
s_to RedDoor,
has light;
Object RedDoor "red door"
with when_closed "The red door is closed.",
when_open "The red door stands open.",
door_to [; if (location == RoomA) return RoomB; else return RoomA; ],
door_dir [; if (location == RoomA) return n_to; else return s_to; ],
with_key RedKey,
name "red" "door",
found_in RoomA RoomB,
has door locked lockable openable static;
[ Initialise;
location = RoomA;
print "^^^^^Welcome to the shell...^^";
];
[ OneKeyTest i j;
objectloop (i in player) { if (i has is_key) j++; }
if (j == 1) rtrue; else rfalse;
];
[ MyUnlockSub i j;
objectloop (i in player) { if (i has is_key) j = i; }
print "(with "; Defart(j); print ")^";
<<Unlock noun j>>;
];
[ MyLockSub i j;
objectloop (i in player) { if (i has is_key) j = i; }
print "(with "; Defart(j); print ")^";
<<Lock noun j>>;
];
Include "Grammar";
Extend "unlock" first
* noun=OneKeyTest -> MyUnlock;
Extend "lock" first
* noun=OneKeyTest -> MyLock;
end;
-----------------------------------------------------------------------------
S.P.Harvey
: That is, it would be nice to have actions use default objects, but still
: be able to use disambiguation when necessary. Is this possible?
Anything's possible, provided you want to work hard enough to achieve
it. Often, the parser not choosing the proper object is to avoid giving
away puzzle answers inadvertantly. For example:
> i
You are carrying a key, a credit card, and a bobby pin.
> unlock door
What do you want to unlock the door with?
> key
The key doesn't fit the lock.
> unlock door with credit card
You jam the card into the doorframe. It snaps in half and the door remains
closed.
> unlock door with bobby pin
Gingerly, you insert the pin into the keyhole and jiggle it back and
forth. A satisfying "snap" lets you know you've unlocked the door.
--------------- or -----------------
> i
You're carrying a key, a credit card, and a bobby pin.
> unlock door
(with the bobby pin)
Gingerly.... blah blah blah.
-------------------------------------------
A nice spin on this would be to keep the parser's object choice
ambiguous, but create a default object once the puzzle is solved. Hence,
if you have a dozen locked doors with different keys (not recommended,
you'll get lynched), the parser would 'remember' which key unlocks which
door. Naturally, this is a poor example.
Overall, I say let the player do the work of remembering which key
unlocks which door. Keeping a few notes is not an unrealistic
expectation to have of a player.
Mathematical Institute, (0865) 2-73525
> Damien P. Neil (dam...@b63519.student.cwru.edu) wrote:
>
> : That is, it would be nice to have actions use default objects, but still
> : be able to use disambiguation when necessary. Is this possible?
>
>
> ambiguous, but create a default object once the puzzle is solved. Hence,
> if you have a dozen locked doors with different keys (not recommended,
> you'll get lynched), the parser would 'remember' which key unlocks which
> door. Naturally, this is a poor example.
>
On the whole, I think there's something to be said for allowing a certain
degree of user-programmable disambiguation (of course, as Scott remarked,
anything's possible with the Inform parser already, but it's quite hard
work by hand). For almost all practical cases, mind you, the easy fix
with a grammar extension that I posted the other day seems acceptable
to me.
The "disambiguation" part of the parser is extremely complicated (I was
going to type "sophisticated" but had a twinge of conscience), certainly
its most complex algorithm: it has an elaborate scoring system, groups
matched objects into equivalence classes according to whether or not the
player can textually distinguish between them (this for plural objects),
tries to get as many things as you wanted out whenever it can make clearly
good guesses, etc. It has to juggle all kinds of awkward things and the
code is not easy to follow!
Well... I'll think about it. My general policy is that the parser should
be as open-access as possible, anyway.
Graham Nelson
Oxford, UK