Can't get [The noun] to capitalize at the beginning of a sentence

Test code:

Lab is a room.

The target is a thing in the lab.

Fred is a person in the lab.

Your head is a backdrop.
Your head is everywhere.
Understand "head" or "my head" as your head.

Instead of attacking:
	say "You attack [the noun]. [The noun] is barely damaged.".

Test me with "attack target/attack fred/attack my head".

Expected results:

>test me
(Testing.)

>[1] attack target
You attack the target. The target is barely damaged.

>[2] attack fred
You attack Fred. Fred is barely damaged.

>[3] attack my head
You attack your head. Your head is barely damaged.

Observed results:

>test me
(Testing.)

>[1] attack target
You attack the target. The target is barely damaged.

>[2] attack fred
You attack Fred. Fred is barely damaged.

>[3] attack my head
You attack your head. your head is barely damaged.

The second sentence in the response to “attack my head” is not capitalized. I want “your” to be capitalized. Seems to work correctly for the other test cases. What am I doing wrong?

I also find this way less intuitive than you think it should be! What you need is “in sentence case” – see 20.4 of the documentation, especially the Rocket Man example. There’s also a forum thread with some practical ideas and alternatives on how to implement.

2 Likes

Yep, what’s happening here is that Inform doesn’t see an article it recognizes in front of “your head” (there’s no “a”, “an”, “the”, “some”, etc), so it assumes it’s a proper noun. And proper nouns’ casing is never changed (it’s assumed the writer put it exactly how they want it).

If this comes up a lot in your game, it wouldn’t be too hard to make an extension that changes this behavior (and capitalizes lowercase proper nouns correctly).

1 Like

Okay, so the interesting part of this is, if I use this code instead:

Lab is a room.

The target is a thing in the lab.

Fred is a person in the lab.

your head is a backdrop.
your head is everywhere.
Understand "head" or "my head" as your head.

Instead of attacking:
	say "You attack [the noun]. [The noun] is barely damaged.".

Test me with "attack target/attack fred/attack my head".

Then it acts the way I want it to act. So, even though your head with a lowercase “y” is still defined as a proper-named thing, it does change the capitalization in the second sentence. So maybe it only changes the first letter case of a proper-named thing if the name is defined with a lowercase letter as the first letter?

Any any rate, it does work.

Huh, that’s very interesting!

By the way, I just noticed that you defined the head as a backdrop – if you’re doing that in your actual game, you might want to instead define it as a part of the player, to avoid having to deal with some odd behavior (like getting told it’s hardly portable or fixed in place…)

2 Likes

Yup, good point, I will do that. Thanks.

I think that’s right. In those cases, the compiler generates an I6 property cap_short_name which contains the capitalized form.

1 Like

I took that and ran with it a bit for fun:

Lab is a room.
The target is a thing in the lab.
Fred is a person in the lab.

A head is a kind of thing.  One head is part of every person.
Understand "your" as a thing when the item described is part of the person asked.
A persuasion rule for asking Fred to try attacking something: rule succeeds.

To attack is a verb.
The block attacking rule is not listed in any rulebook.
Report an actor attacking:
	say "[regarding the actor][Those] [attack] [the noun]. [The noun] is barely damaged.".

Test me with "attack target/attack fred/fred, attack target/attack my head/attack your head/attack fred's head/fred, attack your head".

Notably, the target doesn’t have a head. This makes sense if it’s an archery target, but less so if it’s a mannequin-style training dummy.

And “my head” is always the player’s head, but “your head” is always the actor’s head (so, your head if you’re doing it and Fred’s head if you ask him to do it) – the former happens automatically in the parser, the latter happens due to the understanding rule. This may sound odd at first but due to the way that the story text is printed and how literal the player might be, it seems sensible to support both.

(This report text output assumes that the only reason Fred would attack anything is due to player persuasion. If he can decide to spontaneously attack something then you’d want to phrase it differently, more like what the Standard Rules do.)

Of course, in a real story it probably wouldn’t be this easy to persuade Fred to attack his own head – although since nobody can damage anything, perhaps he just doesn’t care to argue.

1 Like

Another solution for this (from my AIF experience) is to define a body part and then make a unique one for the player.

Test Room is a room.

a head is a kind of thing. One head is part of every person.
my head is a head. It is part of the player. The printed name of my head is "[our] head".

Bob is a man in test room.

Instead of attacking something:
	say "[The noun] isn't attackable."

Test Room

You can see Bob here.

x head

Which do you mean, your head or Bob’s head?

bob’s

You see nothing special about Bob’s head.

x my head

You see nothing special about your head.

attack my head

Your head isn’t attackable.

attack bob’s head

Bob’s head isn’t attackable

Tokenizing the printed name allows Inform to change case as appropriate.

That actually gives the player two heads, though (you can see this if you showme me; I don’t know why this doesn’t seem to trigger parsing ambiguities). And it seems entirely unnecessary – the code I already posted will recognise my head just fine, as demonstrated.