6E59: Code 10 issues for Windows resolved

The issue that had been causing a Code 10 error for some large Windows projects has now been resolved. If you are encountering this problem, please redownload and install Windows from the downloads page.

The fixed build has no other changes and is otherwise still in line with the Mac and Linux builds.

6E59: Fragility issues in the new build

As several people have discovered, release 6E59 produces a Code 10 compilation error on some (not all) large Windows (not Mac, and not to the best of our knowledge Linux) projects. Particularly vulnerable are builds with large numbers of duplicate objects.

As this is a mission-critical issue, a replacement build will likely be posted as soon as reasonably possible after the bug is found and dealt with. Those interested in tracking progress on the bug, or able to contribute more information, may find the details here.

This is not related to the problem that the original upload of 6E59 failed on pre-Intel Macs due to a lack of universal binary tools. That issue has already been resolved and a new version posted, so if you are encountering that issue, you may fix it by re-downloading 6E59 for the Mac. The new version has not received a change of build number because there was no change to the core functionality of Inform, only to the format of the included tools.

6E59: Deprecating Procedural Rules

One of the changes to 6E59 is the deprecation of procedural rules. They still function for the time being, but we’re hoping to remove those rules in the future because they are a heavy drain on performance.

What that means in the meantime is that we encourage extension maintainers, if they have the time and inclination, to try to remove procedural rules from their extensions; and that we’d like to hear about cases where a previously-existing procedural rule can’t easily be worked around.

One of the cases that may be challenging is a procedural rule used conditionally, as in

Procedural rule when putting something on a keychain (this is the allow putting things on the keychain rule):
ignore the can’t put onto something being carried rule.

This is a rule from the Locksmith extension that turns off a specific rule only in a specific case — we don’t want to delist the “can’t put onto something carried rule” at all times. The workaround we came up with was as follows:

The keychain-aware carrying requirements rule is listed instead
of the carrying requirements rule in the action-processing rules.

This is the keychain-aware carrying requirements rule:
if locking or unlocking something with something which is on a keychain which is carried by the actor:
continue the action;
abide by the carrying requirements rule.

This substitutes a new rule into the rulebook — but in all cases but one, it calls on (and follows the directions of) the old rule. Using this technique, the author doesn’t have to copy over anything from the Standard Rules to reproduce the original functionality.

This may still not be quite ideal, or there may be situations that it doesn’t cover, however. This topic is already receiving some discussion over at the uservoice forum. Please do share your experiences if you run into any trouble with removing your procedural rules, so that we can factor those in as we revise the language.

6E59: Description rules

One of the aspects of the Standard Rules that changed is the construction of descriptions. To quote the change log:

(d) We have withdrawn the:

examine undescribed containers rule

and replaced it with two new rules:

examine containers rule
examine supporters rule

The original rule converted the action of examining a container which had
no description text into a searching action instead. Sometimes this was a
sensible idea, but not always. Examining and searching are different actions,
and why should it make a difference whether there’s any description or not?
(The original idea was to avoid a misleading “You see nothing special about…”
reply about a container which, in fact, contained interesting items. But
however pragmatic that is, it’s not very convincing as a reason.) Moreover,
examining something requires only a line of sight to it, whereas searching
requires that the actor can touch the item in question; so converting one
into the other violates the spatial world model in some cases.

The new rules are (equivalent to) this:

Carry out examining (this is the examine containers rule):
if the noun is a container:
if the noun is open or the noun is transparent:
if something is in the noun:
if the description of the noun is not “”:
say “[the description of the noun][paragraph break]“;
say “In [the noun] [is-are a list of things in the noun].”;
stop the action.

and similarly for supporters, but without transparency being an issue.

(e) We have withdrawn the:

examine described devices rule
examine undescribed devices rule

and replaced them with the:

examine devices rule

which works much as the rules for containers and supporters do: the
description paragraph first, if there is one, then the status of the device
(“The hot tap is switched on.”).

What this means in practice is that some adjustments to the behavior of Examine made for earlier builds may not work. In particular, if we have removed the “examine described devices rule” to remove the “…is switched off” statement, we can achieve the same effect with

