Hi Anton, another resource that might help – though you might find it frustrating – is the index. The Rules, Actions, and Scenes tabs each contain a description of rulebooks. In the rules tab, you can click on the plus sign to the left of the rulebook name it’ll show you the rules that are currently in that rulebook. In the actions tab, if you click on the magnifying glass after the action’s name, it’ll list the rules that are in the check, carry out, and report rulebooks for that action. In the Scenes tab, I guess you also want to click on the magnifying glass if you actually have any scenes in your project.
The documentation might also have some more useful information for you – section 18.1 actually does have a list of all the rulebooks, and section 18.6 has the syntax for new rule headings. The Inform Rules Chart (pdf) would probably also be useful; it shows you what order the rulebooks are actually processed in. (Best viewed on a monitor that’s a lot bigger than my laptop screen; it’s huge.)
[UPDATE: Felix also mentioned reading through the standard rules; I recommend looking at Appendix A, which is an annotated version. But I do find the prospect of reading through them all a little intimidating myself.]
I don’t really speak I6, but guessing at what you’re trying to do, most of the specific things don’t seem too bad. For the multiple conditions with a rule, you can just use “or” [and as gravel points out, you don’t even need that]:
An appliance is a kind of thing. An appliance is usually scenery. Instead of taking or pushing or pulling an appliance, say "It doesn't budge." Instead of pushing an appliance to, say "It doesn't budge."
Or, as you can see there, you can split it up into separate rules. We can’t put “pushing an appliance to” in with the rest, because the syntax is slightly different, but we can break it out into its own rule. And if we wanted, we could break everything into its own rule:
Instead of taking an appliance, say "It doesn't budge." Instead of pushing an appliance, say "It doesn't budge." [etc.]
but that would be tedious.
The “with name” business is very straightfoward:
Understand "bed" and "covers" and "sheets" as the bed.
The “understand” as machinery can get very powerful if you start adding conditions and text substitutions and relations and the like, but a case like this is simple.
One of your rules for reporting entering and exiting the bed is pretty straightforward, the other a bit less so. Here’s the first:
Report entering the bed:
say "You slide under the covers and wrap your legs in them. Careful not to wake up Terry.";
What “rule succeeds” means is that, when this rule runs, the “report entering” rulebook stops. (See section 18.10 of the rulebook.) So the standard reporting rule doesn’t run. This rule runs before the standard report entering rule because it’s more specific; it’s about entering the bed rather than entering just anything.
Here’s the second:
Report exiting when the container exited from is the bed:
say "The bed creaks a little as you step out of it on the right, 'your' side.";
The tricky thing is that you can’t write “Report exiting the bed” because “exiting” isn’t an action that applies to a thing; it just means exiting whatever the player is in. But you can’t write “Report exiting when the player is in the bed” because, by the time the report rule runs, the player isn’t in the bed anymore. What I did was to look up “exiting” in the Index (under the “Actions” tab) and see, when I clicked on the magnifying glass, that it had a “named value” called the “container exited from.” That’s what I needed to use here – whenever you exit, “container exited from” stores, well, the container you exited from, which is exactly what we need here.
The other multiple conditions within the rule is also pretty straightforward the way you have it now; you can do it with an “if/otherwise if” structure:
Before going in East End:
if the player is in the bed:
try exiting; [again, you don't actually need "exiting the bed," since the action "exiting" exits whatever the player's in]
otherwise if the noun is the bed and the player is not in the bed: [this was something where I wasn't quite sure what the I6 meant, so this is a guess at what you're trying to do]
try entering the bed.
However, this is a case where it would really be much better to use two rules instead of one. And one of the things about the rulebook structure is that you can in fact break down your rules into as many different ones as you need; you don’t need one big Before rule for the whole object or room. (Actually I don’t even know whether you can do something similar in I6.) So I would write:
Before going when the player is in the bed: try exiting.
Instead of going the bed: try entering the bed.
You don’t need to refer to the room here, because you want this to apply whenever the player tries to enter or exit the bed, no matter where it is; of course in this case the bed will never leave the bedroom. I also left out the “if the player is not already in the bed” condition, because the Standard Rules already generate a useful failure message for entering the bed when you’re in it (“But you’re already in the bed.”) Also note the difference between “Before” and “Instead”; the first rule is “Before” because we want to exit the bed and then continue with the going action the player tried. The second is “Instead” because once the player has entered the bed we don’t want to try anything else. “Before” rules by default continue the action after they’re done, “Instead” rules by default stop it, so that’s what we want.
Now the second rule probably doesn’t do what you want. I’d guess that you want to catch “GO TO BED” rather than “GO BED,” but “GO TO BED” isn’t recognized as default. We can catch this thus:
Understand "go to [something]" as going.
Now “go to bed” will be processed as going bed, and that will be redirected to entering the bed, which is what we want. (“GO TO EAST” will also be processed as going east, which seems fine.)
Now, an annoyance: You can’t have overlapping kinds in I7. That means that you can’t make the bed both an appliance and a container, unless you define appliance as a kind of container, which you probably don’t want to. One way you can get around this is by defining an adjective, “appliancey,” and using your “It doesn’t budge” message when you try to shove around an appliancey thing:
[code]A thing can be appliancey. Instead of taking or pushing or pulling an appliancey thing, say “It doesn’t budge.” Instead of pushing an appliancey thing to, say “It doesn’t budge.”
The bed is an enterable open transparent appliancey container.[/code]
This can lead to other problems – for instance, I don’t think there’s a way to make all appliancey things scenery, so you have to add that by hand – but I think it can be made to work.
Hope this helps! I’m by no means an I7 expert, but it looked like at least some of your problems were relatively straightforward in I7, as long as you know what to do. You might want to find someone who understands “rule succeeds” a bit better than me, though.