Yes, of course! I’d forgotten the magic word “usually”. 
If you never want exceptions, you can also say “always”, which prevents any subkind or individual instance from changing it!
1 Like
I would probably suggest adding a column to the table that would correspond with the UID and be the printed name/printed text of what you want the player to see. Perhaps something like this
Table of Arms
UID display name cost weight
1 "arrow" 0.2 0.2
2 "xbow bolt" 0.5 0.5
And then if the player sees an unrecognizable UID, you would in that instance look up the display name entry in this table that corresponds to the UID and show that text to the player.
I use that for constants, but I forgot about “initially” and “usually”.
I think this would also allow me to assign the UID to the text name of the object, and another table (or the same one) to associate the text name and the object. This solves two problems for me! 
Just a note: the method of building tables for kinds or even unique items by assigning UIDs and then assigning properties using phrases at the start of the game is just a workaround for the bugs I’ve experienced and described in this thread.
These bugs were already known and fixed for the next Inform release.
This method is therefore temporary and will probably become obsolete in time. Also, I’ve only been using Inform for a few months, so this way of doing things suits my project, but it’s probably not optimal. I think people with more experience than me would probably have better suggestions for each of the use cases in your respective projects.
1 Like
Or to make it even make it simpler, have an off-stage container called “arrowbox” that’s accessible by any location that needs arrows.
You could have a backdrop in every vendor location that has an “arrows for sale display case” container attached so it exists everywhere with the same number of arrows.
To replenish arrows, have a chance if the player misses that the arrow is not recoverable or breaks - it goes to the arrow display case to be resold.
2 Likes
I agree. I have something similar called virtualSpace, which is a room. (I’ve not been able to distinguish between using virtualSpace or nowhere, which is where all things go when not assigned, but I’ve been warned they are not the same).
There is a chance that arrows (or any projectile) of not surviving a shot; like it hits the wall and breaks, so these go back into virtualSpace for later.
“Off-stage” (with the hyphen) is the default location I7 uses for objects that aren’t in play. Anything off-stage cannot be interacted with by the player and can be described as “nowhere”.
If you create an object A magical carriage is a vehicle. but don’t specify its initial location, it is stored in the off-stage until you move it to a room where the player can interact with it. You can also test if the magical carriage is nowhere: now the magical carriage is in the Courtyard. That way if the carriage is already summoned and has been moved somewhere else it won’t teleport by accident.
Any time you have a rule like now the crumpled napkin is nowhere, by default it is moved to off-stage so it’s essentially discarded, but a rule can move it back into play if needed.
This is usually good enough for scene changes and prop storage. If you’ve got duplicates of a thing, you can say
if an arrow is in off-stage:
now a random arrow in off-stage is held by the player;
otherwise say "The weapon seller explains they don't have any spare arrows to sell you.";
There may be reasons to organize things off-stage - for tidiness like an arrowbox or a coinbox - or a specific reason you might want to create an inaccessible room like your virtualSpace, perhaps if you have a ship that sails away it can go to an Ocean location the player can’t get to, but it still needs to be onstage for visible scope so the player can talk about parts of it with a Ship Builder NPC to make repairs.
One use for a hidden container is to temporarily store several different objects that you need to keep track of for use but you don’t know what they will be - say if at some point you need the player to give up all of their random possessions and restore them later.
To pat-down the player:
repeat with item running through things enclosed by the player:
if item is not worn:
now item is in stashbox;
say "'We'll just be holding all of your pointy items and contraband while you converse with the King,' the Guard says, relieving you of all your possessions.";
To return possessions:
repeat with item running through things in stashbox:
now the player holds item;
say "The guard returns all your previously seized items and wishes you good day.";
Doc: 8.10. Removing things from play
Recipe book example Pine 3 also discusses this at the end 4.5. Flashbacks if you want a detailed interactive flashback but need to re-costume the player and change their inventory temporarily and restore it later.
Pine 3 code
Saved location is a room that varies. Locker is a container. Wardrobe is a container.
To strip the player:
now every thing carried by the player is in the locker;
now every thing worn by the player is in the wardrobe;
now saved location is location.
To restore the player:
now every thing carried by the player is in the location;
now every thing in the locker is carried by the player;
now every thing in the wardrobe is worn by the player;
move the player to saved location.
1 Like
Yep! Sounds like want I want!
Thanks.