"SampleError" by Zyzzyva
Laboratory is a room. [The Laboratory can be complicated.]
A complicated device is a thing in the Laboratory.
This runs, and creates a thing with the name “complicated device”. If you comment in the complicated property for the room, though, it fails:
The sentence ‘A complicated device is a thing in the Laboratory’ seems to be telling me that two descriptions, one a form of device and the other of thing, are the same.
It seems odd that a change elsewhere would make this declaration unparseable, but on the other hand it feels a bit sketchy to be naming a thing with the name of a kind. Should I log this as a bug or not?
It’s because “device” is a kind of thing already, so if “complicated” is declared as a property, then Inform assumes “complicated device” means that property applied to that kind of thing.
You can fix it by saying “in the Laboratory is a thing called a complicated device”, though it’s going to be a bit annoying to refer to elsewhere in your source code if you aren’t careful about the name.
Another fix is saying A complicated-device is a thing in the Laboratory. The printed name of the complicated-device is "complicated device". Then you refer to it in your code as the complicated-device, but the player only sees it as complicated device.
Yeah, that makes sense; I guess just my mental model was that “complicated” is attached to the one room only, rather than being a general property that only the Laboratory can actually have. But I suppose the compiler has to be able to figure out a whole bunch of things from a big pile of adjectives, and it doesn’t necessarily know that only the Lab can be complicated when it’s trying to figure out what the device-thing is.
Yeah, properties are a bit odd. It’s not actually allowed for a device to be complicated…but that’s generally something checked at runtime, not at compile-time.
Not sure what you’re trying to do, but if you only have one “complicated” room, there’s really no point to having it as an adjective applicable to multiple things. You can say “If something is in the Laboratory” instead of “If something is in a complicated room.”
Is that not allowed? I think you can declare things can have properties, but it applies to everything.
A device can be complicated. The flywheel is a device. The flywheel is complicated.
Not tested, it’s been a while but I think you can do things like
A book is a kind of thing. A book can be openable. A book is usually openable.
This allows the “open” action for a book, but prevents it from behaving like a container.
It’s somewhat fraught with peril to have identifiers, i.e., the label that identifies objects (or variables or properties or constants or kind names or whatever) within the code contain of or and or an existing kind name or a direction. There are lots of cases where it’ll work just fine… until it doesn’t.
A practice that’s somewhat tedious and does some harm to Inform stories’ readability as English prose is to always make your identifiers something distinctive and unique, e.g.,
ComplicatedDevice is a privately-named thing.
Printed name is "the complicated device".
Understand "complicated", "device" as ComplicatedDevice.
[or `complicated-device` instead of ComplicatedDevice, by choice]
The privately-named means the string “complicateddevice” itself won’t be added to the game’s dictionary as something the player could use to refer to ComplicatedDevice. With the default DICT_WORD_SIZE of 9, “complicat” is what would be added, same as what gets added by “complicated” in Understand "complicated", "device" as ComplicatedDevice so it truly doesn’t matter unless one changes DICT_WORD_SIZE. In the forthcoming v11 (no announced schedule), DICT_WORD_SIZE defaults to 14 when compiling to glulx, so it would matter there.
Also, when you have identifiers with spaces in them, then by default you don’t need the whole identifier to refer to the thing, e.g.,
lab is room.
The complicated device is a thing.
complicated is in lab.
Worse (in my ever-humble opinion), the compiler will silently prioritize creation-assertions within the same section/chapter/part/book/volume to disambiguate these such that reorganizing where your sections are can change the meaning of your code. Use unabbreviated object names will prevent this and force you to always use objects’ full names. But if your objects’ names don’t have spaces, the issue doesn’t come up: you’re automatically forced to use their full names.