Working notes on updating extensions for Inform 6L02

These are the major points that I ran across when I was updating my extensions for 6L02, which I originally wrote up as a text file for circulation to people who got a prerelease build.

Apologies for the ugly formatting — email from various people has reminded me that this is needed, which is why I’m posting it inelegantly here right away, rather than more attractively elsewhere later. Tabs in particular are not preserved, but if you’re an experienced Inform extension writer you’re probably aware of where they’re needed. (Sorry.)

  1. Remove deprecated syntax. These have been deprecated for a long time, but are now actually truly gone. In particular:
    1. Procedural rules have to be removed. Depending on what you need to do, you will want to delist or make unavailable old rules; see sections 19.4-19.6 of the documentation for alternative syntax.
    2. change (something) to (something) should now always be replaced by now (something) is (something).
  2. Each piece of text output in a rule (but not in a phrase) needs to be labelled as a response, with labels such as (A), (B), (C), etc., starting anew at A for each new rule. See the documentation chapter on adaptive text and responses.
    1. Occasionally there is a phrase such as

      say paragraph break.

      It is not mandatory to do so, but if we wish these to be responsized, this needs to change to

      say "[paragraph break]" (A).


      say paragraph break (A).

      is rejected by the compiler.

  3. All text needs to be made adaptive, using [We] and verb variations. See the documentation chapter on adaptive text and responses.
    1. The standard rules follow the principle that error messages addressing the player, as opposed to game text concerning the protagonist, stays in the second person singular: so, e.g., “You need to specify a noun”, not “[We] [need] to specify a noun”, which would turn into “He will need to specify a noun” or similar in other tenses.
    2. When a response is negative, it is good practice to include the “not” within the adaptive text. That is to say,

      You are not able to reach that.

      should become

      [We] [are not] able to reach that.

      rather than

      *[We] [are] not able to reach that.

      The reason is that in future tense the former will correctly inflect as “We will not be able to reach that”, whereas the latter will incorrectly come out to “We will be not able to reach that”.

  4. Any “stop the action with…” lines need now instead to reproduce the response text of the relevant response, like this:

    say "[text of print empty inventory rule response (A)]";
    stop the action;

  5. If your extension relies on others, they will also presumably need to be updated for your extension to be fully functional in its new context.
  6. Declarations of local variables have become more exacting to prevent a certain type of error that was formerly possible. Therefore, in past extensions it was sometimes possible to say, e.g.:

    if the pyre is lit:
    let the poem be the funeral ode;
    let the poem be the hymn.

    Now, however, the compiler detects that the local variable poem is declared only conditionally and rejects it. Consequently we now need to write:

    let the poem be the hymn;
    if the pyre is lit:
    now the poem is the funeral ode;

    which has the same effect.

  7. The phrase “is an indexed text” can be removed where it appears; everything is now just “text”.
  8. Plurality often does not need to be included any more, since other options for adaptive text exist.

There is also an ongoing thread here in which
people are discussing what they’ve encountered in converting their code to 6L02, so if you have a particular problem, it may prove to be covered there.

9 thoughts on “Working notes on updating extensions for Inform 6L02”

  1. Other useful knowledge:
    * anything with “consider” and then a rule or rulebook should be changed to “follow”;
    * “end the game …” must be changed to “end the story …”;
    * many standard text substitutions (probably from Plurality) have changed; you need to change [is-are] to [are], [it-them] to [them], and so on. Always choose the plural form, and you’re good to go;
    * text substitutions containing a thing need to changed like this: [possessive of the noun] becomes [regarding the noun][possessive].

  2. if the pyre is lit:
    let the poem be the funeral ode;
    let the poem be the hymn.

    — extracted from the Anthology of Inform Source Code Poetry.

  3. Hi Em, not sure if this is a good place to post this or not. I am updating my work-in-progress long suffering game into Inform7 6L02. I have updated all my extensions, but now the compiler barfs on some of the Menus code that worked fine in the prior release. Perhaps there is something boneheaded I have done in my configuration or I have somehow messed up the extensions. But I was able to reproduce this when attempting to compile the Tabulation sample program. I get the friendly but not terribly meaningful message:

    Problem. In ‘Table of Options’ , column 2 (subtable), the entry ‘Table of Setting Options’ (row 2) is a genuine, non-blank entry: it’s a specific value. That’s fine, of course – the whole idea of a table is to contain values – but this is a column which already contains a name of a kind: ‘a table-name’ .
    Names of kinds are only allowed at the top of otherwise blank columns: they tell me what might eventually go there. So the kind name has to go. You can replace it with a blank ‘–‘, and then either let me deduce the kind by myself, working it out from the actual values in the column, or you can put the kind in brackets after the column’s name, at the top.)

    Any ideas? Let me know if I should post this somewhere else.

  4. Thanks much. I will try to dive into this on the weekend. If you do update the example program, please let me know. (Or let me know what the correct code would be to use the menus.) I took a quick look at the intfiction forum and tried out a few things but haven’t actually figured it out yet.

    1. Ok, I think I got the right syntax to compile the menus stuff properly. But now i’ve run into a related issue. Now the compiler complains about some code in the Menus extension:

      In Section 1 in the extension Menus by Emily Short:
      Problem. You wrote ‘consider the effect entry’ : but this is a phrase which I don’t recognise, possibly because it is one you meant to define but never got round to, or because the wording is wrong (see the Phrasebook section of the Index to check). Alternatively, it may be that the text immediately previous to this was a definition whose ending, normally a full stop, is missing?

      Do I have the right version?

      1. Ok, I have now changed the offending line in menus.i7x to “follow the effect entry” and it compiles. However, I get a runtime error when I try to use the settings or hints menu options:
        *** Run-time problem P23: Attempt to look up a non-existent entry at column 3, row 2 of the table ‘Table of Options’ Glulxe fatal error: Memory access out of range (6C756C01)

        No doubt this is because I haven’t set up the subtables properly. Any pointers to an updated example would be greatly appreciated.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: