Comprehensive lists

being not new to IF but very fresh on Inform as such I do have a few issues.
I started out on Inform 6 a few weeks ago and being a programmer it is very doable for me. however, lacking the awesome Windows front-end (using text-editors and compiling seperately etc) it is extremely time-consuming.
Starting with Inform 7 is easy. But after that it gets very hard. For one; the documentation just doesn’t do it for me. It is a very good read, I admit, but I miss a comprehensive overview of the in-built stuff in Inform.
Having taken the approach to use natural language is great. This will lure people without a programming background (ie.creative writers) into making IF.
Nonetheless understanding natural language Inform 7 is quite picky about syntax.
What I am looking for and am not able to find are lists with the built-in rulebooks, phrases, object conditions, adjectives and verbs etc. etc. with some sort of description on how they should be syntaxed and in what order they should be used.
The documentation itself says about the rulebooks: “When we open the casing and look inside the machinery of Inform, what we see are rules and rulebooks. We seldom need to know how this machinery works,”
Well I beg to differ because I compare rulebooks to libs in programming and every lib (so probably rulebooks) have syntax, starting conditions, resources needed etc.
I am sure it’s hidden in the built-in documentation somewhere but I couldn’t find it. (admitting I haven’t ploughed through the complete docs yet)
And I’m also very aware that Inform 7 encourages and has much features to make your own rules and things but I am sure that the tons of stuff already in there makes me very capable of getting it to do what I want.
I don’t want to clog up the forum but here is a little example from my Inform 6 code:

