I was about to ask a question, but I managed to solve it, so I thought i’d post the answer to help others.
I have two clocks in my game. One is a “clock” and one is a “tide clock”. They are located in different rooms and are totally separate things.
Inform complains when I try to define similar objects eg;
A clock is a thing in Hardy Street.
The tide clock is scenery in the boathouse.
How do I get around this? I need more than one clock.
Solution: Make a new kind of thing, clock. I did:
The boathouse is a room.
Hardy street is a room.
Hardy Street is north of the boathouse.
A clock is a kind of thing. A clock is scenery.
The Tide clock is a clock in the boathouse.
The Grandfather clock is a clock in Hardy street.
Or, define one of them as being the tide_clock and being privately named.
I’ve said this quite recently and I’ll say it again, I do like how I7 lets you do things your way. There’s always an alternative. I’d go the tide_clock route, but I get the feeling your solution is more in keeping with the spirit of I7.
EDIT - Mind, I was under the impression I7 wouldn’t complain about something like this. Maybe it doesn’t complain if they’re defined under different headings? Doesn’t matter much, I guess.
Inform lets you refer to objects in the source code by shortened versions of their name–if you define an object called “the really enormously huge mountain” you can refer to it later by “the mountain.”
This means that if you put things in the order vdu23 did in the original post, then Inform won’t complain–first it defines the “clock” and then it defines the “tide clock.” But if you define the “tide clock” first, then when you try to define the “clock,” Inform thinks you’re trying to refer to the “tide clock” by using part of its name, and complains that you’re trying to put the same thing in two places. (At least, within one heading–I haven’t tested it with multiple headings.)
For reasons like this it’s a good idea to do give the objects names like “grandfather clock” and “tide clock” anyway, as vdu did–it makes it much easier to make sure that you’re referring to the object you mean to when you talk about it in your source code.
Yeah, it didn’t really contribute to the solution.
Just to reiterate the usual solution which has only been implied earlier: Things need unique names in the source text, but they can be called anything in the game world. The game world name is set by default to be the same as in the source text but it can be changed by setting the printed name property:
The grandfather clock is a thing in Hardy Street. The printed name of the grandfather clock is "clock".
The tide clock is scenery in the boathouse. The printed name of the tide clock is "clock".
(I gave them both the same printed name just to underline the point, only the first one is necessary for the original problem.)
I think using a kind is a fine way to do this. Especially if you specify “Understand “clock” as a clock.” Inform will disambiguate if they are both in scope and the player does something to a clock. The problem with having a “clock” and a “tide clock” is Inform cannot disambiguate them. “Which do you mean, the clock or the tide clock?” Responding “clock” to this will disambiguate again and the player cannot choose the one without an adjective.
This is also handy because you can write “Now the shown_time of every clock is “12:15”.” if you have a text field called “shown_time” associated with every clock so the time can change. Perhaps not useful here since you can just use the game time of day, but helpful if you’ve got a lot of things that you might need to update all at once.