[I7] 'Whether all includes' puzzle.

Can anybody tell me why this bit of code doesn’t work?

[code]A thing can be seen or unseen. A thing is usually unseen.

After printing the name of a thing (called the item):
now the item is seen.

Rule for deciding whether all includes unseen things while taking: it does not.[/code]

Take all still takes things that are not included in room descriptions, because they are in containers etc.

Thanks in advance,

Jason

“Take all from box” maps to the removing it from action, not the taking action. Is that the issue here?

Not sure exactly what the problem is–what’s the scenario where things aren’t working? When I try this:

[code]A thing can be seen or unseen. A thing is usually unseen.

After printing the name of a thing (called the item):
now the item is seen.

Rule for deciding whether all includes unseen things while taking: it does not.

Lab is a room. The barrel is in the Lab. The rock is in the barrel.

The mysterious thing is in the lab. Rule for writing a paragraph about the mysterious thing: say “A mysterious thing is in the Lab.”
[/code]

[EDIT: forgot to paste the code in!]

I get

First pass, the barrel and rock got taken because their names got printed when Inform printed “a barrel (in which is a rock).” The mysterious thing didn’t get taken because the rule for writing a paragraph about it didn’t actually run the printing the name of activity for it. Then the printing the name of activity did get run for the mysterious thing in printing “mysterious thing:” when we dropped all, so the second “take all” included it.

(Notice that you can’t check seen or unseen with showme, because the showme command prints the name of the thing!)

What I was getting at was this.

A thing can be seen or unseen.
After printing the name of a unseen thing (called the item):
	now the item is seen.
Rule for deciding whether all includes an unseen thing when taking: it does not.

Market is a room. The barrel is a scenery container in Market. The apple is in the barrel.

This produces

which is all correct. But (new game)

Inform doesn’t recognize a “Rule for deciding whether all includes an unseen thing while removing something from”. (It compiles but doesn’t seem to do anything.)

We can drop the “while taking” clause to get a rule covering both actions (and also dropping, but that seems harmless). Unfortunately even that doesn’t work when the barrel contains exactly one (unseen) thing: apparently “take all from barrel” gets redirected to that thing without the “deciding whether all includes” rules being considered. So covering all cases will be fiddly.

(By the way, something I noticed which I didn’t know before: when you define a kind of value with exactly two values, seen/unseen, the default value is actually the second to be mentioned, not the first.)

Apologies, I should have given a scenario. However jrb’s market scenario is exactly right. The containers are either scenery or are part of another object, so the contents are (intentionally) not listed in the room description. I want the player to have to do a bit of exploring before they find them, and ‘take all’ seems to just bulldoze over that. Thanks for your help so far.

The standard way to accomplish this is to keep the hidden things off-stage until the player finds them.

The apple is a thing.
Instead of searching the barrel for the first time:
      say "You find an apple.";
      now the apple is in the barrel. 

OK, so I think the issue here is that (at a fairly low level) Inform isn’t consulting the deciding whether all includes rules because there’s only one thing matching the description. This used to happen for “Take all” and the fix was complicated, as Graham said. See also here.

I poked around looking at Adjudicate and the parser trace for “Take all from barrel” and I think the problem is not in Adjudicate but in the weird way that the parser handles the “take x from y” command–possibly related to this. I have a suspicion about where this might be happening but right now I’m having an inexplicable problem in trying to put in an I6 inclusion to print some debug text.

You can definitely make a rule for “Deciding whether all includes when taking or removing from”–the problem here is that the Deciding whether all include rules aren’t getting consulted anyway, in this case when we’re removing all from a container with one thing in it.

And jrb is right about its being simpler to just keep things off-stage.

[EDIT: It’s/its error. I have dishonored my ancestors.]

OK, I got my test code to work (there was a stray “–)” in the parser code I was copying in that prematurely ended the I6 inclusion) and I’ve reported it. My explanation for where I think it’s happening is there but I don’t claim to understand what’s actually going on.

Thanks for your help and suggestions. I usually keep things off-stage as described by jrb but I thought I’d come up with a clever way to avoid all that smoke and mirrors. Oh well!

Yes, you’re right. I was trying with “removing something from”, which doesn’t work here, presumably because the existence of “something” hasn’t been established yet.

Hello again.

With regard to my earlier problem concerning “take all”:

I’ve gone down the ‘Smoke and Mirrors’ route of placing the contents of the containers inside when the containers are first examined or searched. This is all well and good, except that if the first thing the player types is “take all from barrel”, and they haven’t yet searched or examined the barrel, the response given by the game is “The barrel is empty.” Which is perfectly correct, but not at all what I want!

