If; looked at object1, then enable object2 description

Greetings!

[size=85](I tried to search for posts similar to mine, but since I suck at using it…I tried to look into Inform 7 Documentation, but didn’t figure this out myself.)[/size]

I have a problem.
There is a hole in my room. You can see the sky from it.
But I want that you can see the sky only after you have looked at the hole.

How do I write this?
[size=85](I tried “If the player looks at the hole, enable sky description.”, but it gave me an error.)[/size]

Crumbling Hall is a room. "There's a gaping hole in the ceiling."

Distant scenery is a kind of scenery thing.
Instead of doing something other than examining with distant scenery, say "It's too far away."
Instead of doing something other than examining when the second noun is distant scenery, say "It's too far away."

The gaping hole is distant scenery in the Crumbling Hall. "You can see the sky through it."
Understand "ceiling" or "roof" as the gaping hole.

The sky is distant scenery. "It's very blue."

After examining the gaping hole for the first time:
	now the sky is in the Crumbling Hall;
	continue the action.

The player carries a rubber ball.

Test me with "x sky / x hole / x sky / touch hole / throw ball at hole / touch sky / throw ball at sky".

The idea is to keep the sky offstage until the player looks at the hole and then move it to the location.

Things omitted for simplicity:

  • Handle the searching action (“look through hole”). Deal with the can’t search unless container or supporter rule.
  • Handle the sky being a backdrop. See §3.9 and §8.8.

Greetings, vlaviano!

After wondering about your code, I tested it in my game.
Somehow it didn’t work. I couldn’t see the sky description after looking at the hole.

[code]The Strange Room is a room. “You stand in a completely empty room. It looks boring. [line break]There is a door in front (in north).”

The walls, the floor and the ceiling are scenery in the Strange Room.
The walls, floor and the ceiling are fixed in place.
The hole is in Strange Room. The hole is fixed in place.

Distant scenery is a kind of scenery thing.
The Sky is distant scenery. “Calm, blue sky, with fluffy white clouds around it.”
Understand “heaven” as the sky.

After examining the hole for the first time:
[ now the sky is in the Test Room;]
continue the action.

The description of the walls is “Naked, grayish, concrete walls. Boring.”
The description of the floor is “Grayish, concrete floor. Looks dull.”
The description of the ceiling is “It seems to be as rough of concrete as the floor. The color is the same.”
The description of the hole is “A big hole to your right - eating a piece of a wall and the floor off. You can see the sky through the hole.”
[The description of the sky is “Calm, blue sky, with fluffy white clouds around it.”][/code]

