Can't examine things or containers (run-time error).

Hey,

resently i have been dealing with this very weird bug; everytime i try to examine “things” or “containers” i get the following error:

*** Run-time problem P10: Since the Wooden Chest is not allowed the property "item condition 3", it is against the rules to try to use it.

but, when i examine something like an item, which is a “kind of a thing” defined by me as such:

An item is a kind of thing.

i get no errors and the correct description is shown.

i went through my code to see if i for some reason made it against the rules to use it, but i can’t seem to find it and i have no idea what item condition 3 is?

any help? :slight_smile:

You didn’t happen to recently reinstall Inform 7 so that you possibly have an older copy of the Standard Rules lying around that Inform may be conflicting with, by any chance?

Nope, never reinstalled it :slight_smile:

I’m not sure exactly what you did, but here’s some code that reproduces the problem:

[code]An item is a kind of thing. An item can be big, medium, or little. An item can be heavy, moderate, or light. An item can be notable, so-so, or insignificant.

The description of a thing is usually “[if the item described is notable]This is very important![otherwise if the item described is insignificant]Eh, whatever.[otherwise]Possibly intriguing.”

Lab is a room. A rock is in the Lab. A gewgaw is an insignificant item in the Lab.[/code]

“x gewgaw” yields “Eh, whatever.” “x rock” gives you the run-time error.

What’s going on here: When you say “An item can be big, medium, or little” you’re creating a property that items can have. If you don’t give it a name (like “An item can be big, medium, or little (this is its size property)”), Inform calls it “item condition.” If you create three of these, Inform calls them “item condition,” “item condition 2,” and “item condition 3.” See §4.10 of Writing with Inform.

Now if you try to test one of these properties on a thing that’s not an item, Inform gets unhappy. In this case, when we “x rock,” when Inform goes to print the description of the rock it sees a text substitution that asks it to check whether the rock is notable, which is a possible value of the item condition 3 property. But the rock isn’t an item, so it doesn’t have an item condition 3 property! So Inform complains.

So I suspect what happened is this: You defined “item” as a kind and you defined some properties that apply to items. Then somewhere in your examining code you tried to use one of these properties regardless of whether the noun is an item. Either rewrite that rule so it applies only to items, or make sure that property applies to all things.

Thanks (fixed it)! looked through my “examine” code, did not think that doing something to “items” which we’re a “kind of thing” would mess up “things” :slight_smile:

MrCallaghan,

It shouldn’t have. The point being made above is that some routine is (probably) trying to apply logic meant for items to something that is not an item. Notice in that matt w’s example, it’s “the description of a thing is usually …” that’s causing the problem, to illustrate a possible cause of the error you’re seeing. Had he written “the description of an item is usually …” the same would not occur.

Since you haven’t given any information on what you’re trying to do (though it seems like you’re trying to make general changes to the way examining works), you may find it useful to construct kind-specific rules, e.g. a rule for examining an item, another rule for examining a container, and so on for any special kinds you’ve set up. I think in the case of examining, these would have to be carry out rules, and I think maybe you would also have to manually end processing of the carry out rulebook at the end of your rules with “rule succeeds” or “rule fails” (whichever is appropriate) to prevent the Standard Rules for examining from also being executed.

If the above doesn’t make any sense, see the built-in documentation on action processing rules. If you’re still stuck, please feel free to post back, but it would be helpful if you provided your source code for further diagnosis.