What I need to do is to insert a new rule into the basic accessibility rules to force the player to examine the barrel (or any unexamined container) before “taking all” from it. This is where I find myself out where the buses don’t run. There’s nothing in the manual to deal with things like this and I feel, like Doctor Eric Vornoff, that I’m “tampering in God’s domain…”

But here’s what I’ve got. Perhaps fortunately, it doesn’t do anything, at all:

[code]The can’t take all from an unexamined container rule is listed before the access through barriers rule in the accessibility rulebook.

Accessibility rule (this is the can’t take all from an unexamined container rule):
if the action requires a touchable second noun and the second noun is an unexamined container:
try the player examining the second noun;
continue the action.[/code]

The easy solution is to put an object called “the contents of the barrel” in there, which is removed when you put the actual contents in. Use a “Before” rule to cancel taking attempts with a message like “you’ll have to search the barrel first”.

Hi Draconis,

Thanks for your suggestion! Unfortunately it reinstates my original problem, which is, that typing “take all” will remove “the contents of the barrel” even before the player has examined the barrel. I’m going around in circles a bit!

This is all for my Inform port of To Hell in a Hamper. It’s been a real struggle to make the I7 version function just as the TADS2 version did, and it’s taken a lot more lines of code. This is not to suggest that I7 can’t be elegant, but perhaps it can’t when it’s trying to replicate the behaviour of TADS2!

Thanks anyway!

Oh, exactly, that’s what I intended!

[code]The contents of the barrel are in the barrel. Before taking the contents of the barrel: say “There’s quite a lot of stuff in there. You might want to search it first.” instead.

After searching or examining the barrel:
remove the contents from play;
move the brass lantern to the barrel;
move the elvish sword to the barrel;
[etc.]
[/code]

The “contents” object is just a dummy to be caught by >TAKE ALL, and print a better refusal.

If the problem is that the message is unhelpful but not that the behavior is wrong, the simplest thing to do might be to find the rule response that is printing the message and change it so it prints the message you want in the right circumstances. Like this:

[code]Lab is a room.

A container can be search-triggered.
The barrel is a search-triggered container in Lab. There is an elvish sword.
For printing room description details of the barrel: stop.

When play begins:
now the parser nothing error internal rule response (F) is “[if the noun is search-triggered][We] should search [the noun] before trying to take anything from it[otherwise][The noun] [are] empty[end if].”

After searching or examining the barrel:
say “You find an elvish sword in it!”;
move the elvish sword to the barrel;
now the barrel is not search-triggered. [so we get the “is empy” message next time][/code]

How about this:

Rule for printing a parser error when the latest parser error is the nothing to do error:
	if the player's command includes "[the barrel]" and we have not searched the barrel:
		say "You'll have to try searching it first." 

Thanks matt w & jrb. I hadn’t thought about targeting the unhelpful message, I’ll give those a try.

I think at a fundamental level you’re looking at the way I7 handles concealment. Concealment is the property that will cause the parser to simulate the PC’s lack of awareness of the item’s existence, while still allowing the world model to properly describe the situation.

In I6 concealment was a basic object attribute, but in I7 it’s a rule-moderated activity. You might find something like this useful:

[code]“Ignore the Apple”

Place is a room.

An open scenery container called a barrel is in Place.

An edible thing called an apple is in the barrel.

A thing can be seen or unseen.

After printing the name of a unseen thing (called the item):
now the item is seen.

Rule for deciding the concealed possessions of the barrel:
if the particular possession is unseen:
decide yes;
otherwise:
decide no.

test me with “take apple / take all / take apple from barrel / take all from barrel / look in barrel / take all”.[/code]

This basically make the seen/unseen property equivalent to I6 concealed/~concealed. As already discussed, this does not address the issue of the unhelpful “none at all available” default error message that occurs when the concealment rules decide that nothing qualifies as the noun for the action (whether taking or removing it from). You might also want to generalize the concealment rule to more than just the barrel.

It seems like I’ve used

Rule for deciding whether all includes the contents of the barrel when taking all: it does not [rule fails?]

I don’t know if that syntax is right.

My suggestion above doesn’t work. There are two major problems with it. The first is the “[barrel]” token is matched by “all”. So any attempt to TAKE ALL when nothing is available will set off the rule, even if the barrel is not present.

The other problem may be an Inform bug. This code

Testing Suite is a room. The barrel is a scenery container in Testing Suite.

Rule for printing a parser error when the latest parser error is the nothing to do error:
	if the player's command includes "[the barrel]":
		say "You'll have to search it."

gives a runtime error:

I don’t know what the problem is here. Removing the “if the player’s command includes…” condition eliminates the problem, but I don’t see why testing that condition should cause an error.

Edit: extra weirdness: