There are leaves on the tree. I want the player to take some.
However, if he goes east, drops them, and comes back, I don’t want the tree to be barren as winter now. Surely he couldn’t have taken them ALL.
If leaves are scenery, he can’t take them – if they are out east they can’t also be on the tree, and so forth. Is there a way to deal with this?
thanks!
This is a classic problem in IF – not classic as in “hard,” just classic as in “everyone asks this question at some point.” Like most classic IF problems, there are a couple of examples of how to deal with this in the Recipe Book (see Ch. 10.3 “Dispensers and Supplies of Small Objects”). Both involve having an object to represent the collective group, and an object or objects to represent the takeable thing – initially off-stage and moved into play as needed. The first one, “Extra Supplies,” uses a singular object (a pen) which you could easily change to “a handful of leaves.” The second example models individual slices of pizza which allows the player to have several at a time with a hard limit. (The supply is replenished with any slice the player happens to eat.)
Neither of these examples implements a truly infinte supply of something. This would entail what is referred to as “dynamic creation of objects” – objects which are not defined ahead of time, but created at runtime (while the player is actually playing the game). Inform does not support this as a standard feature. There is an extension – Jesse McGrew’s “Dynamic Objects,” available on the website – for this which is tres cool, but probably over - kill for what you need. Ask yourself, do you really want or need to have your players running around dropping hundreds of leaves everywhere in the game just to see how many are available? (They will, too, I promise.) In most cases, a limited supply will be enough for the player to consider the matter sufficiently implemented, without tempting them to go all leaf - crazy on your game. To paraphrase Zarf, “There’s a reason why Inform has gotten along without truly dynamic objects for 15 years.”
I want to add that I’m not trying to steer you away from extensions in general or that one in particular. In another thread – not sure if it was to you or not – I might have given that impression. Most of the extensions represent kick - ass, easy - to - use solutions to what are generally painful problems. Some newer authors are afraid to use them because (I guess) they figure, “I don’t fully understand the standard package, so why try an extension?” This is absolutely not the case. Graham’s philosophy with I7 is to leave most of the more complicated, unusual, or simulationy - type things to extensions, leaving the standard rules to deal with the most universal stuff. Also, for me personally, opening up extensions to see how they work has taught me a ton about the language. Definitely use them. Just not in this case. Unless you want to. 
(Sorry for such a long - winded response to what was really a simple question. Five thirty am does that to me sometimes.)
Here’s one way you could do it:
[code]Garden is a room.
A tree is here. “A tree grows in the middle of the garden. [status of foliage].” The description is “[status of foliage].” The tree is fixed in place. Understand “branch” or “branches” as the tree.
To say status of foliage:
if all of the handfuls of leaves are on-stage:
say “It has been stripped bare of leaves”;
otherwise if almost all of the handfuls of leaves are on-stage:
say “Nearly all of its leaves have been stripped”;
otherwise if most of the handfuls of leaves are on-stage:
say “More than half of its leaves have been stripped”;
otherwise if some of the handfuls of leaves are on-stage:
say “Some of its leaves have been recently stripped”;
otherwise:
say “Its branches are full of green leaves”
Some growing leaves are part of the tree. Understand “foliage” as growing leaves.
Understand “take [growing leaves] from/off [tree]” as removing it from.
Understand “get [growing leaves] from/off [tree]” as removing it from.
Understand “remove [growing leaves] from/off [tree]” as removing it from.
Understand “pull [growing leaves] from/off [tree]” as removing it from.
Understand “strip [growing leaves] from/off [tree]” as removing it from.
Instead of removing the growing leaves from the tree, try taking the growing leaves.
Instead of taking the growing leaves:
if there is an off-stage handful of leaves:
move a random off-stage handful of leaves to the player;
say “You strip [if there is at least one off-stage handful of leaves]a[otherwise]the last[end if] few leaves from the tree’s branches.”;
Instead of doing something to the growing leaves when there are no off-stage handfuls of leaves:
say “The tree is completely bare.”
A handful of leaves is a kind of thing. The plural of handful of leaves is handfuls of leaves. There are 50 handfuls of leaves.
[/code]
Michael Gentry:
Nice! Not only is this helpful, but I really like “instead of doing something to” – a functionality I didn’t know was there.
Skinny Mike:
I will check out those chapters, thanks for the info! I am still scared of extensions, but it sounds like I shouldn’t be.
As I’ve said in another thread, I’m making this game as a Christmas present. I’m making some mistakes – for example, I used an awful lot of “instead” code before I realized exactly how it should be used – but I’m hoping to produce something on time and functional (I’m testing each piece to death to avoid bugs) if not elegant.
My second game, however, shall be perfect AND elegant! And will use extensions! 
Thanks so much for everyone’s help. I really am learning a lot in a short amount of time. I love the way Inform has an easy learning curve, even for more complicated tasks.
This is a good thought, too, Mike. If I was playing a game with 50 handfuls of leaves available, I might assume that I was supposed to create a big leaf pile somewhere and then jump out of an airplane into it, or something (hm, there’s a thought for a future game).
For now it seems like 3 or 4 or 5 handfuls would prevent the weirdness of seeing a barren tree upon the second trip into the room, or forgetting where you put the leaves and going back for more only to find the tree bare.
Just now getting around to integrating this into other parts of my game. Actually the leaves are fibers, and the tree is a banana plant, and you need to remove them with a knife instead of by hand. I used the exact code provided by Michael and added my cutting code. Undesirable thing:
After cutting the fibers once, doing something to the fibers again defaults to the handful.
I tried this:
Instead of cutting the handful of fibers:
silently try taking the growing fibers.
But it wouldn’t be silent about it:
>cut fibers
(the handful of fibers)
You use the knife to strip some of the fibers from the banana plant's stem.
Ugh, I hate those parethesis-generated implicit action thingies. They almost always screw up my code.
Any ideas?
This parenthetical has nothing to do with implicit actions. It’s generated by the “clarifying the parser’s choice of something” activity described in ch. 17.28. Basically, when the parser chooses a noun from multiple possibilities, it prints the full name in parentheses. This can be supressed with something like:
Rule for clarifying the parser's choice of the handful of leaves when cutting: stop.
Well, it implicitly chose from among the possibilities, though, didn’t it? Otherwise it might have said “Which fibers, the growing fibers or the handful of fibers?”
Anyway, thanks for that fix!!
It’s not just a semantic issue. The term “implicit action” does have a specific meaning in Inform. An implicit action is when the game makes you do something you didn’t explicitly tell it to do, such as taking an object before you wear it:
>wear the bark cloth
(first taking the bark cloth)
You put on the bark cloth.
The distinction is important because there are sections in the documentation that talk about implicit actions. If you were to look in those sections for an answer to the problem you mentioned, you would not find anything.
Ah, I see. I was just thinking the compiler had performed an implicit action in choosing something from among confusing possibilities without getting my explicit instruction on which thing. Thanks for the clarification.
Hello again!
While testing this bit, I discovered that something wasn’t working as I intended. After you strip one or more handfuls of fibers from the tree, and weave a hat, I’d like to remove at least one of the handfuls of fibers from inventory because intuitively, it was used to make the hat.
I had had this, which didn’t throw an error but didn’t remove the fibers, possibly because it was removing the growing ones rather than the handful? I’ll have to test that again to see. (Edited to add: yes that’s what it’s doing)
Carry out weaving "[hat-names]":
If the player is carrying the handful of fibers
Begin;
say "You weave the fibers into a crude hat. It looks terrible, but it's serviceable.";
remove the fibers from play;
move hat to player;
Otherwise;
say "You don't have anything to weave with.";
End if.
I tried switching to this:
Carry out weaving "[hat-names]":
If the player is carrying the handful of fibers
Begin;
say "You weave the fibers into a crude hat. It looks terrible, but it's serviceable.";
remove the handful of fibers from play;
move hat to player;
Otherwise;
say "You don't have anything to weave with.";
End if.
But then I get this:
Problem. You wrote 'remove the handful of fibers from play' , but 'handful of fibers' seems to be an object matching a description, whereas I was expecting to find the name of an object there.Incidentally the “if” condition is working, and it’s using the same object.
What’s going wrong here?
Thanks!
I suspect that you may have accidentally created a named object called “fibers” that are in the tree but when the player takes them they get “handful of fibers” that is a kind of thing (you can confirm this if you view the game’s objects in Index -> World). Anyway, the correct syntax is
remove a random handful of fibers carried by the player from playOr, more elegantly perhaps:
If the player is carrying handful of fibers (called those fibers):
remove those fibers from play.
Perfect Nitku, that works. Thanks so much.
Back to this topic:
Rule for clarifying the parser's choice of the handful of leaves when cutting: stop.For some reason this didn’t work for:
Rule for clarifying the parser's choice of the purple treasure when inserting: stop. I also tried “inserting it into” and “inserting it into the container” and some other things.
Not a huge deal, but I find the reporting awkward. If I’ve done a good job saying how “likely” actions are, and I’ve reported in my own code, I shouldn’t need Inform to report too.
In reality, I’m inserting a bunch of similarly named things in the same container throughout the game, so even if I can get something to work I might need to write it 12 times.
There isn’t anything like this available, is there?
Rule for clarifying the parser's choice: stop. I think I could stand to have it never report on anything.
Advice on the former problem or the latter idea appreciated.