CODEWITHSUNDEEP
inform7
Prince_of_Oriel
Prince_of_Oriel

Reputation: 25

'If' arguments involving the player in Inform 7 causing contradictions

I'm trying to make a game in Inform 7 and have encountered a major problem, the answer to which apparently can't be found with a google search.

I'm using an 'if' argument to change certain situations based on what room the player is in. Instead of seeing what I have written as an 'if' argument, it has assumed 'If the player' to be an entity of itself.

This is the error message:

You wrote 'If the player is in Reception' , but also 'If the player is in the Corner Table' : that seems to be saying that the same object (If the player) must be in two different places (Reception and Corner Table). This looks like a contradiction.

This is my code in both places:

If the player is in the Corner Table;
    Understand the command "leave" or "exit" as something new.
    Understand "leave" or "exit" as northwest.

If the player is in Reception;
    Understand "key" as the Janitor's Key.

So, uh... can anybody help me?

Upvotes: 2

Views: 516

Answers (1)

JJJ
JJJ

Reputation: 33153

There are several issues with the code you posted:

  • You can't have an if phrase out of context. You must write a rule for when the if phrase is considered.
  • Conversely, you can't use understand phrases in context. More specifically, if ...: understand "..." as ... isn't possible. Understand phrases must always be standalone.
  • The if phrases should end in a colon, not a semicolon.
  • "northwest" by itself is not an action; "going northwest" is.

You apparently want this instead:

Instead of exiting when the location is the Corner Table:
    try going northwest.

This redirects the exiting action (which includes the commands "leave" and "exit") to the going northwest action in that particular room.

For the second if phrase, firstly if you have an object called "Janitor's Key" the game already understands "key" as referring to this object unless you've specifically made the object privately-named. Secondly, why have the game recognize "key" only in one location? Built-in scoping already makes sure that you can't refer to things that are not in the same room as the player.

So if the object is privately-named, and there's a reason why the key should be referred as such only in one location, the code for that is:

Understand "key" as the Janitor's Key when the location is the Reception.

But, as said, this is necessary only in very specific situations and most likely it's best to let the standard library handle it and leave it out altogether.

Upvotes: 1

Related Questions