ok, just going to throw all my questions in here instead

Another way is to specify the player’s stuff.

A body is a kind of thing. A body is part of every person.
my body is a body. it is part of the player. The printed name of my body is "your body". 
A head is a kind of thing. A head is part of every body.
my head is a head. It is part of the player. The printed name of my head is "your head".[/code]

A nose is a kind of thing. A nose is part of every head. 

Making the nose a part of the head will get you "John's head's nose" if you want automatic naming. 
I think you can say:

[code]When play begins: now the printed name of a random nose enclosed by John's head is "John's nose".

This way could lie madness, though, if your game is a cyberpunk Mr. Potato Head simulation!

Hi folks, can someone please do me a favour and clarify the difference between “enclosure” and “incorporate” in this context? I think enclose means and object is made a child of another and incorporate means make the values part of the existing object, but i’m just not sure.

And yes, it’s almost a MR Potato-head situation. THe idea was that unlike other games where you just level up with XP and apply perks, you engage other cyborgs/droids/people/etc… in battle and “take” parts from fallen enemies to increase your level and stats. So something like “left arm” may have a cannon so you get a damage buff and you can take it off a fallen NPC.

Combat system was going to be next after this, I had imagined it was basically a scene with a while loop and a truth state. But I wanted to obviously get the player trading component in place first.

But to your point matt W, the approach of nestling the values inside larger objects so I could swap objects at once was what I hoped for after you mentioned it could not be done generically based on a value/value approach in my other thread.

Relations shouldn’t be confused with inheritance. Relations are a yes-no answer to the question “are these connected by the [name] relation?”. The answer is either a boolean computed as part of a relation, or a stored boolean (a flag in a table). The practical difference isn’t always apparent and generally shouldn’t matter.

The enclosure relation ("[x] encloses [y]") means an object is inside another. If x is in y and y is in z, z encloses both x and y. The depth of nesting doesn’t matter.

The incorporation relation is more straightforward. When you declare x part of y, y is moved inside x and then the incorporation relation is set to true.

For the official documentation of this, “enclosure” is explained in Writing with Inform §3.25;

The other relations are explained in a bit more detail in Writing with Inform §13.4:

You could do this to get the names right.

A body is part of every person.
A head is part of every person.
A nose is part of every person.

When play begins:
	repeat with X running through people:
		let N be a random nose part of X;
		let H be a random head part of X;
		let B be a random body part of X;
		now N is part of H;
		now H is part of B.

thanks guys, given me a lot of ideas to play with, i’m going to tinker with them and see which one works for what I need.