Issues with room properties

Trying to change the property of a room based on whether you’ve done a certain action in that room or not. But my code is making it so that if you do the action in one room, all rooms of that type flip to having the property. So this code:

"test"

a room can be known. a room is usually not known.

a zone is a kind of room. The description of a zone is "[zonedesc].".

lab is a zone.
kitchen is a zone. kitchen is north of lab.

carry out jumping:
	if the location is a zone:
		now the location is known.

To say zonedesc:
	if the room is known:
		say "You've been here before. It's the same as last time";
	otherwise:
		say "It's just a normal room"

is producing this outcome:

test
An Interactive Fiction
Release 1 / Serial number 260328 / Inform 7 v10.1.2 / D

lab
It's just a normal room.

>jump
You jump on the spot.

>l
lab
You've been here before. It's the same as last time.

>n

kitchen
You've been here before. It's the same as last time.

Any help on making this work the way it’s supposed to is appreciated!

2 Likes

Just change the second line here to ‘if the location is known’.

‘the location’ is shorthand for ‘the location of the player’, which Inform understands to be where you are. ‘The room’ here is being interpreted as something else because that ain’t the parlance.

-Wade

3 Likes

I’m not sure why your example compiles at all, but I do know how to fix it: instead of ‘if the room is known’, it needs to be ‘if the location is known’:

a room can be known. a room is usually not known.

a zone is a kind of room. The description of a zone is "[zonedesc].".

lab is a zone.
kitchen is a zone. kitchen is north of lab.

carry out jumping:
	if the location is a zone:
		now the location is known.

To say zonedesc:
	if the location is known:
		say "You've been here before. It's the same as last time";
	otherwise:
		say "It's just a normal room"

test jump with "jump/l/n"

“the room” I guess meant, “the class ‘room’”? Or maybe effectively it mean ‘a random room’? Someone else is going to have to chime in on that one :wink:

(Edit: Timing!)

3 Likes

Thank you both! I’m glad it was such a simple fix!

1 Like

Based on the following code:

The lab starts off with the description "You've been here before. It's the same as last time.", which means that it's likely the code is treating it as any room being known.

[!note]- Edit
I tested it also with @alyshkalia’s original code (but with kitchen starting out as known) and the same thing happens.

1 Like

Inform seems to wing it sometimes when you refer to a kind as if it is a specific thing. If there’s a combination of default property and an instance of a kind with a property, it will come up with something. At least, that’s how it looks.

"test"

lab is a room.

a hat is a kind of thing.
a hat can be tall.
a hat is usually tall.
the derby is a hat.
the trillby is a hat.
the trillby is not tall.

instead of jumping:
	say "[Bazinga]";
	
to say Bazinga:
	if the hat is tall, say "Bazinga!"

I don’t see this as a beneficial thing. Perhaps it is a bug or else I am just not seeing the use case

1 Like

Inform treats if the room is known to mean if any room is known. To be precise, the phrase if A is B is parsed as “if there exists an object that matches both A and B”, and A and B are “descriptions of objects”. The name of a kind matches any object of that kind, so it’s always best to think of it as having an implicit any in front.

I kind of doubt there’s any bug here that can be fixed. You could probably make the compiler complain unless you explicitly write “any”, but I think that would break a bajillion cases where it really doesn’t make sense (from a human standpoint) to write “any”, but the compiler sees it as just another of the same thing.

Remember, Inform 7 is not “coding in English”. It’s “a programming language that utilizes linguistic concepts and kind of looks like English”. The compiler doesn’t actually understand English.

3 Likes

That’s interesting! I don’t think that construction made the documentation (though it could’ve), but I’m glad it isn’t a mystery.

Yeah, in Inform, “a” and “the” are almost always equivalent[1]. So “if the room is known” is equivalent to “if a room is known”.

Personally, I think “the” should not be allowed there, because this is a very common type of mistake! And it seldom helps with code readability, which is the reason to allow unintuitive phrasings like this.


  1. In declarative code, not in text substitutions. “[A noun]” and “[The noun]” are different. ↩︎

3 Likes

I have a suspicion that disallowing the in that position would reveal that, in fact, there are cases where you really do want to write the in that position. But you’d have to actually do it to know.

1 Like

It’s possible, but honestly I don’t think I’ve ever intentionally used “the [kind]” to mean “a [kind]”. Consider this a challenge to find any real-world case where that usage helps readability! :face_with_tongue:

1 Like

I went ahead and filed it as a possible improvement! Feel free to comment there for Graham:

1 Like

Well, the thing is, you use descriptions in all sorts of places throughout Inform, and while it might indeed be true that the in an if statement is almost always a mistake, there might be other uses of descriptions where it’s the most sensible choice.

Or there might not be. The main point is that it may not be trivial for you as a human to realize that “this is a description” everywhere descriptions are used. The easiest way to know would be to modify the compiler to forbid the in this position and then run it on a whole lot of pre-existing code to see if previously-valid constructs are suddenly rejected.

1 Like

No disagreement there! I think that would be a good next step.

2 Likes

I’ve looked, and there really aren’t. The word “the” directly before a kind name is, in practice, 100% likely to be a mistake. When in a description, at least.

There are a few phrases that are constructed this way. “The (kind) produced by (rule)”, for example. But these are not descriptions, although they may look like descriptions.

3 Likes