Inform 7 – GL02 bug with First time / Only construct

I’ve been upgrading my WIPs to the new version of Inform and for the most part things have been going smoothly.  Once a few extensions were updated and I changed the way I was doing a few things (which were deprecated anyways), they worked pretty well.  After almost two weeks, I noticed somethings wasn’t correct with one description I had in some code like below.

The description of myObject is "[first time]Say this the first time only.[only] Rest of text that will print every time."

When examining the object, it never printed the text within the first time first time construct. After some digging and talking to a few people, I find that this has been reported.

0001291: “first time / only” is not shielded by say__comp

The work around for now is to use something like the following:

The description of myObject is "[one of]Say this the first time only.[or][stopping] Rest of text that will print every time."

Inform 7 Gems – Is Transcription On?

As I was poking around the forums the other day, I realized how much information is buried in the forums.  Things I might not even think to search on or are difficult to find even when looking.  And when you do find something, it’s often difficult to piece the useful information together from a long thread.

With that in mind, I’m going to start a series of posts, starting with this one, on things I’ve found in the forums or elsewhere that I find interesting or useful and try to put them in nice digestible bites.  I hope to educate myself through this process and hopefully they’ll be of use to others as well.

Are we transcripting?

My first gem was suggested to me by Andrew Schultz.  Back in 2012 he had started a thread entitled I7 – Check if transcripting is on when noting?  The basic premise behind the post was checking if transcripting is turned on.  As I talked about in my previous post on easy transcription notes, Andrew was doing something similar, but as an added bonus, wanted to check if the transcription was turned on and if so, at a minimum warn the user that it wasn’t turned on.  Very useful for beta-testing and I myself often forget to turn on transcription.

With some help from zarf and others, what we end up with is pretty useful.

