I7 - I thought I should use "try" - guess not

wfryers · October 21, 2010, 3:54am

It looks like I am back begging for help.

Here is the story

A Used_Meal Pack is a thing.
	The description is "The crumpled remains of a meal pack."

A  Meal Pack is a device.

	[The  meal pack is switched on.]

	The description is "[if switched on]Steam rises from the open pack.  It smells good enough to eat.[else] You see a hot meal pack labeled - Test one." [end if];
	
	A Meal Pack can be edible.
	
	Understand  "heat [something]" as switching on.
	
	Instead of switching on the meal pack when the meal pack is switched on,
			say "Its already heated."		
	Instead of eating the meal pack when the meal pack is switched on:
			say "The meal fills you with a warm glow.";
			remove meal pack from play;
			move the Used_Meal Pack to the location of the player. 
			
	Instead of switching on the Meal Pack when the meal pack is switched off:
			try switching on the Meal Pack;
			say "You can feel the heat radiating from the pack.  Its ready to eat."		
	Instead of eating the meal pack when the meal is switched off, 
			say "You might want to heat that up first."

The lab is a room. “A well equipped labratory.”

The meal pack is in the lab.

When I “go” it translates correctly. When I run I get a run time error -

lab
A well equipped labratory.

You can see a Meal Pack here.

examine
(the Meal Pack)
You see a hot meal pack labeled - Test one.

The Meal Pack is currently switched off.

eat
(the Meal Pack)
(first taking the Meal Pack)
You might want to heat that up first.

heat
(the Meal Pack)

*** Run-time problem P7: Too many rulebooks in simultaneous use.

You can feel the heat radiating from the pack. Its ready to eat.

Apparently ‘try’ is not the right choice. So what is?

capmikee · October 21, 2010, 4:19am

Yeah, you’ve got some infinite recursion going on there. Without testing it, I would guess that what you want is this:

After switching on the Meal Pack: say "You can feel the heat radiating from the pack. Its ready to eat."

tggdan3 · October 21, 2010, 1:00pm

You basically have

1 Say “text”
2 goto 1

You are saying “Instead of turning on the meal pack, try turning on the meal pack.”
Take out the try line and it should work, or change to “instead of EATING the meal pack when switched off”

Peter_Piers1 · October 21, 2010, 10:53pm

I would have done something like -

Instead of switching on the Meal Pack when the meal pack is switched off:
now the Meal pack is switched on;
say “(whatever)”

It’s important that you understand what you wrote, however, because it’s not obvious when you start making these mistakes - you look at what you wrote and it seems to be allright. But you in fact told Inform to do this:

Instead of switching on the Meal Pack when the meal pack is switched off:
-try switching the Meal Pack on
<and Inform obediently tries to switch it on. And lo and behold, when it does, it encounters this instruction:>
Instead of switching on the Meal Pack when the meal pack is switched off:
-try switching the Meal Pack on
<which it follows, and when it follows it, it encounters the following instruction for when switching on the Meal Pack:>
Instead of switching on the Meal Pack when the meal pack is switched off:
-try switching the Meal Pack on

…and so on and so forth. Does that help you understand what happened? The first time I made a similar mistake, it took me a good three minutes staring at the code, trying to figure out what had happened.

wfryers · October 22, 2010, 2:26am

It sounds like I am still missing the point on a lot of the commands.

I wanted to create a device that has a specific behavior. Before the meal is switched on it is just a foil pouch. Like any foil pouch it is inedible and not too interesting. Once it is switched on it becomes edible and is much more interesting. After you eat it, it turns into inedible waste.

There are also some situations that need to be handled. For example, turning it on when it is on, turning it off when it is off, eating it before it is on and so on.

Originally I just had the “say” clause. It works fine just as you say it will. There is a small problem. The device is still switched off. Since the idea is to turn it on. That’s kind of a problem.

Yes, I can switch it on with the simple declarative – The meal pack is switched on. Everything works fine.

The player can switch it on. Problem is that allows the player to switch it on several times. Each time I get the “Say” about being ready to eat. That is something I only want the first time it is switched on. Subsequent attempts should result in no action and feedback to the player.

I guess I am still missing the point.

wfryers · October 22, 2010, 2:32am

Wow! I never thought of it as:

1 say “text”
2 go to 1.

The piece of code is like this:

Instead of switching on the Meal Pack when the meal pack is switched off:
try switching on the Meal Pack;
say “You can feel the heat radiating from the pack. Its ready to eat.”

