Runtime errors while checking for missing descriptions

Authoring Inform 7
1

Browsing Writing in Inform (as one does) I came across section 24.6 which describes a handy way to check for things with missing descriptions:

When play begins (this is the run property checks at the start of play rule):
   repeat with item running through things:
      if description of the item is "":
         say "[item] has no description."

I added it to a game I’m working on, and instantly found a bunch of missing descriptions, but also:

*** Run-time problem P10: Since nothing is not allowed the property “current value”, it is against the rules to try to use it.

This was very odd to me, since all the items in my game have working descriptions when testing them interactively. I spent some time trying to find a minimal test-case, and eventually wound up with this:

Laboratory is a room.

Inside the Laboratory is an unbreakable beaker.
The description of the beaker is
"A chipped beaker labelled '[printed name]'."

When run normally, EXAMINE BEAKER reports “A chipped beaker labelled ‘unbreakable beaker’.” just as I expected. However, when adding the “check for missing descriptions” snippet, at the start of play I get:

*** Run-time problem P11: Although nothing is allowed to have the property “printed name”, no value was ever given, so it can’t now be used.

This particular situation is easy to work around: when the value “noun” is substituted in text, Inform always replaces it with the printed name of the current noun, so we can say:

The description of the beaker is
"A chipped beaker labelled '[noun]'."

…and that works with no runtime error.

However, that wasn’t quite the original situation I encountered. In my game I want to have dials that can be turned to a number, and the dial’s description should tell the player what number it’s turned to:

A dial is a kind of thing.
A dial has a number called the current value.
The current value of a dial is usually 5.
The description of a dial is usually
"The mark is turned to point at [current value].".

Inside the Laboratory is a dial called the brass dial.

Again, this works as I expected (EXAMINE DIAL produces “The mark is turned to point at 5.”) until the “check for missing descriptions” snippet is added, which produces a runtime error when the game begins:

*** Run-time problem P10: Since nothing is not allowed the property “current value”, it is against the rules to try to use it.

Unlike the simpler “printed name” example, this can’t be worked around by referring to the noun. This code:

The description of a dial is usually
"The mark is turned to point at [current value of the noun]".

…results in the same P10 error.

For people who want to play around with alternative approaches, I put all the above examples in a Borogove snippet.

As suggested by Writing with Inform, I have the “check for missing descriptions” snippet in a “not for release” section. As a result, runtime error only appears in debug builds, and the game seems to work properly, so I could ignore the runtime error. However, I worry that I am somehow abusing Inform’s mechanisms in a way that will cause problems later, so I’d like to fix it.

Is there some obvious thing I’m doing wrong? Perhaps descriptions aren’t supposed to have substitutions?

The text of these runtime errors suggests to me that in the “check for missing descriptions” snippet, the phrase “description of the item” is some how referring to the description but forgetting the item it’s attached to. As a result, Inform tries to evaluate phrases like “printed name” and “current value” without an item those properties could be attached to, and throws an error. Is there some way to reassure Inform “hey, we are talking about this item now” so it doesn’t get confused?

1 Like
2

This is definitely a bug in the run-property-checks rule. There’s nothing wrong with the way you’re doing descriptions.

I’m not sure what’s causing the bug specifically. However, if you write the checker rule this way, there is no problem:

When play begins (this is the run property checks at the start of play rule):
	repeat with item running through things:
		if "[description of the item]" is "":
			say "[item] has no description."

The value description of the item should be exactly the same text as "[description of the item]". But the code that handles them is different, and in this case something is going wrong with the first case.

2 Likes
3

This is annoying, because usually it’s better, or at least tidier, to leave off the unnecessary "[ ]" marks. For example, this works fine:

	repeat with item running through things:
		say "[item]: ";
		say the description of the item;
		say line break;

But now there’s at least one case where they’re necessary, so I suppose people will use them forever just in case. :/

1 Like
4

Thank you very much!

Should I file this as an issue on the Inform 7 JIRA?

5

Yes, please, that would be helpful.

6

Ah, this also works and has less punctuation:

	repeat with item running through things:
		if description of the item is empty:
			say "[item] has no description.";

(empty is defined by the Standard Rules for texts, rulebooks, activities, relations, tables, and lists. Not, oddly, for containers and supporters.)

2 Likes
7

Debugging this in 6M62, the root cause seems to be that the value of self is not assigned prior to the check of the description property. Because the description property’s text references the printed name property within a substitution, the value of self must be set in order for the routine called by the text to work correctly.

Here’s another workaround addressing that:

When play begins (this is the run property checks at the start of play rule):
	repeat with item running through self-identified things:
		if description of the item is "":
			say "[item] has no description."

Laboratory is a room.

Inside the Laboratory is an unbreakable beaker.
The description of the beaker is "A chipped beaker labelled '[printed name]'."

To decide whether (O - object) is self-assigned:
	(- (self = {O}) -).

Definition: An object is self-identified if it is self-assigned.

I’ve run into related problems before, and I think that Zed already filed a bug for it.

1 Like
8

I have created [I7-2566] - Jira - thanks for your help!

2 Likes
9

Ah, there was a thread last year on this:

1 Like