Entries Tagged 'New Releases' ↓

6E72 for Windows and Linux CLI are now available from the download page.

Unfortunately, there appears to be an issue in the IDE under pre-10.6 versions of the Mac OS, such that Inform refuses to run the compiled game in the IDE or to release it properly. This appears to be intermittent and has a workaround (closing a newly-made project and opening it again) under 10.5; in one case on a PPC for 10.4, the workaround does not work.

For more background on this issue, see these Mantis reports: 1 2. When an updated version of the Mac OS IDE becomes available, we will announce the replacement here.

The Mac OS X version of Inform release 6E72 is now available, to be followed by versions for other platforms. This version offers no new features, but fixes a number of bugs from the 6E59 release that were deemed critical or serious. (Some bugs considered mild or cosmetic remain.)

The change log lists the bugs fixed, and more detail about them can be found at the bug tracking site.

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.

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.

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.

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.

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.

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.

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.)