Capitalization in a rule for printing the name of something

Hi all,

I have an object carried by the player and I would like it to be referred to in the second person possessive. For example, “your PA”.

Cory Resden is a male citizen. The player is Cory. Cory carries a PA called Cory's PA.

Rule for printing the name of Cory's PA:
	say "[our] PA".

The problem here is that the above rule always produces “your PA”, even at the start of a sentence.

For example:

Yelling at is an action applying to one thing.
Carry out yelling at:
	if the noun is a citizen begin;
		say "[The noun] is not impressed.";
	end if.

I don’t want to use the printed name property of the object, because then I get “Cory’s PA”. And using “sentence case” would cause the “PA” part to come out “pa”.

Is there a way to discern whether the token that caused the rule to be invoked was “The noun” or “the noun”? That is, some way in the rule I can determine if I should be using [our] or [Our]?

Or perhaps there is a better way to achieve my goal?

Thanks in advance.

The way I’d do it:

The indefinite article of the PA is "your".
The printed name of the PA is "PA".

The capitalization of indefinite articles is handled automatically. Now "[a noun]" will print “your PA”, "[A noun]" will print “Your PA”, and "[the noun]" will print “the PA”.

1 Like

Thanks for your reply.

Perhaps I’m missing something, but when I try your suggestion, the tokens “a” and “the” are simply ignored and the output is always just “PA”.

Note that I removed the rule for printing the name of the PA.

It’s because of this line:

Inform sees you’re using it as a proper noun, and proper nouns don’t get articles.

You can be explicit to get the articles back:

Cory's PA is improper-named.

But then unless you override the printed name, you’ll get “the Cory’s PA” and “your Cory’s PA”.


Thanks, Draconis! This works very well.

There is a side-effect. Let’s say I enter the following:

> yell at PA

I get:

(the PA)
The PA is not impressed.

Instead of your PA.

But this is not a problem as the text is clear and not awkward. And if it’s the price of always getting a proper sentence, I’m fine with it :wink:

Thanks again.

In this case I think you should be able to change that by saying:

Rule for clarifying the parser's choice of Cory's PA: say "(your PA)[command clarification break]".

There might be other cases in which the definite article is used, for instance when you try to drop it after it’s already been dropped. I found a way to potentially make that work:

