“Manual pronouns” here refers to what I called the “standard” or Infocom-era model – pronouns are auto-set when the player types the name of an object, but not when the game lists objects.
(The I6 switch for this mode was called “MANUAL_PRONOUNS”.)
I did some testing, and found that objects listed in room descriptions grab pronouns, whether “use manual pronouns” is on or off.
An ambiguously plural object will grab the pronouns any time its name is printed, if the manual pronouns is off.
(There is a mention of “if using the manual pronouns option” in Plurality.)
Fix: Add the line “The set pronouns from items in room descriptions rule is not listed in any rulebook.”
“Use manual pronouns” has no effect at all, by default. (It is defined in the Plurality extension, and it probably should have been removed back in 6E59. It only affects the behavior of a deprecated phrase which is no longer invoked by the library.)
Scenery supporters with contents will still set pronouns. Fixing that requires an uglier hack.
“Use manual pronouns” also affects the behavior of ambiguously-plural objects.
After printing the name of an ambiguously plural thing (called the suspect) (this is the notice plurality of printed ambiguous object rule):
if the manual pronouns option is active:
do nothing;
otherwise:
notice the plurality of the suspect.
Indeed. I should have looked harder at the Plurality source code.
This is all a confusing mess and I’ll file a bug report at some point on cleaning it up.
ADRIFT only sets pronouns from the user input. However, I think there are times when you would want to extract from the output, although I think this would be in the minority of cases.
put coin in slot
You put the coin in the slot. The machine clunks, and a can of soda appears below.
get it
Actually, I’ve often WANTED to do something like that (as a player). I just never did because I knew it wasn’t implemented.
In that scenario, it would make perfect sense to set the “it” pronoun to the object that has just appeared. The thought occurs that, in I7, you could simply do a function that’d move an object into play AND set its pronoun… the thought also occurs that maybe I7 could try to do this automatically whenever something is moved to the room where the player currently is. But I don’t like the idea of I7 trying to do it automatically. Too much margin for error.
I don’t feel a need for “it” to cover the vending-machine case.
The one case that should be covered is when you swap one object for another, but they’re the same thing as far as the player is concerned. If you ATTACK RUST MONSTER WITH SWORD, and the game removes the “sword” from play and substitutes “rusty stump”, the pronoun should be switched to the new version. But the library will never be able to automate this; it’s just something the author has to keep in mind.
As a player, I use pronouns. As an author, I think it’s something that all authors should be aware of.
As far as the Hugo language is concerned, it emulates Inform by setting pronouns to objects or last-items-mentioned-in-a-room-description. Finessing pronoun behavior is a bit more hack-y than I’d like, but I have a page explaining how to do the important stuff here: http://hugo.gerynarsabode.org/index.php?title=AssignPronoun
I don’t like this when a list of auto-generated text (inventory, local items, etc) includes multiple items; choosing the last thing to be it/them/him/her feels too arbitrary. If it’s a list of 1, though, the behavior is more understandable.
The player-set option sometimes makes sense, but can become silly when many objectless (or plural-object-less, or her-less, or him-less) commands intervene:
[code]> X GROTESQUE
Carved into a slight recess in the stone wall, the face bears an uncanny resemblance to the late Preliminary-Sub-Minister of Wicksburg.
E
Grotto
N
Silent Passage
D
Base of the Column
A single silver coin lies on the floor.
GET IT
You can’t see ‘it’ (the grotesque) at the moment.[/code]
Agreed on the second scenario, but the vending machine is trickier. I’m sympathetic to arguments both ways.
One case where I believe automatically setting pronouns is warranted is when something extremely notable has happened in the surroundings:
[code]> GET BALL
Taken.
A huge jet engine crashes through the ceiling, embedding itself halfway in the floor not a foot from your feet!
X IT
A simple red rubber ball.[/code]The tone mismatch from a wrong guess in cases like this can become unintentionally absurd.
I feel – and I haven’t actually tried this out in a real project, yet – that it might be a good idea to set up a few simple rules governing pronoun default behavior.
[code]1. If a given pronoun is unset: any player’s command, or auto-generated list, (or room/thing description with [highlighted] nouns, ) featuring exactly one such relevant thing, sets that pronoun from that noun.
EX: > GET KEY AND LEAVES would set pronouns 'it' from the key and 'them' from the leaves.
-
If there are two or more such relevant things, instead, the pronoun remains unset. If the player references an unset pronoun, the parser should disambiguate.
EX: You can see a coin and a tiny wicker doll here.
GET IT
What do you mean by “it”, exactly?
THE COIN
Taken. -
When any thing referenced by a pronoun passes out of scope, that pronoun becomes unset.[/code]This unsetting rule, combined with the pronoun-setting rules, should handle a lot of common scenarios; it’s plausible for the player to want to fiddle with a worn or carried item in multiple rooms, for example, but probably not the 20 foot jade statue of an elephant.
ChrisC: What do you think of:
GET BALL. X IT
Taken.
A huge jet engine crashes through the ceiling, embedding itself halfway in the floor not a foot from your feet!
…
Now, in this situation, I would be pretty annoyed if it chose to examine the jet engine. At the time I typed “it”, that word clearly referred to the ball.
Other silly edge cases:
Those are great cases, ralphmerridew. Here’s another one, maybe:
I agree with ChrisC’s judgment on most of the cases (except that I absolutely would want “it” to cover the vending machine case), except for automatically unsetting the pronoun when the object passes out of scope – it seems to me that sometimes you want to know that whatever it is has disappeared. Consider:
Of course, a lot of the behavior we’re talking about – especially disambiguating the pronouns when there’s more than one sensible thing for them to refer to, which I really like – would require a lot of programming.
The jet engine case seems like it’s really designed for custom pronoun-setting like Pot of Petunias – in fact it’s pretty much the same example, except with a jet engine instead of a pot of petunias. The response to “GET BALL. X IT” might be kind of annoying, but in ideal world I’d want my chain of commands to be cut off there.
But:
EXAMINE GLASS CHEST
You can see a coin and a tiny wicker doll inside the chest.
OPEN IT
What do you mean by “it”, exactly?
This is frustrating, and it does not get better if you treat single-object lists differently:
EXAMINE GLASS CHEST
You can see a tiny wicker doll inside the chest.
OPEN IT
You can’t reach the tiny wicker doll, because the chest is closed.
(In fact, the I7 library would typically render this last response as “The chest isn’t open.” Bug reports would fly.)
Or, e.g.:
ASK STEVE ABOUT GOLD
“What gold?”
ASK HIM ABOUT BROTHER
“My brother’s name is John.”
ASK HIM ABOUT SISTER
You don’t see John here.
I’m not saying that there aren’t cases where auto-setting pronouns doesn’t make intuitive sense; there are plenty. But there are two competing goals here: generating a smooth-reading stream of text, and giving the player a way to enter abbreviated commands with confidence. That last (Steve) case can’t be understood without considering the many games in which I have repeatedly typed [up-arrow] [delete last word] [guess new topic] [enter].
Regarding your “chest” examples, I agree, but I think that’s why most of us are against “set-pronoun-to-last-thing-mentioned” but not necessarily against “set-pronoun-to-something-that-just-popped-into-view”, which is the case with the vending machine example and not with your chest example.
Here’s something else I just realised.
In this case, the command I would probably write next would be to “examine/get volume/book”. However:
In this case, I think I might try “get/examine it”, if I wasn’t jaded from knowing that the pronoun was certainly not going to be set for the book. And this isn’t something that can be automated (unless you argue that on my first example I could have silently set the pronoun to the “volume” and the player would never even notice, thus not doing any harm), it’s just to do with the way things are written.
And in your last case, Zarf, that would be very unlikely to happen, wouldn’t it? Communicating with an NPC uses strings - I would have ASKED ABOUT <a string that equals “Brother”>. Surely at no time this would involve the actual NPC, any more than asking Steve about the gold would set “it” to the gold piece (that might not even exist in the game).
And regarding the jet example… that’s another issue, with strings of commands. That’s another kettle of fish altogether - what interrupts a string of commands? What SHOULD interrupt it? And let’s not even consider strings of commands given as orders to NPCs…
How do you know? The I6 topic system used both objects and strings, and there are I7 conversation systems that run both ways.
I think my point about two competing goals is that it is clearly difficult to support the first goal reliably – given the number of places which require the author’s intervention. Supporting the second goal (having “it” consistently set from the domain of the player’s commands, not the game text) is quite easy. If you’re going to argue that the first goal is more important, you need to deal with that fact as well.
I think all of these examples are based on a misreading of my first rule. In each of these examples, the player’s first command sets the ‘it’ pronoun; in which case my rule 1 will not subsequently fire.
I realize I need an addendum, and made some changes – is this clearer? --:
If it’s all right, I’ve commented the value of pronouns in your examples:
No ambiguity here; not only did rule 1(a) set ‘it’ to the chest, but also rule 2 prevented that pronoun from being changed by the subsequent output.
Same as above.
Arguably ‘her’ may not be set here, depending if the sister is an object known to the player, simply a topic, etc; cross-linking with Epistemology may be useful here.
But why would you want this to occur only in the case of literally typing “her”, and not “Galatea”? It seems to me that cases like this are so rare that you would want to custom-implement it (add a not-galatea dummy object to respond to spurious commands with informative messages), not rely on any automated system – and certainly not a pronoun-only one.
I was under that impression from my brief foray into I7, and playing Inform games usually bears that out. That and a case that often occurs, when I ask NPC about OBJECT and get “You can’t see OBJECT here”. From which I deduced that it WAS possible to ask about objects, but it led to this sort of thing happening, so most authors just went with strings.
Again, just a brief foray and a few deductions. It seems they were wrong - apologies.
Still, in your particular example, to be pedantic, “John” would have to be synonim with “Brother”. But “Steve” is also a “brother”. In this case, I would prefer a string to handle the ambiguities.
Chris - I think it’s bloody brilliant.
[quote]
But why would you want this to occur only in the case of literally typing “her”, and not “Galatea”?/
[quote]
For one thing, it’s easier for the player to use a pronoun to mistakenly (or not) refer to an object that’s no longer in scope. It’s also easier for the author to recognise when this has happened than to have to deal with the player actually trying to interact with it using its name. Having said that, however, I’m perfectly fine with the current “You can’t see Galatea here.”-style default - anything other than that would probably be best left to customisation.
Well, ideally in the case where “Galatea” is typed there’d be a slightly more sensible parser error message (“Either you can’t see Galatea, or ‘Galatea’ doesn’t refer to anything in this world”), which would be applicable beyond this case. But I don’t know that cases in which you want to refer to something that happens to have just left play are that rare, and the current pronoun-handling system does handle it the way I’d like to – the message I put in there was just a fancy variation on the default, but the default is better than the response that you’d presumably get if you unset “her” when Galatea left.
(Test code):
[code]“Galatea’s Façade” by Matt Weiner
Gallery is a room. Galatea is a woman in the gallery. The description of Galatea is “She is chatting animatedly.”
Instead of asking Galatea about “drupes”, say “She says, ‘Drupes are plums blah blah.’”
Instead of asking Galatea about “melons”:
say “Galatea slaps your face and walks out.”;
remove Galatea from play.
test pronouns with “ask galatea about drupes/x her/ask her about melons/x her”.
test nouns with “ask galatea about drupes/x galatea/ask galatea about melons/x galatea”.[/code]
But making this work smoothly would require a lot of custom stuff and special-casing. I guess I can see the argument that it’s so much work to get smooth-flowing prose that we should just use pronouns to refer to the last thing you typed, but the vending machine and jet engine cases seem pretty egregious to me, and it’d be much friendlier for people who already know the code, I think.