The examine devices rule is not listed in any rulebook.

Along similar lines, supporters and containers will now list what they support or contain, when they’re examined. If we don’t want them to do that, we can write

The examine supporters rule is not listed in any rulebook.
The examine containers rule is not listed in any rulebook.

…and supporters or containers will just print their descriptions. (NB: There is currently also an irritating bug that arises if the player examines a container or supporter that contains himself but nothing else, as the rule will print “On the shelf is .” or “In the bed is .”. This is being repaired for the next build, but if this situation is likely to arise in your game, unlisting the rules will work, as will replacing them with a substitution as discussed here.)

Inform 7 version 6E59

Inform 6E59 is available for Windows and Mac OS X. The release of the Linux IDE will, alas, likely take some days longer, thanks to some computer troubles plaguing our Linux maintainer, Philip Chimento.

The new build makes fairly extensive changes, and may be expected to alter the behavior of just about any work in progress. Therefore, we recommend keeping a backup before attempting to update extant code to work with the new build. (Always a good idea, but especially so in this case.) The change log is here; especially likely to affect WIP output is the section labeled “Actions in the Standard Rules”, which handles a large number of changes to the default behavior of standard actions.

Extensions are gradually being updated for 6E59 as well.

Mantis bug tracker

Inform now has a public bug-tracking system, to be found at

http://inform7.com/mantis

The tracker follows several different projects: when you log in and create a new bug report, you will be asked to choose whether your bug applies to

  • Core Inform. This will be the most common category, applying to errors in Inform’s compilation and gameplay behavior.
  • Built-in extensions — errors found in the extensions bundled with Inform, including the Glulx support extensions, Locksmith, Plurality, et al. This does not apply to extensions by third parties: errors in those extensions should be reported directly to the extension authors, as previously.
  • Documentation, Examples, and Website. This is the place to report errata in the supporting documents, from typos on up to misinformation.
  • IDEs. There are three subcategories here, for reporting problems specific to the IDE for each platform.
  • Inweb. This is for reporting problems with the inweb system, and is likely not to concern most standard users of Inform.

When filing bugs for the Core Inform project, please remember to choose an Effect: this corresponds to the check boxes on the old bug form. Each effect also lists the suggested Severity for bugs of that type.

Those who would prefer the old method of submitting a bug report by email may still do so, by sending a bug report form to

bugs at inform7 dot com

New suggestions forum

Inform 7 has a new uservoice forum for suggestions.

What it’s good for
The uservoice forum is meant to collect suggestions and feedback people have about what might be included in future builds of Inform, and also a bit of a record of what we’ve said about certain suggestions in the past. It is not a place to post bugs; those will be tracked separately elsewhere, because bug reports require more and different types of data. It is also not a place to ask for technical support, which is better served by the intfiction forum.

How it works
Anyone can add new suggestions to the forum, vote for suggestions made by other users, or comment on suggestions. Each user has a total of 10 votes to assign, of which up to three votes can be used on a given suggestion. That means you can give three votes to “Implement a flying pony made of coffee ice cream in the Standard Rules” if that really floats your boat, and just one to “Create three-way relations”.

If one of the suggestions you voted for is closed — either by being completed or by being declined — you receive back the votes to assign to something else. You can also un-vote for things if you change your mind or decide your priorities lie elsewhere. If you want, you can choose to receive email about the status of the suggestions you voted for, so you’ll know if they receive a response.

We have started off the forum with suggestions from our email and from all previous consultation documents. We’ve also been adding an informal system of tags, in parentheses. The most common tags are “syntax” (suggestions for adding specific phrases to the language), “parsing” (recommendations about how to read and interpret player commands), “world model” (things to change about the way the Standard Rules track the behavior of the world), “output” (tricks for modifying what Inform prints in various situations), “IDE” (issues with the behavior of the IDE), “documentation” (comments on the built-in manual), and “website” (suggestions for the behavior of the Inform website). You are encouraged, but not required, to use these. The idea is to make it easier for people (including ourselves) to get a view of everything that’s currently under discussion for a given aspect of the program.

