After many years, I’m dipping my toes back in the IF waters. My addiction was broken way back when following the introduction of Inform 7… the re-learning curve proved steep enough to require more time than I had to dedicate. Jumping back in now, I’ve immediately run into a head-scratcher that must have a simple solution, but one that I can’t figure out.
Is there a way to have duplicate names of different kinds? Specifically:
The South Pier is a room. “This is the description of the South Pier.”
The pier is scenery in the South Pier.
Okay, so the compiler doesn’t like this and thinks we’re trying to put an object inside itself.
What’s the workaround for this? If I want the pier to be scenery (actually to be a backdrop for all the piers in the game) there must be a way to disambiguate it from the name of the room.
The solution is to give them distinctive names in the code and change the name that’s shown to the player to whatever you want.
The South-Pier is a room. "This is the description of the South Pier." The printed name of the South-Pier is "South Pier".
The pier is scenery in the South-Pier.
or
The South Pier is a room. "This is the description of the South Pier."
The background-pier is scenery in the South-Pier. The printed name of background-pier is "pier". Understand "pier" as the background-pier.
Isn’t this simpler? (Untested code, I don’t have Inform 7 handy.)
The South-Pier is a room. "This is the description of the South Pier." The printed name of the South-Pier is "South Pier".
There is a thing called the pier. The pier is scenery. The pier is in South Pier.
I had experimented with that workaround (having found the ‘printed name’ property described in Jim Aiken’s I7 Handbook) and it works fine. But for some reason I thought there might be something more elegant I7 could do in cases like this.
So basically, anything I ever want to examine (scenery, portable item, etc.) can’t have a name that’s also a part of a room’s name? Once it’s in the room’s name, all you can do is access the room’s description via a “look” if you want any description attached to that word?
I’m sure there’s a way to dip into the lower level input and catch the noun before it’s processed (NounDomain rings a bell, but that bell hasn’t been rung in a decade) using some kind of disambiguation routine, but it’s been years since I messed with any of the I6 libraries and I have my hands full just learning the basics right now.
However, it sounds like a nice challenge for writing an extension once I know what I’m doing…
No. The ‘understand’ in Juhana’s code tells the game to recognise ‘pier’ as (possibly referring to) the scenery object, when it’s used in the player’s command. (Normally, the player can’t interact with rooms by referring to their names anyway, though of course you might change this.)
It’s true that you can’t have an object with a code name that is a match for part of an existing object. That’s a normal namespace issue. But this doesn’t have to affect the player at all: using Understand and changing the printed name of the object will mean that, as far as the player is concerned, the object’s name in the code can be totally hidden.
Ah, thanks Maga… now it’s making sense. The understand keyword was what I was not catching. Juhana’s code allows me to keep the clean room naming convention (one of I7’s appealing aspects… no more underscore linked words) and still let you use the words in a room’s name. That’s what I was looking for.
All this new syntax is going to take a bit to get used to. Glad you all started up this forum – much easier than rec.arts.int-fiction ever was!