Thanks! OK, here’s a fairly detailed explanation.
So I began by looking through your demo code.
‘eating’ is a built-in action in Inform, but Inform does not understand ‘has eaten’ or ‘has been eaten’ out of the box.
(I thought it might understand ‘has been eaten’, the way it understands ‘has been open’… see 9.13 in the documentation… but it doesn’t.)
I had to remind myself how Inform eating works. The way it works is that if you have made a thing ‘edible’, eating it will eat it and take it out of play. (Documentation 3.22) If the thing hasn’t been made edible, attempts to eat it will be rejected.
So in the source, I put a toadstool in the field, and made it edible. Information we need to track about it in the future includes:
-
has the player eaten it? (a cheap way to detect this might be to check whether the toadstool is now ‘out of play’ or ‘nowhere’, where it automatically goes when eaten, but to be a bit more rigorous, I’ll have a flag – a truth state – set to true when we eat it. Because what if we dropped it off a cliff elsewhere in the game? It would be ‘out of play’, but we would not have eaten it, so that would no longer be a valid way to check that we ate it.)
-
IS the player currently poisoned from eating it?
-
has the player vomited it up?
A good place to store information about the toadstool is right ‘in’ the toadstool itself. So I’ve made three truth states that record the three bits of information above, flags that can be set true or false, on the toadstool. Apologies, I forget what the name for this kind of variable is (local? object-specific?) and couldn’t find it quickly in the documentation:)
Since we want something non-standard to happen when the toadstool is eaten (poison the player and say that it tasted bad) I’m using an AFTER rule to get the job done.
‘After eating toadstool:’…’
An after rule will print its messages instead of the standard report message for the same action, and allows us to do extra things in code, too. In this case, set the ‘eaten’ and ‘poisoned_you’ toadstool flags to true.
The next thing you wanted was a message about feeling sick. I can already see a shortcoming in my program: If you pick up the toadstool, go east and then eat it, you’ll never get the warning about being sick, because I set the warning to only appear when going east from the meadow when already poisoned. So fixing that can be homework for you.
There are a couple of fiddly things about the sick message as is.
First, it’s often difficult to recall and use the right phrasing to get Inform to act on players going to/from rooms.
I found that ‘going east from meadow’ worked.
‘going east in meadow’, which I tried first, compiled, but did not actually work to print the message. ‘going’ in general is the action to use for this sort of thing, however. ‘entering’, like you tried, is generally more for containers and supporters and non-room things in Inform.
The line that dispenses the sick message is not one that reads logically to humans, but it makes Inform sense:
‘Report going east from meadow when poisoned_you of toadstool is true for the first time:’
This line first looks for these circumstances: You’re going east in the meadow, and poisoned_you of toadstool is true. Let’s call that clause A.
It then looks for this additional circumstance, clause B, which is… you’re satisfying clause A for the first time. Therefore, the second time you satisfy clause A, this report will NOT happen. (See documentation 9.14 ‘How many times?’)
The icing on the cake of this demo is the creation of vomiting. This is not a built-in action, so we have to make it from scratch, and set the words that will lead to it.
I’ve created the default response to vomiting with the line ‘Report vomiting:’
To create the specific response for vomiting when you’re poisoned, I again use an ‘after’ rule, recalling that it lets you print a non-standard message for the action, overrides the report message, and runs some code.
-Wade