What it offers
The strengths of the uservoice forum from our point of view are these:

  • More transparent tracking of the suggestions people have made and the answers they’ve received in the past.
  • More comprehensible data. One of the difficulties about suggestion discussions in unspecialized forums (especially RAIF, which is unmoderated, but even the intfiction forum) is that it’s not always easy to figure out which suggestions enjoy widespread support and which are strongly desired by a few people. The voting mechanism should help us track that information.
  • More visibility to the non-usenet world. This is part of a general move away from using the traditional interactive fiction usenet groups, towards communication venues that will be more familiar and more visible to users from other backgrounds.
  • Built-in spam protection and other moderation filters that we don’t have to work to maintain ourselves.

What it doesn’t offer
This probably doesn’t need pointing out, but this forum does not guarantee that suggestions, even highly rated ones, will be carried through; there are some that are inevitably going to be too hard to implement, too incompatible with the existing nature of the system, contrary to Inform’s essential vision, or otherwise impractical for reasons that may not be obvious.

Why we’re going this route now when we didn’t before
Users have been asking for some kind of suggestion forum for a long time. The issue up to this point is that we’d largely been thinking in terms of a self-hosted phpBB or similar bulletin board system, and we felt that this was unlikely to work well. We weren’t happy about solutions that would require extensive setup and moderation, because these would be a further drain on the limited time we have to spend on Inform. Moreover, the data we did receive from general-purpose forums was welcome, but tended to be complex and hard to untangle into feedback we could act on — there were lots of suggestions and counter-suggestions, but they didn’t always present a clear picture of how many users were really concerned about a given issue or what solution the majority preferred. Sorting through that kind of discussion was something we only had time for periodically, when we produced new consultation documents.

We are hoping that the combination of voting and moderation tools offered by uservoice will address the issues we saw in other types of forum. It wasn’t until we encountered uservoice that we felt there was appropriate technology for what we wanted to do. (There probably was, in fact. We just didn’t know about it.)

Thoughts on Icons

Inform is a multi-platform program now, but its original home was Mac OS X. When we needed an icon for it, Andrew Hunter drew up the familiar slanting I against a compass rose. The compass was a reference to the old-school interactive fiction of adventure games, where the story was always driven by moves NORTH, EAST and so on around a map. But the metallic look of the bearings, a little like the NATO logo, gave Inform quite a modern vibe.

fig1afig1b

A compass wouldn’t have worked anyway, because Apple’s web browser Safari had already co-opted that. This was an interesting design choice on Apple’s part, and so was calling their brower “Safari” – as if the Web were a distant, half-explored continent, or even a jungle, and not a place to work or go shopping.

fig2

Inform began life as a sister application to Andrew Hunter’s other IF program, the interpreter Zoom, and so they had originally had matching icons. Here’s Zoom:

fig3

That “family look” is something you see increasingly often. Whereas CDs and books and physical packaging give their makers plenty of room for the house livery – the logo of the Acme Widget Inc., say – icons for applications are too small for that kind of branding. Instead, program suites from large software houses outside of Apple – Omni’s apps, or Microsoft Office, or the Adobe Creative Suite – tend to use matching designs. These are freshened up after every major release, so that you can see you’ve bought something new when you’ve paid a hefty upgrade fee. Adobe’s CS3 icons, riffing off the Periodic Table of the Elements, are typical of Adobe’s robustly independent stance:

fig4

These icons don’t slant, and don’t feature hand-tools, as Apple thinks they should. And they show a dawning awareness that users these days have reams of tiny icons but often can’t remember which is which, so they label themselves with clearly visible letters. Microsoft does the same, always giving the current Word icon a prominent W.

Apple is often, and sometimes fairly, accused of pushing eye-candy. When OS X’s icons first appeared in 2000, eyebrows were raised at their resolutions – icons now had to be designed at 128 by 128 pixels, and the dock magnifier meant that bluffers trying to get away with 32 by 32 would be exposed. The full photographic-range palette of colours also looked lushly indulgent. But in retrospect it was simply that OS X was the first major operating system to start fresh with modern hardware. Pixel densities and colour gamuts had vastly improved since the 1990s, and Apple didn’t want to run on legacy hardware anyway.

