Printing items by property

Authoring Inform 7
1

I wanted to add a feature for one of my games where, at the end, it listed certain items by a specific property.

I don’t want to get into the details of that code, but my major roadblock/question was: can I do this without writing code that mostly copy and pastes itself?

The example below is a very cut down version of the above.

Saying (xyz of) seems like the more elegant way to do things. It would allow me to add, say “xlarge,” and not type in any more code. If it worked. But I can’t get it to. And the reason Inform gives, makes sense.

It would be acceptable to use the smalls/larges/mediums code (e.g. one “to say” per size property), but my example may have 10 or so properties, and I suspect I’m missing a way to generalize.

I’m using 6g.

[code]“failed sizeprop try” by Andrew Schultz

a thing can be small, medium or large (this is the size property).

McDonald’s is a room.

the shake is a small thing in McDonald’s.

the big mac is a large thing in McDonald’s.

the fries are a medium thing in McDonald’s.

to say xyz of (abc - a size):
repeat with th running through things:
if th is abc, say “[th] is [abc].”;

to say smalls:
say “[list of small things].”

to say mediums:
say “[list of medium things].”

to say larges:
say “[list of large things].”

every turn:
say “[one of][smalls][or][mediums][or][larges][cycling].”;
say “Above shows how I want to do things. Of course, the user will have control, and there’ll be no arbitrary cycling, but this is for demonstration purposes. The code below seems more elegant and flexible, but it gives a runtime error.”;
say “[one of][xyz of small][or][xyz of medium][or][xyz of large][cycling].”;[/code]

Thanks for any and all help!

2

Well, you can do what you have here if you make size into a kind of value instead of defining it directly as a property:

[code]size is a kind of value. The sizes are small, medium, and large.

a thing has a size.

McDonald’s is a room.

the shake is a small thing in McDonald’s.

the big mac is a large thing in McDonald’s.

the fries are a medium thing in McDonald’s.

to say xyz of (abc - a size):
repeat with th running through things:
if th is abc, say “[th] is [abc].”;

to say smalls:
say “[list of small things].”

to say mediums:
say “[list of medium things].”

to say larges:
say “[list of large things].”

every turn:
say “[one of][smalls][or][mediums][or][larges][cycling].”;
say “Above shows how I want to do things. Of course, the user will have control, and there’ll be no arbitrary cycling, but this is for demonstration purposes. The code below seems more elegant and flexible, but it gives a runtime error.”;
say “[one of][xyz of small][or][xyz of medium][or][xyz of large][cycling].”;

After jumping: now yourself is medium.[/code]

I was surprised that the last line worked (I added it to test). This might conceivably break code elsewhere, unfortunately.

1 Like
3

Since you said the user will have control, it might be easier to just define it via an action. (This is build 6M. Dunno if it works on 6G.)

[code]a thing can be small, medium or large (this is the size property).

McDonald’s is a room.

the shake is a small thing in McDonald’s.

the big mac is a large thing in McDonald’s.

the fries are a medium thing in McDonald’s.

Sizelisting is an action applying to one size. Understand “list [size]” as sizelisting.

Report sizelisting:
say “[list of things that are the size understood].”[/code]

1 Like
4

Wow! Thanks to both of you for helping so quickly. I think I’ll be using Brian K’s code in this instance (it works in 6g) but Matt’s will come in handy with some code I’d half given up on, for another project.

5

I’d like to add something to this, in case anyone wonders how the rest of the programming should go, because it was a bit tricky. I found what I needed in “printing the player’s obituary.”

(note, 1) the code is specific to the game, so you can cut it down more–this is just generally how it works, and 2) yes, I need to make better names for the contexts):


a concept has a context. a concept is usually normal.

context is a kind of value. the contexts are unmissable, x-item, go-wrong-way, and normal. A context is usually normal.

Table of Final Question Options (continued)
final question wording	only if victorious	topic	final response rule	final response activity
"see (CONC)EPTS you missed throughout the game: [list of contexts]"	true	"CONCEPTS/CONC [context]"	concept-spec rule	--

this is the concept-spec rule:
	let x be normal;
	let got-one be false;
	repeat with co running through contexts:
		if the player's command matches the text "[co]":
			now x is co;
			now got-one is true;
			break;
	if got-one is false, say "NOTE: I should've gotten something but didn't, so I'm going with the default.";
	let curcon be 0;
	repeat through table of explanations:
		if exp-thing entry is a concept:
			if context of exp-thing entry is browny:
				say "[b][exp-text entry][r]: [exp-text entry][line break]";
		increment curcon;
		if the remainder after dividing curcon by 10 is 0:
			wfak;