I’m afraid I don’t understand plurals. I have a simple case and it is not working. I want two pews to be in a room. Examining a single pew should give a different response than examining both pews.
A pew is a thing. Description of pew is "A twenty-foot wide wooden bench seats with faded-red thin upholstery. This is one of the pews that was ripped from the Sanctuary.".
The plural of pew is pews.
two pews are in South Corridor. Description of pews is "The two pews were once in the Sanctuary, but have been torn out in order to block the door at the south end of the hallway."
LOOKING (in South Corridor) shows that two pews are in the room. X PEWS works but X PEW does not. It says it doesn’t exist. What is INFORM understanding here, and what am I not?
Advice?
Daniel is right - if you want multiples of the same thing you first define it as a kind.
Your problem isn’t with Inform misunderstanding the plural - you designed a new object called “two pews” that Inform understands, but there’s no object called just “pew”
Inform doesn’t allow “examine all” or examine multiples of a kind (without extra coding to make it work) because generally you don’t want that transcript storm to happen. Also if you have generic kinds you won’t be able to disambiguate to the generic kind. This is why historically in Infocom games you wind up with “dusty scroll/battered scroll/smudgy scroll/tattered scroll” etc. so there’s no confusion when there are multiples in the same room or in inventory.
Generic kinds are often useful for something fixed in place where you might just want the same exact fireplace in each room where there’s only one and disambiguation wouldn’t be a problem. This is why authors are usually gently dissuaded from making portable multitudes for the player to collect like coins.
Note if the player is holding a generic kind, the complier defaults to the “preferably held” one or a random one of held kinds.
If the pews cannot be moved by the player (i.e. they are scenery in the room), you can also fake it by using two different things:
I had a similar case in my game where I had goats in a meadow and wanted to have different responses to examining a goat vs examining the goats.
South Corridor
Two pews block the door at the south end of the hallway.
>x pew
A twenty-foot wide wooden bench seats with faded-red thin upholstery. This is one of the pews that was ripped from the Sanctuary.
>x pews
The two pews were once in the Sanctuary, but have been torn out in order to block the door at the south end of the hallway.
Having naively made the big set-piece climax of my first game a puzzle that involved wrangling a dozen identical items, which could be modified or moved to a bunch of different places, I would say that if anything “gentle dissuasion” undersells how much of a pain this can be! The workarounds Hanon and Onno posted seem smart to me, I think those are better approaches both for the author and the player.
Your other option: customize every kind you place: “dusty pew/battered pew/singed pew/pew with graffiti”. You might even do what churches sometimes do and affix a plaque of whomever’s donation funded each one in the description, so you would have “the Smith pew/the Jones pew/the Kardashian pew” etc. which might make more in-world sense than just giving each one a random adjective.
I think that if the pews are to be moved later in the game (e.g. when there’s no more need of keeping barricaded the south door) you can make two separate pegs, e.g. upper peg and lower peg as movable things, then a deco for both pegs (having “both” as disambiguation adjective); this should also solve nicely the disamb issue noted by Onno.
This also allow a very simple puzzle, logically, because of a thing called “gravity” in debarrcading (disbarring ? or is only for getting rid of bad laywers ? ) one MOVE first the upper peg, then the lower peg (assuming the PC is strong enough, if not, let’s add a strongman NPC…)
All the disambiguation code in NounDomain() does is take what you have typed in response to the question (assuming it doesn’t start with a verb or contain a comma, in which case it assumes that this a new command or a new attempt at conversation respectively) and shove it into the player’s command before the noun being disambiguated.
So, in the above example the command ends up as take a clock clock - the repetition of clock doesn’t matter- but this illustrates why
>take clock
Which do you mean, a clock or the grandfather clock?
>a
also works- the command ends up as take a clock, and you’ll find that if you start out by typing this command in its entirety, the parser prefers a generic clock to the grandfather clock without disambiguation (this is in fact precisely analagous to the command found in test all of x one clock)
Since moving the pews has come up…I am stumped over a synonym for MOVE.
When I enter MOVE PEW, I get 'Nothing obvious happens" when I really want the pew to be moved from blocking to unblocking. However, when I code INSTEAD OF MOVING PEW…
I get a compile error that says MOVE is not an action, and yet it clearly seems to be something the parser understands (and gives me a default message).
I have been temporarily using TAKE PEW as a synonym, and then placing the pew on the floor. Is there a way to replace the MOVE verb?
Move is a built-in synonym for the pushing action (you can test this by typing ACTIONS in the test window, which will tell you how all your commands are being understood).
Onno,
Yes, this could work but I do want the pews, after being moved, to go from blocking the door to sitting in the hallway, but apparent. LOOKING in the room mentions both pew always; only their state of blocking or not is different.
Here’s the related problem. I can TAKE a pew, or override TAKING it, and the parser distinguishes a single pew from two pews. However, when trying to override the MOVE action with PUSH override, the compiler sees pew as a kind and throws an error.
A pew is a kind of thing.
Description of pew is "A twenty-foot wide wooden bench seats with faded-red thin upholstery. This is one of the pews that was ripped from the Sanctuary.".
Two pews are in South Corridor. ["[if BlockNbr is 3]Two pews are wedged against the double door, holding it shut. Someone really did not want something coming this way through those doors![else if BlockNbr is 2]One pew blocks the door and another is thrown
to the side.[else]Two pews sit along the wall of the hallway.[end if]".]
Description of pews is "Each pew was once in the Sanctuary, but has been torn out in order to block the door at the south end of the hallway."
Instead of pushing pew:
try taking pew.
Instead of taking pew in South Corridor:...
First, why the discrepancy between these two verbs in disambiguating a kind?
Second, if I include initial appearance of two pews (commented out above), then I get that description twice. How to get a single initial description for ‘two pews’.
I know I am trying hard to avoid pew1 and pew2 but perhaps I shouldn’t–just bite the bullet and make two different objects with the same printed name?
Inform 7 supplies the “pushable between rooms” property which allows creation of something like a wheeled luggage cart with grammar like PUSH CART NORTH which makes the object travel through the map with the player and rule conditions like
Instead of going to the Alpine Meadow with the wheelbarrow:
say "You don't want to crush the delicate blooms."
Instead of going north with the handcart:
say "The headwind is so stiff that you are unable to make much northerly progress at all while encumbered by the handcart."
But in this case you want furniture changing positions within a location. For that usually the trick is to assign it a value:
You could probably also make pews “pushable between rooms” which is a different action than just PUSH [NOUN]. So you could also PUSH PEW NORTH which would move it to the adjacent room. For that, you’d want additional checks on the plain PUSH action to just say “You give the pew a shove.” if the location isn’t the Church so the player couldn’t block the door from across the map. You’d also want to adjust all the messages based on location.
This is where implementation is tricky because some players will probably try BLOCK NORTH DOOR WITH PEW which you could redirect to PUSH PEW but there’s multiple ways someone might think to do the same action. That’s why I’d recommend tutorializing within descriptions to tell the player exactly what they can do for the desired effect somehow.
actually, I’m afraid I’ve misled you all here. It turns out on closer inspection that a clock does not cause the parser to prefer a generic clock to the grandfather clock- it just appears to in this scenario because the generic clocks are defined earlier in the source. Reverse this and the grandfather clock is picked.
The parser scores the generic clocks and the grandfather clock equally, can’t decide between them, but just goes with the first tied-highest-scoring object it’s listed (which turns out to be whichever is declared first in the source). It does this because a clock or one clock implies to the parser that a definite, particular clock is not required, so any of the ‘joint winners’ will do. Conversely, clock or the clock will prompt a disambiguation question because it implies to the parser that you meant a specific, particular clock.
So here a clock as a response to the disambiguation question actually serves to switch the command from a definite to an indefinite request, thereby swerving disambiguation when the command is reparsed by implying no preference among any clock in scope.
The following is one way of coercing the parser into choosing a generic clock over the grandfather clock in response to indefinite requests such as a clock or two clocks regardless of the order in which they are declared in the source code, and the reverse in response to definite requests such as clock or the clock:
indefinite-mode is a number that varies.
the indefinite-mode variable translates into I6 as "indef_mode".
Does the player mean doing something with the grandfather clock when indefinite-mode is not 0: it is unlikely.
Does the player mean doing something with the grandfather clock when indefinite-mode is 0: it is likely.
This is close to what I have working best, but not working totally. I think I need this approach plus the omit pews from description approach together to get what I want. I have explicit text for each action the player performs on the pews/each pew.
Question: what does this do?
A pew is a kind of enterable supporter. A pew can be pushable.
A pew is pushable.
) one MOVE first the upper peg, then the lower peg (assuming the PC is strong enough, if not, let’s add a strongman NPC…)