Apple’s cartoons retained a cartoonish look, but they were photorealistic rather than stylised – more like the ligne claire of Tintin than the sketched zaniness of Krazy Kat:

fig5afig5b

This could become pretty obsessive. I, for one, didn’t actually know what hard drives looked like when I first saw Apple’s weird icon:

fig6

But then, this was also the age of Jonathan Ives’s daringly translucent computers – of the see-through iMac. Another bold move was the use of a true three dimensional viewpoint, rather than the isometric view so effectively used on 1990s Windows icons, but which now looked rather old-fashioned:

fig7afig7b

To Apple, icons are all about the users’s point of view when sitting down to work at a table:

fig8

At any rate, Apple upped the ante in 2007, with the release of Mac OS 10.5, “Leopard”. The new maximum icon resolution was to be 512 by 512, a sixteen-fold rise in the number of pixels – though in part this compensated for the steady rise in screen dot-pitches. (The same year saw the iPhone screen reach 160 dots per inch; 40 dots per inch had been typical on mid-1990s screens. This year we’re up to about 300.)

Inform didn’t react, and nor did most existing applications, but gradually there came new apps which made a virtue of the new icons – making them share design elements with splash screens, installers, animations, and websites. “Papers”, for instance:

fig9

An isometric view again – now so old-fashioned that it was retro. But then, this one doesn’t even pretend to follow Apple’s guidelines.

* * *

By 2009 we had decided it was time to think about a larger, richer icon for Inform, one which would be coherent with other design images. We no longer needed a visual match with Zoom, because Inform had gone out into a wider world. (Zoom is for OS X and Linux only, so Windows users never see it.) Time to go back to basics and start over.

Apple’s guidelines divide up applications into different genres, each with their own conventions for icons, so that seemed a place to start. (The guidelines are a little confused here, probably to blur the issue that Apple often fudges them itself.) Apple claims to divide programs into User Applications, Viewers (aka Players), Accessories, and Utilities. Well, Inform is clearly a User Application. So:

“Mac OS X user application icons should be vibrant and inviting, and should immediately convey the application’s purpose… If the primary function of your application is creating or handling media, its icon should display the media the application creates or views. If appropriate, the icon should also contain a tool that communicates the type of task the application allows the user to accomplish… it should closely relate to the base object that it rests upon.”

On that basis Apple’s own Safari ought to have been something like a map of Kenya with a hunting rifle, but Apple went with a compass instead, perhaps on grounds of taste, perhaps because browsers traditionally have circular icons:

fig10

All the same, Safari’s disc still contrives to follow the lines of traditional Apple icons: it’s not an accident that the compass is tilted north-by-northwest, and the needle, pointing northeast, is in effect the “tool”.

…its icon should display the media the application creates…: but because IF story files have no analogues with physical existence, unlike photos, film, DVDs, handwritten letters, books, and so on, this isn’t easy.

…tool that communicates the type of task…: well, working with Inform is a sort of writing, so perhaps a pen? The trouble is, there are already plenty of icons with pens, ink and/or paper:

fig11a fig11b fig11c

The pen is so ubiquitous here that we can vaguely tell that Mariner Write is a word-processor even though it features a bronzed sprinter with a pen the size of a javelin. Mariner Write is so keen to have the pen in the correct position that the sprinter is obliged to run the wrong way, as if we’re writing right to left. But his body tilts into the wind at the correct north-by-northwest angle. In the centre is Apple’s own Pages, which has become all tool and no media – it isn’t, after all, an application for designing inkwells.

So Inform’s icon can’t compare IF creation to writing on paper, or not in any distinctive way. We need a different analogy. The next idea was IF as world-building. Perhaps a globe? But that takes us back to the web browsers. Or even a map? But that’s a rather old-school idea of IF, not much better than a compass, and anyway plenty of navigation and networking apps use maps.