I had been thinking that I should understand the code something like this:

If the meal pack is in the state “Switched Off”
Ignore the player input - “Switch on”
Substitute the machine input “try”
Show the player a feedback text string.
End
End

Some other I7 commands

Reading it like above means I only check the switched state at the beginning of the if. Any statements within the block are then executed. Execution then continues with the next I7 command. It does not jump back to the if to check the switched state while it is executing statements in the block.

Clearly it doesn’t work that way.

wfryers · October 22, 2010, 3:15am

Peter Pears:

I would have done something like -

Instead of switching on the Meal Pack when the meal pack is switched off:
now the Meal pack is switched on;
say “(whatever)”

It’s important that you understand what you wrote, however, because it’s not obvious when you start making these mistakes - you look at what you wrote and it seems to be allright. But you in fact told Inform to do this:

Instead of switching on the Meal Pack when the meal pack is switched off:
-try switching the Meal Pack on
<and Inform obediently tries to switch it on. And lo and behold, when it does, it encounters this instruction:>
Instead of switching on the Meal Pack when the meal pack is switched off:
-try switching the Meal Pack on
<which it follows, and when it follows it, it encounters the following instruction for when switching on the Meal Pack:>
Instead of switching on the Meal Pack when the meal pack is switched off:
-try switching the Meal Pack on

…and so on and so forth. Does that help you understand what happened? The first time I made a similar mistake, it took me a good three minutes staring at the code, trying to figure out what had happened.

Thanks for suggesting a different way to approach the problem. I tried it and it worked!

To be honest I am completely confused by the “try”. To me even if it recursively invoking the same instruction (why that is happening completely escapes me) the state of the meal pack changes to switched on which means the when clause is not met. That should end the recursion, but it doesn’t.

While I appreciate your attempt to explain how this is happening, I just don’t get it.

Thanks

Dannii · October 22, 2010, 3:29am

That’s what “try” does, it invokes a new instruction, in your case the same one. The when clause is never met because nothing actually changes the state of the pack. Peter suggested using a “now” phrase, which will change the state.

capmikee · October 22, 2010, 3:52am

It’s all about rule order. Rule order is one of the trickiest points in I7, but it’s really, really important.

Every time the player tries an action (or the action is triggered by a “try” command in the source), all of the applicable rules are followed, in this order:

Before rules
Instead rules
Check rules
Carry out rules
After rules
Report rules

Now, the standard library rules for devices will handle switching on and off for you, and give reasonable default messages for actions like switching on a device twice (“That’s already on.”) The checking happens in the check rules, and the actual state-changing happens in the carry out rules. The trouble is that your instead rule is running before carry out rules, meaning that its condition is re-checked before the meal has a chance to be switched on.

“Try” can be a little hard to understand at first, but there are a few things that are useful to know about it:

Actions are processed in more or less exactly the same way whether they were triggered by a player command or a “try” statement. So when you write “try,” you are essentially putting words in the player’s mouth. It’s useful if you’d like to funnel a variety of commands into one particular action, or you’d like to make things more convenient, like automatically unlocking a door before opening it.

Because of this, a single turn can actually contain any number of actions. In your case, an infinite number.

I suggested using “After” in this case, because After rules run after the carry out phase, ensuring that the action succeeded and was processed normally by other rules, but giving you a chance to write your own message about what happened. To me that sounds like what you’re trying to do.

katz · October 22, 2010, 6:41pm

Instead of switching on the Meal Pack when the meal pack is switched off: now the Meal pack is switched on; say "(whatever)"

Correct me if I’m wrong, but you shouldn’t need to say “now the Meal Pack is switched on” at all, since you’re using the “switch on” action already. So the even more concise way to say it would be:

After switching on the Meal Pack when the meal pack: say "(whatever)"

You don’t even need to specify “when the meal pack is switched off,” because there’s already an “instead” rule for when it’s not switched off.

Erik_Temple · October 22, 2010, 7:43pm

No, that’s not correct: “Instead” cancels the action, so you don’t get to the carry out rules that set the switched on property.

–Erik

katz · October 22, 2010, 9:28pm

Which is why I then suggested using “After”, not “Instead.”

Erik_Temple · October 23, 2010, 2:46pm

Oops, clearly my skim module was malfunctioning. I took you to be saying more or less the opposite of what you actually said. Sorry about that.

–Erik