A seat is a kind of supporter.
For writing a paragraph about an occupied common seat (called the throne):
If the throne supports exactly one thing:
Say "On [a throne] is [the random thing on the throne].";
Otherwise:
Say "On [a throne] are [list of things on the throne with definite articles]."
Those adjectives in the For… about construction are, I think, irrelevant to the issue, but I’ll include them anyway:
Definition: A supporter is occupied rather than unoccupied if there is something on it. A seat can be unique or common.
Apparently Inform doesn’t like the “list of things” construction, but I can’t figure out why. It gives this:You wrote 'Say "On [a throne] are [list of things on the throne with
definite articles]."' (source text, line 295): but descriptions used as
values are not allowed to contain references to temporary variables defined
by 'let' or by loops, because they may very well not exist any more when
the description needs to be used, in another time and another place.
I vaguely understand that the list construction involves a description, but I don’t see why I’m not allowed to do this. What’s this “other time and place” Inform is talking about?
I’m doing this because I want “common” seats to mostly be described with indefinite articles; I’ve been using the property to indicate whether or not the seat in question was constructed via duplicates, or is a unique object.
I tried to simplify this with Plurality and [is-are], but Inform didn’t like it (but unlike this issue, I know how to work around that!)
This is an example of a not-very-helpful error message. There are two different types of lists in I7: lists generated by descriptions and the “list of…” kind of value. The “with definite articles” syntax is defined for the latter. For the former, just use "a list of… " or "the list of… " The good news is in this case you don’t have to worry about “is / are” either (see ch. 5.5). Try this:For writing a paragraph about an occupied common seat (called the throne):
say "On [a throne] [is-are the list of things on the throne].".
Okay, I’ve done that, but the “describe what’s on scenery supporters rule” is beating me to the punch and I’m not sure why. I tried making the rule about the occupant instead but that didn’t do anything either.
I tried with “rules all” but my rule didn’t even come up in the listing.
My guess is that the “don’t mention scenery in room descriptions rule” is getting in the way when the rule is about the seat, and the occupant isn’t being selected as “notable” in the first place since (s)he’s not actually in the location itself.
I was able to get it working by changing the rule to a “printing a locale paragraph about” rule so that the whole description process is bypassed, but this seems like overkill. I did want to avoid procedural rules since they’re deprecated. Thanks for your help.
would give the same result as the describe what’s on scenery supporters in room descriptions rule (NYKevin rather wants something like
For writing a paragraph about an occupied supporter: say "On [AN item described] [is-are a list of things on the item described]."
)
Whoops! Maybe it would be better to replace the “describe what’s on scenery supporters in room descriptions rule” with something that covers this particular case - it seems to target this situation pretty well. But here’s a hack:
[code]Auditorium is a room.
A seat is a kind of supporter. It is usually enterable. It is usually scenery.
There is one seat in Auditorium.
The player carries a ticket.
Definition: A supporter is occupied if it supports something.
For writing a paragraph about an occupied supporter:
say “On [an item described] [is-are a list of things on the item described], and this is your very own rule for saying so.”;
After choosing notable locale objects:
Repeat with item running through seats enclosed by the location:
if item is occupied:
now item is not scenery;
otherwise:
now item is scenery;
(Update: Misinformation hidden under the rant tag.)
[rant]After banging my head on this for a while, I realized (or think I realized) this: if something’s scenery, then it’s not supposed to be mentioned in the “You can also see…” part of the room description. But that’s exactly where the writing a paragraph rules fire. So even if you get around the describe what’s on scenery supporters in room descriptions rule, your writing a paragraph rule isn’t going to fire when the seat is scenery.
So my advice is to make the seat fixed in place but not scenery. That should prevent the describe what’s on scenery supporters in room descriptions rule from firing (obviously), and your writing a paragraph rule should still fire.
It’ll also mean that the seat will show up even when nothing is on it. If you don’t want that to happen, then I think you should go for the “printing a locale paragraph about” approach.
[UPDATE: Or you could switch it from being scenery to not being scenery the way capmikee does. But that reeeaallly seems like overkill.][/rant]
The writing a paragraph about activity is triggered by a for printing a locale paragraph about rule (the very aptly named “offer items to writing a paragraph about rule”), and the printing a locale paragraph activity is triggered not by the you-can-also-see rule but by another for printing the locale description rule (viz. the interesting locale paragraphs rule).
I suppose you really have to deal with this on the printing a locale paragraph level, but that doesn’t mean you need to bypass anything.
The offer items to writing a paragraph about rule excludes only things that are mentioned, so I tried this and think it worked:
For printing a locale paragraph about a thing (called the item) (this is the unmention mentioned scenery seats rule):
if the item is a mentioned seat and the item is scenery:
now the item is not mentioned;
abide by the offer items to writing a paragraph about rule.
The unmention mentioned scenery seats rule is listed instead of the offer items to writing a paragraph about rule in the for printing a locale paragraph about rulebook.
Ah, thanks. I hadn’t got nearly deep enough into the locale description rules to understand what was going on. Just to get me clear on what’s going on here, what is the rule that makes the scenery supporters mentioned?
Here’s something I tried that I think worked – instead of adjusting the “mentioned” property, I just copied out the relevant part of the “offer items to writing a paragraph about” rule and made it apply to occupied seats, whether or not they’re mentioned. I’m still not entirely clear why the “describe what’s on scenery supporters…” rule isn’t firing for the seat, though; rules tracing lists it as applying.
[code]A seat is a kind of supporter. A seat is scenery.
Definition: A supporter is occupied if something is on it.
Rule for writing a paragraph about an occupied seat (called the throne) (this is the writing about a seat rule):
say “On [a throne] [is-are a list of things on the throne].”
For printing a locale paragraph about an occupied seat (called the item) (this is the offer seats to writing a paragraph about rule):
if a paragraph break is pending, say “[conditional paragraph break]”;
carry out the writing a paragraph about activity with the item;
if a paragraph break is pending:
increase the locale paragraph count by 1;
now the item is mentioned;
say “[command clarification break]”;
continue the activity.
Station is a room. “A station filled with benches and a table.” The bench is a seat in Station. Understand “benches” as the bench. The table is a scenery supporter in Station. The stand is a supporter in Station. The player carries a ticket. The player carries a wallet. The player carries an ID.
[/code]
I guess it’s the don’t mention scenery in room descriptions rule. It sets the locale priority of scenery to 0, and this automatically makes that scenery mentioned.
Thanks – “locale priority of 0 = mentioned” was what I was missing. And I see that that’s in “To set the/-- locale priority of (O - an object) to (N - a number):”
The describe what’s on scenery supporters rule runs, but it does nothing; because all things on the supporter have already had their names printed by the writing about a seat rule, and printing a thing’s name also makes it mentioned, and mentioned things are not “locale-supported”; and the describe what’s on scenery supporters rule only does something, if there is a locale-supportable thing on the supporter.
I’d thought that might be it, but the describe what’s on… rule seems to be running before the writing about a seat rule. The output with rules tracing on looks like this (in part):
[Rule "offer items to writing a paragraph about rule" applies.]
[Rule "use initial appearance in room descriptions rule" applies.]
[Rule "describe what's on scenery supporters in room descriptions rule" applies.]
[Rule "offer seats to writing a paragraph about rule" applies.]
[Rule "writing about a seat rule" applies.]
On a bench is a wallet.
True, but the for printing a locale paragraph rulebook (to which the describe what’s on scenery supporters in room descriptions rule belongs) runs once for about every object in the room (once for every notable-object in the Table of Locale Priorities), and the first time it runs for “yourself” (who is “undescribed” and therefore unmentioned).
I confirmed that with this extra rule:First for printing a locale paragraph about a thing (called item):
say "[paragraph break](Now printing a locale paragraph about [the item])[paragraph break]";
continue the action.
Thanks. Makes me think that it might be nice to enable some sort of trace that tracked the activities that were being carried out, or which named the objects that were arguments to the rules that were being applied. (If that’s not possible already.)
So why are the “don’t mention…” rules in the “printing a locale paragraph about” rulebook and not in the “after choosing notable locale objects” rulebook (or even incorporated into the “for choosing notable locale objects” rule)? That seems overly complicated.
And why isn’t there a “don’t mention the player” rule, eliminating the need to have an “undescribed” property at all?
I think the idea is that since the printing a locale paragraph about activity is going to be complicated one way or the other, you might as well put all the complication in one activity, especially since For… rules have default success.
Because this way you can use the “undescribed” property in the story, for example if you have a not-really-there object that needs to be in-scope but can’t be referred to… or something.
Yes, let’s provide already-confused authors with more opportunities to write garbled spaghetti code that doesn’t play nice with the Standard Library!
Seriously, the choosing notable locale objects activity is your friend. I’d like to see it get more attention both in the Standard Rules and in the documentation. It can do everything “undescribed” can do, in a more consistent way, and it can also give the author control over the ordering of paragraphs, and even provide views of distant objects. Its syntax and behavior are easy to understand, clear, and predictable, which is not something I can say for printing a locale paragraph.
Choosing notable locale objects fits my idea of how Inform does things: Set parameters, check restrictions, change the world model, report the changes. That’s how actions work generally, and I think it applies well to activities and descriptions too. In another language, I might build a string piece by piece before deciding whether or not to print it. Inform doesn’t do that because texts are routines or compressed text, which can be used without dynamic memory. So to “say” something complicated, you first need to have all the parameters set. I have vague ambitions of using Ron Newcomb’s “Unsuccessful Attempt by the Player” extension to make this process even more explicit and consistent… but I’m waiting to see how library messages are handled in the next release of Inform first.
