Entries from June 2010 ↓

Quixe Glulx interpreter

Quixe, a Glulx interpreter for browsers, now comes in a form that can be used to release a website with playable Glulx content. The package and instructions can be found here. Please note that Quixe is still in development, and in particular that it does not yet feature save and restore abilities.

6E59: Phrasebook Index

screen-shot-2010-06-16-at-111153-pm

One substantial change to Inform release 6E59 is the improvement to the Phrasebook tab of the index. The new version has been substantially redesigned so that each phrase expands to a detailed description of syntax, linked to an equivalent portion of the manual.

This is a partial attempt to address the ongoing desire for better reference documentation in Inform 7.

For the time being, we have not updated the plain text “syntax document” that accompanies Inform to account for the syntax of 6E59. One reason for that is time — it would need some hours of work to be brought in line with the new build, and the document maintainer is over-extended — but the other reason is that we are hoping to discover whether the Phrasebook can usefully take over some of the work that the syntax document has done in the past. Obviously, it won’t handle everything — the syntax document addresses assertions as well as phrases, and assertion formats are not discussed in the Phrasebook. On the other hand, the Phrasebook is automatically generated, reliably thorough, and directly linked into the documentation — features the syntax document can’t copy. So we are hoping to move towards improving Inform’s indexing and documentation, rather than continuing to produce syntax documents indefinitely.

Suggestions concerning this — the usefulness of the Phrasebook, and any other elements that might be needed — can helpfully go on the uservoice forum.

6E59: Generalized scene rulebooks

The change log mentions very briefly:

Up to now, every scene has had a “when S begins” and “when S ends” rulebook,
but there has been no way to express rules generalising about scenes. We
can now write, e.g.:

A scene can be bright or dim. A scene is usually dim. Dawn is a bright scene.

When a scene which is bright ends: say “So passes the bright [scene being changed].”

When a recurring scene begins: say “Groundhog Day!”

In addition, text defined in quotes after a scene definition becomes part of the scene description, and is printed automatically when the scene begins.

The new example Entrevaux shows how these features might be used for a scene-centric rather than location-centric kind of programming.

6E59: “end the game” vs. “end the story”

The new build discourages the use of several old phrases; of these, perhaps the most common is the set “end the game in victory”, “end the game in death”, and “end the game saying…”. Almost every project will have contained at least one of these phrases.

Instead, Inform now prefers

end the story
end the story finally
end the story saying (text)
end the story finally saying (text)

There are two reasons behind this change.

One is to move away from the terminology of “game”: not everything produced by Inform these days is a game.

The other is to deal with an inconsistency in the old system. The previous phrasing structure meant “end the game saying ‘…’” could only be used to describe what Inform thought of as “losing” endings. This corresponds to a structure from Inform 6, where there could be only one victory message, but any number of exotic death messages.

The distinction between winning and losing has been replaced by a distinction between “final” and “non-final” endings. This makes a difference only to what is printed by the “Table of Final Question Options”: it is possible to specify some options to be printed only if we have reached a final ending — for instance if there is spoilery information we would like to show the player only after we know he has seen everything the story has to offer.

For more about the options at the end of the story, see the Recipe Book on Out of World Actions and Effects > Ending the story.

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