Include (-
[ CheckTranscriptStatus;
return ((0-->8) & 1);
return (gg_scriptstr ~= 0);

To decide whether currently transcripting: (- CheckTranscriptStatus() -)

ignore-transcript-nag is a truth state that varies.

After reading a command:
	if the player's command matches the regular expression "^\*.+":
		if currently transcripting:
			say "Noted.";
			if ignore-transcript-nag is false:
				say "You've made a comment-style command, but Transcript is off. Type TRANSCRIPT to turn it on, if you wish to make notes.[paragraph break]The long version of this nag will only appear once. You may press any key to continue.";
				wait for any key;
				now ignore-transcript-nag is true;
				say "(Comment not sent to transcript.)";
		reject the player's command.

What we have is some I6 code that is checking a flag (different depending on zcode vs glulx) that when the user enters a note command, it checks to see if transcription is on and warns the user if it is not.

We can even take it one step further and add this line of code if it is not on:

try switching the story transcript on;

This will prompt the user to turn on transcription and should work in either zcode or glulx.

I seeing more and more that I really need to dive into I6 more to see the possibilities that I may be missing.

Edit: changed the regular expression to work around the I7 bug mentioned in the comments.


Inform 7 – Paragraph Breaks in Text Substitutions

I’m a bit of a stickler when it comes to formatting of my text.  Not that I get it correct all the time…but it does bother me when I see something out of whack.  As I am continuing to practice my Inform 7 skills and increase my knowledge of the language constructs, I found myself being tripped up with one aspect of paragraph breaks repeatedly….hence this post to try and help me remember this.

One thing I run into enough is just the simple paragraph breaks that follow after hard stops at the end of some text.  (   This seems easy enough and works the way I expected it too most of the time.

The clock tower is scenery in the town-square.  
The description of the clock tower is "You look up at the clock tower and see the time is [time of day]."

This produces the following results as expected.

>x tower
You look up at the clock tower and see the time is 11:10 pm.


Where I tend to run into trouble is when my description becomes a bit more complicated, where I may have nested logic in there so I’ll have to break it out into a new phrase. BTW: examples are really nonsensical for illustration purposes only…better ways to do things like this I’m sure.

The description of the clock tower is "[clock-tower-description]".

To say clock-tower-description:
	if turn count is 2:
		say "You look up at the clock tower and see the time is [time of day].";
		if turn count is 3:
			say "You really want to see the time again?";
			say "You've looked at this  before."

That produces the following output

town square
You can see a clock tower here.

>x clock tower
You look up at the clock tower and see the time is 9:01 am.

>x clock tower
You really want to see the time again?

>x clock tower
You've looked at this  before.


You’ll notice the extra spacing. between the printed text and the next prompt. To fix that problem is a really easy fix, but wasn’t obvious to me at first.

The description of the clock tower is "[clock-tower-description][run paragraph on]"

Adding the [run paragraph on] phrase is letting the substituted text handle all line and paragraph breaks without the printing of the description adding it’s own.

I’m guessing that even this isn’t the best way to do things, but it is working for me for now.

Large interactive objects that act like a backdrop (sort of) – Inform 7

I ran across an interesting problem in my WIP that to solve I went through a couple different solutions before getting something simple to work.

Note:  This may not be the best way to handle the problem and I’m always open to suggestions for improvements.

In my current WIP (one of them anyway), I have a situation where I had a large object that was visible from many rooms.  Let’s say a large tree in my front yard and the rooms are areas around the yard.  There is also one room inside my house that I can see the tree out a window.  My first inclination was to make it a backdrop so it could be seen from those rooms.  Let’s assume that the entire map of the game is those outside locations and that one room in the house.

The shade tree is a backdrop. The shade tree is everywhere.
The description of shade tree is "A great big tree."

Worked great, until i wanted to the tree to be a supporter.  I tried adding the supporter tag to the tree “The shade tree is a backdrop and a supporter.”  This gave me the error: “… as a backdrop and a supporter are incompatible…”  I really needed the tree to be a supporter as it was critical to be able to put something on the tree.  So out came the backdrop and making the tree a supporter worked great.

However, it wasn’t very realistic.  It made no sense that I could go to a different part of the yard and if I tried to look at the tree I would get the message: “You can’t see any such thing.”  Well what’s the best way to be able to interact with an object that is not in the current location?  Put it in scope.

after deciding the scope of the player:
    place the tree in scope;

This worked fine, now I could examine the tree from anywhere.  And if I tried to do anything to the tree away from the actual location where the tree is, I get a message saying “I can’t reach into Under-the-tree” (which is where the tree is located).  Well that’s not a very good message so I need to change the rule for reaching inside a room (which is what you’re doing if you are trying to interact with an object, in scope, that is located in another room.)

Rule for reaching inside a room:
    if the location is up-the-tree:
        if the noun is the shade tree:
            allow access;
            say "You can only look at [the noun] from a distance.";
            deny access;
        say "You can only look at [the noun] from a distance.";
        deny access.

Let’s look at a few things with this last section of code.

  1. We are replacing the rule for reaching inside a room from the standard library so we can run some of our own checks.
  2. We first check to be in the location up-the-tree.  I hadn’t mentioned this before, but I let the player climb the tree and it puts you in a location up-the-tree.  Since the tree is not in that room, but is in-scope (because of our scope rule) without this rule we would have gotten the “Can’t reach into” message.  Which is silly since of course I can “touch the tree” since I’m in it.
  3. So if we are in the tree and the noun is the tree (meaning we are trying to do something to the tree while up the tree) then we allow access, which lets the appropriate rules and actions trigger.
  4. The otherwise’s tell us we are either not up the tree (say in the house) or we are trying to interact with something other than the tree.  In those cases, just display a generic (but more friendly) message.

So now if we try touching the tree for example and we are either under the tree or in the tree, both locations we should be able to touch the tree from we can do this.

instead of touching the tree:
    say "You affectionately touch the tree."

Like I mentioned, I went a couple different directions with this, trying to do more with overriding some standard library rules and going down the path of trying to find a way to create some sort of backdrop / supporter.  (Something I didn’t try that seems kind of obvious now that I’ve typed all this up is making a separate supporter part of a backdrop and then working with it that way, I suspect that may work, but haven’t tried it)

I haven’t tested this code completely, so there may be some flaws or unintended consequences that I’ve not run across yet.  But perhaps this will be useful to someone.

Please feel free to tell me why this is wrong or show me a better way

Edited (9/29/13) to format code a little better

Easy transcription notes in Inform 7

This may not be very clever and I am sure I stole this from somewhere (don’t really even remember to be honest), but here’s a nice little line of Inform 7 code that will allow for easy and clean comments in a game transcription.

Understand "* [text]" as a mistake ("Noted.").

Simply put, this allows you to type in:

>* whatever notes you want to enter

and the parser simply says “Noted.” instead of the usual “That’s not a verb I recognize.” or some similar message.

This makes looking at transcriptions a little easier and also helps separate the notes from the true error messages that you may want to see so you can check what verbiage the user is having trouble with.

If this is your code that I don’t recall snagging it from, let me know and accept my apologies for not remembering.

Update:  I found where I got this from, straight from the manual….LOL (

Reporting the location of wandering NPCs

I was recently having a discussion with Marshal Tenner Winter on the forums about having your PC standing on a high point where they would be able to peruse the landscape around them and see other NPCs in other locations.  The goal was to print out the locations of each NPC in a friendly way.

Here is some code I came up with that seemed to the trick and only really needs some tweaks to look more grammatically correct or visual appealing.

every turn when player is in cliff:
   say "From here you can see that [run paragraph on]";
   repeat with someone running through persons who is not the player: 
      if someone is in the exterior:
         say "[The someone] is in [location of someone][run paragraph on], ";
   say "[paragraph break]".

I could seem some tweaks and enhancements to this that would need to be made:

    1. Need to check if the location is actual visible from the high vantage point, this code does do that to a certain degree (by region, in this case the region exterior, assuming ALL of exterior is visible from this vantage) and that may be enough. But let’s say your vantage was up a high tree and not only could you see those locations outside, but perhaps also inside just a few rooms in a house that you’re peeping into.
    2. Grammatically, the code above produces some awkward sentences, tweaks would need to be made to conjunctions, location printed names, things like that.

I can see quite a few uses for this and is a nice little piece of code that I’ll keep around.