Referring to things as yet unseen

I want to be able to automatically open things and take other things when they’re not at first accessible. For instance, in this scenario, taking the key doesn’t work:

The testing chamber is room. The box is a closed, openable container in the testing chamber. The key is in the box.

Check taking the key:
	if the key is in the box and the box is closed:
		say "(first opening the box)";
		silently try opening the box.

Test me with "take key".

So I can do something like this instead:

[code]After deciding the scope of the player:
place the key in scope.

This is the opening-stuff rule:
if the action requires a touchable noun:
if the noun is not in a closed container:
make no decision;
if the noun is in a closed container (called the enclosure):
say “(first opening [the enclosure])”;
silently try opening the enclosure.

The opening-stuff rule is listed first in the action-processing rules.[/code]

That way, the player can ‘see’ the key and try to open the box before taking the key. That works fine. But if we add an additional layer of complexity:

[code]The key unlocks the red door. The red door is a locked door. The red door is north of the testing chamber.

Test unlocking with “unlock the red door with the key”.
[/code]

“unlock door” doesn’t try opening the box before taking the key to unlock the door with. What should I do?

Can you rewrite the opening-stuff rule so it applies when the action requires a touchable second noun as well?

Try this. It seems to work.

[code]After deciding the scope of the player:
place the key in scope.

Before unlocking something with the key:
if the key is in the box and the box is closed begin;
say “(first opening the box)”;
silently try opening the box;
end if.

The Testing Chamber is Room. The box is closed, openable and a container in the testing chamber. The key is in the box. The key unlocks the red door. The red door is a locked door. The red door is north of the testing chamber.

Test me with “unlock red door with the key”.[/code]

You’ll need a before rule in order to get there before the accessibility rule fires.

Hope this helps.

Matt: Ah yes! It was to do with second nouns! These problems are always so obvious in retrospect. It works now, cheers!

‘Climbing stars’: Above is a very simplified version of what I’m actually doing, but I’ll try it out with before rules.

Ok, I’ve tried it and it works for unlocking BUT not for taking when the box is closed.

This should do it.

[code]After deciding the scope of the player:
repeat with item running through things enclosed by the location of the player begin;
if the item is not nothing and the item is in a closed container, place the item in scope;
end repeat.

Before doing anything:
if the noun is not nothing and the noun is in a closed container (called the first container) begin;
say “(first opening [the first container])”;
silently try opening the first container;
if the first container is closed, do nothing instead;
end if;
if the second noun is not nothing and the second noun is in a closed container (called the second container) begin;
say “(first opening [the second container])”;
silently try opening the second container;
if the second container is closed, do nothing instead;
end if.

The Testing Chamber is Room. The box is closed, openable and a container in the testing chamber. The key is in the box. The key unlocks the red door. The red door is a locked door. The red door is north of the testing chamber.

Test me with “take key / put key in box / close box / unlock red door with the key”.[/code]

A similar problem to this was posted here.

Hope this help.

You might want to consider how much help you want to give the player. I can’t imagine a player objecting to “unlock door with key” failing when they’ve played the game before and they know the key is hidden. On the other hand, you’re doing a lot of work to accommodate that particular whim, at the risk of exposing too much to a player who types “unlock door with key” without knowing where it is hidden. If you take this to its ridiculous extreme, you might end up having to implement a “win game” command…

Oh I know it’s a terrible design choice: thankfully it’s not for a proper game.