(I put “now the sky is in the Test Room;” in []'s, since that code created an error)

I would also have one thing to point out about this, plus one thing about asking about something else.


I don’t think I need to use these following codes in my example?

Instead of doing something other than examining with distant scenery, say "It's too far away." Instead of doing something other than examining when the second noun is distant scenery, say "It's too far away." The player carries a rubber ball. Test me with "x sky / x hole / x sky / touch hole / throw ball at hole / touch sky / throw ball at sky".

(I also tried your code as you wrote yourself for further experimenting [only changed Crumbling Hall to Ball Room], but it created an error.)

  1. I wanted something to happen after a Player goes from room1 and before the player gets to the room2. But when I try to play it, it only shows the happening, without showing the name of the second room.

Code:

[code]The Test Room is north of Strange Room.
After going north, say “You walk at the door, pull it open and walk through the doorway. The door shuts behind you as you enter in a new room.”

The Test Room is a room.[/code]

When I put the “After going…” -sentence in [], the game shows the room name correctly, but doesn’t show this happening text.

Something must be wrong about my code, but I can’t figure out, what.
I also tried the following, but it didn’t bring the room name visible in-game:

The Test Room is a room. now the player is in Test Room.

On the second issue: an “after” rule, by default, suppresses the default messages. So you can use it to put custom messages in for actions. If you want the normal text to still show up, add “continue the action” as the last line of the rule.

I took your program, restored the line that moves the sky (which is critical), changed Test Room to Strange Room (also critical, since that’s where the hole is and where the player is), removed an unnecessary line (see below), restored the line about the rubber ball (only important for testing), and added some commands to “test me”. Here’s the result:

The Strange Room is a room. "You stand in a completely empty room. It looks boring. [line break]There is a door in front (in north)."

The walls, the floor and the ceiling are scenery in the Strange Room.
The hole is in Strange Room. The hole is fixed in place.

Distant scenery is a kind of scenery thing.
The Sky is distant scenery. "Calm, blue sky, with fluffy white clouds around it."
Understand "heaven" as the sky.

After examining the hole for the first time:
	now the sky is in the Strange Room;
	continue the action.

The description of the walls is "Naked, grayish, concrete walls. Boring."
The description of the floor is "Grayish, concrete floor. Looks dull."
The description of the ceiling is "It seems to be as rough of concrete as the floor. The color is the same."
The description of the hole is "A big hole to your right - eating a piece of a wall and the floor off. You can see the sky through the hole."

The player carries a rubber ball. [This is only for testing the sky as the second noun]
Test me with "x sky / x hole / x sky / touch hole / throw ball at hole / touch sky / throw ball at sky / touch walls / take walls / touch ceiling / take ceiling".

This compiles for me with 6M62 and produces the following output:

The main thing to notice is that the sky isn’t visible before the hole is examined and is visible after.

However, there are few things that are different about this output when compared to that of the program that I posted.

First, the hole is mentioned as a nondescript item in the room description. This is because you’ve defined the hole as fixed in place, while I defined it as distant scenery (a specialized kind of scenery).

Second, it’s not necessary to define the walls, floor and ceiling as fixed in place if they’re already defined as scenery, because scenery implies fixed in place. So, I removed that line. See the output for “take walls” above as a demonstration of this. You can also do “showme walls” to see that the fixed in place property is automatically set for scenery.

Third, when the player tries to touch the sky, the hole, or the ceiling, the game says “You feel nothing unexpected” which is inappropriate since those things should be too far away to touch. Similarly, when the sky is an action’s second noun, the normal default msg is produced even though it might not be appropriate. The output “Futile” isn’t all that bad, but consider:

Well, yeah, but putting the ball on the sky isn’t possible in the first place. This is the reason why I defined a distant scenery kind in my example: to produce more appropriate responses for scenery objects that should be out of the player’s reach.

You said:

You do need to use those two instead rules if you want distant scenery to do anything, since they are the reason that it exists. The test me line is so that we can test the program by typing “test me” at the prompt, and the rubber ball line is to give us something held that we can act on with the sky as the second noun in our tests.

With the two instead rules added to the program above, we get this output:

This is better, other than the output for manipulating the hole and the ceiling. As I said, this is because they’re defined as regular scenery instead of distant scenery.

You also wrote:

The program as posted compiles without errors. You’d have to post the modified version of the code and the specific error message for us to know what went wrong. If I change all three instances of Crumbling Hall in my original program to Ball Room (or all four instances of Strange Room in this program to Ball Room), it compiles without error. If you just changed the first Crumbling Room to Ball Room, then of course it would produce an error, because there are other references in the program to Crumbing Room, a room that no longer exists after the change.

Let’s now look at your second question, about this code:

The Test Room is north of Strange Room.
After going north, say "You walk at the door, pull it open and walk through the doorway. The door shuts behind you as you enter in a new room."

The Test Room is a room.

There are several problems here.

You’ve already said that Test Room is north of Strange Room, so, while it doesn’t hurt, you don’t need to also explicitly say that Test Room is a room (or even that Strange Room is a room), since Inform’s able to infer that they’re rooms because one is north of the other. However, you might want to give each its own paragraph if you’re also writing room descriptions. See below.

The after rule is written for the very broad condition “after going north”. This might not hurt you in this game where there are only two rooms, but it’s a bad idea in general, because it will apply any time the player goes north from anywhere in the game.

Third, as Draconis says, an after rule will halt the action by default. To allow the action to proceed, you need “continue the action;” after your say command (and you’d also need to use the colon syntax instead of the comma syntax since there would then be more than one statement in the rule).

Here’s a fixed up version of the code:

Strange Room is a room. "This is a strange room."
Test Chamber is north of the Strange Room. "This is the test chamber."
Third Room is north of the Test Chamber. "This is the third room."

After going north from Strange Room:
	say "You walk at the door, pull it open and walk through the doorway. The door shuts behind you as you enter in a new room.";
	continue the action.

It would be even simpler to use a before rule instead of an after rule in this scenario, because before rules continue the action by default. This would allow you to get rid of the explicit “continue the action”.

Strange Room is a room. "This is a strange room."
Test Chamber is north of the Strange Room. "This is the test chamber."
Third Room is north of the Test Chamber. "This is the third room."

Before going north from the Strange Room:
	say "You walk at the door, pull it open and walk through the doorway. The door shuts behind you as you enter in a new room."

While we’re on the topic, note that there is a difference between going north from a room, which requires there to be an exit to the north, and going north in a room, which doesn’t require that an exit exists. See §7.13.

Don’t let “natural language” programming fool you. The programs might be easy to read, but there is an underlying strict syntax that you must adhere to when you write an I7 program. For example, “now the color of the balloon is red”, not “the color of the balloon is now red”. Both are equally readable, but only one works. There can also be significant semantic differences between seemingly similar statements (“going north in” vs. “going north from”).

I’d be cautious about using a “Before” rule to print this message, though, because you might get a situation where the Before rule runs and prints the message even though some later rule prevents the going action from taking place. Like this:

[code]“Test project” by Matt Weiner

Strange Room is a room. “This is a strange room.”
Test Chamber is north of the Strange Room. “This is the test chamber.”
Third Room is north of the Test Chamber. “This is the third room.”

Before going north from the Strange Room:
say “You walk at the door, pull it open and walk through the doorway. The door shuts behind you as you enter in a new room.”

A rock is in the Strange Room.
Check going from the Strange Room when the rock is in the Strange Room: say “You don’t want to leave here without your rock!” instead.[/code]

Yields:

For this reason, you might want to stick with the “After” rule with “continue the action” in it. You could also use a “First report” rule:

First report going north from the Strange Room: say "You walk at the door, pull it open and walk through the doorway. The door shuts behind you as you enter in a new room."

which will run at the beginning of the “Report” rules, before the rule that prints the new room description. Unlike “After” rules, “Report” rules don’t cut off the rest of the action even if you don’t write “continue the action.”

(Also, if you describe a door, players might expect you to actually have implemented the door as a separate object. Look at the section of the documentation on Doors if you want to see more about that.)

Yes, this is very true and important!

Thanks for the correction, Matt.

OP, you should go with the after rule + continue the action or first report rule as Matt suggests.

However, for the sake of mentioning another technique, this is also a possibility:

Before going north from the Strange Room:
	abide by the check going rules;
	say "You walk at the door, pull it open and walk through the doorway. The door shuts behind you as you enter in a new room."

This doesn’t provide much benefit here compared with the alternatives, but I’ve found “abide by the check fooing rules” to be useful as part of an instead rule in cases where I want to intercede in between the check and carry out stages. In other words, when I want to ensure that something could have been done, but I don’t actually want the changes to the world model that would occur if the action were actually carried out.

Oh. I didn’t notice naming that one room wrong until now.

  • Understanding rubber ball throwing as test for stupid-sounding outputs…CHECK (added “It’s too far away.” -stuff back in code)

  • Understanding “…hole is mentioned as a nondescript item in the room description. This is because you’ve defined the hole as fixed in place, while I defined it as distant scenery (a specialized kind of scenery).”…UNCHECK

  • Understanding room parts as scenery without fixed stuff…CHECK

  • Trying out first example code…DISCARDED (I’ll just go along with this new stuff and information)

  • Not implying that something is a room, when exits are defined, and when there are no special in/out messages…CHECK

  • Understanding about this paragraph-stuff with room descriptions…UNCHECK (checked the examples, but I didn’t understand)

  • Understanding about the after-rule…CHECK (I don’t know how to find any lists of commands and verbs available, so I don’t know how to program this stuff correctly…)

  • Understanding the after-rule, and action-continuing, correct way of coding it…CHECK (Thanks, about the example too. Didn’t know about this either.

  • Using before-rule rather than after-rule…CHECK


QUESTION.
If I wrote (something) like this:

Before going north from the Strange Room for the first time: say "You walk at the door, pull it open and walk through the doorway. The door shuts behind you as you enter in a new room."

…would the moving-to-the-next-room description be shown only once?


  • Understanding about the natural-language-programming…CHECK (I actually find this system interesting, but since I have no clues about verbs or commands I have on my disposal…well, it’s easy to break my code…)

  • After-rule, before rule, rock changing the play, report stuff…hmm…so many things to make note of, so many options…

  • Door description…CHECK (didn’t even think about this. I could remove that part of the text, yeah)

  • Abide by the check going rules…TOO MANY TECHNIQUES AVAILABLE =D

  • Understanding its explanation…UNCHECK (I lack some English skill)


Oh gods.
These replies are so full of detail…takes lots of time to both go through this all and replying on it =D
So much stuff in Inform…