When the player tries to talk to a person whose last name is Rooms, e.g. George Rooms, the default result is “To talk to someone, try ‘someone, hello’ or some such.” However, if the player has examined or tried doing anything other than examining to any person or object anywhere in the game (including George Rooms), then the player can talk to George Rooms and get an appropriate result.
Here’s an example of what’s happening:
GEORGE ROOMS, HELLO
To talk to someone, try “someone, hello” or some such.
MARCY GRANT, HELLO
There is no reply.
LISTEN TO MARCY GRANT
You hear nothing unexpected.
GEORGE ROOMS, HELLO
There is no reply.
In this example, I could have listened to (or tried other actions on) George Rooms, and that would have had the same result that I got with Marcy. So the game recognizes his name, except when the player talks to him before doing anything else to him or anyone or anything else.
This suggests that some condition changes when the player tries a certain type of action (in the example, listening to a character). Can I set that condition in the code, so that the player doesn’t need to try such an action before talking to George Rooms?
Well this is one of the more entertaining bugs I’ve seen! You could probably figure out what’s going on via higher levels of the TRACE testing command, but I mocked up a (george) room(s) of my own in a test, and was able to reproduce the issue but also fix it via a simple “does the player mean” statement (I just did “Does the player mean answering George Rooms that: it is very likely”). Would that – plus similar statements for asking about and telling about – solve things?
Thanks for your reply! I added “Does the player mean answering George Rooms that: it is very likely”, but this had no effect. Could I be missing something? If it matters, my Inform is version 1.68.1.
Ugh, sorry – I’m actually trying that again this morning and it’s not working for me either, so apologies for leading you astray! My only other idea was to see if examining George silently when play begins would skip the needed step, but it doesn’t do the trick, I’m guessing since that’s not actually a command being parsed. Internally renaming George Rooms to just George and adding “Understand ‘George Rooms’ as George” likewise doesn’t do it. So I’m guessing some Inform 6 level code getting into the guts of the parser might be what’s needed here to really suss out the issue – sorry not to be more help! Dunno if it’s possible to just design your way around this (like, make sure the player has to interact with someone/something else before encountering George).
The low-level cause is that, in one case, the allow_plurals global is false. ROOMS counts as a plural word and is therefore the match gets cut off, though not entirely rejected. This is the line
if (~~allow_plurals) k = 0;
in TryGivenObject().
In the other case, allow_plurals is true so that doesn’t happen.
I think the deal is: allow_plurals really should have a consistent value at the start of object parsing. But name parsing (for the “NAME, VERB” syntax) happens before object parsing (Parser Letter C). So it winds up relying on an uninitialized value of allow_plurals – whatever is left over from the previous command.
It should probably suffice to set allow_plurals = true; after reading the player’s command. I haven’t tested that, though.
To get around this problem, instead of telling the player to “Press any key to begin” at the end of the intro screen, now the player starts in an empty, isolated room whose printed name is “Type ‘START GAME’ to begin.” The game understands START GAME as a command that helps it to understand when the player is trying to speak to George Rooms, and it transports the player to one of the locations in the game. This is working. Thanks, everyone!
It actually happens for any name that is a plural form of a kind instantiated in the model world, and therefore with a plural entry (e.g. ‘rooms//p’) in the dictionary. In any game there are only two kinds guaranteed to be instantiated- room and person (for the initial location and the player), so the same problem will always arise for ‘George Rooms’ and ‘George People’, but if you instantiate a door, you have the same problem with ‘George Doors’ and so on.
The following fixes it:
allow-plurals is a truth state that varies.
The allow-plurals variable translates into I6 as "allow_plurals".
Before reading a command:
now allow-plurals is true.
For example, this sequence of play switches allow_plurals to true, then back again:
"____Test_George_Rooms" by PB
Lab is a Room.
George Rooms is a person in the Lab.
A flask is a thing in the Lab.
____Test_George_Rooms
An Interactive Fiction by PB
Release 1 / Serial number 210516 / Inform 7 build 6M62 (I6/v6.34 lib 6/12N) SD
Lab
You can see George Rooms and a flask here.
>listen to george
You hear nothing unexpected.
>george rooms, hello
There is no reply.
>take six flasks
Only one of those is available.
>george rooms, hello
To talk to someone, try "someone, hello" or some such.
but
"____Test_George_Rooms" by PB
Lab is a Room.
George Rooms is a person in the Lab.
A flask is a thing in the Lab.
allow-plurals is a truth state that varies.
The allow-plurals variable translates into I6 as "allow_plurals".
Before reading a command:
now allow-plurals is true.
____Test_George_Rooms
An Interactive Fiction by PB
Release 1 / Serial number 210516 / Inform 7 build 6M62 (I6/v6.34 lib 6/12N) SD
Lab
You can see George Rooms and a flask here.
>listen to george
You hear nothing unexpected.
>george rooms, hello
There is no reply.
>take six flasks
Only one of those is available.
>george rooms, hello
There is no reply.
Out of curiosity, why is it vital that the character is called George Rooms? A simpler workaround would be to simply give him a different surname that doesn’t represent the plural of a kind!
Actually, this isn’t quite true because although a person, selfobj is compiled with a parse_name property but no name property, so no ‘people//p’.
Consequently George People is only a problem if there is someone else declared as a person (rather than as a man, for example) and therefore providing a name property including ‘people//p’- George People himself doesn’t provide a name property including ‘people//p’ either even if he is declared as a person, just a plain singular ‘people’.
"____Test_George_Rooms"
Lab is a Room.
George Rooms is a person in the Lab.
A flask is a thing in the Lab.
A coin is a kind of thing. Five coins are in Lab. [<-- NEW]
allow-plurals is a truth state that varies.
The allow-plurals variable translates into I6 as "allow_plurals".
Before reading a command:
now allow-plurals is true.
yields
____Test_George_Rooms
An Interactive Fiction
Release 1 / Serial number 210517 / Inform 7 build 6M62 (I6/v6.33 lib 6/12N) SD
Lab
You can see George Rooms, a flask and five coins here.
>listen to george
You hear nothing unexpected.
>george rooms, hello
There is no reply.
>take six flasks
You can't see any such thing.
>george rooms, hello
To talk to someone, try "someone, hello" or some such.
Hmmm… That’s a separate bug entirely, which occurs regardless of George’s surname and ends up exiting from NounDomain() with an incorrect matched_from that is too high (2) so that wn, which becomes (matched_from + match_length) is now too high (4) instead of too low (1) when it should be 3 (marking the comma)!
I think the problem arises in
[ MatchTextAgainstObject item i;
if (token_filter ~= 0 && ConsultNounFilterToken(item) == 0) return;
if (match_from <= num_words) { ! If there's any text to match, that is
wn = match_from;
i = NounWord();
if ((i == 1) && (player == item)) MakeMatch(item, 1); ! "me"
if ((i >= 2) && (i < 128) && (LanguagePronouns-->i == item)) MakeMatch(item, 1);
}
! Construing the current word as the start of a noun, can it refer to the
! object?
wn = match_from;
if (TryGivenObject(item) > 0)
if (indef_nspec_at > 0 && match_from ~= indef_nspec_at) {
! This case arises if the player has typed a number in
! which is hypothetically an indefinite descriptor:
! e.g. "take two clubs". We have just checked the object
! against the word "clubs", in the hope of eventually finding
! two such objects. But we also backtrack and check it
! against the words "two clubs", in case it turns out to
! be the 2 of Clubs from a pack of cards, say. If it does
! match against "two clubs", we tear up our original
! assumption about the meaning of "two" and lapse back into
! definite mode.
wn = indef_nspec_at;
if (TryGivenObject(item) > 0) {
match_from = indef_nspec_at;
ResetDescriptors();
}
wn = match_from;
}
];
because indef_nspec_at has not been reset from the previous command, leading to an inappropriate attempt to reparse from wn=2, and match_from ends up as 2 instead of 1…
In any case, ResetDescriptors() seems to fix this one…
Lab is a Room.
George Rooms is a person in the Lab.
A flask is a thing in the lab.
A coin is a kind of thing. Five coins are in the lab.
allow-plurals is a truth state that varies.
The allow-plurals variable translates into I6 as "allow_plurals".
To reset descriptors: (- ResetDescriptors(); -).
Before reading a command:
reset descriptors;
now allow-plurals is true.
Furthermore, the problem doesn’t arise if ‘flasks’ is recognised as the plural of ‘flask’. It’s a feature of Inform that the default plural recognised for objects is the plural of their kind. Consequently the default plural compiled in the name property of the flask is ‘things//p’, not ‘flasks//p’.
This is the reason that an attempt to ‘take six flasks’ results in the perhaps unexpected ‘You can’t see any such thing.’ when one might expect ‘There is only one of those available’. Inform can’t find anything with the plural ‘flasks’, or a singular object called ‘six flasks’ (in the way a singular card might be called ‘six of clubs’). Consequently, Inform can find nothing in scope to match the word ‘flasks’.
Trying ‘Take seven flasks’ results in the even more unexpected ‘There are only six of those available.’, which has strayed into definite bug territory. The reason for this odd response is that as far as Inform is concerned, nothing matches ‘flasks’ so it tries compiling a list of the objects which it guesses might be the closest match based on their gender/number/animation attributes- in this case the five coins and the flask, totalling six objects. Although this list is then rejected, the error message associated with ‘too few found’ persists, instead of the more appropriate ‘You can’t see any such thing.’
Understand "flasks" as the plural of flask.
avoids these errors and produces the expected ‘There is only one of those available.’
Coincidentally, this also avoids descriptors being left uninitialised, so the ‘george rooms, hello’ error now also doesn’t occur after typing ‘take six flasks’.
"____Test_George_Rooms" by PB
Lab is a Room.
George Rooms is a person in the Lab.
A flask is a thing in the lab. Understand "flasks" as the plural of flask.
A coin is a kind of thing. Five coins are in the lab.
allow-plurals is a truth state that varies.
The allow-plurals variable translates into I6 as "allow_plurals".
Before reading a command:
now allow-plurals is true.
____Test_George_Rooms
An Interactive Fiction by PB
Release 1 / Serial number 210517 / Inform 7 build 6M62 (I6/v6.34 lib 6/12N) SD
Lab
You can see George Rooms, a flask and five coins here.
>take six flasks
Only one of those is available.
>george rooms, hello
There is no reply.
One moral of this tale of more general applicability to authors than dealing with (or avoiding) the rare instance of naming something after the plural of an instantiated kind is:
Always provide a specified plural for any object(s) you suspect the player might type a plural for.
e.g.
Understand "flasks" as the plural of flask.
Since Inform by default understands the plural of kinds in player input, but not of objects.
Otherwise, you’ll get this sort of output:
"____Test_Plurals" by PB
Lab is a Room.
A red flask is a thing in the Lab. A blue flask is a thing in the Lab. A retort is a thing in the Lab.
Lab
You can see a red flask, a blue flask and a retort here.
>take flasks
You can't see any such thing.
>take all flasks
You can't see any such thing.
>take two flasks
You can't see any such thing.
>take both flasks
You can't see any such thing.
>take two flask
red flask: Taken.
blue flask: Taken.
>drop all
blue flask: Dropped.
red flask: Dropped.
>take two things
red flask: Taken.
blue flask: Taken.
>drop all
blue flask: Dropped.
red flask: Dropped.
>take three things
red flask: Taken.
blue flask: Taken.
retort: Taken.