Awkward name clash?

I have two separate objects with unique names, in two separate rooms - but Inform sees this as a conflict. Here’s the error;

Problem. You wrote ‘The deep forest leaves are scenery in The Deep Forest’ , but also ‘The pile of sticks and leaves is scenery in The Bottom of the Hole’ : that seems to be saying that the same object (deep forest leaves) must be in two different places (Deep Forest and Bottom of the Hole). This looks like a contradiction.

I actually don’t understand the logic behind why it thinks they’re the same, if I knew I might try and avoid it. How do you commonly work around a problem like this?

I believe it is because your Thing is “deep forest leaves” and your Location is “The Deep Forest”. The actual conflict is between a thing and a room. Maybe change the Thing’s name to something else, maybe more descriptive?

If I’m wrong, someone will follow-up and let us know!

If you absolutely want the Thing’s name to be “deep forest leaves”, you can do a little trick like this:

```some deep_forest_leaves are scenery in The Deep Forest. understand "deep","forest","leaf","leaves" as the deep_forest_leaves. the printed name of the deep_forest_leaves is "deep forest leaves".```

There are a few ways to handle this. You could also write

A thing called the pile of sticks and leaves is scenery in The Bottom of the Hole.

You can see the problem by compiling this:

```The Bottom of the Hole is a room. The pile of sticks and leaves is scenery in The Bottom of the Hole.```

and looking at the Map section of the Index. Because of the “and,” Inform thinks that you’re trying to create one piece of scener called “the pile of sticks” and another called"leaves"! Then since you’ve already defined “The deep forest leaves,” it thinks “leaves” is meant to refer to the deep forest leaves, and you get the name clash.

zarf’s solution with “called” will ensure that you create one thing called “the pile of sticks and leaves,” instead of two. That should resolve the namespace clash. As MTW suggested, you can also give things funny internal names and use the printed name property and Understand statements to get them to behave the way you want.

Note that if you use the “unambiguous internal names overridden with Understand lines” solution, it’s best to make the thing privately-named (which means no default Understand lines will be created for it).

I disagree. Don’t bother with privately-named.

Hahah, you guys are right - matt w’s breakdown showed the problem, it indeed was the “and”. It’s like the old Panda joke - eats shoots and leaves

zarf’s solution worked perfectly And MTW I will keep the “the printed name of the…” solution on hand, I think that may come in handy some time, seeing as all object names are global… I’m going to run into clashes with similar objects that exist in different locations; I like to make a lot of scenery objects to give the player things to examine after reading the room description.

Worst case scenario, you can always fall back to "Frob is a room. The printed name of frob is “Elaborate Location West of the House and Containing Words You Shouldn’t Use”.

Yes exactly I’m glad this option exists.