Contradictory...??

I am at my wit’s end with this. I have tweaked the descriptions in every way I can conceive, and I still get an error message saying that I am setting the same property but with a different outcome. These are two different objects. Can anyone tell me why the descriptions are returning error messages, and what I need to change about them—

A narrow blue door is north of Room 217.  The description is "It's rather narrow and blue, which doesn't fit the dull pink paint of the walls.  In fact, the door seems not to even fit the wall nicely, as it appears to have signs of patching around it, as if it were hurriedly put in.  It has a rather generic knob. [closbath][line break]".  It is a door and scenery.  It is south of Room 215.  It is closed and locked.

And —

A shiny knob is scenery.  The description is "So generic.  You have one at home, and like the one at home, it has a tiny hole in the center."  Understand "doorknob/handle" or "door knob/handle" or "shiny door knob/handle" as the shiny knob.

Thanks.

Putting those lines together in a game (with definitions of room 215 and room 217) compiles without error. So the problem is more complicated than that.

What is the error message?

Sometimes when you mention two objects in a phrase, and then refer to one with “it”, Inform will not understand which one you mean or assume the wrong one.

Oftentimes, you just need to be Dick and Jane/Ernest Hemingway pedantic. This is at least a troubleshooting step to take; don’t give Inform the chance to get confused.

A narrow blue door is a lockable, locked door. Narrow blue door is north of Room 217 and south of room 215.  The description of narrow blue door is "It's rather narrow and blue, which doesn't fit the dull pink paint of the walls.  In fact, the door seems not to even fit the wall nicely, as it appears to have signs of patching around it, as if it were hurriedly put in.  It has a rather generic knob. [closbath][line break]".  Narrow blue door is scenery.

Another trick is to separate each phrase so Inform can point out where it’s specifically having the problem.

[code]A narrow blue door is a door.

Narrow blue door is north of Room 217 and south of Room 215.

The description of narrow blue door is […][/code]

Zarf,
The error message is along the lines of “In one sentence, you wrote ‘The description is “It’s rather narrow and blue…[closbath][line break]”’. Yet in another sentence, you wrote ‘The description is “So generic. You have one at home…tiny hole in the center.”’ To me, this looks like a contradiction, because you are setting the same property for two different things, with the same outcome.”
HanonO They were in two different paragraphs, but I think I spotted my error just by re-reading what I posted here. I should have said ‘A shiny knob is here. It is scenery.’ I forgot to mention that it was ‘here’, and I had placed the phrase in a position after I discussed the room exits(doors) and before where I normally put rules about exiting the room(always last in the segments about rooms). When I corrected the phrase about the doorknob, and moved it into the section about objects in the room, it compiled without a hitch. Of course, I’m going to see if it plays correctly. Thank you both for the tips.

I’m always leery about “A frob is here.” because of the exact kind of problems you mention.

Random question - You are making the knob scenery, ostensibly so the parser won’t mention it in the room description. Is there a reason you’re not making it part of the door, which would do this automatically? Incorporated things do not show up in the room description.

Incorporating the knob in the door is the easy way to make sure it’s in-scope on both sides of the door. If you want it visible on only one side, it’s fine to have a separate scenery object.

Just now read the last two postings–the shiny door knob is a crucial part of a puzzle–it’s part of a generic interior door which has the lock mechanism on one side, and only the blank knob on the other–except for the tiny round hole, and the solution is, as many of us have observed as kids, is…well, you know it or you don’t know it. Let’s just say that that door was installed in a very crucial location, very incongruously(it’s not a bathroom door, though it previously was). Though there are a number of such doors in the game, which can be locked and unlocked keylessly(provided you are on the correct side), this one would have you locked out. The ‘key’ for the door works only on the side with the tiny hole–I wrote some rules re-directing any ‘unlock door with’ commands to the knob–so the knob, not the door, really has the ‘key’, the door simply unlocking when the knob is unlocked. The door locks/unlocks keylessly on the other side, and if this is attempted on the side with the tiny hole, a Check rule cancels it. You’ll have to have the ‘key’, and an Instead rule prevents the player from being able to re-lock the door with this ‘key’(in essence, he would be ‘picking the lock’ to unlock it). I made the knob separate from the door so it would not be accessible from the ‘keyless lock’ side. Though if the player solves the problem from the ‘tiny hole’ side, s/he might not notice the difference, re-locking the door would not be necessary, but having both knobs visible from either side might seem rather cock-eyed(even if the shiny knob is scenery and the player might not know to look for it when he is on the other side before unlocking the door(it’s a room he’ll have to get back into…)). One possible issue is the fact that there are several ‘keylessly un-/locked’ doors in the game, but I do not describe the outer sides having tiny holes in the knobs–but I think I resolve this by making the one crucial door very incongruously placed, being neither to a bathroom nor to a closet–oddly, when the player encounters it, it’s locked, with no keyhole. Thanks for the help!