Comparing properties

Authoring Inform 7
1

I’m trying to create security doors and keycards, so I started with the following definitions:

A seclev is a kind of value. The seclevs are green, yellow, red, and private.

A security door is a kind of door. A security door has a seclev. The seclev of a security door is usually green. A security door is usually closed.

A keycard is a kind of thing. A keycard has a seclev. The seclev of a keycard is usually green.

Creating doors that are security doors and cards that are keycards seems to work fine, but when I try to check to make sure that the player is carrying a high enough level keycard, I can’t seem to get the comparison to work.

If I do this:

Check opening a security door when the player is carrying a keycard:
	if the security door is yellow and the keycard is green:
		say "Access Denied! This door requires a Yellow security card or higher." instead.

I get this error message: ‘security door is yellow’ was okay; ‘the keycard is green’ did not make sense; so I ran out of ideas.

Security door and keycard both have seclevs, so I don’t understand why one is a valid condition but the other isn’t. I’m sure it’s something I’m doing wrong, but I can’t figure out what it is.

As always, any help would be greatly appreciated!

Cheers,
Scott

2 
Check opening a security door when the player is carrying a keycard (called the pass):
	if the security door is yellow and the pass is green:
		say "Access Denied! This door requires a Yellow security card or higher." instead.
1 Like
3

I have some ideas (more guesses) as to why you have to create a named variable for the key card, but I’m not very confident in them, and I wouldn’t want to unintentionally mislead. Plus I admit to an ego that shudders at the thought of being wrong on the internet (can you imagine? Gasp!) :sweat_smile:
That said, my best guess is that it’s to do with specificity of names, and the error is misleading you here. There should be no problem with comparing properties. The security door in your check rule is whichever security door the player is opening, so there’s no ambiguity about objects there. But “keycard” is the name of a kind, so checking if the keycard is green without saying which one makes the condition ambiguous. Naming the keycard carried by the player with a variable like “pass” narrows the condition. You’d think it’d be obvious which one we’re talking about, since the rule only fires if the player actually does carry a keycard, but such are the ways of Inform.

If I’m right, I’m sure there’s someone who can explain that better, but there’s my stab at it.

1 Like
6

I looked at this in 6M62, but I think you may have run into a minor compiler bug. That error message should not be appearing in this case; it seems that the compiler is choking on the word “the” at the start of the second condition. (The condition compiles just fine if the second “the” is removed.)

That said, even when it compiles the logic is probably not what you expect. First, note that the compiler usually treats the words “the” and “a” interchangeably. Second, as BlueAskew points out, a condition on a kind is not specific to any particular instance. For example:

if the keycard is red

compiles with a meaning of “if any keycard anywhere is red,” which is more like the expected translation of:

if a keycard is red

The “called name” functionality as used in BlueAskew’s example is provided to allow reference to situationally-specific instances of a kind. See WWI 8.15 Calling names for details.

FYI, you can use multiple called names at once, which can be useful here:

Check opening a security door (called obstacle) when the player is carrying a keycard (called pass):
	if the seclev of the pass is less than the seclev of the obstacle:
		say "Access Denied! This door requires a [seclev of obstacle] security card or higher." instead.

You might also want to deploy some ease-of-use features:

The printed name of a keycard is usually "[seclev] keycard". Understand the seclev property as describing a keycard.

More information can be found in WWI 17.15 Understanding things by their properties.

EDIT: Note that the behavior for the problem message is the same in 10.1 as in 6M62. Removing the second “the” prevents it.

As an aside to the Mad Scientists’ Club: The declaration:

There is a yellow security door. It is north of Place.

works fine in 6M62 but is rejected by 10.1 with a malformed “saying two things are the same” Problem message. This doesn’t seem like correct behavior in 10.1.

For those still using 6M62, I coincidentally ran into some other 6M62 issues while playing with this scenario. The following declarations are accepted in 6M62, but it appears that the text related to the seclev property is ignored:

There is a security door with a seclev of yellow. [ignores color??]
There is a security door with seclev yellow. [ditto]

In 10.1, the first version now gets a Problem message, and the second version works as expected.

5 Likes
7

Yep, while a human reader can guess that “the security door” means the door the player is currently opening, Inform doesn’t have enough context to figure that out. You’ll instead want to either give them explicit names with “called”, or use “the noun” and “the second noun” to mean the objects involved in the current action.

8

I’m not sure the use of with in noun phrases is ever documented, though we see it used in Revenge of the Fussy Table.

Looks like assertions with “with/having” work, even in kind-creation:

There is a thing with description "foo" and initial appearance "zzz" called foo.
Bar is a thing having matching key foo and description "blorp".
anonymous is a kind of thing with description "".

but not in imperatives or conditionals:

now every thing with description "foo" is nowhere; [won't compile]
if there is a thing with description "foo", say "foo!"; [won't compile]

I think we should probably conclude that it was a bug in 9.3/6M62 that There is a security door with a seclev of yellow. didn’t result in a compiler error.