hiding something in an enterable

[peterorme]

A quick question I think: is there a simple way of hiding something inside an enterable container? So that you have to enter it before you see the things inside it.

Here’s what I ended up with:

Alley is a room.

the bush is an enterable container in the alley. 
the mysterious card is a thing in the bush. "Hey, there's a card here on the ground.";

After printing the name of the bush: omit contents in listing.

check examining the bush:
	unless the player is in the bush: 
		say "It's big enough to enter. There's enough large leaves that you can't see inside.";
		stop the action.
	
instead of searching the bush, try examining the bush.

But maybe there is some property of containers that do this with less code? (A closed container does it, but I don’t want a closed container)

[climbingstars]

Here’s one way of doing it.

[code]“Test”

Before printing the name of the bush: omit contents in listing.

Rule for listing contents of the bush when the player is not in the bush:
say “you can see a load of leaves. You’ll need to enter it first”.

The Alley is A Room. The bush is an enterable container in the alley. The mysterious card is in the bush. The initial appearance of the card is “Hey, there’s a card here on the ground.”.

Test me with “x bush / search bush / enter bush / x bush / search bush”.[/code]

This makes use of the fact that the content listings for examining and searching containers go through the listing contents activity.

Hope this helps.

[peterorme]

Thanks, that does it, I hadn’t figured that one out.

Is there are reason you changed my “after printing the name” to “before printing the name”? As far as I can tell they both seem to work, but maybe I’m missing something?

[ChrisC (Chris Conley)]

Per WI 18.10:

The default outcome of “before” (and of almost all rulebooks, in fact) is no outcome; the default outcome of “instead” is failure; the default outcome of “after” is success.

This means that any “after” rule which fires immediately ends the processing of that activity with the outcome of success. In your case, no other behavior is meant to happen in the printing the name of activity, and so this is indistinguishable from the standard behavior; but in a more complex work the activity may well have other intended behavior, which this rule (being very likely to fire) might preempt. Sine “omit contents in listing” is something more like a passive flag than any kind of complex action, it may be a bad idea to put it in a rule with an outcome.

[climbingstars]

@ChrisC

Per WI 18.10:

The default outcome of “before” (and of almost all rulebooks, in fact) is no outcome; the default outcome of “instead” is failure; the default outcome of “after” is success.

This means that any “after” rule which fires immediately ends the processing of that activity with the outcome of success. In your case, no other behavior is meant to happen in the printing the name of activity, and so this is indistinguishable from the standard behavior; but in a more complex work the activity may well have other intended behavior, which this rule (being very likely to fire) might preempt. Since “omit contents in listing” is something more like a passive flag than any kind of complex action, it may be a bad idea to put it in a rule with an outcome.

This only applies to actions, not activities.

@peterorme

Thanks, that does it, I hadn’t figured that one out.

Is there are reason you changed my “after printing the name” to “before printing the name”? As far as I can tell they both seem to work, but maybe I’m missing something?

Actually, I thought the code that prints the content listing actually ran inside the “for printing the name” rule and therefore the after rule would be too late. It turns out that a separate bit after printing the name deals with this.