Thanks a lot, it all works now. I don’t suppose there is any way to script it so Inform does that automatically?
Mmm, I don’t think so. In some cases you could do something involving a table, but you can’t put kinds in tables–unless Object Kinds lets you do that, I’m not really familiar with that extension.
You sort of can. You can have a table of numbers acting as indices to kinds, but these can change between builds of your game, so you’d need to fill in the table at runtime.
Hmm, that sounds like it might be more trouble than it’s worth, and I tend to keep away from tables, generally.
You could make a table originally filled with objects, and have a When Play Begins rule that goes through and fills in the kind indices.
Just came up with an awesome idea, but there is a slight snag: Does anyone know a way to pause a script to ask for the player to say ‘yes’ or ‘no’, like it does when you type ‘quit’?
Yeah, that’s built in; see the part about “If the player consents” in section 11.5 of Writing with Inform.
Cool, thanks it works! :3
I’m suddenly having problems with setting up one very specific relation in my script now though, even though it worked fine earlier. Part of my script allows you to put a item into a machine and have it spit out a different ‘processed’ item. It is identical to the crafting script except that the machine has an additional relation called ‘Object Feeding’ that sends the item to a linked container by saying “The Output Box receives items from the Imput Hopper”. This worked fine for ages, but suddenly Inform has stopped storing the relation, meaning the crafting script tries to send the object to ‘nothing’. This is pretty infuriating but I can’t think of a way to fix it and it won’t accept any version of your ‘when play begins script’.
At the moment the relation reads:
Object Feeding relates one thing to another (called the Machine Output). The verb to receives items from means the Object Feeding relation.But I have also tried:
Object Feeding relates a thing (called Machine Imput) to a thing (called the Machine Output).But this doesn’t compile, even though it is based on an example in Inform’s documentation. This whole thing is kinda infuriating and makes me think Inform doesn’t really handle these relationships very well. Can anyone help me fix it? 
EDIT
Never mind, I solved it by ripping out the relation script and using ‘kinds of things’.
0k, I have one last little tweak I need to sort out (as far as I know ). Basically I can’t get this to compile:
If the Hyperspace Chest contains the craft result:
let the new thing be a random craft result in Hyperspace Chest;
Otherwise:
let the new thing be a new object cloned from the craft result;
I know that Inform is finiky about this kind of thing, but I’m wondering if anyone can think of a way round this that doesn’t use another extension before I launch this.
If craft result is an object, you can’t say “a random craft result”–that only works for kinds (or kinds modified by adjectives or something like that).
This was the issue for which I recommended Object Kinds before, but it’s possible to get a workaround without going to Object Kinds–you just have to create a new relation to represent the fact that two things are of the same kind, set everything that’s of the same kind as each other with that relation at the beginning of play, and then use that to check for things in the Hyperspace Chest. So (I lowered the number of Lup Powders to 3 so you can check that it works once you’ve used up all the Lup Powders in the Hyperspace Chest):
[code]Wizard Shop is a Room. Hyperspace Chest is a room.
Object Transmutable relates various things to various things. The verb to become means the Object Transmutable relation.
Definition: a thing is Object Transmutable if it becomes more than one thing.
Combining Objects is an action applying to two things. Understand “use [something] on [something]” as Combining Objects.
Lup Powder is a kind of thing. There are 3 Lup Powders in Hyperspace Chest.
Powdered Nut is a kind of thing. There are 5 Powdered Nuts in Hyperspace Chest.
Nup Nut is a kind of thing. There are 5 Nup Nuts in the Wizard Shop. Quog is a kind of thing. There are 5 Quogs in the Wizard Shop.
Carry out Combining Objects:
if something (called the result) that is become by the noun is become by the second noun:
if something (called the real result) that is the same as the result is in the Hyperspace Chest:
say “You use [the noun] on [the second noun] and get [a real result].”;
now the noun is in the Hyperspace Chest;
now the second noun is in the Hyperspace Chest;
now player carries the real result;
otherwise:
say “This is where the Dynamic Objects stuff would go, if I knew how to use Dynamic Objects.”;
otherwise:
say “Those don’t combine.”
When play begins:
now every Nup Nut becomes every Lup Powder;
now every Quog becomes every Lup Powder;
now every Nup Nut becomes every Powdered Nut;
now every Lup Powder becomes every Powdered Nut.
Cosubstantiality relates things to each other in groups. The verb to be the same as means the cosubstantiality relation.
When play begins:
now every Nup Nut is the same as every Nup Nut;
now every Quog is the same as every Quog;
now every Lup Powder is the same as every Lup Powder;
now every Powdered Nut is the same as every Powdered Nut.[/code]
Note that we don’t have to use “random” anymore, because we already have to check whether something that’s the right relation is in the Hyperspace Chest, and we can just grab that thing (it shouldn’t matter which thing we grab from the Hyperspace Chest as long as it’s the right kind).
When you put in the code for Dynamic Objects you probably want to check that the newly cloned object has all the “same as” relations as the old objects–I’m not sure how that works. And I should warn you that it’s my understanding that many-many relations can be computationally expensive, so it’s possible that (especially with lots of objects) this could lead to performance issues.
Thanks, I’ll give it a go, but I am wondering if adding all this ‘at start of play’ stuff is going to make things too fiddly and put people off using the extension. Can you think of a way to automate the ‘when play begins’ part of the script? Memory issues are the main reason I was trying to keep objects in circulation and prevent the chest only being a dumping ground for cloned objects, but if object relations are that heavy then I’m wondering if I might be trading one problem for a much bigger one.
Hmmm, this line isn’t compiling, I’m getting the ‘expecting a condition’ error:
if something (called the real result) that is the same as the result is in the Hyperspace Chest:Any ideas?
The code I posted compiled, so something must have changed somewhere. Exactly what error are you getting? Are you sure you defined the cosubstantiability relation and “to be the same as” verb?
As for the other question, I’m not sure there’s any way to avoid the “When play begins” setup with the way you’re doing it. You could try using Object Kinds and doing what Draconis said to have a rule for automatically filling in a table, but I’m not sure how that works myself… And if you want this to be an extension other people will use, it’s probably much better to make a table if that’s possible. It’s easier for extension users to add lines to a table than to go through a lot of declarations about what combines to make what.
Also you shouldn’t take what I say about memory too seriously; I’m really not familiar enough with the inner workings to know what will and won’t cause problems.
Oh yeah, sorry, I didn’t paste it all as I was testing it on the full script. It does work, thanks.
I’m currently rebuilding the script from scratch to make use of your recommendations, and I’m looking for a way to make it more efficient. Is there any way to store the contents of the noun (and all variables attached to it) so I can use it in an external script?
What do you mean by an external script?
What I mean is that the script could be stated as a ‘To’ command somewhere else and then inserted into the main body of the script. For example:
To Something:
If something:
Then something;The reason is that there are quite few repeated scripts in this thing now and they make it hard to debug and alter the main script, which is quite short without them.
Well, “the noun” is a global variable, so if you write a thing like this:
To frumble:
now the noun is bloop.
Then you can call “frumble” in the middle of another rule and it’ll work.
Better yet, you can pass variables to that kind of phrase:
To frumble (item - a thing): now the item is bloop.and then call “frumble the noun” in the middle of another code block.
Is that what you mean?
Yes, thanks, that’s very helpful. Thanks to you the script is all done now and I’m just working on the examples.
Actually, I just have one more little bug I can see. Is there any way to stop an object stacking with another object if it has a different variable attached?