This seems to be a partial solution, something from an earlier thread I opened:
This seems to make everything happy, because as Blecki explained later, now all the objects are “expanded”. Unfortunately, this only works for items that already exist at the start of play. If items are being programatically generated by loot tables… how to apply this concept without a loop that needs to run at a particular time so that just every thing that ends up existing, at any time, always benefits from being expanded?
Turns out that this understands every durability term as describing every armor object – with a side effect of setting “the durability understood” to the term that the player typed. This is definitely not what you want. (It might be useful in some other case.)
Aha, ok, well that explains that. I could go that route, but actually expanding everything improves the readability of items that are auto-genereated and differentiated by properties so I think I’ll still go that route.
I made it run every turn on only visible items, instead of only at the beginning on everything, or on everything every turn which would be totally crazy…
Every turn:
repeat with item running through visible things:
now the indexed printed name of the item is "[item]".
Understand the indexed printed name property as describing a thing.
A thing has an indexed text called indexed printed name.
I still feel like there might be some problems here regarding things that are not visible, but still might be typed into commands… I can’t think of the use case, but I’m sure it will come up. So, I wonder if there is still a better way to essentially do the above, but get all things without too much processing overhead?
Edit:
I thought about doing the loop on all items in the current room… but is “current room” not an inform convention?
Every turn:
repeat with item running through things in the current room:
now the indexed printed name of the item is "[item]".
Understand the indexed printed name property as describing a thing.
A thing has an indexed text called indexed printed name.
It doesn’t like “things in the current room”. What would be the syntax for that?
(In general “location of X” is the room where X is. But we refer to the room where the player is all the time, so you can refer to it as “location” for short instead of having to write out “location of the player.”)
Beating a dead horse here, but in the Inform 7 documentation, it feels like I would have to know the answer to my questions to be able to find the reference that would answer the question. I looked at “rooms”, and tried the search term “current room”, “this room”, etc… but If I knew the search term “location”, I would already have known the answer… learning to write IF is a lot like playing IF I guess… a lot of confusion and wondering why all the words I’m typing in don’t seem to lead to any joy! ha…
Don’t get me wrong, I’m not complaining to you or any of the big shots of Inform who made all this really… just venting my own woes, not demanding better… this is free after all! The people that write the big programming languages get, uh, paid… and there are lots and lots of them with a whole organization driving their efforts. It’s impressive that languages like Inform even exist, really. Just want to make that clear. That doesn’t mean I don’t WISH there was something as good as Microsoft documentation for C language for Inform … I can want things that are unreasonable, it’s my right (to want them, not have them)!
Besides, folks are really patient and helpful on this forum!
Yes, I find that I have the same problem with documentation for big commercial software. Like, I’m pretty sure there’s a way to take a spreadsheet in Microsoft Excel and flip it so the rows are the columns and vice versa, but I can’t find it in the help file without knowing what it’s called already. (It’s not “rotate.”) (No wait, it is “rotate,” but you can’t find it by searching the help for “rotate” because it’s in an image, you have to search for “align.”) (Except the specific things that this help thing is telling me to do aren’t actually in this copy of Excel AAARGH FRACKING MICROSOFT I’m incredibly frustrated now and I don’t even actually want to do this thing.)
OK, maybe Microsoft wasn’t the best example, but it’s hard to index documentation so you can always find an answer if you don’t know the word for it.
Ok, so now a new problem has come up with there being lots of the same kind of thing.
I wanted the player to be able to examine different kinds of things, like sorting them. So, I added understands for kinds. Usually, if an item is held by a person, the item doesn’t get listed in an examine “” as in:
look
… it just list the stuff that isn’t carried or worn.
After adding ‘Understand “armor” as armor.’ it starts listing stuff that is worn or carried. I could live with this, and even call it an accidental “feature” I suppose, except that when it does this, it doesn’t list all the items worn or carried… it only lists one instance of a kind.
So, if more than one person is wearing a leather chest piece, and the player types >look armor, it will only automatically assume one of the armors (I’m not sure which is “first”) is applicable, and won’t try to disambiguate like it does if both are not held. And yes, this doesn’t seem to negatively affect how items not held are processed.
How can I make sure that either a) this doesn’t happen, and items understood are still not listed when held or b) if they are listed, make sure all are listed for disambiguation?
Do you really want carried/worn things to be listed in a LOOK command? If you do, try adding this rule: After looking, try taking inventory.
And I don’t think you actually want a disambiguation prompt here. “Which do you mean, the leather chest piece, the leather chest piece, or the leather chest piece?”
I do though… now that I’ve thought about it some more, I actually would like every item to be able to be listed, even worn items. Each leather chest piece isn’t going to be the same. Each can have different properties, so the player needs to be able to look at different items, even held ones, and know which is which.
I added this rule but it is not quite right:
Before printing the name of a thing held by a person (called owner):
if owner is the player:
say "your ";
otherwise:
say "[owner]'s ";
The player will want to be able to distinguish the condition and other qualities of items to determine the strength of their foe or other considerations based on more specific information about the items the character has.
So, if you type:
look armor
I’m hoping for a result like:
Which do you mean, your damaged leather chest piece or Imperial Soldier’s perfect leather chest piece?
The rule I added though only fakes associating the name of the owner… you can actually see the adjectives in the disambiguation, but it’s still kind of kludgy… I’d rather the player be able to directly reference “Imperial Soldier’s armor” or “Imperial Soldier’s perfect leather chest piece” directly, because maybe the description has more going on, like yes, it’s perfect durability, but perhaps the description could read “seems a little too big for him, perhaps he is quite young and inexperienced.” or some such.
I’m still implementing some part or form of what I’ve learned here in this thread so that there is some centralized function and reuse in how things are described, but I have abandoned the idea of creating instances of a kind without a specific name, as you suggest, Draconis… it creates weird problems in parsing and disambiguating… it almost works, but not quite.
If I ever do get around to making a function to create items, I guess what I’ll do is have it give them numbered IDs and do some kind of loop to verify that the id is not already in use by another item before assigning it. Working on other things first before getting to that level of complexity though.
That’s not a very Inform 7 way of doing it. If you really want to use a function to create items, you might try Jesse McGrew’s Dynamic Object Creation.
Having a stock of “blank” items off-stage is a perfectly I7 way of doing things. It’s simpler. The dynamic creation stuff is for when that is insufficient.
… I can want things that are unreasonable, it’s my right (to want them, not have them)! 