@inform7tips twitter account

(My personal experience)
So the Inform Documentation is not concise nor simple, but it is comprehensive and easily navigable if you learn it’s quirks.

I read or skimmed most of the chapters over a period and discovered lots of “stick a pin in that for later” concepts. I had best success searching the documentation (and recipe book) within the Inform IDE. It also helps if you catch some phrases in the documentation to remember as a bookmark. Any time I would forget how to specify conjugation of an assertion verb, I remember the example in §13.9. Defining new assertion verbs used the example “to sport” so I’d search for “sports a tory rosette” “The verb to sport (he sports, they sport, he sported, it is sported) implies the knowledge relation.

Searching also works online - enough of the documentation is available that you can google search “inform 7 sports a tory rosette” and it shows up.

Even if you don’t want to slog through the entire documentation just for fun, I would suggest spending some time at least browsing the recipe book. It’s shorter, more entertaining, and gets a lot of concepts across via example. And you can click/experiment if you’re reading it in the IDE.

1 Like

That’s fair enough, I didn’t mean to imply you’d single-handedly go full in on it - mostly just voicing that I think it’d be neat to have a more centralized single documentation. I know very well that going through hundreds of disparate threads, documentations, pdfs, posts, and the like could be rather overwhelming to the point where one person is unlikely to be able to do such very easily - especially with how crazy things are in life sometimes.

And yes, I’ve originated several threads (or, at least three) that I’m sure are answered elsewhere - however in each case I wasn’t able to find an easy answer on my own or the answers I found didn’t solve the issues I had. Even with the memory limit one I only asked after I had noticed that turning up values I already knew existed wasn’t helping, I’d like to think I wasn’t too out there with the other threads I’ve made as well. I always feel pretty bad asking for help, as it feels like it is expected to know everything currently written everywhere - especially with how long I’ve been using inform and even more so with something that seems like it should be more obvious (such as the thing with the figures/images) - so I only make threads when completely puzzled.