The other sub-genre Inform belongs to is software creation. IDEs, or “integrated development environments” – programs for making programs – are usually thought of as “workshops”, or “workbenches”. The user is portrayed as a craftsman, surrounded by open trays of tools, rather than a creative artist, with easel and paint. (The studio in Microsoft’s “Visual Studio” sounds more like an artisan’s than an artist’s.) Here are Apple’s excellent icons for Xcode and Dashcode, its own IDEs:

fig12afig12b

So perhaps Inform should look a little like these, but for making works of art, not engineering. Where the draughtsman’s plans appear, we want an emerging work of art, but at the same time we still want a construction tool, and if possible a hammer. In Iconworld, screwdrivers are for assembly or installation, spanners for adjustments, but hammers are for primary building. I’m not sure what the metal claw-tool on Dashcode’s icon is, but I’m pretty clear that it does something permanent.

What kind of art is made with a blunt instrument? Sculpture is chiselled, but its connection to IF is remote, and besides we need a two-dimensional art form, or the desk projection won’t work.

* * *

An afternoon’s cycle ride from my house is a farmer’s field near North Leigh, Oxfordshire, where a little shed protects the mosaic floor of a villa uninhabited since the 6th century. Imagine that: a great house which was sacked, probably burned, demolished for its stone, and abandoned for 1500 mostly lawless years, and yet its single most valuable treasure survived. My own home, brick-built in 1925, could disappear without trace in well under a century, as the nearby ploughed-over village of Hampton Gay demonstrates.

Mosaic-making is a subtle art. It simulates a world with only granular details, playing games with scale, position, time. It’s somehow architectural without being obsessively geographical. It’s durable, indeed stubbornly enduring, and what is ancient may at the same time be bright and solid today. It is a two-dimensional medium, and it satisfies our idea of art that you make with a form of hammer:

fig13

Inform’s tool that communicates the type of task is in fact, if you look closely and if you are a masonry buff, not a hammer but a martellina. It’s traditionally used with a hardie, a chiselled edge against which the tesserae, the individual stones, are cut. (They look like the sort of random stones you might get in your shoe, but in fact they’re individually cut with exquisite accuracy to fit.) Propping up a little hardie in the bottom right of the image would nicely complement the hammer, but it would just clutter the icon. The hammer is colour-saturated to make it a little more cartoonish, and to increase contrast; there are also drop-shadows, though it’s never wise to look too closely into the question of where the light is coming from. Apple’s Xcode icon plays further games with its own hammer, which must be bent into a gentle curve, since you can see its claw at an angle but can’t see the base of the handle. But this hammer we left in a true three-dimensional perspective, though of course it’s wildly out of scale with the mosaic.

The mosaic needed to be a panel, not a vast floor, in order to be propped up on a workbench, as Apple’s guidelines intend. It also needed to be fairly small, a detail rather than a huge scene, or it would be impossible to recognise when reduced to icon size. And since an abstract wouldn’t be very IF, it needed to be a pictorial panel, something vibrant and inviting.

And so we chose a panel of a parrot and a guinea-fowl, balanced by a flower, with a fruit at each bird’s head. (In the icon, the head of the martellina covers up the parrot’s fruit.) This panel is now in the Pushkin Museum of Fine Arts, Moscow, and our source material was a photograph by “shakko”, though it has been extensively treated. Many mosaic floors were largely abstract, but representational panels, like this one, overflow with life. Often they seem to want to show all of creation, composed like bestiaries. Part of the art of the mosaic is to fix, in stone, something transient – birds who might take off at any moment, leaving the floor bare, or fish who will swim out of view if you blink.

* * *

So the new Inform icon was put together from two different sources, both ultimately photographic in origin. Wasn’t there something a bit shoddy about that? But then I looked more closely at Apple’s “Icon Composer” utility:

fig14

It seems that the tool that communicates the type of task for icon-making is a tube of glue. I felt better.

May development update

