Is there a debugging command to change the kind of an object? Like if I have an ice cube that can be frozen or melted and it’s currently frozen, is there some command I can use to change it to melted during play? Or would I need to create my own mini de-bugging code?
Technically that’s not changing the kind, but changing the property. “Kind” is the sort of thing that a thing is, like “room” or “thing,” and you can’t change that, but properties can be changed all the time.
Anyhow, I think it’s definitely simplest to make mini-debugging code:
[code]Florping is an action applying to nothing. Understand “florp” as florping.
Instead of florping:
say “Ice cube now is melted.”;
now the ice cube is melted.[/code]
Okay, so as far as the coding goes, I get. But apparently I have had a misconception all this time about kinds vs properties. So, if I have:
A cubestat is a kind of thing. A cubestat can be frozen or melted. A cubestat is usually melted.
An ice cube is a frozen cubestat.If I understand you correctly, the ice cube is a KIND of cubestat and the cubestat is a KIND of thing. Whether the cube is melted or frozen is the property of the cube. Right?
I’ve read through http://dhayton.haverford.edu/wp-content/uploads/Inform-manuals/WI_4_14.html (and other sections of Chapter 4) several times, but the examples are fairly simple and easy to follow, so when I try doing something myself that’s a little more complex, I start getting confused.
Yeah, you can probably simplify this a whole lot by using a property, which is nowhere near as fiddly as a kind.
I tend think of properties as “adjectives”.
You use a kind when you want multiples of a type that share the same properties.
[code]An ice cube is a kind of thing. An ice cube can be melted. [“can be” means it won’t be unless you specify it is.]
Before printing the name of a melted ice cube, say "melted ".
There are 10 ice cubes in the refrigerator tray.
Every turn when an ice cube is not enclosed by a cold thing: [“cold” is another property I can give to the refrigerator, the ice chest, the Antarctica location…]
repeat with block running through ice cubes:
if block is not enclosed by a cold thing:
now ice-cube is melted.[/code]
You can use multiple phase properties as well.
An ice cube is a thing carried by the player. The ice cube can be frozen, melting, or melted. The ice cube is frozen.See the Manual: inform7.com/learn/man/WI_4_7.html
Cubestat is a kind of thing. Ice cube is an instance of cubestat. (I don’t know if the manual uses the term “instance”, but that’s the usual programming jargon.)
A kind is a class of many similar instances.
Okay, so if I were to build a tree:
[u]Things[/u]
containers supporters doors rooms
[u]Kinds[/u]
box (i.e. The box is a kind of container) table shipdoor
[u]Instances[/u]
crate (i.e. The crate is a box). endtable, nightstand captain's door, prison bars Ballroom, the West Wing
[u]Properties[/u]
open, closed fixed in place locked, unlocked
Right? Or… no?
Thank for everyone’s patience with me, by the way. Every time I think I’ve got a decent grasp on Inform, something else comes along to pretty much tell me, “Haha! Guess again.”
Yeah, the learning curve of Inform 7 is a long series of “Oh this is so easy” “Oh, this is complicated” “WHY DOES INFORM HATE ME SO MUCH” “Oh, I can make it do anything…”
1 Like
Things, containers, supporters, doors, and rooms are all kinds defined by the standard rules. If you write “An ice cube is a kind of thing” then you are creating a new kind for your game.
You can look at the standard rules, in fact, and see the declarations:
A thing is a kind. [2]
A direction is a kind. [3]
A door is a kind of thing. [4]
A container is a kind of thing. [5]
A supporter is a kind of thing. [6]And so on.
And you can keep going with subkinds as long as you want. Given that a thing is a kind, you could do:
A body part is a kind of thing. A digit is a kind of body part. A finger is a kind of digit. A thumb is a kind of finger.If you then write something like:
Tom is a thumb.then Tom will automatically be an instance of the kinds thumb, finger, digit, body part, and thing.
The diagram on page 16 of http://inform7.com/sources/src/stdrules/Woven/Appendix-A.pdf has always been my understanding of the hierarchy, I think. At least, based on what I always see when I look at the Kinds Index under the Index tab.
So the first row is “objects”, which is basically all-encompassing. The second row is room, direction, thing, region. So the second row are Kinds? Or would it be more helpful to interpret the second row as kinds of objects, while the third row are kinds of things? Then the left half of the fourth row is kinds of containers and the right half is kinds of persons. Then the fifth row is properties of their respected things. And the sixth row is only a property of something that’s openable. Then if I wanted to include instances, those would be specifically named objects, like if I wrote “A teacup is a container.” then the teacup would be an instance of a container.
So it’s not so much that “kinds” are a category all themselves, it’s more like “kinds” are the linking arrows on the diagram.
Yes? No? Please tell me I get it now. My head hurts.
The boxes are the kinds, the arrows are the “is-a” relationship (a thing is an object, a container is a thing).
The solid boxes in that diagrams are the kinds.
Okay, that helps a lot, I think. So then to kind of put together what both zarf and matt were saying (creating new kinds and going on with subkinds), I can create a new kind at any level of the hierarchy. Like if I wanted to create a new kind on the third level, I could say “Australia is a kind of region” or “wrongly is a kind of direction”. Or if I wanted to create a new kind on the second level, I could say “A USB stick is a kind of object.”
Then if I wanted to give those kinds specific properties I could put “Australia can be rainy or sunny.” Or I could give the USB stick several specific properties (carrying capacity, attached/detached, long/short), and then create a bunch of instances of the USB stick kind:
A USB stick is a kind of object.
A USB stick can have a carrying capacity. A USB stick can be attached or detached. A USB stick is usually detached. A USB stick can be long or short.
A K-Bus is a USB stick.
A LIN-Bus is a USB stick. The LIN-Bus is attached.
A thumb drive is a USB stick.And if I wanted to create subkinds of the USB stick:
A flasher is a kind of USB stick. A flasher is long.
A Sonic Screwdriver is a flasher.Don’t think about it too hard. Basically you are making singular things and multiple kinds of things that have the same properties.
You can think of a “thing” as unique and a “kind of thing” as a template to create lots of similar things with all the properties you’ve given the kind, though each instance of the kind can be customized.
Everything you create that isn’t a room, a direction, or a region is a thing or a kind of thing. The sub-types container, supporter, door, person, backdrop, and device are all kinds of thing each having similar properties - a container is “usually openable” and Inform has built in rules that simulate that interaction. If I want to make a tent for the player to sleep in, that’s essentially a container that can be opened and closed, so:
your tent is a container. [I know that by default, containers are openable, closed, and portable. But I do have to make it enterable.]
your tent is enterable. [Most tents can be carried around, but if I don't want the player to do this as if it were staked to the ground...]
your tent is fixed in place.
You can make kinds of the other proto-objects, such as if you create a vehicle and want to restrict it to specific locations:
A road is a kind of room. Main Street is a road. Eastern Highway is a road. It is east of Main Street.
Then you can write rules to prevent an automobile vehicle from entering non-road rooms.
You can allow kinds of things and singular things to have properties that they don’t normally have. I can make a thing that is not a container “openable”, but I have to tell Inform that’s allowed first to let it have that property:
A book is a thing. A book can be openable. A book can be open. A book is openable.
Adding the “openable” and “can be open” property to a thing will tell Inform to recognize and respond to “open book” and “close book” but it won’t contain things because it’s not a container.
Where you would use “kind of thing” is when you are going to make a whole library of books that all work the same way. I’m making a kind of thing with its own set of properties and rules for interaction similar to the high level “container” or “supporter” archetypes.
A book is a kind of thing. A book can be openable. A book is openable. A book can be open.
Now every book I make will have will have the potential to be opened and I can write rules based on a books “open” property.
A book called War and Peace is in library. Fifty Shades of Gray is a book in library.[code]Before examining a book:
if the noun is closed:
say “You’ve not learned the X-Ray vision spell yet…”;
try opening the noun.
Check examining a book:
if the noun is closed:
say “The book is closed.” instead.[/code]
I can give the book more properties - say in a fancy magic library there are books with those lockable straps:
[rant=example][code]Library is a room.
A book is a kind of thing. A book can be openable. A book is openable. A book can be open.
A book can be lockable. A book can be locked.
Check examining a book:
if the noun is not open:
say “It’s [the noun]. There are pages inside.” instead.
A book called War and Peace is in Library. The description is “It’s really long.”
The Tome of Ancient Magick is a book in Library. It is lockable and locked. The description is “Oo, Ancient Magick!”.
The Librarian’s Key is in Library. It unlocks Tome of Ancient Magick.[/code]
[/rant]
TL;DR: Pretty much everything is a thing. You can make a “kind of thing” which is a prototype to make multiples of similar things.
Although I might quibble with a couple of your examples based on best practices (I would be more inclined to make Australia a specific instance of a region rather than a kind of region; and it would probably be better to make a USB stick a kind of thing rather than a kind of object), you have otherwise pretty much nailed it.
How about:
The SEast is a kind of region. A Seast can be humid, arid, or cold.
Australia is a SEast. Australia is humid.
New Zealand is a Seast. New Zealand is cold.
Papua New Guinea is a Seast. Papua New Guinea is arid.
Philippines is a Seast.Would that be a more sensible way to write it? Also, I intentionally left Philippines without a property definition because I had a question about it. If I don’t put “A Seast is usually [whatever]”, and I don’t define it, does it automatically receive the first SEast property that’s mentioned? That’s what it seemed like when I tried to code it.
Probably. I mean, obviously, given enough time and enough typewriters, someone will figure out a situation where it is appropriate to define Australia as “a kind of region”. But your SEast example is more in line with how regions actually get used. There’s a more intuitive sense to it.
I think that is correct for properties with 3 or more values. When you define binary properties, unspecified objects usually default to the second choice. So for example, if you declared “a thing can be hot”, then everything would default to “not hot” unless you specify otherwise. Likewise, if you declared “a thing can be hot or cold”, then the default would be “cold”. But for properties with 3 or more choices, the default is usually the 1st choice. If you declare “a thing can be hot, cold, or just right”, the default would be “hot”. Couldn’t tell you the reasoning behind that, though.
I know there’s a little-known (?) trick where you can define properties with sequential states where you can say something like “Increment the temperature property of the iron” or “Now the temperature property is the next one”. I don’t remember how it’s exactly worded, but instead of writing “if the iron is hot, now the iron is very hot. if the iron is very hot, now the iron is scalding hot”… you arrange your properties in sequential order “The iron can be cold, warm, moderately warm, hot, very hot, scalding hot, or white hot”. Then you can do it in reverse also “decrement the temperature property of the iron” (“Now the temperature of the iron is the previous one” ??)
In the case of a property with a large array, it would make sense for the default to be the first one.
that’s awesome. learn something new every day. this is definitely something i’m going to have to play with.
I wish I could find the place where I read about incrementing properties. Chapter 4 in the manual is where all this is explained in detail.