To say the (item - Cory's PA): say "your PA".

To say The (item - Cory's PA): say "Your PA".

When I do that and try “drop PA” twice in a row it says “Your PA is already here.” (What’s going on is that I’m redirecting phrase substitutions of the form “[The (foo)]” and “[the (foo)]” whenever “foo” is the PA–Inform will do the more specific substitution that applies only to Cory’s PA before trying the one before the one for saying “The (any object)”. So when it sees “[The noun]” in this message it invokes the one I’ve defined.)

For some reason this doesn’t cover the case where you’re clarifying the parser’s choice of Cory’s PA; both those are needed. And if the PA appears on a list printed definite articles, I think it will appear as “the PA.” As far as I know there’s no way to directly redefine the definite article.

Thanks! I am learning as I go and probably should have taken the time to study the manual and Recipe Book in their entirety. I was so eager to start though that once I thought I had absorbed enough to begin, I did just that. With these consequences…

The only case I’m noticing now is when there are two objects that parser is dealing with. I read the description of the clarifying the parser’s choice activity. Not sure if it’s actually being invoked here due to the presence of a second noun.

For example (in this case, a Card is just like a PA in that it is strongly associated to its owner but can be in someone else’s possession):

> insert my card in slot

I get:

(the Card in the slot)
You put your Card in the slot.

Again, I don’t find this horrible. But I am curious what is producing that disambiguation text.

If the player has two Cards, I have a “does the player mean” rule in place (so Inform picks his own Card unless otherwise specified) and rule for supplying a missing second noun when in the location of the slot. So this works fine:

> insert card

(your Card)
(into the slot)
You put your Card into the slot.

Just a hunch here - because as I’m going through my test output I’ve observed “the Card” or “the PA” more than once, for example during a “take all” - I think there are times when Inform is printing the type of the object and not the printed name.

Well, it should always be printing the printed name, but there are going to be some times when it won’t invoke either of the things we did to get it to print “your.”

Usually in “take all” it should print the printed name without any articles:

>take all
rock: Taken.
PA: Taken.

But if you have anything that invokes a list with definite articles, it’ll fall back to “the PA”:

After taking inventory: say "That's right, you're carrying [the list of things carried by the player]."


You are carrying:
your PA
a rock

That’s right, you’re carrying the PA and the rock.

Where the inventory listing uses indefinite articles and gets “your,” but the list uses the definite article and not our workaround for the definite article.

(Also, you’re right about clarifying the parser’s choice–it only works when there’s a single noun. I think the two-noun disambiguation text is being produced by parser internals. In fact, I haven’t looked it up, but I suspect/believe what is happening is that the parser produces the text in a similar way whether it’s a one-noun or two-noun clarification–but if it’s a one-noun clarification, there’s a hook to allow the “clarifying the parser’s choice” activity to intervene, if any rules have been written for it. But it would be too complicated to have an activity that applies to two nouns. This is just rank speculation though, I haven’t looked into the parser internals to try to figure this out.)

Thanks for the insight. Makes sense about “the PA” showing up in a list context.

FYI, if I give the command:

> take all

I’ll get:

Card: taken
incident of birth report: taken

But this makes sense in the context of your description, since I assume each item in the output comes from a list.

Thanks for your help!

Well, in this case, the reason you don’t get the definite article is because the rule is invoking the substitution “[current item from the multiple object list]”, which doesn’t have an article–so you just get the plain printed name which is “Card”.

For another tricky thing, I think the “multiple object list” isn’t technically a list, but you don’t have to worry about that.

Inform is a great system. I’m not surprised its internals are complicated. And I guess what I’m trying to do is unusual.

Once this game is done I’ll get through the manual and the Recipe Book and really absorb the info. I imagine if someone experienced like yourself saw my rules you’d recoil in horror :wink:

As a side note: I’m curious how people organize their rules. Maybe there is an existing discussion for this topic. I find myself more often than not using the search function to locate specific rules.

One of the major head-space things I had to get past is that it doesn’t matter where you put rules, which seemed counterintuitive to me, “How does Inform know what order to process the rules in?” But the answer is clear once I understood that Inform sorts them into rulebooks, and then knows what order the rulebooks occur in. It’s very flexible.

The only time you need to worry is in the occasional case where your custom rules do need to go in a specific order, and you can do that with “Last” and “First” which puts them at the end and beginning of rulebooks respectively. As an example, before taking a white-hot gem that is both blinding without goggles and too hot to pick up, you’d want to check the blinding first. The other trick is the rules are sorted in your source-text order…the last “First…” rule in a list winds up at the top of the rulebook before other specified “First…” rules when there are multiples, and the last “Last…” rule ends up at the bottom similarly.

First check taking the nuclear gem:
     if the player does not wear the lead glass goggles:
          say "You can't even look at the gem directly, much less put your hand on it." instead.

That rule will check and fail first, which makes sense if it’s also inside a locked glass case. You don’t want the player to fail to open the case when there’s a bigger issue with even doing that.

As far as personal organization, I tend to section my code into headers, and custom rules that affect a specific item are usually defined right after the item, or at least within the same header section. If there’s a game-wide system - like the light switch and electricity rules in Transparent - those rules get their own section outside of any room header, usually toward the beginning of the code.


Thanks again, Hanon. Interesting stuff on imposing an ordering on rules within rulebooks. I’m sure I’ll need that some day!

I’ve sorted the rules into chapters: the world-building stuff (that could be reused in another game in the same world), the two regions, various scenes, conversation, and finally the menu. Within each chapter are the actions first, locations, and then other rules sorted by check, carry out, to --, before, instead, after, rule for, and rulebooks. Rules that are specific to a location are listed right under the location (where there is a proviso containing a reference to the location) as well as objects that are originally placed there.

This seems to work, except certain objects are important in more than one context, so sometimes the rules involving them get spread out. I guess that’s bound to happen no matter how we organize the rules. I’m curious how others do it.

I use the same system as Hanon. Rules that are universal (to the game) go at the beginning. Rules that effect just one object or room go under the heading for that room.

It makes it easier for me to figure out “what went where and why” later when I am hunting down bugs.