There are a few things here to speak to.
You will need to be careful about how you define arrows as things if you’re also trying to work with duplicates of kinds. If you try to say The player carries 15 arrows and arrow is not a kind, then Inform will literally create one object named 15 arrows and it won’t be what you might assume it is (15 separate arrows).
Lab is a room.
The player carries 15 arrows.
>i
You are carrying:
15 arrows
>x 15 arrows
You see nothing special about 15 arrows.
>showme 15 arrows
**15 arrows - thing**
location: carried by yourself in Lab
unlit, inedible, portable, handled; singular-named, proper-named
description: none
initial appearance: none
printed name: "15 arrows"
printed plural name: none
indefinite article: none
list grouping key: none
“15 arrows” is just a single thing (as confusing as that is to read).
WI 4.14 talks about this trap
Firstly, a counted-out description like “two squares” is only allowed if it combines a number with the name of a kind which is already known (perhaps modified with adjectives, so “two open doors” is fine). If we say:
Two circles are in the Lab.
without having defined “circle” as a kind in advance, then only a single object will be created - whose name is “two circles”. (This is because many natural names start with numbers: “six of clubs”, for instance, referring to a single playing card, or “12 Hollywood Close” meaning a single house. We wouldn’t want such names to be misinterpreted.)
Secondly, if you want to specify a uniform weight and cost for a kind, then I think the technique found here from @Monsieur.HUT may help. Since you are probably not going to be able to specify a kind as a value on a row in a table, you may be able to work around this by giving each kind a unique ID and then pulling the cost/weight out of the table as needed.
Lab is a room.
Orc is a man in the lab.
Ammunition is a kind of thing.
Ammunition has a number called uniqueID.
An arrow is a kind of ammunition. The uniqueID of an arrow is 1.
A xbow bolt is a kind of ammunition. The uniqueID of a xbow bolt is 2.
The player carries 15 arrows.
Orc carries 10 arrows.
The wooden table is in the Lab. The wooden table is an open container.
Table of Arms
UID cost weight
1 0.2 0.2 [arrow]
2 0.5 0.5 [xbow bolt]
When play begins:
say "The orc has [list of arrows carried by orc].";
choose row with UID of 1 in the Table of Arms; [UID 1 = arrow]
say "The orc's arrows weigh [the number of arrows carried by Orc times weight entry].";
say "The player's arrows weigh [the number of arrows carried by the player times weight entry].".
Report inserting something into the wooden table:
choose row with UID of 1 in the Table of Arms; [UID 1 = arrow]
say "The player's arrows now weigh [the number of arrows carried by the player times weight entry].".
The orc has ten arrows.
The orc's arrows weigh 2.0.
The player's arrows weigh 3.0.
[...]
Lab
You can see Orc and a wooden table (empty) here.
>put arrow in wooden table
The player's arrows now weigh 2.8.
You put the arrow into the wooden table.
The issue of course is that you will need to look up the cost and weight from the table with a hard-coded unique ID.
The main gist of the workaround is to try to preserve using duplicates of kinds without resorting to making every specific instance of a kind (the player’s arrows, the orc’s arrows, etc.). You’ve probably already seen this, but you can’t define a kind, give the kind properties (cost as a real number, weight as a real number, etc.), and then specify precise values for those properties. (If arrow is a kind, and arrow has a real number called cost, the arrow kind cannot have a cost of 0.2)
So by moving the cost/weight properties to the Table of Arms, you would do table lookups any time you need to refer to cost or weight of the kind rather than setting the properties on a thing.
Edit: You’ll notice I’ve also done a bit of indirection too. I’ve defined ammunition as a kind of thing, and given the unique ID to the ammunition kind. I think then if you create kinds of ammunition, it allows you to define the unique ID property specifically.
Edit 2: Continuing the previous thought, with that same indirection, you could make cost and weight properties of the ammunition kind, and then set the properties of the arrow and xbow bolt kinds to specific cost and weight values. However, you will probably run into issues when you then need to refer to the cost and weight of an arrow. So given a choice, it’s probably preferable to use table lookups to define and retrieve these property values over having them be set as properties directly.