I have two related questions, hopefully fairly easy to answer.
[1]My player has in inventory 6 sling bullets and 1 sling. When I enter X BULLET, all is well: I get the description of a bullet. When I enter SLING, I am asked which one: SLING or SLING BULLET. These are two different things! How can I get the parser to not equate them?
[2] I have a general kind called SKEIN. I have a subkind called WATER SKEIN. I want to include the SKEIN description within the WATER SKEIN description so I say
Description of skein is "A bota-like waterproof bag for holding liquids.".
A water skein is a kind of skein. The fullness of water skein is usually completely full.
Description of water skein is "[description of skein] This waterproof leather bota can hold a quart of water, wine, or some other liquid. Currently, it is [fullness] of water.".
The parser is choking on the description of skein included in the description of water skein. Can’t the kind be an umbrella over the subkind descriptions?
When you named these Sling and Sling Bullet, you told Inform that “Sling” is a valid way to describe the sling. Meanwhile, “Sling“ and “Bullet” are both valid ways to refer to a sling bullet. You have some options for easing the issue here:
The Garden is a room.
A sling bullet is a kind of thing.
The sling is a thing in the garden. In the garden are 6 sling bullets.
Does the player mean doing something with a sling bullet: it is unlikely.
Or:
The Garden is a room.
A sling bullet is a kind of thing. A sling bullet is usually privately-named. Understand "sling/-- bullet" as a sling bullet.
The sling is a thing in the garden. In the garden are 6 sling bullets.
The first tells the parser to deprioritize sling bullets. The second removes Inform’s default name tokens and has you define your own: what I put there says that a sling bullet can be referred to as “sling bullet“ or “bullet” but not “sling“. Between the two it might be best to use the former example. The last thing you want is for a player to be in a room with sling bullets but no slings and for the parser to not understand “sling“ as the sling bullets which surround them.
I believe what you are setting here is a default description for a skein. It can still be changed throughout play, and thus you cannot reasonably trust Inform to know what the description of an entire kind is. You could try this, though!
The Garden is a room.
A skein is a kind of thing. A water skein is a kind of skein.
The description of a skein is "[skein-description].".
The description of a water skein is "[skein-description]. This waterproof leather bota can hold a quart of water, wine, or some other liquid. Currently, it is completely full of water.". [I didn't use the fullness property here because you didn't define it in your example code.]
To say skein-description:
say "A bota-like waterproof bag for holding liquids";
A water skein called the old water skein is in the garden.
I feel like I have leveled up as an Inform programmer! Lots of new (or not familiar syntax structures). For the first issue, I like the second one better, closer to my understanding. I will be doing things with sling bullets, like loading the sling. Damage from a sling attack depends on what is used as ammo: bullets, stones, etc.
A sling bullet is usually privately-named. Understand "sling/-- bullet" as a sling bullet.
What does privately-named actually do, and what does the Understand statement do? I am not familiar with that syntax.
I really like your solution for the skein-description. Gotta use that! (I have other similar cases.)
You can also call it sling-bullet if you want. Especially if it’s privately-named and has a different printed name; then you can call it whatever you want and the player will never be exposed to its name.
When you create a thing in the Inform world it will typically get the name that you have given to it while defining it and turn every word included into little nouns which the parser will match to it. If I wrote “The red ball is a thing in the garden“ then by default “red” and “ball” would both be accepted for commands regarding it. So would “red ball”. And, unfortunately-though-understandably in my opinion, “ball red“.
When you declare something as privately-named… well, the most simple way I could explain it is that you are telling Inform “No. Do not automatically assign those words as accepted nouns for this thing.”. By default, this means that the player can’t type anything which refers to it. The parser can still try to fill in the gaps if you give it nothing to work with and get that thing as a result, but the player would become incapable of explicitly referring to it. “Red”, “Ball”, “Red Ball”, and “Ball Red”; none of it would work.
That’s where “understand“ statements come in. That is you deliberately telling the parser to accept whatever is inside those quotation marks as valid nouns to use for the thing in question. “Red/-- Ball“ tells Inform to accept “(Either “Red” or nothing) Ball”, so “Ball” works and “Red Ball” works but not “Red” or “Ball Red“.
Tobias’ advice is certainly good! It would help you avoid the scarce bugs being privately-named can cause. Although yeah, sadly it’d be a tricky solution with multiple kinds of bullets…
The issue with being privately-named is it can cause some bugs with inherited “understand“ statements from kinds. Would you object to “ammo“ being accepted for your sling bullets? If not…
A bullet is a kind of thing. A bullet is usually privately-named. Understand "bullet/ammo" as a bullet.
A sling bullet is a kind of bullet. Understand "sling/-- bullet/ammo" as a sling bullet.
Yes, sling-bullet might be the best choice. I can think about that later. I did get it to work with this.
A sling is a kind of weapon. Description of sling is ...
A sling is privately-named.
A sling bullet is a kind of ammo. Description of sling bullet is ...
A sling bullet is privately-named. Understand "bullet" as sling bullet.
Now if I examine bullet, sling bullet, or sling, I get the right desription.
I am confused about one thing. If SLING is privately-named, that is, kept invisible to the player, then how does the parser know to say the correct description when the player enters X SLING?
The problem is that description of skein is a vague description. Which skein do you want the description of? You could write description of a random skein to get around that, but then you’ll have an infinite loop if the skein randomly chosen happens to be a water skein.
Privately-named means that the name given to that object in the source code is not automatically injected into the parser as a means to refer to that object. In other words, a privately-named object cannot be referred to by the parser unless you give some other way to refer to it. The Understand rule does exactly that, giving a way for the parser to refer to it.
