Changing default ('usually') properties for parts of objects

Hi,
I have the following toy problem:

The Lab is a room.

A machine is a kind of thing.
A button is a kind of thing. A button can be green or red. A button is usually red.
One button is part of every machine.

A machine_a is a kind of machine.
A machine_b is a kind of machine.
A machine_c is a kind of machine. One button is part of every machine_c. It is usually green.


There is a machine_a in the Lab.
There is a machine_c in the Lab.

Specifically for machine_cs, I would like to override the default assertion that buttons are usually red. Is this possible somehow? The current code creates 2 buttons, green and red.

Possibly related is another case:

After examining a noun:
	let L be the list of buttons which are part of the noun;
	say "[noun] has the following buttons: [L]. ";
	repeat with B running through L: 
		say "[B] is [if B is green]green[otherwise if B is red]red[end if]. ";

The Lab is a room.

A machine is a kind of thing.
A button is a kind of thing. A button can be green or red. A button is usually red.

A button_a is a kind of button.
A button_b is a kind of button.
One button_a is part of every machine.

A machine_a is a kind of machine.
A machine_b is a kind of machine. One button_b is part of every machine_b. It is usually green.
A machine_c is a kind of machine. One button_b is part of every machine_c. It is usually red.


There is a machine_a in the Lab.
There is a machine_b in the Lab.
There is a machine_c in the Lab.


test me with "x machine_a / x machine_b / x machine_c"

>[1] x machine_a
You see nothing special about the machine_a.

machine_a has the following buttons: button_a. button_a is red. 
>[2] x machine_b
You see nothing special about the machine_b.

machine_b has the following buttons: button_b and button_a. button_b is red. button_a is red. 
>[3] x machine_c
You see nothing special about the machine_c.

machine_c has the following buttons: button_b and button_a. button_b is red. button_a is red.

I would like machine_bs to have green button_bs and machine_cs to have red button_bs by default, but it seems the last usually sets the value for all. What is the right way to do this?

Thanks^2!

I’m not sure that you can do exactly what you’re asking for here. When you have an individually defined thing of a kind that has some properly that it “usually” has, you can override it by hand; but that may not be possible with assemblies (things created by “one button is part of every machine” and the like).

I might be wrong about that, though.

In any case, one thing I would try is changing the colors you want at the When play begins stage. So if you’ve got “a button is usually red” you can add:

When play begins:
	repeat with M running through machine_cs:
		now every button incorporated by M is red.

(That’s if you go with one kind of button.)

I haven’t tested this so I’m not sure it works!

1 Like

I think a kind can only have one default value. You would either need to create a number of different button kinds with different default values for different kinds of machines, or systematically set the property for a subgroup of a kind when play begins, as Matt suggests.

The following works, for example:

When play begins:
	Now every button which is part of a machine_c is green.
2 Likes

Alternately, would it work to say

A green button_b is part of every machine_b.

(My Inform install just gave me an “abject failure” error so I couldn’t check.

1 Like

So long as you define button_b as a new sub-kind of button:

A button_b is a kind of button.
A green button_b is part of every machine_b.

However, I think perhaps you meant

A green button is part of every machine_b.

which works neatly without subclassing.

A green button is part of every machine_b.
A red button is part of every machine which is not a machine_b.

looks like it should take care neatly of all cases, but although it compiles, unexpectedly and disappointingly it gives a red button to every machine, including ‘machine_b’ s. (Plus the green button to ‘machine_b’ s) Which does look rather like a bug, since the ‘which is not…’ phrase is compiling but doing nothing.

The only way I have found to make this work is to define a sub-kind for machines to be created with green buttons and another for machines to be created with red buttons:

A red_machine is a kind of machine.
A green_machine is a kind of machine.

A machine_a is a kind of red_machine. 
A machine_b is a kind of green_machine.
A machine_c is a kind of red_machine. 

A green button is part of every green_machine.
A red button is part of every red_machine.
1 Like