Perhaps I am being thick, but I still don’t understand a simple phrase like “stop the action”. Suppose I have this rule:
Carry out taking the apple:
say "Nope.";
stop the action.
The result is:
Why oh why does stop the action not, well, stop the action? How does one stop the carry out rulebook from proceeding? (Hint: “instead” equals “stop the action” and doesn’t work, and neither does “rule fails”.)
Sure, I can get around this by making it a “Last check” rule instead – but why is there a difference between the check rules and the carry out rules anyway? They’re both just, you know, rulebooks?
I started out by writing a long post about considering and abiding by – and then I suddenly realised that, yes, I am being thick. My rule does end the Carry out rules, but the “Taken.” is printed by a Report rule. How embarrassing.
I would still like to discuss the advice quoted by Andrew, because it leaves me unsure how to handle a common situation.
Apparently, it would be a best practice to use carry out rules only to add something to an existing action. Suppose I want to (a) replace the standard behaviour of an existing action in situation X, but also want (b) all the normal check rules to run and Inform to increase its count of how many times we have done this action. What kind if rule should I write?
Not a Before rule, obviously.
Not an Instead rule, because I want all the normal check rules to apply.
Not a Check rule, because I’m not checking whether it’s possible.
Not a Carry out rule, according to the manual, and also because it won’t stop any of the standard report rules from firing.
Not an After rule because I don’t want the normal action to take place.
Not a Report rule, because that is only for printing text, and it’s too late to block the normal action.
I suppose you could write a First carry out rule and a First report rule, both of them blocking the rest of their specific rulebooks from running – but that is not very elegant, is it? How do you guys handle this?
I suppose you could redirect the action to a custom rulebook.
Carry out original verbing when conditions X are true:
abide by the alternative verbing rules.
Alternative verbing is a rulebook.
Alternative verbing: do this and that; rule succeeds.
That would still count as a successful act of original verbing, I think.
As an I7 newbie myself I might be totally missing your point, but I think instead rules do exactly what you want. I’ve just downloaded at job Nyx’s portable I7 from this thread and tried just this:
[code]
Location_01 is a room. South is Location_02.
An apple is a thing in Location_01.
Instead of taking the apple for the first time: say “Nope”.
Instead of taking the apple for the second time: say “Nope, I won’t take the apple for the second time.”.
Instead of taking the apple for the third time: say “Nope, I won’t take the apple for the third time.”.
Instead of taking the apple: say “Oh, please…”.[/code]
You can check that instead rules get the count properly and check that the apple is present (try getting it in the other room). Or perhaps you mean some other thing I didn’t understand.
Hm, well I view having the action do something which is a variation on the norm, based on situation, as ‘adding something’ - you’re adding a possible outcome. So part of me says, if you want all the checks to run, do this at the ‘carry out’ stage. Though that goes against my instinct, which is to do anything checky at the check stage.
Overall, though, I admit the Inform programming style I’m developing is very non best practice, because it seems to make life easier for me.
It’s extraordinarily rare I would do something at the ‘report’ stage other than report on an action, because that’s too anti-intuitive, but whether I actually execute an action at the check stage or at the carry out stage is something that just arises intuitively based on the programming of the action. Some of my actions are check heavy, others are carry out heavy. I often find it painful or against my intuition (or organisationally annoying) to divorce the moment of deciding what to do with the execution of the response, which Inform often encourages at multiple levels. I would say most often, I’m assessing stuff at the check stage, and both executing and reporting on it there as well. I actually write almost no report rules, except for character movement.
I don’t think I ever (well, maybe once!) use mechanisms which are based on responding to the success or failure of actions as decided by inform. I know if the action succeeded or failed in terms of game meaning - the game’s already acted accordingly. Using ‘instead’ to instantly branch off to execute my desired action at the moment it’s relevant is way too handy and attractive to me to worry about the fact that behind the scenes, inform says ‘that action failed’ when I do use ‘instead’. But what inform thinks of that status is irrelevant in real terms unless I ask it what it thinks.
With my approach, inform can’t necessarily keep accurately track of how many times the player has performed actions. This doesn’t worry me, because in cases where I don’t care - I don’t care, and don’t ask. In cases where I do care, I don’t use the ‘for the third time’ type phrases to try to count the times executed. I throw a numeric flag on the action and just have one line of code which increments the flag whenever the action is carried out. This is quite foolproof - I don’t need to worry about whether inform considered that the action failed or succeeded or was indecisive - when you tell a flag to increment, it increments.
So this may sound like a trainwreck approach to some of you, but I’ve got 10s of thousands of words of code of a game-in-progress that’s working great. Inform 7 is ultimately another programming language that you can use how you see fit to achieve your aims. I wouldn’t discourage anyone from trying to follow best advised practise from the outset, especially if new to programming in general, as it will help you sort your thoughts. But as I’ve found out (and with other programming background) if it makes you more productive to do things in non-standard ways or suits your style, I wouldn’t worry about wiggling things between check and carry out stages. I’ve wiggled way more than that!
Good to know that they do increase the count (one thing less to worry about), but they are certainly not considering the check rules. You say that Inform checks whether the apple is present, but that is actually not done with a check rule: the action will only apply to a visible thing because of how the action and the grammar were defined. The actual check rules (such as the rule that stops you from taking something you already have) are not considered, as you can check by running your example with the apple already carried by the player. The order of the rulebooks is the following:
so you can see that Check rules can never fire before Instead rules.
I don’t really worry about it, but I’m curious about the design philosophy here. Also, wiggling is okay, but only if I know what the consequences are. Until recently, for instance, I wrote “Instead of examining X:” all the time, instead of the cleaner “The description of X is”. Doesn’t make a difference, right? Well, it starts making a difference once you begin adding new behaviour to the examining action, which is what I recently did.
Going through my code and changing those instead rules into declarations about the description of objects wasn’t a big deal, of course, but it definitely taught me that using Instead rules can cause bugs. This may not be a significant problem for games that consist mostly of special case code, but I’m writing a pretty large game full of general systems that interact with each other, and which should always allow new systems to be added in easily. In such a game, using the wrong kind of rule can trip you up. So that’s why I have become more cautious and more curious about best practice.
This may be hacky and may not work, but how about setting a flag in the Carry Out rules that you check with the first After rule?
Like this:
[code]Interrupting is a truth-state that varies. Interrupting is usually false.
After doing something while interrupting is true (this is the interrupt rule):
stop the action.
The interrupt rule is listed first in the after rulebook.
Carry out taking the flour:
if the toque is worn:
say “Your toque wobbles so much that you can’t pick the flour up.”;
now interrupting is true;
stop the action.
Every turn:
now interrupting is false.[/code]
This has worked in the one case in which I tested it. [EDIT: Obviously if you have a rulebook that runs between Carry Out and After it won’t work.]
Hm, interesting. It could be made less hacky by defining a general “interrupt the action” or “really stop the action” phrase, and running the appropriate rule between all of the 6 stages of action processing. Something to think about.
Heh. That sounds like the kind of advice which anyone who needs it, should not need – if you understand what I mean.
If I were going to go that route, I’d probably use action variables.
But what I commonly do is create a new action and redirect to it with a check rule. If you want all the regular check rules to apply, then you make it a last check rule. That’s pretty much how “removing it from” is handled in the Standard Rules, for example.
Check rules are nicely set up to handle this sort of thing:
Last check taking the apple:
instead try picking the apple
If I remember correctly, this will count as a successful action if picking the apple succeeded.
You can even mix in some rules from the original action:
Carry out picking something:
if the noun is not part of the apple tree:
follow the carry out taking rules;
otherwise:
....
Ouch! That’s not only right but has cuased a bit of a panic here My first I7 attempt was made for a speed-comp and used instead rules for almost everything as they were the first rules I understood how to work with. In fact I resolved their very first mess just a few days ago. Some vital events in my work were triggered when “instead of examining” certain objects “for the first time”… I wasn’t aware that the player could try to examine the object while she is in the dark, which would increase the counting but cause the event never to happen at all 'cause when the object is succesfully examined under the light it could be the second or third time, but never the “first time” again! Luckyly there were nice workarounds for all cases (and I’ve triple-checked now that none of the remaining instead cases require taking objects the player could be already carrying! )
Anyway, if I haven´t misunderstood you (again ) “Last check” is your friend now. It increases the count, run through the check rules and allow you to do whatever you want at that stage, including stopping the action. Sticking to our “taking the apple” example, now I tried this:
[code]
Location_01 is a room. South is Location_02.
An apple is a thing carried by the player.
Last Check taking the apple: say “Nope.”; stop the action.
Instead of taking the apple for the third time: say “Yeah, the counting seems to be doing fine!”[/code]
I’ve added an instead rule to state when a certain counting has been reached so we can experiment when It’s increasing and when not. Now the checks rules have effect (they’ll correctly warn you if you try to get the apple while carrying it) and the action is stopped in any other case. You can do what you want here. Diverting to another action, as Capmikee has exposed, adds tons of versatility. Anyway, I’m still learning most of these things on the fly, so I could be totally wrong!
How embarrassing.
My first I7 attempt was made for a speed-comp and used instead rules for almost everything as they were the first rules I understood how to work with. In fact I resolved their very first mess just a few days ago. Some vital events in my work were triggered when “instead of examining” certain objects “for the first time”… I wasn’t aware that the player could try to examine the object while she is in the dark, which would increase the counting but cause the event never to happen at all 'cause when the object is succesfully examined under the light it could be the second or third time, but never the “first time” again! Luckyly there were nice workarounds for all cases (and I’ve triple-checked now that none of the remaining instead cases require taking objects the player could be already carrying! 
)