I think including the memory limit stuff more on its own, as well as a comprehensive list of them (if the one in that documentation you linked and in the thread are all of them [which incidentally means that unless I’m mis-typing none of them control the mythic 'Understand possibilities]) would be pretty good. And especially stuff for folks that, like myself, lack much coding experience outside of inform. I know there are a lot of pretty neat things that you can do with a lot of third party or external things that seem to stream-line a lot of stuff I’ve either not been able to do at all or had massive problems finding work-arounds for.

A pretty interesting way to remember where things are. Though I will also admit, like a lot of other similar difficult folks I’m not exactly using inform to make a basic puzzle game. I’m surprised it doesn’t cry when I press go - I don’t think any of the numerous projects I’ve made for it have been anywhere close to its intended purpose (or what I understand to be its intended purpose). A lot of the information that I’d find valuable might not be quite as helpful, and therefore not needing to be as front and center, to people looking to make different things.

I will say though, the ‘recipe’ book is indeed pretty good. Looking through the examples provided in the entirety of the documentation helped me a lot when I first got into inform!

Are we siblings? I am also that horrible person who learns a new thing and immediately goes “okay, what ELSE can I make this do that it wasn’t intended for…”

1 Like

Its possible! That mentality has led to a lot of the smaller projects I’ve used inform for. I’ll come across something that seems mechanically neat and put it in the thought cabinet for a bit before happening across some neat thing I could use it for.

1 Like

Okay, get out of my head!! :upside_down_face:

It’s not all of them; if you look at the Inform 6 release notes I linked to, there are more. Looking at the Inform 6 6.35 source, MAX_LINESPACE looks like the best candidate; it defaults to 16000. MAX_VERBSPACE could be relevant too, depending on whether you have too many understand lines because you have too many verbs or just too many different ways to parse your verbs. It defaults to 4096. Seems worth a shot to double those and see what happens…

I wish more people asked more questions more often. In my half-year now of being a regular here (during which time I’ve spent a lot of time reading archives), I’ve never seen anyone get criticized or patronized for asking a question. I’ve asked a couple I felt silly about in hindsight… but only because of foolish pride on my part; I received really helpful answers that didn’t imply they were silly questions. This is the most consistently nice online tech community I’ve encountered, and I’ve been at it since before there was a web.

I7 is a great big sprawling, expansive, complicated language built on a complicated tech stack with 40 years of history. As you say, there’s a lot of knowledge that’s very hard to find outside the minds of the user-base.

(Now I’m thinking maybe there should be some “how and when to ask questions” advice, maybe in the About the I7 Category sticky post. Hmm.)

1 Like

Hehe, glad you got that reference.

I used those too, none of them seem to control the number of ‘Understand possibilities’ a verb can have. Though there are definitely some of these I haven’t seen before that look rather useful. Still, appreciate the link, I think I might’ve finally broken inform.

As for asking questions. You’re quite correct, Everyone where seems exceptionally friendly and helpful, no matter how esoteric the problem. I wish I had discovered it earlier than I did, though I’m sure my thread count would’ve been rather high (re-reading the ‘Memory Limit’ thread has dredged up memories, such as the infamous ‘You are a lair’ error message among many other frustrations). That actually brings up another point, its kind of odd but an idea of something to include in that or on the twitter.

I know inform has a lot of weird quirks concerning its built-in actions, objects, ‘figures’, and the like that it absolutely does not like being challenged or messed with (such as attempting to define an action already in the engine or redefine an object or number as something else). Such things have caused a lot of headache for me in the past. I am vaguely aware there are numerous ways to do work-arounds for things like that (since I came up with my own I don’t know a whole lot off the top of my head), however I am not sure if there is a list of the more involved ones or a list of how to handle the more vague error messages that arise from admittedly niche situations.

1 Like

On the bright side, as of 6M62, “That, sir, is a damnable lie.” and “And I am the King of Siam.” received explanatory follow-up sentences.

Inform 7 has finished.
  >--> '1 is a number' (source text, line 13): Grateful as I generally am for
    your guidance, I think perhaps I could manage without this sentence.
  >--> '12 is a rulebook' (source text, line 14): That, sir, is a damnable lie.
    '12' is a number.
  >--> '"X" is a number' (source text, line 15): And I am the King of Siam.
    '"X"' is some text.

I may have missed a question that was posted earlier. Have you run into an Inform 6 error related to too many understand possibilities? If so, what was the error message?

Much less cryptic for sure! Glad to hear that they were clarified.

Its in I7, “this command verb now has too many Understand possibilities, that is, there are too many ‘Understand “whatever …” as …’ which share the same initial word ‘whatever’. The best way to get around this is to try to consolidate some of those lines together, perhaps by using slashes to combine alternative wordings, or by defining new grammar tokens [in square brackets].”

This is it, for context there are about 30 or so different actions that use “End Turn” as what triggers them, in various circumstances via the ‘Understand “End Turn” as x action when y condition is fulfilled’ deal. There are other similar things for other actions as well that its spitting out errors for, not all of them would be terribly easy to consolidate without making the code into a mess - so as silly as it would be to have broken inform I am hoping that isn’t the case!

1 Like

I think you’re out of luck until the next release of Inform 7. There’s something called MAX_LINES_PER_VERB in Inform 6 (before 6.36). It’s set to 32. It’s more constant than the other constants; one would have to modify the source to change it… except that that won’t help either, 'cause it looks like ni decides to spare inform6 from going to the effort of balking at this value being exceeded by independently enforcing it itself.

Would it be so messy to consolidate some and then split them in Before rules? So instead of (untested code):

Understand "end turn" as fooing when foo is true.
Understand "end turn" as barring when bar is true.

You could have

To endturn is a verb.
endturning is an action applying to nothing.
Understand "end turn" as endturning.
Before endturning when foo is true, instead try fooing.
Before endturning when bar is true, instead try barring.
Instead of endturning: [something to do if none of the before rules caught it]

(Possibly you could even get away with less granularity than distinct actions but without knowing what you’re up to, I couldn’t say.)


Yeah. If you don’t see an I6 error message saying “The memory setting MAX_XXX (which is N at present) has been exceeded”, then there is no memory setting that will help you.

Thanks! That’s a lot less messy than what I had in mind. I was going to just make a long list of actions that called on actions that called on actions with conditions on each to ensure it selected the correct one - which would’ve been tedious and left quite a lot of room for mistyping or missing something.

As for what I’m doing, just a very basic combat system. I am not really adept enough at coding to use the extensions that help, and some of them don’t let me do everything I want anyhow - so the work-around I’ve made is rather convoluted. Basically every ‘opponent’ has a unique action for being beaten, being victorious, and performing their turn (which is accomplished by the player passing or ending their turn, for simplicity). Needless to say, its still going to require quite a bit of copy-pasting and editing, but a lot easier than having to make several new actions to call on other actions…at least as long as this before/instead itself doesn’t have a hard limit.

Speaking of the ‘Next Release of Inform7’, I’ve heard it mentioned a bit - for quite a while. Is it going to be just an update of inform7 itself or an entirely ‘new’ thing?

This sounds like it might be organized as rules per opponent in different rulebooks, something like:

Victory is a rulebook.
Defeat is a rulebook.
Enemy-action is a person based rulebook.

Definition: A person (called P) is other if it is not the player.
Every turn:
  repeat with opponent running through other people in the location begin;
    follow the enemy-action rules for opponent;
  end repeat.

Enemy-action for Zangief: say "Zangief looks menacing."

Defeat when the noun is Zangief: say "Now who will crush foes' skulls like sparrow's egg?"

Victory when the noun is Zangief: say "Zangief crushes your skull like sparrow's egg."

[ since rulebooks default to being action based, these automatically get called with the current action,
so "the noun" works to identify the opponent within defeat and victory ]
Carry out the player attacking someone:
  if a random chance of 1 in 2 succeeds, follow the defeat rules;
  else follow the victory rules;

This is all that is publicly known: Graham Nelson’s 2019 Narrascope talk; 2020 Narrascope talk. So we know there will be big changes to the architecture. What changes there will be to the language itself / the world model / the standard rules are unknown. Another big change is that it’ll be open-source, so that one could remove that MAX_LINES_PER_VERB test oneself if one really wanted.

1 Like

First, this is really good to see! I think I made a few tweets way back when of Inform 6/7 stuff, but they went nowhere.

I’ve felt so too, but a lot of that is on me. I find it gets me basically what I need if I need to get started. Then I ask on here, and I realize other people have paid more attention to details I overlooked while I was just getting something going. I’m okay with that two-step approach of doing something in the recipe book, or just getting something to work, and asking the whys or even “can this be done better” later. Or seeing “oh, that’s why detail X was important, but I’m glad I got something up and running.”

I don’t think that’s unique to Inform. I think because it has natural language, we can get relaxed and think “oh, entry 1 of my_list” is the same as if “in” or other prepositions replaced “in.” So sometimes there’s that fight with the compiler, and we have to learn how to fight efficiently.

Also it’s way tougher to google for help for something in Inform then, say, Python. It’s tough to separate the technical from the creative.

As for asking questions: I try to find 3 ways to get around a problem before posting here. Maybe that means a few good questions got lost. I don’t know what the solution to that would be. It’d be neat to have an “Inform 7 small victories” thread, though some might find that cheesy or bragging of a sort. I think I could seed the forum with a lot of good questions I had which I answered on my own, and I’m not alone. But I’m not sure if that’s what we want. This seems to fit in more with itch.io devlogs.

Me too. I have to admit that, now I’ve been programming in Inform for several years, I think “I should know the answer to this. I shouldn’t have to ask.” But when I do, I usually get answers and then some – some people answered a future question I’d probably have had. So I appreciate that.

I’ve been around the community for a while and haven’t seen anyone get criticized, though there is the general specter of programmers saying “Boy, you REALLY should’ve known this” and also of, apparently, enough trolls from the past to make this forum or the old newsgroup forbidding for new people. But I’ve been here off and on and I am glad to see new names making real contributions to the forum, and we want to continue that. Something like a person who’s been here 1 or 2 years answering a question may make me feel like I’m a bit slow, but the end result is quite practical and positive, and we obviously need people like that.

Those really rubbed me the wrong way, and I’m glad they were fixed. They’re obviously an order of magnitude or two below a legitimately offensive joke, and I’m just grateful Inform exists, but still, having it happen (and forgetting why) does make it that much harder if I’m in a bad mood and don’t want to deal with snarky error messages.

It’s also tough to report these things because I realize only a few people are working on the project, and they aren’t paid. Yet all the same, when I read some error messages in the IDE, I think “wouldn’t it be better to say it this way?” Now that we have more people using the compiler, it’d be neat to say “In practical terms, you probably said X when you meant Y” or “this was probably a typo for a variable name” instead of a literary reference that I get, but that’s not what I want to focus on right now, and besides it might intimidate/turn off new programmers.

After a few years, I know what the messages “really mean” to me, but 1) others may feel differently and 2) it’d be neat to help make it quicker to internalize things. I recognize this is relatively low-priority though.

Hope I haven’t hijacked the topic. The original post and Lapsa’s questions brought up a lot of concerns I’ve had floating around. So I hope I can push the envelope further in a positive direction.