5 plates, 5 bowls, 5 spoons, 5 forks and 5 knives are in the cupboard.
This only works grammatically correct for the user if they take more than one object, eg. “take 2 knives”, works just fine.
But “take one knife” gives the response “You can’t see any such thing.” Obviously, this is going to be frustrating. One has to type “take one knives”, to get it to work, and no one is going to think to type that.
What is the correct way to deal with this?
The trick is, Inform is good at making plurals from singulars, but not really the other way around. So you have to first explain what the singular is, and then it’ll figure out the plural appropriately.
A knife is a kind of thing. Five knives are in the cupboard.The way you’ve phrased it, Inform has made individual objects in the cupboard called “5 knives” “5 plates” “5 bowls” etc., and therefore doesn’t have grammar to understand “knife”
showme plates
5 plates - thing
location: in the cupboard in Test room
singular-named, proper-named; unlit, inedible, portable
list grouping key: none
printed name: “5 plates”
printed plural name: none
indefinite article: none
description: none
initial appearance: none
The way Daniel explained will separate them:
Test room is a room.
A cupboard is a container in test room.
a plate is a kind of thing. 5 plates are in cupboard.
Test room
You can see a cupboard (in which are five plates) here.x cupboard
In the cupboard are five plates.showme cupboard
cupboard - open container
plate - plate
plate - plate
plate - plate
plate - plate
plate - plate
take plate
Taken.i
You are carrying:
a platetake plate
Taken.
i
You are carrying:
two platestake 3 plates
plate: Taken.
plate: Taken.
plate: Taken.
Thanks guys! I was literally just copying the examples as given in the Inform manual “4.14 Duplicates” - ah now I see that it does lead with “A triangle is a kind of thing.” type statements. I guess I was so used to being able to create an object by saying “The pestle is in the mortar.” that I didn’t think it was necessary. Not used to having to set up an object that way.
@HanonO What’s funny is in my example, I COULD take any number of “knives”, as I described, it’s just that to take one knife I had to refer to it as a “knives”. Okay I’m trying it now and it’s actually working as you described. I swear… maybe it’s because I’m using a different version of Inform to test it out right now.
Thank you for your detailed answer. And thanks @Draconis for your super succinct answer too.
I must say I’m impressed that Inform can understand that the plural of knive is knives. I guess it just has a huge dictionary in it with all this information. I suppose there is a way to manually provide the plural version of a thing, if it doesn’t have it in its dictionary.
The Very Noisy Playroom is a room.
A xylophone is a kind of thing.
There are five xylophones in the very noisy playroom.
The printed plural name of xylophone is "xylophonia".
This is another reason SHOWME is handy:
> showme xylophone
xylophone - xylophone
location: in the Very Noisy Playroom
singular-named, improper-named; unlit, inedible, portable
list grouping key: none
printed name: “xylophone”
printed plural name: “xylophonia”
indefinite article: none
description: none
initial appearance: none
That’s fantastic, thank you 
I’m still wondering whether Inform is brilliant or confusing. Once I know how something works it seems very simple and perfectly reasonable, but as soon as I don’t know how to do something, I rarely have any idea where to start looking in the manual. For example, in the previous post I literally had to find the “Duplicates” part of the manual by searching for “triangles” because that’s the part of the example I remember. Searching for “multiples” brought up pages about “actions that work on multiple objects”. Not sure if it’s because Inform has a lot of complex things to know, or if the documentation could be clearer, or if this is just what it’s like learning something. (It’s been a long time since university when I first learnt programming.) Conversely I have no problem with programming languages. Every new programming language has similarities to other programming languages, and I find I can get answers in their documentation in a way I don’t seem to be able to do with Inform.
Curious what other people think of it.
Out of sheer morbid curiosity, I want to see what happens if duplicate objects have interactions, eg. “containers”:
A servant bed is a kind of enterable container. The printed plural name of servant bed is "servant beds". There are 10 servant beds in the Servant's living quarters.
I find that all interactions only happen with what I assume is the first one. Is there a way to interact with different duplicate objects?
If you have two objects with exactly the same dictionary words associated with them–that is, the words that can be understood as those objects–then Inform treats them as identical and doesn’t try to do disambiguation for them. There’s some discussion of that here.
There’s no way to interact with different ones in this case because, well, there’s no way to interact with different ones! Anything the player types could be understood as any of those objects. There are a couple of edge cases where this causes issues–if you’ve got an Understand by relations statement, Inform won’t realize that this is a possible way of distinguishing the two objects, and will treat them as duplicates. For instance:
Lab is a room.
A rock is a kind of thing.
Understand "on [something related by reversed support]" as a thing.
The counter is in the Lab. One rock is on the counter.
The table is in the Lab. One rock is on the table.
After printing the name of a rock (called stone) when the stone is on a supporter (called the pedestal): say " on [the pedestal]".
Ideally if you said “x rock” the game would ask “Which rock do you mean, the rock on the counter or the rock on the table?” But the parser isn’t quite clever enough to figure out that it can do that, so it automatically selects one.
You can, however, understand things by their properties, and the game will know that those aren’t indistinguishable:
The servant's living quarters is a room.
A servant bed is a kind of enterable container. The printed plural name of servant bed is "servant beds". There are 10 servant beds in the Servant's living quarters.
A servant bed has a number called id. Understand the id property as referring to a servant bed.
After printing the name of a servant bed: say " [id of the item described]".
When play begins:
let index be 1;
repeat with cot running through servant beds in the servant's living quarters:
now the id of cot is the index;
increment the index.
This code assigns different IDs to the servant beds and lets the player refer to the beds using the IDs (they also have to type “bed”–the “referring” in the Understand statement means that the property can’t be the only thing the player types to refer to it, if you want to let that happen you’d say “describing”). It has lots of design problems, as you can see if you look at the room description, but it shows one way you can let the player interact with specific duplicate objects.
Another way is simply to give the different beds names, so they aren’t duplicates:
The servant’s living quarters is a room.
A servant bed is a kind of enterable container. The printed plural name of servant bed is "servant beds".
The messy bed is a servant bed in the living quarters.
The rumpled bed is a servant bed in the living quarters.
The shipshape bed is a servant bed in the living quarters.
And finally it’s worth asking yourself whether having ten actually-implemented identical beds is really necessary for your gameplay.
For me personally Inform 7 did have an odd learning-curve: “English language code? Wow this is so easy I can do anything! Okay, this is kind of complex. WHY DOESN’T ANYTHING WORK? Oh wait, I can do anything so long as I compromise and use the very specific English syntax Inform understands. Wow, I can do anything!”
If you jibe with it it’s great. People who are good at regular coding usually can’t abide it at all. If you like normal coding better, you might want to look at Inform 6 (which is what Inform 7 compiles down to) or Dialog, which is a new language being created by Linus Akesson that feels like Inform with slightly more straightforward and compact code.
Many people really also like TADS3. I don’t use it, but it seems to be Windows only, and the publishing and distribution options aren’t as up to date.
My best suggestion for Inform 7 is take time to read the manual AND the recipe book in the IDE and play with the examples to get a fuller understanding of how things work. The concepts do build upon each other.
Inform 7 seems so initially user-friendly that I suspect many people read the first couple chapters and think they have the hang of it since it’s just “plain English” but as you’re discovering there’s a very specific syntax you have to use to make it understand what you’re talking about.
Also if you are dealing with multiple mass-created duplicates, you need to be aware of the “a random” syntax which has tripped people up:
If the player carries a carnival token:
now a random carnival token carried by the player is in the wishing well.Matt is right. The usual convention when dealing with myriads in Inform 7 is to make one special interact-able object and then use descriptions or scenery to stand in descriptively for the extra ones. It doesn’t usually make sense to model 9000 separate leaves in a pile when for practical purposes the player only needs one.
You make one “pile of leaves” object (possibly a fixed in place enterable container), then if the player takes a leaf, you give them one special hero leaf and prevent them via rules from taking more: “You’ve got one leaf, and that’s plenty for now.”
Ah, thank you. It’s good to know this is possible, in case there is a puzzle involving maybe stacking multiple items - but of course, as both of you have stated, it’s far better to design the gameplay around the type of game that text games are best at!
Yes I’m getting that feeling! It’s like learning a new programming language, but there is literally no point of reference, apart from IF and LOOP statements, this is an entirely new and esoteric set of rules that I have no choice but to learn. However, I do suspect that making a game in Inform may be simpler than writing it in traditional code, once you know what you’re doing. For the parts I do understand, I’m enjoying the simplicity.
And thanks for the heads up about Dialog. I was vaguely aware of TADS3 as the “programming version of inform” but had no idea it was out of date and that Dialog was the best version of that. I’m enjoying Inform as a kind of programming language that doesn’t feel like programming, but I will probably check Dialog out just to compare the experience.
Yes, good idea, I will aim for that design in my actual games 
Inform coding/usage comment:
As someone that always feels he is learning something new, I have found that having one instance of Inform open that I am working in, and a separate one where I can open, look at, and modify the examples in the Docs and Extensions section gives me a playground I am not afraid breaking. I can copy and paste back and forth until I finally get the syntax worked out. I can explore the ideas in the second (or sometimes third) instance of Inform and just test that part of a larger project.
When it finally works as expected, copy and paste into your main project. It has become my standard workflow.
Forgot to add… if needed I will create a copy of an extension and use it in the test instances when I need to modify the extension. I break a lot of things. 