the story I’m writing to teach myself Inform7 is set up up as a form of “dialogue” between the main character and the player, i.e. as if the player is giving commands to the main character and the main character is responding by carrying out the action and describing the results.
To achieve this, I’ve set the story viewpoint to the first person singular, but I’ve now come across a parsing issue: I want the parser to accept the second person singular, so that, for example, to examine the main character you’d have to ask examine yourself or similar rather than examine myself , and ask your father about topic rather than ask my father about topic.
I can’t seem to find in the manual a way to do this though. Did I miss something?
I don’t think you’ve missed anything in the manual, this probably requires some Inform 6. This thread might help (just with second person pronouns instead of third person):
Ouch. I’ll try my hand at that. In the mean time I’ve done some testing, and apparently the parser always uses the first person pronouns? I tried setting the second person singular viewpoint, and it will still accept ask my father about topicbut not ask your father about topic, so this is indeed much more ingrained than I originally thought.
Is that because the object you’ve created is called my father?
You might need to do Understand "your father" as my father etc. to get the parser to do what you want. You can probably make a custom kind for this if you have a lot of things that are “my”.
But we want the parser to refer to it as my father, right?
Incidentally, you’ll probably want to catch the case where the player types “my father” and make sure the narrator responds with something like “your father isn’t here, this is my father”.
Thanks for all the comments. No, the person in question is just defined as Fatherand has no possessive adjective associated:
>showme father
Father - man
location: in the studio
unlit, inedible, portable, repaired, necessary; transparent, male; singular-named, proper-named, found
description: none
initial appearance: "My father is sitting at his desk, working."
carrying capacity: 100
printed name: "Father"
printed plural name: "men"
indefinite article: none
list grouping key: none
I’ve done some more testing, and it’s apparent that the parser just skips over first-person possessive adjectives, so I can say things like take my chair or open my door. This is not only regardless of the viewpoint, but also of the object definition, so this is something very deep into the parser. In fact, it’s even more generic: I can use basically ANY possessive or demonstrative adjective, EXCEPT for your, and it will just be ignored (it’s possible that it might contribute to the parser scoring when disambiguating, I haven’t tested that deeply).
I’ve been looking at the source code and it seems that this is handled by the LanguageDescriptors table, which includes all of these, again EXCEPT for your. I don’t know if this is an intentional decision or an omission due to it never mattering … now I’m thinking I should report this as an enhancement (or bug report?) for the English language kit …
I have managed a solution, inspired by the one proposed by @Zed in Recognize third person pronouns as the player - #7 by Zed plus the necessary addition to edit the LanguageDescriptorstable, which —to avoid rewriting the whole thing— I achieved leveraging the fact that Inform7 language kits (at least in the version of I7 that I’m using) have a currently-unused LanguageInitialiseI6 function.
As recommended by @jwalrus I’ve also added some handling for the case when the player uses my instead of your.
For the curious, this is the code I’m currently using:
Include (- Constant ME1__WD = 'you'; -) replacing "ME1__WD".
Include (- Constant ME2__WD = 'yourself'; -) replacing "ME2__WD".
Include (-
Constant YourPossessive = 'your';
[ LanguageInitialise ;
LanguageDescriptors-->1 = YourPossessive;
]
-) replacing "LanguageInitialise".
Before printing a parser error (this is the wrong possessive rule):
if the player's command includes "me/my/myself":
if the player's command matches the regular expression "\bmy (.*)$":
let M be "YOUR [the text matching subexpression 1]";
say "What makes you think I could find [M] here?" instead;
otherwise:
say "You are not here if not through me, why are you referring to yourself?" instead.
One word of caution: test this with GET MY CLOTHES THEN X THEM.
(Well, two words of caution I guess. The other is that, if you’re printing your own error messages, you probably want “for printing…” instead of “before printing…”.)
Concerning the choice of Beforerather than For, this is intentional. The intent here is not to replace the standard parser error, but to complement it by proposing a possible reason the reason for the next “I can’t see any such thing” message. If anything, the question would be whether After would be better than Before.
Here’s an example interaction with the double action, wrong vs right:
>x my father then ask him about the key
What makes you think I could find YOUR father then ask him about the key here?
I can't see any such thing.
>x your father then ask him about the key
I see nothing special about Father.
Father says "The cellar key should be somewhere in the kitchen."
whereas for actions that don’t make sense either way:
>x your clothes then take them
I can't see any such thing.
>x my clothes then take them
What makes you think I could find YOUR clothes then take them here?
I can't see any such thing.
I actually had code earlier that would check if the word after mywas a recognized object and limit the error message to that one, basically:
if the player's command includes "my [something]":
let M be "[the matched text]";
replace word number 1 in M with "YOUR";
say "Do you really think I could find [M] here?" instead;
before the regexp check/replacement. I then decided to remove it because I felt it was “overkill“; ultimately it depends on what kind of errors are made. For example, with this extra check one gets the “restricted” error message if the issue is just the possessive, but the includes check will still fail if we still can’t match anything (e.g. x my father then ask him about the doll will only complain about the father, but for the command x my fancy father then etc it will still capture the whole sentence.
I can improve the regexp match by adding an optional thento fence the text at the first then, but it will still get too eager if the user mistypes then into thwn for example. Ultimately there’s not perfect solution (but I think I will add the then fencing).
Also check for ., which is equivalent to “then” in the parser. I normally warn against trying to replicate parsing machinery like this, but when it’s just for providing useful error messages (and not for affecting the game world), this is probably the best way to do it.
Thanks for the recommendation, @Draconis . After some more testing, I’ve come up with this
After printing a parser error (this is the wrong possessive rule):
if the player's command includes "me/my/myself":
if the player's command includes "my [something]":
let M be "[the matched text]";
replace word number 1 in M with "YOUR";
say "Do you really think I could find [M] here?" instead;
otherwise if the player's command matches the regular expression "\bmy (.*)(\.| then .*)":
let M be "YOUR [the text matching subexpression 1]";
replace the regular expression " *\p+ *$" in M with "";
say "What makes you think I could find [M] here?" instead;
otherwise if the player's command matches the regular expression "\bmy (.*)$":
let M be "YOUR [the text matching subexpression 1]";
say "What makes you think I could find [M] in [italic type]my[roman type] house?" instead;
otherwise:
say "You are not here if not through me, why are you referring to yourself?" instead.
which seems to be restrictive enough unless the user really messes up with the command, which seems acceptable
And even if they do, the only consequence will be a malformed error message—this won’t make any otherwise-legal commands fail, which is my main concern with this sort of trickery.