Work continues on the new build. The current state of affairs is as follows:

  • Testing of the new compiler features turned up a number of bugs; we’re partway through resolving these, but some remain. We expect this will take about a fortnight, but no promises.
  • A week or so of work went into heavily revising the phrasebook and manual. This was a project we hadn’t anticipated doing for the current build, but we decided that it was too valuable to put off longer. The phrasebook tab of the index is reformatted and categorized to be easier to read; every phrase listed links directly to a place in the manual; and the manual description of phrases has been tightened up, so that each new piece of syntax is specially highlighted where it’s introduced, and there is more complete and systematic explanation of syntax behavior. This process also identified a few phrases that were not properly introduced in the manual at all.
  • In the process of going over the phrasebook, we identified a number of phrases that seemed inelegant or that were very rarely used. Since we’re already making many changes to the Standard Rules in this build, this seemed a good time to address some of the syntax issues as well, including things such as the anomalous presence of an “award … points” phrase when there’s no need for a special phrase to change the score, which is a standard variable; the fact that “change … to …” and “now … is …” have mostly-but-not-completely-overlapping functionality (the solution being to withdraw “change”, since “now” is more broadly capable); inconsistency in the phrases used to manipulate and blank out portions of tables; and a host of smaller and less notable things.
  • On the other hand, these are sweeping changes, and we don’t want to endanger existing projects by removing too much existing syntax without warning. As a compromise position, we’ve created a category of “deprecated” phrases and text substitutions, marked out in the manual to show that they will probably be withdrawn in a future release. Authors can set a use option to find any deprecated material in their existing source text, but otherwise it will compile as usual.
  • As they’ve proven a consistent threat to performance, especially in the increasingly-important realm of browser-based interpreters, procedural rules are also being considered for removal. We have therefore deprecated those phrases intended to be used only within procedural rules. This is intended as a test to see whether we can optimize by simply removing them from the system, or whether they provide functionality that needs to be compensated for in some way.
  • The newly-deprecated material was written out of the Standard Rules, examples, and bundled extensions.
  • A handful of small changes from the previous consultation document were added despite not being in the last change log: specifically, we have added a couple more text variations allowing authors to mark text as first-time-only, or to cycle through text in order the first time but then pick randomly among the options.
  • All the material from all previous consultation documents, and all suggestions received since the last document, have been added to a database in preparation to launch a new suggestions forum with the new build; the suggestions forum has been tested by some volunteers; and new comments/responses provided for a number of those suggestions.
  • Work is underway on creating a bug tracker to display the status of bug reports on the Inform 7 site. We do not know for certain whether this will be ready in time for the build, or whether it will follow the new release a bit later.
  • In response to some old requests, we have created a few more simulationist extensions to be released at the same time as the new build (though not bundled in). The largest of these is an extension for handling measurable, mixable liquids, and the code to tie that in optionally with the sinks-and-taps part of the Modern Conveniences extension.

ZMPP now with Glulx

Wei-ju Wu announces his progress on a browser-based interpreter for Glulx, which includes the ability to display images:

I spent the majority of April’s evenings to implement the Glulx/Glk
part of ZMPP’s second revision and just wanted to share the current
progress, as I reached an important milestone – running “Alabaster”:

http://zmpp.sourceforge.net/alabaster.html

I hope it works for you and you find it useful or amusing in one way
or another :-)

It was running for me when testing on:
- Mac Safari
- Linux Firefox (Ubuntu Lucid Lynx, OpenJDK/IcedTea), Windows Firefox
- Windows IE (with Sun/Oracle Java Plugin)

Yes, it’s again a Java applet based interpreter. ZMPP is not
necessarily specialized on Applet/Desktop, but it’s the quickest for
me to implement.

Some points that you might find interesting:
- It is now completely written in Scala
- I only ran “Risorgimento Represso” and “Alabaster” so far
- Since “Alabaster” is such an extreme case in terms of the sheer
amount of instructions that gets thrown at the interpreter (especially
when accelfuncs are not supported), it was the perfect game to test
with. Besides, it was fun, playing and reading through it.

I apologize for the quirks that might and will arise (like positioning
the mouse pointer inside the input window) – I decided against
extensive polishing and instead sticking to my timeline.