[code]Class Appliance
with before [;
Take,Pull,Push,PushDir: [this is a problem for me. multiple conditions within a rule]
“It doesn’t budge.”;
has scenery;

Room bedroom “bedroom”
with name ‘window’,
“Your scarcely furnished bedroom is lit by the bleuish streetlights seeping through the half-shut window blinds. ^Left is some more light coming through the staircase down to the hall. ^The bathroom on your right is dark so you prefer to look that way.”,
before [;
Go: [same here multiple conditions within a rule]
if (player in bed) <>;
if (player notin bed && noun == w_obj || noun == left_obj) <>;
e_to bathroom;

appliance bed “bed” bedroom
with name ‘bed’ ‘covers’ ‘sheets’, [simple but extremely efficient help to playability]
“This is one of your true friends. Your own warm and comfortable bed.”,
after [; [here the text overrides the standard report text automatically in Inform 6. is quite some work in Inform 7, understand]
“The bed creaks a little as you step out of it on the right, ‘your’ side.”;
“You slide under the covers and wrap your legs in them. Carefully not to wake up Terry.”;
has enterable container open transparent;[/code]
(note: I put some remarks in the code at the places where it hurts in Inform 7)
For a programmer like me this is no rocketscience but in Inform 7 I only managed to get only half of this done.
Now if I had some lists describing what Inform 7 really needs then I could puzzle it together.
(on the other hand; in that piece of code is most of what is unclear for now. so if someone could give me a few tips that also would be helpful :slight_smile: )
If you read my post so far I am already grateful.
Meanwhile I am typing away on a storyline. :slight_smile:

There are link to useful resources on the Inform site at a very handy Inform 7 Cheat Sheet, a flow chart for all the built-in rulebooks of Inform 7, and a syntax document (for the language up to build 5Z71).

For the fine details you’ll have to search the Standard Rules and the I6 Templates, which you will find here:

Everytime someone says “I’m a programmer and therefore find Inform 7’s documentation to be unsuitable” I link them to Ron Newcomb’s tutorial. … rogrammers

Both The Cheat Sheet and Ron Newcomp’s “Inform 7 for programmers” (in the same page Felix has linked or here -ah, I see Peter has linked it too!- ) are probably made for you.

I’ve been in your shoes not long ago: having a programming background and being fluent with I6, then stepping into I7 for the first time and feeling like landing on a totally alien landscape, searching desperately for a reference guide where I could find how to do the things I was used to the way I was used to…

That way might work for you. In fact, I hope it will. But in my case it would have been the long painful way of getting into the new stuff. I was trying to enter a speed-comp, the Indigo speed-comp which was about authors using a creation tool for the first time, and I learnt the hard way that trying to adapt the new language to my old habits wouldn’t work at all: the sooner I would forget my old ways the quickest I could give the critical first step to have it finished in time.

This, of course, is just my case. Other minds could work in a different way. I sent Jacqueline a short text talking precisely about it all for a hipotetical SPAG article in which Indigo participants would expose our experiences managing a new language (but I know she’s been quite busy in real-life so that might never happen!) :slight_smile:

Good luck with your transition! It’s not as hard as it seems the first time, you’ll see! :slight_smile:

I did read the ‘inform for programmers’ and I found the ‘learn’ tab on the site all quite useful to begin with inform. But when you need a bit more complexity I found myself trying to invent stuff and getting an error message. And then after a lot of searching through the docs I found out there was something already in Inform 7 that could do the job and I was meddling with it.
The ‘Inform for programmers’ does a great job in, for example, describing the hierarchy of classes (kinds) but, ofcourse, can’t do that for everything.
What I’m saying is that it is very hard to distill all that info from the body-text in the manuals I’ve seen. And concerning the cheat-sheet. It is great in describing seperate parts of Inform 7 but being very picky on order and punctuation sometimes it is hard to combine these things when you don’t have an overview of these rules. Having to find that all out with trial and error doesn’t really speed up the process.
Another example (not code this time): Inform 7 knows what dark and light is; it knows heavy and blue and red etc. is but does it know what a clothed or nude adjective is? Or when it knows what a car is does it know what a fence is?
Is is there one of those manuals, that I might have missed, that describe all of these things or, for that matter, rulebooks in order instead of strewn about in the text.
Forgive me if I sound bitchy (has to do with being Dutch) but that would make my IF life so much easier.
And what I said earlier: If someone comes up with an elegant solution to the problems noted in my code example I would be already helped a lot. (If I have to move it to a new topic in the development section, please tell me so)

Well, you can extract all of this information from the Standard Rules (and the Chart of Rules). But I’d say you need to read Standard Rules through, from beginning to end, once, before you would know where to look in it to find what you’re looking for. (On the other hand that document is not a really a pain to read.) The Standard Rules are as much documentation as source code (I guess that’s part of literate programming paradigm to which Inform 7 adheres).

I can’t help with the manuals - a lot of learning I7 for me has to do with immersion and absorbtion. Sorry.

However, the forum is a good place for specific questions, even those that seem basic. (They may or may not actually be basic!) You can use the Inform 6 and 7 section for asking questions on how to do something. Lots of people are not fluent in both I6 and I7, so you might get a quicker response if you state the specific problem you’re having, what your current solution is, a compilable example, what error you’re getting, or whatever would be helpful. (A transcript of what you’d like to see happen can be helpful, too.) Not that all that’s necessary on each post, but whatever is necessary to give people a place to start.

So if you’re looking for a way to code:

You can try:

[code]“Test” by Gravel

The Bedroom is a room.
The bed is a supporter in the Bedroom.

Instead of taking, pushing, pulling the bed:
say “It doesn’t budge.” instead.

test me with “take bed / pull bed / push bed”. [/code]

Also, chapter 1.4 of the built-in Recipe Book summarizes some I7 syntax.

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."; rule succeeds.

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."; rule succeeds.

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.

Whoohoo! All hail the forum! \o/
Now that is information I can work with. I knew it was around somewhere.
And matt w thanks for the complete solutions especially the ‘is an appliancey(!) thing’ one. It made me laugh.
What I did in the i6 code concerning the if player goes west and is not in bed thing had to do with that in the beginning of the program I defined respectively left and right as west and east. And it looked more obvious story-wise that when you step out on the right side of your bed going left gets you under the covers again. Also considering there is no exit left out of the room. Only down and right (east) But I didn’t copy that part of code so you couldn’t have known.
A part of the problem is that I learned from the beginning to cram as much as possible between two brackets to be efficient. But here you have to break it all down into seperate rules and put them in order. (which to me seems it extremely and illogically convolutes your code but, then again, can look vewwy pwwetty.)
I will take all this info in. And as soon as I have a ‘real’ problem I’ll put it in the other section.
Thanks a lot guys,

Update especially for matt w:
Here is how I solved the whole bed thing:

your bed and a nightstand is fixed in place in the bedroom. your bed is an open enterable container. player is in bed. instead of going when in bed: try exiting. instead of going down when in bed: say "You're already lying down quite comfortably.". instead of going left when location is bedroom and player is not in bed: try entering. Report entering the bed: say "You slide under the covers and wrap your legs in them. Careful not to wake up Terry."; rule succeeds. 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."; rule succeeds. Before pushing, pulling or taking something that is fixed in place: instead say "It won't budge.".
(I admit that the last rule is just vanity to suppress the dry ‘it is fixed in place’ message :slight_smile:
Though elegant to read, it is twice as long as my i6 code (minus the room descriptions) which, ofcourse, is completely against the programming doctrine that has been slapped into my head since 1986.
Thanks again and consider this problem solved.

Good news 1:

Make that After entering the bed: say "You slide under the covers and wrap your legs in them. Careful not to wake up Terry."
After rules run before any report rules, and they automatically stop the action.

Good news 2:

Using the Index is good advice! As it happens, Inform (nowadays) lets authors write thing like After exiting from the bed in their rules – though it won’t let players write commands like “EXIT FROM BED”!

Good news 3:

Yes, there actually is: An appliancey thing is usually scenery.

Thanks for the good news, Felix! And for correcting my misapprehensions. I see from section 26.2 that “exiting from” was introduced in 6E59, which is actually after I started learning the system, so I don’t feel so bad. And now that you pointed out I found this line in the standard rules:

The exiting action has an object called the container exited from (matched as "from").

I was afraid that “an appliance thing is usually scenery” would lead to loops, but actually if you create loops:

A thing can be non-Jourdain-front or Jourdain-front. A thing can be Jourdain-back or non-Jourdain-back. A Jourdain-front thing is usually non-Jourdain-back. A Jourdain-back thing is usually Jourdain-front. A non-Jourdain-front thing is usually Jourdain-back. A non-Jourdain-back thing is usually non-Jourdain-front.

It seems to handle them sensibly if not predictably.

(Anton, I don’t know if I’d advise doing the “left means back in the bed when you’ve just got out of it” thing. Unless you have a lot of sophisticated stuff going on with moving around rooms with relative directions, it seems like it might be pretty annoying to deal with.)

Finally got around to visit and reply again.
Thanks, Felix for the update. As I said. It isn’t all that easy but it makes for vewwy pwwetty cowwde. :slight_smile:
@ matt w.
Don’t worry. I won’t make a habit of it. But the body text explains a lot. I am not making a game, as such, with puzzles, and everything, but more or less an interactive novel. (based on a real novel I started a while ago. but writing a complete novel is such hard work.)
So there isn’t any real challenge (although in every chapter here is some stuff you have to do to get to the next chapter) but the idea is to give a greater sense of immersion by letting the player explore parts of the world themselves and, in that way, giving the characters more depth.
So that ‘left to your bed’ business was something leftover from the novel. But I had to remove it anyway because I made an exit to the left. :slight_smile:
I’m going to insert Felix’ lines of code into my program. (and then shout everywhere that I am a genius :slight_smile:
And If I have something to show or playtest you’ll be the first to know.