Boolean variable to condition movement

Hi All,

I’m looking to use a boolean variable to determine whether the user is currently allowed to go south or not. Below is the code I’m using.

After going south:
	if FightExamined is false:	
		instead of going south:
			say "Because you are still learning how to play the game, you are being prevented from going south just yet. After the tutorial you are free to move as you please.";

Elsewhere in my code I’m changing the boolean variable like this, which someone here has helped me with:

After examining the fight :
	now FightExamined is true;
	say "Variable FightExamined is [FightExamined]";

I have checked and this is working (I define the boolean variable earlier). The problem is that the first piece of code always prevents the user from going south. I want the user to move south once FightExamined is true.

Any help would be really appreciated!
Chris

You’re trying to nest rules inside each other, which doesn’t really work. Try this:

Instead of going south when FightExamined is false: say "...".

EDIT: Ninja’d, here’s what I was going to post!

The syntax “instead of going south” is redundant; Inform seems to be interpreting it as a completely new rule. You just want “instead”:After going south: if FightExamined is false: instead say "Because you are still learning how to play the game, you are being prevented from going south just yet. After the tutorial you are free to move as you please.".But, since you’re creating an “after” rule, this logic isn’t applied until after the action. So you can still go south, it just replaces the usual report that’s printed after the action. You probably want an “instead” rule: Instead of going south when FightExamined is false, say "Because you are still learning how to play the game, you are being prevented from going south just yet. After the tutorial you are free to move as you please.".

The problem is not just with how you have written your rules. It’s also that you’re using an “after” rule. Any code that you put in an “after going south” rule will not, by definition, prevent the player from going south – because the rule is not invoked until after the player has gone south.

It will, however, prevent the player from seeing the destination room description, because that happens in the “report” rules, and “after” rules supercede “report” rules by default. This can make it seem to the player that movement was prevented, even when it really wasn’t.

For example, compile the following code and see what happens when you type “test me”:

[code]Test chamber is a room.

After going south from Test Chamber:
instead say “You are prevented from going to the other chamber.”

Other Chamber is south of Test Chamber. “Oops, you’re in the other chamber after all.”

Test me with “s / look”[/code]

What you want is an “instead” rule. Instead rules prevent the action in question from actually occurring. Here’s how you’d write it, along with a condition that makes sure the rule is only invoked when your boolean is false:

Instead of going south when FightExamined is false: say "Because you are still learning how to play the game, you are being prevented from going south just yet. After the tutorial you are free to move as you please."

Wow, thank you everyone for helping me out! I’ll give this a try. What you say makes sense. I don’t know if I’ll ever get used to this higher-level language. It would be nice to use the nesting of rules, but I see the logic you’re explaining. Thanks again everyone =]

If you’re used to lower-level languages, think of rules as functions. A rulebook is simply a series of functions that run in order until one of them returns a value, at which point that’s the return value for the whole thing. When I7 is compiled to I6, a rulebook literally becomes just a function that calls each rule in order. And a header like “Instead of…” or “After…” is just syntactic sugar for defining a rule and inserting it into a rulebook; you can also write “This is the foobar rule: say ‘Foobar’. The foobar rule is listed in the Instead rules.”

Ah gotcha, thanks! I was thinking of it more as an if statement.

On a related note, I can’t see what is wrong with this:

[code]
NEnterPupilage is a number that varies.

After entering the Pupilage Basement Corridor:
increase NEnterPupilage by 1;
say “NEnterPupilage = [NEnterPupilage]”;[/code]

Assuming the Pupilage Basement Corridor is meant to be a room, then the action you want is “going”. The “Entering” action is only called when the player attempts to enter a supporter or a container. (Attempts to enter a door are converted into a “going” action.)

After going to the Pupilate Basement Corridor: increase NEnterPupilage by 1; say "NEnterPupilage = [NEnterPuplage]"; continue the action.

A couple of additional points:

  • The phrase “to the Pupilate Basement Corridor” is specific to rules involving the “going” action. It tests a local variable called “the room gone to”. “After going to X” is equivalent to saying “After going when the room gone to is X”.
  • Whenever you write an after going rule, you need to add “continue the action” at the end, or else the rule will prevent the room description from displaying when you arrive at the room gone to. (Because the rule to display the room description is in the report going rulebook, and the after rules supercede the report rules unless specifically told not to.)

Ah so simple! Funny how it didn’t error on me, but like so many languages I’m sure it has its own weird logic. Thanks!

It doesn’t error because “entering” is itself an action–it’s the action you’d do to get into an enterable container (ENTER BOX). So “entering the Pupilage Basement Corridor” is a valid description of an action, it’s just not the action that’s happening in this case. (Inform’s default world model makes it pretty hard to get an action of entering a room to succeed, but it’s grammatical.)

Yeah. It’s totally valid to write a rule that triggers “if the player successfully does X”, even when the world model makes it impossible for the player to do X.

I’m well aware of the age of the thread, but I think I have actually something new to add. And well, it might be useful for future readers.

The others already mentioned the issue with After, but I’m missing out on this idea: why not use Before? That’s what I did a few times:

Before going through the blue door:
	If buildingFloor is 0:
		say "You push the door open and step through.."

This also gives me full control to do whatever I want here. In a very easy way too. For example: a small random routine which then… Oh well, might as well share:

Before going through the blue door:
  If a random chance of 2 in 5 succeeds and buildingFloor is 0:
    say "You push the door a little too fast and your hand slips, making you crash into the door <auch>."
  Otherwise:
    say "You push the door open and step through.."

That’s some of the fun code I’m playing with, and which makes me enjoy Inform so much. Makes the whole thing a lot less static, and best of all: gives you full control to do a lot more if needed.

That’s probably the best use case, yeah.