mirror of
https://github.com/ganelson/inform.git
synced 2024-07-16 22:14:23 +03:00
3027 lines
126 KiB
Markdown
3027 lines
126 KiB
Markdown
# Release notes for Inform v8.1 (build 6E59)
|
|
|
|
This release was made on 12 June 2010, before Inform was open-sourced.
|
|
At that time bugs were tracked by a Mantis server, with seven-digit issue numbers,
|
|
and versions of Inform were identified by build codes in the form NLNN.
|
|
Suggestion numbers, also large but not starting with a 0, referred to tickets at
|
|
a Uservoice forum then in use.
|
|
|
|
This is part of the [historical archive of release notes](../version_history.md).
|
|
|
|
## Overview
|
|
|
|
This is a major release of Inform: the first in a little over a year, and
|
|
with a change log well over double the previous record size - large enough
|
|
to need a table of contents for the first time. Inform has new icons, and
|
|
a slightly revised design; more than 250 bug reports have been closed, so
|
|
that it currently has no issues open. There are minor surface enhancements
|
|
right across the language, and these are (mainly) the result not of fiddling
|
|
but of substantial rewrites of the underlying compiler. Many exceptions
|
|
have gone, and the language's design is more uniform as a result. 6E59
|
|
contains many changes from 5Z71 and it may take authors a day or two to
|
|
adapt their existing source text to these changes, but it should also prove
|
|
a stronger and more reliable Inform to work with. For the first time there
|
|
was a substantial third-party exercise in beta-testing the release, and
|
|
as from this build we are also launching a public suggestions forum and
|
|
an open bug-tracker.
|
|
|
|
Note that a prototype release, [7.2](7-2.md), had included many of these
|
|
features for beta-testing purposes, so that the two release notes have a great
|
|
deal of overlap (though this one is longer).
|
|
|
|
## Language
|
|
|
|
### Releasing
|
|
|
|
Feedback after clicking the "Release" button has been much improved, with
|
|
Inform either producing a report on what has happened or a legible list of
|
|
problems. Inform has always been able to release a project with supplementary
|
|
material added, right up to a mini-website for housing it, and in this build
|
|
we add the ability to create a web page making the project playable
|
|
in-browser. The new syntax:
|
|
```
|
|
Release along with an interpreter.
|
|
```
|
|
causes Inform to bundle up a customised copy of a Javascript interpreter,
|
|
along with a suitably encoded story file, so that the eventual player can
|
|
just visit the page in any modern browser and begin playing. We believe that
|
|
giving Inform a one-click way to make such web pages will help IF authors
|
|
to reach out to casual gamers on the web.
|
|
|
|
There has been great interest in browser-based story file interpretation
|
|
recently; as recently as a few years ago this would have been prohibitively
|
|
slow, but continuing increases in processor speed - and intensive work by
|
|
browser manufacturers in optimising Javascript performance - have made this
|
|
a genuinely workable option today. Projects such as "Silverglulxe", "Leaflet"
|
|
and "Parchment" have made considerable progress, and we would like Inform to
|
|
help this development.
|
|
|
|
Inform ships with "Parchment" built in. At present this supports only
|
|
projects using the Z-machine story file format, but we have made every effort
|
|
to help Inform to accommodate future developments, and to enable it to be
|
|
used with other interpreters, too:
|
|
|
|
(a) Interpreters are stored by Inform in almost exactly the same way as
|
|
website templates are. Each must have a name; the default is "Parchment",
|
|
just as the default website template is called "Standard", but it's easy
|
|
to specify something different:
|
|
```
|
|
Release along with the "Urbzig" interpreter.
|
|
```
|
|
(b) Exactly as with website templates, Inform looks for these first in the
|
|
"Templates" subfolder of the current project's "Materials" folder; then in
|
|
the "Templates" subfolder of the Inform folder on the user's computer (the
|
|
details vary with platform, but for instance on Mac OS X this is the folder
|
|
"~/Library/Inform", where "~" is the user's home folder); and lastly in its
|
|
own built-in stock, hidden away inside the Inform application. "Parchment"
|
|
is undergoing rapid development; placing any new copy of it in one of the
|
|
two locations above enables the user to get its benefits straight away,
|
|
without having to wait for some future build of Inform to incorporate the
|
|
update.
|
|
|
|
(c) An interpreter is stored as a folder of Javascript and/or CSS files
|
|
and/or images, together with a file called "(manifest).txt" which describes
|
|
it and how Inform should put together a story file for it to play. The
|
|
manifest for "Parchment" is heavily commented, and should help provide a
|
|
model for other interpreter-writers to use. We very much hope that authors
|
|
of other Javascript-based interpreters will find it straightforward to use
|
|
this system, and we will be very happy to look at any problems they have.
|
|
|
|
Another notable change is that "Release" now always releases the story
|
|
file into the "Release" subfolder of the project's "Materials" folder -
|
|
creating these if they do not already exist. In previous builds, it almost
|
|
always did so; but would put up a Save... dialogue box if the release
|
|
contained only the story file and nothing else. In practice, most
|
|
serious releases are going to involve at least some material beyond the
|
|
story file, and for consistency's sake we've got rid of the Save...
|
|
dialogue box and gone for the "Release" folder in all cases.
|
|
|
|
Miscellaneous small changes have been made to the "Release" mechanism
|
|
throughout; for example, a problem to do with Skein files which have lines
|
|
over 10K in length has been removed (the threshold was raised to 50K and
|
|
warnings about trimming have replaced errors), and a more serious bug to
|
|
do with projects containing around 500 or more images (which affected
|
|
Windows users but not OS X or Linux) has been fixed.
|
|
|
|
### Relations
|
|
|
|
Relations are central to Inform. Every verb's meaning is a relation, and
|
|
Inform's model of the world is based on relationships holding between objects
|
|
and/or other values.
|
|
|
|
This build makes it possible to define relations on any kinds of value (not,
|
|
as before, only on finite kinds and even then with petty restrictions); to
|
|
use relations as first-class values in their own right; and to create
|
|
relations on a temporary basis.
|
|
|
|
(a) Relations on any kinds of value:
|
|
|
|
We can now define relations between more or less anything:
|
|
```
|
|
Partnership relates various texts to various texts.
|
|
|
|
The verb to belong with (he belongs with, they belong with) implies the
|
|
partnership relation.
|
|
|
|
"cheese" belongs with "crackers".
|
|
"clam" belongs with "chowder".
|
|
```
|
|
And this allows us to create large and varied data structures. A relation is a
|
|
natural generalisation of an associative array (an "associative hash" in Perl,
|
|
a "dictionary" in Python, a "table" in Lua, and so on - the idea goes back
|
|
at least to Smalltalk and the mid-1970s). In fact, an associative array is
|
|
exactly a various-to-one relation in Inform terms.
|
|
|
|
There are two caveats:
|
|
|
|
- (i) Previous builds would have rejected this because the domain
|
|
(texts) is simply too big. The new build makes use of hash tables
|
|
dynamically built in allocated memory to cope with this (using
|
|
run-time code generously contributed by Jesse McGrew) - as such it
|
|
really only works efficiently when the Settings for the project
|
|
are set to the Glulx virtual machine.
|
|
- (ii) Inform isn't good at reasoning with relations when the domains
|
|
are too big to make search loops practicable, so some constructions
|
|
like "if 5 tallies with an even number" - where "tallies with" means
|
|
a various-to-various relation of numbers to numbers - aren't allowed.
|
|
But see below.
|
|
|
|
(b) Extracting values from relations:
|
|
|
|
Suppose we've defined the example partnership relation above. How could we
|
|
find out what, if anything, "caviar" belongs with? It would be impractical
|
|
to keep trying
|
|
```
|
|
if "caviar" belongs with "aardvarks", ...
|
|
if "caviar" belongs with "abacuses", ...
|
|
...
|
|
```
|
|
Instead:
|
|
```
|
|
if "caviar" relates to a text by the partnership relation, ...
|
|
```
|
|
tests whether or not it relates to anything; and if it does,
|
|
```
|
|
a text which "caviar" relates to by the partnership relation
|
|
```
|
|
will produce one such text. Of course, there might be many: so
|
|
```
|
|
list of texts which "caviar" relates to by the partnership relation
|
|
```
|
|
will produce them all. And we can also look at this the other way round:
|
|
```
|
|
if a text relates to "caviar" by the partnership relation, ...
|
|
a text which relates to "caviar" by the partnership relation
|
|
list of texts which relate to "caviar" by the partnership relation
|
|
```
|
|
Still more interesting are the slightly tongue-twister-like:
|
|
```
|
|
list of texts which the partnership relation relates
|
|
list of texts which the partnership relation relates to
|
|
```
|
|
If we had written:
|
|
```
|
|
"cheese" belongs with "crackers".
|
|
"clam" belongs with "chowder".
|
|
```
|
|
then these lists might be { "cheese", "clam" } and { "crackers", "chowder" }
|
|
respectively. (For efficiency reasons, there are no guarantees about what
|
|
order the lists have - but they can of course always be sorted when found.)
|
|
|
|
(c) Relations as themselves values:
|
|
|
|
Relations have always been values, but in past builds their kind was simply
|
|
"relation", which made it impossible to distinguish, say, the visibility
|
|
relation (can one person see another?) from, say, these:
|
|
```
|
|
Parity relates a number (called N) to a number (called M) when N minus M
|
|
is even.
|
|
|
|
Joint magnitude relates a number (called N) to a number (called M) when
|
|
N plus M is greater than 7.
|
|
```
|
|
In any case, little could usefully be done with relations as values, because
|
|
there was no good way to test or assert them other than explicitly.
|
|
|
|
In this build, a relation has the kind "relation of K to L", where K and L are
|
|
the kinds of the two things it relates. For instance, "joint magnitude relation"
|
|
has the kind "relation of numbers to numbers"; though it's also allowed to
|
|
write just "relation of numbers", because Inform assumes both kinds are the
|
|
same if only one is given. We can now write, say:
|
|
```
|
|
To chart (R - a relation of numbers):
|
|
repeat with N running from 1 to 5:
|
|
repeat with M running from 1 to 5:
|
|
if R relates N to M, say "[N] <=> [M] ";
|
|
say "[line break]";
|
|
```
|
|
and now "chart parity relation" will work nicely, but "chart visibility
|
|
relation" will be rejected (as it should be). More ambitiously:
|
|
```
|
|
When play begins:
|
|
let L be { parity relation, joint magnitude relation };
|
|
repeat with R running through L:
|
|
chart R;
|
|
```
|
|
Here the kind of L is "list of relations of numbers to numbers".
|
|
|
|
In general, we can write
|
|
```
|
|
if R relates X to Y, ...
|
|
now R relates X to Y;
|
|
now R does not relate X to Y;
|
|
```
|
|
to test, set and unset a relation R between two values, though of course
|
|
Inform checks that the values have the right kind and produces a problem
|
|
message if not.
|
|
|
|
(d) Adjectives applying to relations:
|
|
|
|
The following are now defined:
|
|
```
|
|
"empty" - nothing relates to anything else
|
|
"symmetric" - by definition X relates to Y if and only if Y relates to X
|
|
"equivalence" - this is a relation "in groups", or an "equivalence relation"
|
|
"one-to-one" - it relates one K to one L
|
|
"one-to-various" - similarly
|
|
"various-to-one" - similarly
|
|
"various-to-various" - similarly
|
|
```
|
|
So for example it's possible to ask
|
|
```
|
|
if R is a symmetric one-to-one relation of texts, ...
|
|
```
|
|
With some relations, it's possible to clear them out by writing:
|
|
```
|
|
now R is empty;
|
|
```
|
|
and with temporary relations (see below), it's even possible to change their
|
|
valencies (one-to-one vs. one-to-various, etc.) using "now", but only when
|
|
they are empty. The exceptions where "empty" can't be used are those which
|
|
can't be changed at all, and a few built-in cases such as "support",
|
|
"containment" and "incorporation", where emptying would dissolve the model
|
|
world in a disastrous way.
|
|
|
|
(e) Making temporary relations:
|
|
|
|
In past builds of Inform, the relations were all created explicitly by the
|
|
source text. The stock of relations which exist at the start of play could
|
|
not be changed; the relationships might change - sometimes Red Riding Hood
|
|
would be in the Woodcutter's Cottage, sometimes not - but the relations
|
|
themselves (in this case, containment) were eternal.
|
|
|
|
This is no longer true, and it's now easy to create relations as dynamic
|
|
data structures, like lists or indexed texts. For example:
|
|
```
|
|
let the password dictionary be a relation of texts;
|
|
```
|
|
This makes a purely temporary various-to-various relation between texts,
|
|
which lasts as long as the temporary value "password dictionary" lasts.
|
|
By default, relations are various-to-various, but we could instead write,
|
|
say:
|
|
```
|
|
let the nicknames catalogue be a various-to-one relation of texts;
|
|
```
|
|
Such a relation exists only in the current phrase, and is destroyed when
|
|
the phrase finishes, like any other "let". Of course there's no verb whose
|
|
meaning in this relation, but that's no obstacle, because we can manipulate
|
|
it using "relates":
|
|
```
|
|
now the nicknames catalogue relates "Trudy" to "Snake-eyes";
|
|
```
|
|
(At present such a relation cannot be used outside its own phrase, but we
|
|
hope to enable this in future builds by means of closures.)
|
|
|
|
### Assemblies
|
|
|
|
Up to now, assemblies like this:
|
|
```
|
|
A signpost is a kind of thing. Every room contains a signpost.
|
|
```
|
|
have been deprecated as not always reliable - it was a bad idea to make
|
|
constructions on the basic kinds "room", "container", "supporter", "door"
|
|
or "thing", the above being an example of an assembly on "room". That
|
|
restriction is now lifted, and the above works as it looks as if it should.
|
|
|
|
Assemblies can now involve values as well as objects. For example, if we
|
|
start from:
|
|
```
|
|
A colour is a kind of value. The colours are red, green and blue.
|
|
Liking relates various people to various colours.
|
|
The verb to like (he likes, they like, it is liked) implies the liking relation.
|
|
```
|
|
then the assembly:
|
|
```
|
|
Every person likes a colour.
|
|
```
|
|
will produce an initial situation like so:
|
|
```
|
|
>relations
|
|
Liking relates various people to various colours:
|
|
You >=> your colour
|
|
Daphne >=> Daphne's colour
|
|
```
|
|
Here the assembly process has created two new colour values. Had the assembly
|
|
instead been written:
|
|
```
|
|
A person likes every colour.
|
|
```
|
|
then the result would be:
|
|
```
|
|
Liking relates various people to various colours:
|
|
The person >=> red
|
|
The person >=> green
|
|
The person >=> blue
|
|
```
|
|
where this time three new people have been created. Note that these people have
|
|
no fancy names. But we can arrange for that with another new feature:
|
|
```
|
|
A person (called its fan) likes every colour.
|
|
```
|
|
Which would instead produce:
|
|
```
|
|
Liking relates various people to various colours:
|
|
Red's fan >=> red
|
|
Green's fan >=> green
|
|
Blue's fan >=> blue
|
|
```
|
|
Similarly,
|
|
```
|
|
Every person likes a colour (called his favourite colour).
|
|
```
|
|
produces:
|
|
```
|
|
Liking relates various people to various colours:
|
|
You >=> your favourite colour
|
|
Daphne >=> Daphne's favourite colour
|
|
```
|
|
Just as "its" (or "his" or "her" or "their") expands out to a possessive form
|
|
of the name of the owner, so to speak, so "it" (or "he" or "she" or "they" or
|
|
"him" or "them") expands out to the name itself. Thus:
|
|
```
|
|
A person (called the world's leading fan of it) likes every colour.
|
|
```
|
|
produces:
|
|
```
|
|
Liking relates various people to various colours:
|
|
World's leading fan of red >=> red
|
|
World's leading fan of green >=> green
|
|
World's leading fan of blue >=> blue
|
|
```
|
|
All of these callings can of course be made for standard assemblies of
|
|
objects too; for example,
|
|
```
|
|
Every room contains a vehicle (called its buggy).
|
|
```
|
|
would make a whole lot of suitably named buggies.
|
|
|
|
The rule on what happens if there's no "(called ...)" text might be worth
|
|
spelling out exactly:
|
|
|
|
- (1) If we are assembling a value of kind K, then the calling text is
|
|
taken as if it were "(called its K)" - for instance, "(called its
|
|
colour)" in the first example above, which resulted in names like
|
|
"your colour" and "Daphne's colour".
|
|
However, if that results in a name which already exists, a number
|
|
is suffixed to make it a unique name; for instance, if there were
|
|
six anonymous people, then "Every person likes a colour" would
|
|
result in names like "person's colour 2", "person's colour 3", and
|
|
so forth. (It's a bad idea to write assemblies where this could
|
|
ever matter.)
|
|
- (2) If we are assembling an object of kind K, then no name is attached
|
|
unless the relationship is incorporation - i.e., being a part of
|
|
something - and the object being attached to already has a name;
|
|
in that case, the calling text is again "(called its K)".
|
|
|
|
The reason that the convention differs between objects and values is that
|
|
objects are allowed to have names clashing with other objects, or no name at
|
|
all, whereas values have to have names belonging to themselves alone.
|
|
|
|
### Kinds
|
|
|
|
As a convenience for debugging awkward phrases, the following:
|
|
```
|
|
showme V;
|
|
```
|
|
works for any value V, and prints out V, its kind, and then (unless it is a
|
|
constant) its current value. For example:
|
|
```
|
|
When play begins:
|
|
showme indigo;
|
|
showme location;
|
|
showme the list of vivid colours;
|
|
```
|
|
might open play by printing up:
|
|
```
|
|
colour: indigo
|
|
"location" = object: Lille Conservatoire
|
|
"list of vivid colours" = list of colours: {red, indigo, chartreuse}
|
|
```
|
|
This is intended purely for testing. In a Release version, "showme" is always
|
|
silent, so that if any "showme" phrases are left in by accident, they'll never
|
|
be seen by anyone else.
|
|
|
|
Almost every kind has a "default value", that is, a value used when Inform
|
|
knows that a variable or table entry should contain something of this kind,
|
|
but doesn't know what it is. The phrase
|
|
```
|
|
default value of K
|
|
```
|
|
evaluates to this value, for any named kind K. For example,
|
|
```
|
|
showme default value of time;
|
|
```
|
|
produces the output:
|
|
```
|
|
"default value of time" = time: 9:00 am
|
|
```
|
|
This can be useful when the default value is needed, but has no convenient
|
|
natural-language name; for example, "default value of table name", or
|
|
"default value of sound name".
|
|
|
|
Enumerated kinds have always had phrases to make it easier to trawl through
|
|
their values: for instance,
|
|
```
|
|
the colour after C
|
|
the colour before C
|
|
a random colour
|
|
a random colour between orange and blue
|
|
a random colour from orange to blue
|
|
```
|
|
(The last two are synonymous.) To these, we now add:
|
|
```
|
|
the first value of colour
|
|
the last value of colour
|
|
```
|
|
If, for example:
|
|
```
|
|
Colour is a kind of value. The colours are red, orange, yellow, green,
|
|
blue, indigo and violet.
|
|
```
|
|
then "the first value of colour" produces "red", and "the last value of colour"
|
|
produces "violet".
|
|
|
|
It is now possible to change how kinds relate to each other, but only if no
|
|
previous statements are contradicted by doing so. For example, the Standard
|
|
Rules say that "container" and "supporter" are kinds of "thing"; now supposing
|
|
we type:
|
|
```
|
|
An enclosure is a kind of thing.
|
|
A container is a kind of enclosure. A supporter is a kind of enclosure.
|
|
```
|
|
This is now allowed. Containers and supporters are still things; they have
|
|
merely become more specialised, and there is no contradiction. On the other
|
|
hand, this is incorrect:
|
|
```
|
|
An enclosure is a kind of region.
|
|
A container is a kind of enclosure. A supporter is a kind of enclosure.
|
|
```
|
|
This is a contradiction, since regions are not things, and Inform rejects
|
|
it with a problem message.
|
|
|
|
The "description" kind has been removed. In its place is a more expressive
|
|
one: "description of K" for any kind K - for example, "description of numbers",
|
|
which would be matched by "even numbers".
|
|
|
|
This may mean changing a small amount of existing source text; the change
|
|
should be as simple as replacing "description" by "description of objects".
|
|
(We apologise for the nuisance, but "description" was always a poor choice
|
|
of name, clashing with the property called "description", for instance.)
|
|
|
|
Given any two kinds K and L, the kind "relation of K to L" is now a kind.
|
|
More concisely, "relation of K" means the same as "relation of K to K".
|
|
|
|
Given any two kinds K and L, the kind "phrase K -> L" is now a kind. (This
|
|
is meant to look like a mathematical function arrow.) For example, the
|
|
phrase defined by
|
|
```
|
|
To decide which number is the square of (N - a number): ...
|
|
```
|
|
has the kind "phrase number -> number". Brackets and commas are used if the
|
|
phrase combines several values: thus
|
|
```
|
|
To decide which indexed text is (T - text) repeated (N - a number) times: ...
|
|
```
|
|
would have kind "phrase (text, number) -> indexed text". The word "nothing"
|
|
is used if there are no values in, or no value out - thus
|
|
```
|
|
To decide which number is the magic target: ...
|
|
```
|
|
has kind "phrase nothing -> number", and
|
|
```
|
|
To dig (eastward - length) by (northward - length): ...
|
|
```
|
|
has the kind "phrase (length, length) -> nothing".
|
|
|
|
Thus phrases can be stored in variables, properties and so on. We can give
|
|
any phrase a name like so:
|
|
```
|
|
To decide what number is double (N - a number) (this is doubling):
|
|
decide on N plus N.
|
|
```
|
|
This is the same syntax used to name rules, and the idea is the same. If we
|
|
try "showme doubling", the result is
|
|
```
|
|
phrase number -> number: doubling
|
|
```
|
|
But there's no advantage to storing a phrase if it can't be used, so:
|
|
```
|
|
showme doubling applied to 2;
|
|
```
|
|
produces
|
|
```
|
|
"doubling applied to 2" = number: 4
|
|
```
|
|
There are versions of "applied to" for phrases applied to 0 to 3 arguments:
|
|
```
|
|
F applied
|
|
F applied to V
|
|
F applied to V and W
|
|
F applied to V and W and X
|
|
```
|
|
For phrases which do not produce a value, we use "apply":
|
|
```
|
|
apply F;
|
|
apply F to V;
|
|
apply F to V and W;
|
|
apply F to V and W and X;
|
|
```
|
|
The default value for "phrase K -> L" is a phrase which, no matter what value
|
|
of K it applies to, always produces the default value of L. It's a sort of
|
|
equivalent of the zero function in mathematics - indeed that's exactly what
|
|
it is, if L is "number". These trivial phrases have no names, but can be
|
|
referred to using "default value of...". Thus:
|
|
```
|
|
let Q be a phrase numbers -> times;
|
|
showme Q;
|
|
showme Q applied to 4;
|
|
showme Q applied to -7;
|
|
```
|
|
might produce:
|
|
```
|
|
"q" = phrase number -> time: default value of phrase number -> time
|
|
"q applied to 4" = time: 9:00 am
|
|
"q applied to -7" = time: 9:00 am
|
|
```
|
|
Here Q is set to the default phrase because we didn't give it any other
|
|
value; it has the name we might expect ("default value of phrase number -> time")
|
|
and it works as advertised, producing 9:00 am no matter what number is fed in.
|
|
|
|
More ambitiously:
|
|
```
|
|
let R be a phrase numbers -> (phrase numbers -> colours);
|
|
showme R;
|
|
showme R applied to 3;
|
|
showme (R applied to 3) applied to 2;
|
|
```
|
|
might produce:
|
|
```
|
|
"r" = phrase number -> (phrase number -> colour): default value of phrase
|
|
number -> (phrase number -> colour)
|
|
"r applied to 3" = phrase number -> colour: default value of phrase number
|
|
-> colour
|
|
"( r applied to 3 ) applied to 2" = colour: red
|
|
```
|
|
In the case where L is "nothing", we get a phrase which does nothing and
|
|
produces no value. For example, if we write:
|
|
```
|
|
let S be a phrase numbers -> nothing;
|
|
```
|
|
then
|
|
```
|
|
apply S to 17;
|
|
```
|
|
does nothing at all, but it's perfectly legal.
|
|
|
|
Just as phrases now have kinds, the same is true of the other "active" gadgets
|
|
within Inform: activities, rules and rulebooks.
|
|
|
|
For any kind K, "activity on K" is a kind. If we write:
|
|
```
|
|
Tweaking the nose of something is an activity.
|
|
Refreshing the screen is an activity.
|
|
```
|
|
then the first is an "activity on objects", and the second an "activity on
|
|
nothing". That was true in previous builds of Inform, too, though there was
|
|
no way to express the difference, and so Inform didn't typecheck it. (Indeed,
|
|
it turned out that a minor error in the Standard Rules was going uncaught as a
|
|
result.) But we can now write, say:
|
|
```
|
|
Announcing something is an activity on numbers.
|
|
Rule for announcing a number (called N): say "Ladies and gentlemen, [N]."
|
|
```
|
|
and then
|
|
```
|
|
carry out the announcing activity with 12.
|
|
```
|
|
This won't be useful for many people, but it's more flexible and consistent,
|
|
and activities on pictures and sound effects may be a nice interface for
|
|
multimedia extensions to provide.
|
|
|
|
(The word "activity" is now an abbreviation for "activity on value", that is,
|
|
any kind of activity. It's unlikely that anyone will need to change existing
|
|
source text.)
|
|
|
|
Rules and rulebooks now have kinds which can be written as follows:
|
|
```
|
|
rulebook
|
|
K based rulebook
|
|
rulebook producing L
|
|
K based rulebook producing L
|
|
```
|
|
(and similarly for "rule"). See the RULEBOOKS section below for more; if you
|
|
have source text which makes use of values produced by rulebooks, you will need
|
|
to modify it, as those are now typechecked for the first time, and some syntax
|
|
changes have been necessary to make this reliable.
|
|
|
|
Finally, two of Inform's ways to store values are similarly extended, though
|
|
in practice it's rare to mention kinds of either sort explicitly in source
|
|
text, so people will mainly not notice.
|
|
```
|
|
K valued property
|
|
K valued table column
|
|
```
|
|
As a piece of syntactic sugar, writing "either/or property" is equivalent to
|
|
writing "truth state valued property".
|
|
|
|
Given that Inform now has seven constructions on kinds - lists, descriptions,
|
|
relations, activities, rules, rulebooks and phrases - some interesting
|
|
combinations are now open:
|
|
```
|
|
phrase (relation of numbers to colours, number) -> list of colours
|
|
```
|
|
Brackets can be used to clarify matters:
|
|
```
|
|
phrase (phrase number -> (phrase number -> number)) -> nothing
|
|
```
|
|
Nothing will make that a simple idea, but it's unambiguous and can be puzzled
|
|
out with practice.
|
|
|
|
The following sentences now have identical effect:
|
|
```
|
|
Concept is a kind.
|
|
Concept is a kind of object.
|
|
```
|
|
Previously Inform rejected the second form, but it's now being allowed for the
|
|
sake of consistency of syntax. Similarly:
|
|
```
|
|
The green leather sofa is an object.
|
|
```
|
|
is now allowed; previously Inform would have demanded that it be said to be
|
|
a thing, a door, etc. (In the absence of other information, it will come out
|
|
as a thing, in fact.)
|
|
|
|
The kind "table name" can now be the kind of a variable whose value is not
|
|
explicitly declared.
|
|
|
|
The kind "action name" can now be repeated through, which means it's now
|
|
legal to form, say, "the list of action names".
|
|
|
|
The kind "use option" can similarly now be repeated through, and can be said,
|
|
for the first time. Two new adjectives have been defined for use options:
|
|
"active" and "inactive", with the obvious meanings. This means it's possible
|
|
to describe the current options with something like:
|
|
```
|
|
say "We're currently using: [list of active use options].";
|
|
```
|
|
The result might be, say,
|
|
```
|
|
We're currently using: dynamic memory allocation option [8192], maximum
|
|
indexed text length option [1024], maximum things understood at once
|
|
option [100], American dialect option and fast route-finding option.
|
|
```
|
|
This may be useful for testing purposes.
|
|
|
|
The former condition "using O", true if the option O is active, false
|
|
if not, has not yet been withdrawn but is now deprecated, and may be
|
|
removed in future builds, since it is redundant and less flexible; please
|
|
write "if O is active" instead of "if using O".
|
|
|
|
In the early days of Inform, built-in kinds of value had to have single word
|
|
names. That has long ceased to be true, but some of those awkward names
|
|
remained - for example, we had "indexed text" (two words) but "table-name"
|
|
(hyphenated to make it one word). All of those hyphenated kinds of value
|
|
are now written out in words, with the hyphens removed: thus
|
|
```
|
|
table name figure name sound name action name equation name
|
|
external file Unicode character use option table column
|
|
```
|
|
The traditional hyphenated names are still recognised (table-name, figure-name
|
|
and so on), except for the hardly ever used "table-column", but the documentation
|
|
and Index pages always prefer the new unhyphenated forms.
|
|
|
|
The following kinds, always intended for internal use only, have been withdrawn:
|
|
```
|
|
domain-description miscellaneous-value text-routine boxed-quotation
|
|
rule-outcome abstract-relation
|
|
```
|
|
|
|
### Map, Filter and Reduce
|
|
|
|
When a mass of computations has to be done, the traditional approach is to work
|
|
through them in a "repeat" loop. One modern alternative, growing in popularity,
|
|
is to form a list of inputs; then apply the same computation to each input in
|
|
turn to form a list of results (this is called "mapping"); throw out any
|
|
bad or unwanted results ("filtering"); and then combine the surviving results
|
|
into a single composite answer ("reducing", though some programming languages
|
|
call this "folding" or "accumulation"; it's a much-reinvented idea).
|
|
|
|
Inform provides all three of these fundamental list-processing operations. There
|
|
is no special term for a "map", because Inform treats it as another case of
|
|
"applied to". Thus:
|
|
```
|
|
doubling applied to {2, 3, 4};
|
|
```
|
|
produces the list {4, 6, 8}. More divertingly, suppose we define:
|
|
```
|
|
To decide what indexed text is the longhand form of (N - a number)
|
|
(this is spelling out):
|
|
decide on "[N in words]".
|
|
|
|
To decide what indexed text is the consonant form of (T - indexed text)
|
|
(this is txtng):
|
|
replace the regular expression "<aeiou>" in T with "";
|
|
decide on T.
|
|
```
|
|
Then we can write a chain:
|
|
```
|
|
txtng applied to spelling out applied to doubling applied to {3, 8, 4, 19, 7}
|
|
```
|
|
to produce the value {"sx", "sxtn", "ght", "thrty-ght", "frtn"}.
|
|
|
|
Next, filtering. Here we make use of descriptions, in order to say what values
|
|
will be allowed through the filter. Thus:
|
|
```
|
|
filter to even numbers of {3, 8, 4, 19, 7}
|
|
```
|
|
produces {8, 4}, with the values 3, 19, and 7 failing to make it through. (A
|
|
sufficiently fine filter may well thin out a list to a single entry, or even
|
|
no entries at all, but the result is always a list.) To get the full effect of
|
|
filtering, we probably need to define an adjective or two:
|
|
```
|
|
Definition: an indexed text (called T) is lengthy if the number of
|
|
characters in it is greater than 6.
|
|
```
|
|
so that we can then write, say:
|
|
```
|
|
filter to lengthy indexed texts of spelling out applied to {15, 2, 20, 29, -4}
|
|
```
|
|
which produces {"fifteen", "twenty-nine", "minus four"}.
|
|
|
|
Lastly, reduction. In order to combine a whole list of values, we need a phrase
|
|
to combine any two. Here are some samples:
|
|
```
|
|
To decide what number is the larger of (N - number) and (M - number)
|
|
(this is maximizing):
|
|
if N > M, decide on N;
|
|
decide on M.
|
|
|
|
To decide what number is the sum of (N - number) and (M - number)
|
|
(this is summing):
|
|
decide on N + M.
|
|
|
|
To decide what indexed text is the concatenation of (X - indexed text) and
|
|
(Y - indexed text) (this is concatenation):
|
|
decide on "[X][Y]".
|
|
```
|
|
And here are some sample reductions:
|
|
```
|
|
let X be the maximization reduction of {3, 8, 4, 19, 7};
|
|
let Y be the summing reduction of {3, 8, 4, 19, 7};
|
|
let Z be the concatenation reduction of txtng applied to spelling out
|
|
applied to doubling applied to {3, 8, 4, 19, 7};
|
|
```
|
|
sets X to 19, the highest of the values, Y to 41, their sum, and Z to the
|
|
indexed text "sxsxtnghtthrty-ghtfrtn". In each case a list has been reduced
|
|
to a single value which somehow combines the contents.
|
|
|
|
Is map/filter/reduce always a good idea? Devotees point out that almost any
|
|
computation can be thought of in this way, and in systems where the work has
|
|
to be distributed around multiple processors it can be a very powerful tool.
|
|
(There are programming languages without loops where it's essentially the only
|
|
tool.) At its best, it reads very elegantly: one assembles all of the tools
|
|
needed - definitions of doubling, lengthy, spelling out, concatenation and
|
|
so on - and then each actual task is expressed in a single line at the end.
|
|
|
|
On the other hand, there are also times when this is a needlessly complicated
|
|
disguise for what could more easily be done with a "repeat" loop, and also
|
|
more efficiently since assembling and dismantling lists in memory does take
|
|
some overhead time. So these list operations are not a panacea, but it's good
|
|
to have them available.
|
|
|
|
### Generic Phrases
|
|
|
|
The following looks quite innocent:
|
|
```
|
|
To say (V - value) twice: say "[V]. [V], I say!";
|
|
```
|
|
It's clear what we intend it to do, but previous builds of Inform would have
|
|
rejected it. "Value" is not itself a kind - it's too big and unspecific. For
|
|
instance, if we were to allow a variable to be just "a value", we could freely
|
|
set it to 12 one minute and to "dahlias" the next, and such a variable would
|
|
be dangerously useless since we would never know what could safely be done
|
|
with it.
|
|
|
|
So "value" is not a kind, but a kind of kind. Inform has quite a few of these:
|
|
```
|
|
value, pointer value, word value, arithmetic value, enumerated value,
|
|
sayable value
|
|
```
|
|
Most Inform users never notice these, since they belong to the eight-tenths
|
|
of the iceberg which is underwater, but they act as ways to say "a value of
|
|
any kind matching this can go here". For example, "value" is a way to say
|
|
"any kind at all"; "arithmetic value" is any kind which arithmetic can be
|
|
performed on (any kind with the little calculator icon in the Kinds index);
|
|
and so on. If we write:
|
|
```
|
|
To double (V - arithmetic value): say "[V times 2].";
|
|
```
|
|
the restriction to "arithmetic value" means that although "double 3", "double
|
|
6 kg", etc., would be matched, "double the Entire Game" would not - you can't
|
|
perform arithmetic on scenes. Similarly, it would have been tidier to write:
|
|
```
|
|
To say (V - sayable value) twice: say "[V]. [V], I say!";
|
|
```
|
|
because then Inform will make it clearer why "say X twice" won't work if X
|
|
is one of those rare values which it can't say (an activity, for instance).
|
|
|
|
Inform has always used generic definitions like these to set up the built-in
|
|
stock of phrases (though only with so-called inline bodies, that is, with
|
|
direct translations to Inform 6 code). In this build, it's now possible to
|
|
write generic definitions using proper Inform source text - so that both of
|
|
the above definitions are accepted, and they work just as they look as if
|
|
they should.
|
|
|
|
|
|
But those are toy examples. Notice the way "double" just said the answer,
|
|
instead of returning it - the trouble was that, not knowing the kind of V,
|
|
we couldn't say what the kind of its double would be. We needed a way of
|
|
saying "the same kind comes out as went in". This is how Inform expresses that:
|
|
```
|
|
To decide which K is triple (original - arithmetic value of kind K):
|
|
decide on 3 times the original.
|
|
```
|
|
Here, K stands for any kind which matches "arithmetic value". Inform supports
|
|
exactly 26 of these symbols, which are written A to Z, but it's customary to
|
|
use K and L. (They can be written in the plural if we like: e.g., "list of
|
|
Ks". But they must always use a capital letter: "list of k" is not allowed.)
|
|
|
|
Each symbol we use has to be declared in exactly one of the bracketed
|
|
ingredients for the phrase - here, the declaration is "arithmetic value of
|
|
kind K". That creates K and says that it has to be arithmetic; if we'd just
|
|
said "value of kind K", it could have been anything.
|
|
|
|
For a more ambitious example, here is the definition in the Standard Rules
|
|
of the mapping operation described above:
|
|
```
|
|
To decide what list of L is (function - phrase K -> value of kind L)
|
|
applied to (original list - list of values of kind K):
|
|
let the result be a list of Ls;
|
|
repeat with item running through the original list:
|
|
let the mapped item be the function applied to the item;
|
|
add the mapped item to the result;
|
|
decide on the result.
|
|
```
|
|
Here we needed two symbols to explain the complicated way that the values
|
|
going in and out have to match up to each other. Note also the way that the
|
|
temporary variable "result" is created:
|
|
```
|
|
let the result be a list of Ls;
|
|
```
|
|
Ordinarily, of course, "L" is not a kind. But within the body of a phrase
|
|
definition, it means the kind which L matched. For instance, if we try
|
|
```
|
|
showme spelling out applied to {3, 7, 11};
|
|
```
|
|
then in this usage "L" becomes "indexed text", because spelling out is a
|
|
phrase whose kind is "phrase number -> indexed text".
|
|
|
|
|
|
Sometimes a phrase needs to know what kind it's to work on, but isn't going
|
|
to be given any particular value of it. For example:
|
|
```
|
|
To assay (name of kind of value K):
|
|
repeat with item running through Ks:
|
|
say "There's [item]."
|
|
```
|
|
Note that there's no hyphen, and no name for the bracketed token - it only
|
|
sets K. We can then have, say:
|
|
```
|
|
assay colours;
|
|
assay vehicles;
|
|
```
|
|
(But "assay texts;" would throw a problem message, because we can't repeat
|
|
through all possible texts.)
|
|
|
|
|
|
When a symbol occurs several times in the same definition, subtle differences
|
|
can arise according to which appearance is the declaration. These are not
|
|
quite the same:
|
|
```
|
|
To hunt for (V - value of kind K) in (L - list of Ks): ...
|
|
To hunt for (V - K) in (L - list of values of kind K): ...
|
|
```
|
|
Consider:
|
|
```
|
|
let T be "[location]" in title case;
|
|
hunt for T in {"Greater London", "Greater Basildon"};
|
|
```
|
|
Here T is an indexed text, but the list is of texts; and a text can be used in
|
|
place of an indexed text, but not vice versa. This will match the first
|
|
definition, because K is set to "indexed text", but it won't match the second,
|
|
where K is set to "text".
|
|
|
|
### Properties
|
|
|
|
The handling of properties has been simplified and made more systematic in
|
|
this build, removing a number of tiresome exceptions. In particular, eight
|
|
ways in which "object" differed from other kinds have been removed:
|
|
|
|
(a) It's possible to give properties to "object", and indeed the Standard
|
|
Rules now include:
|
|
```
|
|
An object has a text called printed name.
|
|
An object can be plural-named or singular-named. An object is usually
|
|
singular-named.
|
|
```
|
|
Previously one had to specify them each time for each of the fundamental kinds
|
|
in turn (thing, room, direction, region), which was tiresome. The problem
|
|
was essentially that "object" did not behave as if it were a property-owning
|
|
kind; now it does.
|
|
|
|
(b) Relations in groups, one to various relations, various to one relations,
|
|
and one to one relations are no longer restricted to objects - they can be
|
|
defined over all kinds. Again, objects are no longer a special case.
|
|
|
|
(c) Properties have always been able to be held by several kinds of object
|
|
independently - for example "matching key" is held by both doors and
|
|
containers - but in previous builds that wasn't true for more general kinds.
|
|
A property of a scene couldn't be a property of anything else. This is no
|
|
longer true. (Indeed, scenes now have the "description" property, just as
|
|
objects do.)
|
|
|
|
(d) Any value which can have properties at all can now have a condition
|
|
property, e.g., thus:
|
|
```
|
|
Colour is a kind of value. The colours are red, green and white.
|
|
A colour can be bright, neutral or flat. Green is neutral.
|
|
```
|
|
Condition properties were previously restricted to objects only.
|
|
|
|
(e) Implications can now be written for any values capable of holding
|
|
properties, not only for objects. Thus:
|
|
```
|
|
Colour is a kind of value. The colours are red, green and blue.
|
|
A colour can be zesty or flat. A colour can be bright or dull.
|
|
Red and blue are bright. Blue is flat.
|
|
|
|
A bright colour is usually zesty.
|
|
```
|
|
results in red being zesty, but blue and green being flat; blue because the
|
|
source text explicitly says so (which trumps the "usually"), and green because
|
|
this isn't a bright colour, so the implication doesn't arise. Again, all of
|
|
this works exactly as it does already for objects.
|
|
|
|
(f) Inform has always allowed a piece of double-quoted text, as a complete
|
|
sentence all by itself, to set a description for the object currently being
|
|
talked about. This now works for a named value, too, provided that the
|
|
value is of a kind which has the "description" property. For example,
|
|
the Standard Rules now include the following:
|
|
```
|
|
A scene has a text called description.
|
|
When a scene (called the event) begins:
|
|
if the description of the event is not "",
|
|
say "[the description of the event][paragraph break]".
|
|
```
|
|
which enables any scene to have a description text, which is printed when it
|
|
begins. For example, we could write:
|
|
```
|
|
Arrival is a scene. "There's a flourish of trumpets."
|
|
```
|
|
(g) Adjectives can now be given specific definitions for named values.
|
|
(Previously they could be defined for any kind and for any specific object,
|
|
but not for specific values in general.) This allows, e.g.:
|
|
```
|
|
A colour is a kind of value. The colours are red, green and blue.
|
|
Definition: red is subtle if the player is a woman.
|
|
Definition: a colour is subtle if it is blue.
|
|
```
|
|
The first definition here takes precedence, of course, since it has the
|
|
more specific domain. If the player's a woman, the subtle colours are red
|
|
and blue; if not, just blue.
|
|
|
|
(h) The pronoun "it" can now mean either an object or a named value, whereas
|
|
previously it could only be an object. Thus:
|
|
```
|
|
Colour is a kind of value. A colour can be zesty or flat.
|
|
Mauve is a colour. It is zesty.
|
|
```
|
|
makes mauve a zesty colour. (The restriction to named values is because we
|
|
really don't want "it" to mean 63, or the text "frog", etc., just because
|
|
such a value has been mentioned in a previous sentence.)
|
|
|
|
It's now possible to have a topic valued property, that is, a property whose
|
|
content is a topic. (This is possibly useful when defining things or values
|
|
using a table, one of whose columns holds topics.)
|
|
|
|
The kinds "figure name", "sound name" and "external file" can all now have
|
|
properties. For example:
|
|
```
|
|
File format is a kind of value. The file formats are plain
|
|
text, HTML and CSS. An external-file has a file format.
|
|
|
|
The File of Ghosts is HTML.
|
|
```
|
|
Similarly, all three can be understood in commands. This is likely to be
|
|
useful only for testing purposes, but that's a good enough reason to
|
|
provide it.
|
|
|
|
|
|
The either/or property "initially carried" is withdrawn, though sentences
|
|
such as:
|
|
```
|
|
The umbrella is initially carried.
|
|
```
|
|
continue to work, so it's likely that nobody will notice any difference. (The
|
|
word "initially" is redundant here; this property goes back to the early
|
|
days of Inform, when sentences mentioning the player were more restricted.)
|
|
|
|
|
|
Previously, certain core Inform properties had the anomalous behaviour that
|
|
if they were not explicitly defined then they could be read but not written,
|
|
and would show up as not provided - for instance, the "description" of a
|
|
thing, or the "carrying capacity" of a container. The same wasn't true for
|
|
new properties created within the source text. This anomaly, which came out
|
|
of Inform 6 memory economies now of very little purpose, is revoked. For
|
|
example, a thing with nothing special about it now has the description ""
|
|
(an empty text) rather than not providing a description at all; this means
|
|
that, for example, the test
|
|
```
|
|
if the description of R is "", ...
|
|
```
|
|
will now work correctly in the case where R is a room whose description has
|
|
never been specified.
|
|
|
|
|
|
It used to be legal, but deprecated, to create a property like so:
|
|
```
|
|
An elevator has a number that varies called maximum capacity.
|
|
```
|
|
The "that varies" is redundant here, and confusingly similar to the syntax
|
|
for creating variables. None of the Examples has ever used this syntax, and
|
|
most users probably weren't aware it was allowed. Well, it isn't any more.
|
|
|
|
|
|
Inconsistencies to do with inherited properties of values are now more
|
|
consistently checked: e.g.,
|
|
```
|
|
Colour is a kind of value. The colours are red, blue and green. A colour
|
|
can be vivid or drab. A colour is always vivid. Green is drab.
|
|
```
|
|
now produces a problem message, as it clearly should.
|
|
|
|
### Scenes
|
|
|
|
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!"
|
|
```
|
|
|
|
Scenes can now be understood in commands, which may be useful for testing.
|
|
|
|
The built-in Entire Game is not supposed to be modifiable - that is, it can't
|
|
be made to begin or end when other scenes do. This is now enforced with a
|
|
problem message.
|
|
|
|
The Scenes index is now more helpful in explaining Entire Game, and also marks
|
|
which scenes are recurring (and this now includes Entire Game).
|
|
|
|
### Rulebooks
|
|
|
|
"When... begins" and "when... ends" are scene based rulebooks, meaning that they
|
|
take a parameter which is a scene. Inform has always had object based rulebooks,
|
|
but in the past that's been the only kind allowed here; Inform now allows, e.g.:
|
|
```
|
|
Grading is a number based rulebook.
|
|
|
|
Grading 5: say "It's five. What can I say?" instead.
|
|
Grading an odd number (called N): say "There's something odd about [N]." instead.
|
|
Grading a number (called N): say "Just [N]." instead.
|
|
|
|
When play begins:
|
|
repeat with N running from 1 to 10:
|
|
say "Grading [N]: ";
|
|
consider the grading rulebook for N.
|
|
```
|
|
which produces:
|
|
```
|
|
Grading 1: There's something odd about 1.
|
|
Grading 2: Just 2.
|
|
Grading 3: There's something odd about 3.
|
|
Grading 4: Just 4.
|
|
Grading 5: It's five. What can I say?
|
|
Grading 6: Just 6.
|
|
Grading 7: There's something odd about 7.
|
|
Grading 8: Just 8.
|
|
Grading 9: There's something odd about 9.
|
|
Grading 10: Just 10.
|
|
```
|
|
(A technicality: The familiar IF rulebooks like "instead" are all based on
|
|
actions, not values, so it looks as if they can't fit into this system; but
|
|
they can, because the Inform kinds system treats that as being based on
|
|
the kind "action name".)
|
|
|
|
|
|
There used to be three ways to describe rulebooks:
|
|
```
|
|
rulebook object-based rulebook action-based rulebook
|
|
```
|
|
(though the last two could only be used at the moment of creation). But now
|
|
we ought to use one of these forms:
|
|
```
|
|
rulebook
|
|
K based rulebook
|
|
rulebook producing L
|
|
K based rulebook producing L
|
|
```
|
|
Here K is the kind of value we're basing the rulebook on. If this is omitted,
|
|
a test like "(R - rulebook)" will match any basis; and a creation like
|
|
"Drum summons rules is a rulebook." will use the basis "action name" - in other
|
|
words, will make an action-based rulebook. L is the kind of value produced
|
|
(see below) - again if this is unspecified in matching, it can be anything;
|
|
if it's unspecified at creation time, it will be "nothing". Thus
|
|
```
|
|
Drum summons rules is a rulebook.
|
|
```
|
|
is equivalent to
|
|
```
|
|
Drum summons rules is an action name based rulebook producing nothing.
|
|
```
|
|
The old syntaxes "object-based rulebook" and "action-based rulebook", with
|
|
hyphens, are still allowed, to avoid breaking existing source text. But
|
|
"object based rulebook" and simply "rulebook" are now preferred.
|
|
|
|
|
|
The other kind associated with a rulebook is the kind of value it produces,
|
|
though for the great majority of rulebooks this is "nothing" - they don't
|
|
produce values. (None of the rulebooks created by the Standard Rules do, and
|
|
there's only one such across the whole of the Examples.) In past builds, this
|
|
produced value has to be an object, but that wasn't checked, making this
|
|
little-used feature decidedly rickety.
|
|
|
|
Making it safe has meant changing the syntax, and that will mean altering
|
|
any existing source text which uses such rulebooks. The one Example we had
|
|
to change ("Feline Behavior") read, in part:
|
|
```
|
|
The cat behavior rules is a rulebook.
|
|
[...]
|
|
|
|
Every turn:
|
|
consider the cat behavior rules;
|
|
if rule succeeded:
|
|
let the destroyed object be the result of the rule;
|
|
[...]
|
|
```
|
|
It now reads:
|
|
```
|
|
The cat behavior rules is a rulebook producing an object.
|
|
[...]
|
|
|
|
Every turn:
|
|
let the destroyed object be the object produced by the cat behavior rules;
|
|
if the destroyed object is not nothing:
|
|
[...]
|
|
```
|
|
Put more formally, the following phrases have been withdrawn:
|
|
```
|
|
rule fails with result (O - an object)
|
|
rule succeeded with result (O - an object)
|
|
rule failed with result (O - an object)
|
|
result of the rule
|
|
```
|
|
A rulebook can now only produce a value if it succeeds; and only if it was
|
|
declared as producing a value; that value can have any kind, and this is
|
|
enforced by Inform; and it can only be obtained if the rulebook is considered
|
|
using the new phrases
|
|
```
|
|
the K produced by RB
|
|
the K produced by RB for V
|
|
```
|
|
(the second being used if the rulebook RB is based on some value, and V is
|
|
the one being supplied here).
|
|
|
|
It used to be the case that a rule was not allowed to use a named rulebook
|
|
outcome unless it was filed in a rulebook which recognised this. What's now
|
|
true is that it's not allowed to use a named outcome if it's filed in a
|
|
rulebook which doesn't recognise this. The difference is subtle, but it
|
|
means that this combination:
|
|
```
|
|
Does the player mean removing something not worn by the player from
|
|
(this is the unlikely to mean removing unworn things rule):
|
|
it is unlikely.
|
|
|
|
The unlikely to mean removing unworn things rule is not listed in any rulebook.
|
|
```
|
|
...is now legal, whereas previously it would have thrown problem messages.
|
|
|
|
Finally, and unrelatedly, the logic Inform uses to decide what order to place
|
|
rules into rulebooks has been slightly improved. This is something we're
|
|
always wary of tinkering with, but the change means that a domain consisting
|
|
of a kind K together with one or more adjectives will now be considered
|
|
more specific than a kind L together with the same adjectives, if K is itself
|
|
a kind of L. For example, suppose we write:
|
|
```
|
|
An envelope is a kind of container.
|
|
```
|
|
We then write:
|
|
```
|
|
[R1] Before printing the name of a closed envelope while listing contents:
|
|
do nothing instead.
|
|
|
|
[R2] Before printing the name of a closed container while listing contents:
|
|
say "closed ".
|
|
```
|
|
In previous builds of Inform, [R1] and [R2] were considered to have equal
|
|
specificity, so that the order of their effect would be the order in which
|
|
they were defined; in other words, they will only have the effect intended
|
|
by the writer of the above (Kathleen Fischer, as it happens) one way around.
|
|
In this build, [R1] is considered more specific than [R2], and always takes
|
|
precedence over it, regardless of definition order in the source text.
|
|
|
|
### Inflections
|
|
|
|
(a) Previous builds generated plurals with a very crude algorithm (for instance,
|
|
"day" pluralised as "daies"); this sloppiness was mitigated by the face that
|
|
the user can specify plurals explicitly:
|
|
```
|
|
The plural of ox is oxen.
|
|
```
|
|
Inform's default pluralisation method is now a form of Conway's algorithm,
|
|
and this should make most uses of "The plural of..." redundant now. For
|
|
example, the following now work:
|
|
```
|
|
A wolf is a kind of animal. Two wolves are in the Stable.
|
|
```
|
|
and similarly for oxen, geese (but mongooses), sheep, wildebeest, bream and so
|
|
forth among animals alone; Inform constructs plurals such as vertebrae, quartos,
|
|
wharves, phenomena, jackanapes and smallpox correctly. In cases where a noun has
|
|
both a modern and classical plural, Inform prefers the modern form, so brothers,
|
|
not brethren, and cows, not kine. In the spirit of old-school interactive
|
|
fiction, Inform uses Tolkien's invention dwarves, not dwarfs, as plural of dwarf.
|
|
|
|
"The plural of..." continues to work, of course, and is still useful for
|
|
cases such as:
|
|
```
|
|
The plural of brother in law is brothers in law.
|
|
```
|
|
Another improvement is that the new pluralizer respects capitalization, which
|
|
the old one did not:
|
|
```
|
|
A Rolex is a kind of thing. The player carries two Rolexes.
|
|
```
|
|
would be understood, but an inventory listing would print as "two rolexes".
|
|
It now prints as "two Rolexes".
|
|
|
|
(b) In similar vein, a more careful algorithm derived from a pronunciation
|
|
dictionary is now used for choosing between "a" and "an" when Inform has to
|
|
make a guess; thus an honorary doctorate, an FBI windcheater, a U-boat,
|
|
a ouija board, a ukiyo-e print, among many others. But this change will be
|
|
less visible since Inform doesn't often have to guess; it will mainly show
|
|
in problem messages (where Inform will no longer complain that a value
|
|
should have been "an use option" or "an Unicode character", for example).
|
|
|
|
(c) Finally, the method used to guess past participles from present participles
|
|
has been improved by the inclusion of some 460 irregular verbs; for example,
|
|
catching to caught, fleeing to fled, crossbreeding to crossbred. This means
|
|
that the "with past participle..." syntax in action definitions now won't
|
|
be needed anywhere near so often, though of course it still works. For
|
|
example,
|
|
```
|
|
Weaving is an action with past participle woven, applying to one thing.
|
|
```
|
|
can now simply be
|
|
```
|
|
Weaving is an action applying to one thing.
|
|
```
|
|
A few cases are ambiguous; Inform prefers "got" to "gotten", but it's unlikely
|
|
to arise since in most IF situations "getting" is not an action - instead
|
|
"get" is synonymous with "take" and "taking" is the action.
|
|
|
|
### Minor New Features
|
|
|
|
The interpretation of conditions which combine Inform's two past-tense syntaxes
|
|
has been changed. Thus,
|
|
```
|
|
Every turn when we have waved the candle at least twice: ...
|
|
```
|
|
is legal, but - reading strictly by the specification, as previous builds did -
|
|
"we have waved the candle at least twice" could never be true; it implied
|
|
two or more distinct periods in which it was true that "we have waved the
|
|
candle" was true, with at least one intervening period in which it was false.
|
|
Such a situation can never come about. In this build of Inform, we read the
|
|
condition "we have waved the candle at least twice" to be counting actions,
|
|
not counting periods, which is far, far more likely to be what was meant.
|
|
|
|
|
|
It has always been possible to indicate map connections using the direction
|
|
alone (the origin being understood as the room being discussed), but up to
|
|
now, only in the form "Direction is Target", like the second sentence here:
|
|
```
|
|
The Temple is a room. North is the Approach. The Sphinx is east.
|
|
```
|
|
The third sentence now works as expected: the Sphinx being east of the Temple.
|
|
|
|
|
|
The serial comma is now allowed in sentences like:
|
|
```
|
|
A room can be lofty, regular, or poky.
|
|
```
|
|
|
|
Inform provides two ways to make headings hold source text whose use relates
|
|
to an extension. One is to say something like
|
|
```
|
|
Part 1a - Alternative Leaps (in place of Part 1 - Leaps in Jumping by Eric Eve)
|
|
```
|
|
which says that what follows should be used instead of what's in the extension;
|
|
the other is
|
|
```
|
|
Chapter 1P - Sidling (for use with Plurality by Emily Short)
|
|
...
|
|
Chapter 1NP - Sidling (for use without Plurality by Emily Short)
|
|
...
|
|
```
|
|
giving source text to be used depending on whether the extension is being
|
|
included or not. In past builds, these two features were forbidden to "nest";
|
|
in this build, it's only the first kind which can't "nest". (That is, once
|
|
a chunk of text has been used in place of an extension's text, it can still
|
|
contain subheadings "for use with" or "for use without"; but it can't contain
|
|
subheadings "in place of".)
|
|
|
|
|
|
In previous builds, the "Options.txt" file (if present) was allowed only to
|
|
contain use options - that is, sentences such as "Use American dialect."
|
|
It is now allowed also to contain "Test ..."s and release instructions, so
|
|
for example the following is now a valid "Options.txt":
|
|
```
|
|
Use American dialect.
|
|
Test fish with "fish/fish with pole/angle".
|
|
Release along with source text.
|
|
```
|
|
To recap, "Options.txt" is intended mainly for classroom use, in setting
|
|
up a standard configuration on multiple machines. Here the instructor can
|
|
make sure the Release button will do what she would like, and can arrange
|
|
for each student's copy of Inform to respond to given Test commands: for
|
|
instance, if the class has an assignment to create a simulation of a camera,
|
|
the instructor could set up "Options.txt" so that TEST CAMERA would run
|
|
through some commands the camera ought to respond to.
|
|
|
|
(The bug causing "Options.txt" to obstruct the bibliographic titling sentence
|
|
at the top of the visible source text has also been fixed; and a problem
|
|
message has been added for trying to do forbidden things with "Options.txt".)
|
|
|
|
|
|
The participles "worn", "carried" and "held" are now given additional
|
|
definitions in the Standard Rules as adjectives applying to things:
|
|
```
|
|
Definition: a thing is worn if the player is wearing it.
|
|
Definition: a thing is carried if the player is carrying it.
|
|
Definition: a thing is held if the player is holding it.
|
|
```
|
|
Previous builds allowed some adjectival uses but not others, a little
|
|
inconsistently; for example, the following now works, but previously did not:
|
|
```
|
|
A diamond bracelet is here. It is wearable. The description is
|
|
"It sparkles [if worn]on your wrist[otherwise if carried]in your
|
|
hand[end if]."
|
|
```
|
|
|
|
The adjectives "on-stage" and "off-stage" can now be made true using "now",
|
|
so, for instance, "now the diamonds are off-stage" is equivalent to "remove
|
|
the diamonds". (If we say "now the diamonds are on-stage" and they already
|
|
were, nothing happens; if they weren't, they are moved to the current
|
|
location.)
|
|
|
|
There are three new forms of "[one of]":
|
|
```
|
|
"Maybe the victim is [one of]Adam[or]Bertrand[or]Carlos[then purely at
|
|
random]."
|
|
"Maybe the murderer is [one of]Colonel Mustard[or]Professor Plum[or]Cardinal
|
|
Cerise[then at random]."
|
|
```
|
|
The first means that the alternatives are chosen in sequence until all have
|
|
been seen, but that after that they are chosen uniformly randomly. The
|
|
second is similar, except that once randomness is reached, care is taken to
|
|
avoid the same choice coming up twice running.
|
|
|
|
The third is really a shorthand form:
|
|
```
|
|
"The screen door squeaks loudly as when you open it. [first time]Well,
|
|
you'll get used to it eventually. [only]"
|
|
```
|
|
This is exactly equivalent to
|
|
```
|
|
"The screen door squeaks loudly as when you open it. [one of]Well,
|
|
you'll get used to it eventually. [or][stopping]";
|
|
```
|
|
but easier to read.
|
|
|
|
Inform, like Python and some other languages, uses indentation from the left
|
|
margin to show how phrases are grouped. In past builds, the practical limit
|
|
was 9 tab stops in, though this wasn't very clearly explained and the problem
|
|
message if exceeded was cryptic. The limit is now raised to 25 and a better
|
|
problem message has been created.
|
|
|
|
The phrase "repeat with V running from X to Y" previously worked only when X
|
|
and Y were numbers; it's now allowed for any arithmetic or enumerated values,
|
|
so
|
|
```
|
|
repeat with counter running from 1 to 10:
|
|
...
|
|
repeat with counter running from 4 PM to 4:07 PM:
|
|
...
|
|
repeat with counter running from orange to indigo:
|
|
...
|
|
```
|
|
are all allowed (supposing that we have a colour kind whose values are, say,
|
|
red, orange, yellow, green, blue, indigo and violet).
|
|
|
|
|
|
The phrases for making entries in a table blank have been made more consistent:
|
|
```
|
|
blank out (table entry)
|
|
blank out the whole row
|
|
blank out the whole (column) of (table)
|
|
blank out the whole of (table)
|
|
```
|
|
(The last two abilities are new.)
|
|
|
|
|
|
The phrases for altering the length of a list are worded using "entries";
|
|
for example, "truncate L to 10 entries". It's now legal to use the singular,
|
|
"truncate L to 1 entry", too.
|
|
|
|
|
|
Previous builds allowed rules in the "printing a parser error" activity to
|
|
test which error had occurred using rather clumsy fixed-wording phrases:
|
|
```
|
|
if parser error is can only do that to something animate: ...
|
|
```
|
|
These have been withdrawn. For this build, the following should be used
|
|
instead:
|
|
```
|
|
if the latest parser error is the can only do that to something animate
|
|
error: ...
|
|
```
|
|
This is tidier since it is a standard comparison. A new kind of value,
|
|
"command parser error", exists to hold the possibilities; "can only do that to
|
|
something animate error" is one of these. (The others are listed on the Kinds
|
|
index page. They are all worded exactly as before, with the addition of the
|
|
word "error" at the end, as in this case.) The advantage of the new system,
|
|
aside from getting rid of 19 clumsy phrases, is that "latest parser error"
|
|
is now a variable; the value can be said, or stored, and so on. This is all
|
|
much more flexible.
|
|
|
|
|
|
In the startup rulebook, the first two rules - in fact, the first two rules
|
|
every Inform story file runs - have been transposed. So the initialise memory
|
|
rule now happens before the virtual machine startup rule, not vice versa.
|
|
Because the latter rule runs the "starting the virtual machine" activity, the
|
|
effect is that we sacrifice a little bit of that activity's ability to be
|
|
the very first thing run; but we gain the ability for this activity to use
|
|
indexed text, stored actions, and similarly complex data, since those depend
|
|
on memory having been initialised.
|
|
|
|
|
|
There is now a way to define an adjective in terms of an Inform 6 routine
|
|
which is more capable, since it can not only be tested, but also made true
|
|
or false using "now". For example:
|
|
```
|
|
Definition: a scene is crucial if I6 routine "SceneCrucial" makes it so
|
|
(it is essential to winning).
|
|
```
|
|
This is very similar to the existing syntax:
|
|
```
|
|
Definition: a scene is vital if I6 routine "SceneVital" says so
|
|
(it is essential to winning).
|
|
```
|
|
(a) Whereas "SceneVital" is just a test, "SceneCrucial" is called with two
|
|
arguments: SceneCrucial(S, -1) tests whether the scene is crucial or not and
|
|
returns true or false; SceneCrucial(S, true) must make it true; and
|
|
SceneCrucial(S, false) must make it false.
|
|
|
|
(b) If the adjective is defined over a kind of values stored in block form
|
|
on the heap, S is passed as a pointer to the block, not as a fresh copy.
|
|
|
|
|
|
Inform's automatically generated documentation on included extensions has
|
|
always listed names of kinds, objects, variables and so on; it now also lists
|
|
names of use options.
|
|
|
|
|
|
The maximum complexity of a single "say" - basically, the maximum number of
|
|
chunks it can contain, some being fixed text, others being substitutions -
|
|
has been increased from about 400 to about 4000. (In practice this removes the
|
|
limit altogether, since the maximum length of a single quoted text gets in
|
|
the way first. Having any maxima at all is unfortunate, of course, but it
|
|
enables the compiler to run faster, and makes it easier to catch punctuation
|
|
mistakes in the source.)
|
|
|
|
|
|
When Problem messages are reported inside an extension, Inform typically says
|
|
under what headings they occur, but doesn't make clear which extension is
|
|
involved, which can be a nuisance if many extensions are in use. In this build,
|
|
Inform explicitly names the extension.
|
|
|
|
A new use option, "Use no deprecated features", puts Inform into a mode where
|
|
it issues problem messages for syntaxes which are currently allowed but which
|
|
we expect to withdraw in future. At present this is used only with phrases;
|
|
see the Phrasebook index, where deprecated usages are marked with a red
|
|
warning triangle.
|
|
|
|
### Word limits on relations, verbs, prepositions and directions
|
|
|
|
Most constructions in Inform can have quite long names. But in previous
|
|
builds, much tighter limits were placed on relation names, parts of verbs,
|
|
the wording of prepositions, and the names of directions.
|
|
```
|
|
Example Old maximum New maximum
|
|
Relation name containment 1 X - 1
|
|
Part of verb wears 1 X - 4
|
|
Preposition across from 3 X - 2
|
|
Direction northwest 3 X - 2
|
|
```
|
|
The intention is that there should be no practical limit in any of these
|
|
cases; the current value of X is 32, which it's very difficult to see any
|
|
plausible source text ever needing to exceed.
|
|
|
|
For example, this is now allowed:
|
|
```
|
|
The verb to cover oneself with (he covers himself with, they cover themselves
|
|
with, he covered himself with, he is covering himself with) implies the
|
|
wearing relation.
|
|
|
|
Peter is covering himself with a tent-like raincoat.
|
|
```
|
|
Here each part of the verb is three words long; the maximum is now 28.
|
|
Similarly:
|
|
```
|
|
The verb to be very far away from implies...
|
|
```
|
|
is a preposition four words long, which previous builds would have rejected.
|
|
The limit is now 30.
|
|
```
|
|
Adept sensitivity relates one person to one vehicle.
|
|
The verb to imagine (he imagines, they imagine) implies the adept sensitivity
|
|
relation.
|
|
Peter imagines the Astral Chariot.
|
|
```
|
|
Here we have a relation, "adept sensitivity", which is two words long; the
|
|
limit is now 31.
|
|
|
|
And if you should want:
|
|
```
|
|
Just the tiniest smidge off magnetic north is a direction. The opposite of
|
|
just the tiniest smidge off magnetic north is just the tiniest smidge
|
|
off magnetic south.
|
|
Just the tiniest smidge off magnetic south is a direction. The opposite of
|
|
just the tiniest smidge off magnetic south is just the tiniest smidge
|
|
off magnetic north.
|
|
```
|
|
then knock yourself out.
|
|
|
|
Note that when a direction is created, a relation is automatically created
|
|
to represent being in that direction; for instance, "north" creates what is
|
|
now called the "mapping north relation". It used to be called the "mapping-north
|
|
relation", with a hyphen, to squeeze into the former requirement that relations
|
|
have one-word names. It's unlikely that much source text makes direct use of
|
|
these relations by name, so the change will probably not be noticed.
|
|
|
|
### Actions in the Standard Rules
|
|
|
|
Some of the small design decisions about actions in the Standard Rules go back
|
|
to accidents of implementation in the early 1990s (if not earlier still), and
|
|
have no rationale except custom and practice. We are very conservative about
|
|
changing them, all the same, since anything done here will affect essentially
|
|
every source text compiled with Inform. But for this build we have made a
|
|
systematic search for small changes, unlikely to cause much disruption, but
|
|
which will improve the playing experience.
|
|
|
|
(a) In its earliest works, Infocom introduced the now-traditional commands
|
|
VERBOSE, BRIEF and SUPERBRIEF for the player to choose how much detail to
|
|
see in room descriptions: the whole thing, even for a room revisited; the
|
|
whole thing the first time, but an abbreviated form after that; or always
|
|
only the abbreviated form. The default mode was BRIEF, the middle of these
|
|
positions.
|
|
|
|
In 1993, when Inform made its debut, this was still conventional, but since
|
|
then authors and players have increasingly found VERBOSE mode more natural.
|
|
Even a tiny iPhone screen shows more text that a 1980s micro did, and printing
|
|
time is now essentially zero, whereas a long description could take five to
|
|
ten seconds to print back then. Inform's fellow IF development system TADS
|
|
has long since used VERBOSE as the default; from this build, Inform is finally
|
|
following suit. So, farewell to default BRIEF mode (1981-2010).
|
|
|
|
Three new use options exist to set the default behaviour:
|
|
```
|
|
Use VERBOSE room descriptions.
|
|
Use BRIEF room descriptions.
|
|
Use SUPERBRIEF room descriptions.
|
|
```
|
|
So if this change causes problems, simply add "Use BRIEF room descriptions."
|
|
to restore the old behaviour. For us, it changed the blessed transcripts of
|
|
45 out of about 440 examples, but never such that we minded the change.
|
|
|
|
(b) Inform has always been liberal in how it reads the word ALL in commands
|
|
typed by players - TAKE ALL really does mean all - but has given authors
|
|
the option to change this by writing rules for the "deciding whether all
|
|
includes" activity. As from this build, the Standard Rules include three
|
|
such rules to strike out people, scenery and things fixed in place. Thus:
|
|
```
|
|
Studio is a room. Jenna is a woman in the Studio. Kenneth is a man in the
|
|
Studio. The peacock, the script and the stage set are in the Studio.
|
|
The stage set is fixed in place. The curtains are scenery in Studio.
|
|
```
|
|
the traditional reply to TAKE ALL would be:
|
|
```
|
|
Jenna: I don't suppose Jenna would care for that.
|
|
Kenneth: I don't suppose Kenneth would care for that.
|
|
peacock: Taken.
|
|
script: Taken.
|
|
stage set: That's fixed in place.
|
|
curtains: That's hardly portable.
|
|
```
|
|
With the new default conventions, it's just:
|
|
```
|
|
peacock: Taken.
|
|
script: Taken.
|
|
```
|
|
The new rules are named, of course, and can be cancelled if unwanted (see the
|
|
Rules index):
|
|
```
|
|
exclude scenery from take all rule
|
|
exclude people from take all rule
|
|
exclude fixed in place things from take all rule
|
|
```
|
|
(c) In this release, the Inform parser changes the default way in which it
|
|
asks what is meant by an ambiguous noun such as FROST. It can ask the
|
|
question in two different forms:
|
|
```
|
|
(1) Who do you mean, Jack Frost or Jill Frost?
|
|
(2) Which do you mean, Jack Frost or Jill Frost?
|
|
```
|
|
In the past it has used form (1) if the token being parsed was "[someone]",
|
|
and (2) otherwise. This wasn't very accurate, as plenty of other tokens might
|
|
expect a person rather than a thing to be typed; but in English, it didn't
|
|
matter very much, because "which" wasn't too bad for people. In German, it
|
|
made a bigger difference, and at Christian Blümke's suggestion we are
|
|
incorporating a change worked out by German Inform users: message (1) is used
|
|
if all of the possible meanings refer to people, and message (2) otherwise.
|
|
|
|
(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.").
|
|
|
|
(f) The command "switch [something]" is now understood as switching off if the
|
|
item in question is currently a device switched on, and vice versa. (Previously
|
|
it would always be understood as switching on.)
|
|
|
|
(g) The command "fix" is no longer a synonym for "tie". (There is too much
|
|
confusion of the two senses - "fix" in the sense of affix may mean "tie", but
|
|
"fix" in the sense of repair does not.)
|
|
|
|
(h) The command "get down" is now understood as exiting. (A natural thing to
|
|
type when, say, at the top of a library stepladder.)
|
|
|
|
(i) The command "get in" is now understood as equivalent to typing just
|
|
"enter". In general "enter" requires a noun - there could well be a choice
|
|
of enterable things available - but a rule new in this build, the
|
|
```
|
|
find what to enter rule
|
|
```
|
|
automatically infers an enterable noun in the current location, if one is
|
|
available. (It has no effect if the player has typed something explicit, such
|
|
as "enter cage".)
|
|
|
|
(j) The command "look [something]" is understood as examining, as if it had
|
|
read "look at [something]". (This is not so much aimed at retro gaming fans
|
|
who want to recreate the full 1982 experience, but at novices, who often seem
|
|
to type commands like this.)
|
|
|
|
(k) In previous builds, the going action would be stopped by the
|
|
```
|
|
can't go through closed doors rule
|
|
```
|
|
if the actor would need to pass through a closed door. That remains true, but
|
|
if the door is openable then the rule now tries opening the door first - thus
|
|
allowing players to walk through ordinary doors without having to type
|
|
explicit "open door" commands. (The popular "Locksmith" extension has always
|
|
provided this; anyone using that extension will see no change.)
|
|
|
|
(l) A new rule for the going action, the
|
|
```
|
|
stand up before going rule
|
|
```
|
|
causes an actor to try getting off a supporter before going in a given
|
|
direction. (A rule which was previously an optional extra, demonstrated by the
|
|
"Hagia Sophia" Example. Use of the "Rideable Vehicles" extension unlists this
|
|
rule, i.e., abolishes it, since this extension makes supporters into mobile
|
|
things which can indeed be used to go from place to place.)
|
|
|
|
(m) The "putting it on" and "inserting it into" actions require the item
|
|
being put or inserted to be held by the actor; if it isn't, one of the rules:
|
|
```
|
|
can't put what's not held rule
|
|
can't insert what's not held rule
|
|
```
|
|
will stop the action. In this build, they first try to take the item, and
|
|
only stop the action if that fails.
|
|
|
|
(n) A quaint convention going back to the mid-1980s is that an inventory
|
|
listing changes the meaning of pronouns like "it". Thus
|
|
```
|
|
> INV
|
|
You are carrying a pineapple.
|
|
> EAT IT
|
|
```
|
|
...would result in "it" meaning the pineapple. We think it's time to give up
|
|
on this convention, which causes nothing but confusion. Accordingly, we have
|
|
deleted the rule responsible:
|
|
```
|
|
use inventory to set pronouns rule
|
|
```
|
|
(o) The run-time parser's handling of commands with commas in has been
|
|
changed; previously, a command such as
|
|
```
|
|
> FRED, GO NORTH
|
|
```
|
|
would be parsed as an instruction for Fred to do something only because
|
|
FRED was not recognisable as a verb. This turned out to be unfortunate for
|
|
story files with Japanese characters called Takemoto ("Take" for short), or
|
|
for anyone called Don (a verb for putting on clothes), and so on. The
|
|
parser now considers the command to be an instruction provided that the
|
|
text up to the comma matches the name of a possible actor; this avoids
|
|
(most) false positives such as
|
|
```
|
|
> TAKE BELL, BOOK AND CANDLE
|
|
```
|
|
(p) The "exiting" action has long had a variable called the "container
|
|
exited from", so that it's possible to write rules depending on what is
|
|
being got out of. This can now be referred to using "from", as in the
|
|
following example:
|
|
```
|
|
After exiting from the Mini Cooper:
|
|
say "You painstakingly unpack your limbs from the tiny car."
|
|
```
|
|
|
|
(q) The "giving" action has a new rule, imitating a similar one for dropping:
|
|
```
|
|
can't give clothes being worn rule
|
|
```
|
|
(r) The "removing it from" action has an exemption in the "can't remove from
|
|
people rule", so that in the event that the actor is trying to remove something
|
|
from himself, this is converted to a taking off action. (For instance, if the
|
|
player is involuntarily wearing a monkey on his back, and types REMOVE
|
|
MONKEY FROM ME.)
|
|
|
|
(s) The commands TAKE ... OFF and PUT ... ON are now understood as taking off
|
|
and wearing, respectively, just as the commands TAKE OFF ... and PUT ON ...
|
|
always have been.
|
|
|
|
(Translators may need to note that as a result of these changes three library
|
|
messages, going action number 3, 4 and 5, have been removed; but there are
|
|
also three new ones, going action number 27 and 28, and Miscellany 75, which
|
|
is " The End " in English, and is used to provide a generic ending message.)
|
|
|
|
### A note about figure and sound names
|
|
|
|
Figure names and sound names are the standard Inform kinds for representing
|
|
pictures and sound effects. In this build they gain in functionality (they
|
|
can have properties now, can be repeated through, and so on), but to achieve
|
|
this we needed to change their data representation at the Inform 6 level.
|
|
|
|
This only affects I6 code included into I7 source text, but the practical
|
|
side-effects run wider, because many people use Glulx extensions for doing
|
|
ingenious things with (especially) images; and those extensions tend to rely
|
|
on the old representation.
|
|
|
|
This means they will need to be updated in order to work with this new build
|
|
of Inform.
|
|
|
|
Previously, a figure name and a sound name were each represented in I6 by
|
|
the resource ID number of the picture or sound resource inside the blorbed
|
|
story file. These would usually be small numbers, and would be different from
|
|
each other (i.e. no picture would have the same ID number as a sound).
|
|
|
|
From this build, figure name and sound name are enumerated kinds, meaning
|
|
that they are each independently stored as the I6 level as 1, 2, 3, ... in
|
|
order of creation. These are typically off by one, or some other small amount,
|
|
from resource ID numbers, but don't rely on that. To convert to a resource
|
|
ID number, indirect through the word arrays:
|
|
```
|
|
ResourceIDsOfFigures-->N
|
|
ResourceIDsOfSounds-->N
|
|
```
|
|
In other words, whereas in an I6 inclusion
|
|
```
|
|
(+ figure of Space Shuttle +)
|
|
```
|
|
would previously have produced the resource ID number as an I6 value, you
|
|
now need to say
|
|
```
|
|
ResourceIDsOfFigures-->((+ figure of Space Shuttle +))
|
|
```
|
|
and similarly for sounds. We apologise for the inconvenience of changing
|
|
this, but from the long-term point of view, it's the right thing to do.
|
|
|
|
### Miscellaneous
|
|
|
|
The I6 template reader has been made more forgiving of what it considers
|
|
malformed headings - marked by the use of an "@" character in the leftmost
|
|
column; some users ran into this by accidentally placing Z-machine or Glulx
|
|
assembly language, also marked by an "@" in I6, unindented on the left
|
|
margin of material included using "(-" and "-)". The template reader will
|
|
now handle any such material correctly, and a more helpful problem message
|
|
is produced if it nevertheless runs into trouble because of a stray "@".
|
|
|
|
Part 3 of the Standard Rules now has slightly better section divisions,
|
|
making it easier to replace smaller chunks.
|
|
|
|
Formatting improved on the Problems page for the case of running out of
|
|
readable memory in the Z-machine. In 5Z71 the message for this was, due to
|
|
a text editor accident, full of words run together without spaces; which
|
|
"creates the alarming impression of a nervous breakdown" (Eric Eve).
|
|
|
|
Perhaps this was a bug fix, perhaps a small new feature, but it likely won't
|
|
be controversial: local variable names (created by "let", and such) now take
|
|
precedence over global names of physical objects even in descriptions of
|
|
essentially physical situations. For example, in the fragment
|
|
```
|
|
To sweep (staircase - a supporter):
|
|
let the debris be a random thing that is supported on the staircase;
|
|
```
|
|
...Inform now reads "staircase" as the supporter appearing as a token in the
|
|
expansion of "sweep", even if there is an object in the world called "the
|
|
staircase".
|
|
|
|
### Index
|
|
|
|
The Phrasebook index has been redesigned. Each phrase is now provided with
|
|
a "plus" icon which, when clicked, reveals full documentation of what that
|
|
phrase does, along with a link to the relevant page in the manual; and the
|
|
manual has similarly been redesigned to match the Phrasebook.
|
|
|
|
The Kinds index has been reorganised to reflect the new structure of the
|
|
kinds system in Inform.
|
|
|
|
The Contents index now includes links to the documentation for any extensions
|
|
included in the project being indexed.
|
|
|
|
Timed events have moved from the obscure sub-panel of the Rules index, where
|
|
they had previously languished unnoticed, to the Scenes index. They now
|
|
include cross-references for each event to the points in the source text
|
|
which trigger them.
|
|
|
|
The Scenes index now marks which scenes are recurring, and clarifies the role
|
|
of the special Entire Game scene.
|
|
|
|
### Deprecated phrases
|
|
|
|
With this build, we take a first step towards removing a few features of the
|
|
Inform language which, in the light of experience, we regret having introduced.
|
|
A few syntaxes change with every major release, of course, but we plan a
|
|
bigger change next time, and are now preparing the way for this.
|
|
|
|
There are some 367 built-in phrase definitions in the Standard Rules. The
|
|
great majority will stay, of course, but we intend to remove 34 of these
|
|
phrases in the next big release of Inform. This will inevitably cause a
|
|
little disruption, so we've done three things to ease the way:
|
|
|
|
(a) Each phrase due to be removed is now officially "deprecated", and marked
|
|
with a red warning triangle in the Phrasebook and in the documentation.
|
|
The documentation explains what to use instead.
|
|
|
|
(b) Deprecated phrases are not used in the Examples, except for a very few
|
|
cases where the only purpose of the Example is to show how to use the phrase
|
|
in question. They are similarly avoided by built-in Extensions, including the
|
|
Standard Rules.
|
|
|
|
(c) A new use option has been added:
|
|
```
|
|
Use no deprecated features.
|
|
```
|
|
With this set, Inform will reject any of the deprecated phrases; so setting
|
|
this is a good way to see whether any existing source text is likely to give
|
|
trouble after the next release.
|
|
|
|
The deprecated phrases are a mixed bunch:
|
|
```
|
|
say "[contents of object]"
|
|
say "[the contents of object]"
|
|
change (a stored value) to (value)
|
|
change (object) to (property)
|
|
change (object) to (enumerated value)
|
|
delete (a table entry)
|
|
if using the/-- (use option):
|
|
if (a condition) then (a phrase)
|
|
while (a condition) repeatedly (a phrase)
|
|
while (a condition), (a phrase)
|
|
ignore (rule)
|
|
reinstate (rule)
|
|
reject the result of (rule)
|
|
accept the result of (rule)
|
|
substitute (rule) for (rule)
|
|
restore the original (rule)
|
|
move (rule) to before (rule)
|
|
move (rule) to after (rule)
|
|
end the game in death
|
|
end the game in victory
|
|
end the game saying (text)
|
|
resume the game
|
|
if game is in progress:
|
|
if game is over:
|
|
if game ended in death:
|
|
if game ended in victory:
|
|
if it is before (time):
|
|
if it is after (time):
|
|
change the/-- player to (object)
|
|
if in (object):
|
|
award (number) point/points
|
|
set pronouns from possessions of the player
|
|
```
|
|
Some of these are very familiar-looking, but almost all simply duplicate more
|
|
general constructions. "award 5 points", for instance, is exactly the same as
|
|
"increase the score by 5"; "change the time of day to 10 PM" is the same as
|
|
"now the time of day is 10 PM". Exotic forms of "if" and "while" are being
|
|
removed for simplicity's sake: people didn't use them much in practice.
|
|
That leaves two clusters of phrases - those for ending the game, and those
|
|
for procedural rules. With ending the game, we have adopted a more uniform
|
|
style of wording, and abolished the idea of "death" and "victory":
|
|
```
|
|
end the story
|
|
end the story finally
|
|
end the story saying (text)
|
|
end the story finally saying (text)
|
|
if story has ended:
|
|
if story has ended finally:
|
|
if story has not ended:
|
|
if story has not ended finally:
|
|
resume the story
|
|
```
|
|
The difference between ending and ending finally is that a final ending is
|
|
one where we don't expect the reader to play again, and can safely show him
|
|
menu options such as Infocom's traditional AMUSING (which suggests alternative
|
|
unlikely possible plays). Thus "game" becomes "story", "death" becomes merely
|
|
the "end" and victory the "final end". In the process, we gain the ability to
|
|
have a final ending with wording other than "You have won"; and the default
|
|
ending text is now "The End", not "You have died". Sic transit gloria mundi.
|
|
|
|
Procedural rules, on the other hand, definitely do provide functionality
|
|
which is not available otherwise by a simple rewording. When they go, they
|
|
will be a small loss. But after four years of Inform 7's public use, we
|
|
find that very few people use them, and then almost always in situations
|
|
where it would be just as good to use "not listed in" sentences instead -
|
|
the main use of procedural rules is to abolish some built-in rule, but
|
|
that can be done just as well by unlisting it.
|
|
|
|
The reason for removing procedural rules is that it will enable optimisations
|
|
of the code generated by Inform to get faster run-time performance, which we
|
|
expect to become a more significant issue in future - the time may come when
|
|
the majority of IF players are running the story file in a browser; perhaps
|
|
even a browser on a relatively slow-CPU mobile device, such as an iPad. We
|
|
also hope to bring down the writeable memory usage at run-time, which is an
|
|
issue for story files running on the Z-machine (though not for Glulx, where
|
|
memory is essentially unlimited). Besides this, procedural rules often
|
|
confused authors (hardly anybody knows the difference between "follow" and
|
|
"consider" - a difference which will be abolished), and they made the Index
|
|
a little misleading, since it displayed the structure as it was before
|
|
being manipulated.
|
|
|
|
So we have swallowed our medicine, and deprecated procedural rules. They
|
|
were cool, but not worth the cost.
|
|
|
|
### A note about external files
|
|
|
|
Prior to March of 2010, the Glk reference materials and interpreters
|
|
incorrectly specified the underlying code for appending text to
|
|
external files. This means that, on most interpreters, external file
|
|
handling did not work correctly. The major interpreters, including
|
|
WinGlulxe, WinGit, and Gargoyle, were patched in mid-March. (Zoom was
|
|
not affected.) Authors should be aware of this when testing and
|
|
recommending or packaging interpreters for games that utilize external
|
|
files.
|
|
|
|
## Documentation, examples and extensions
|
|
|
|
### Recipe book
|
|
|
|
Modifications to "Ending the Game" (now called "Ending the Story") to
|
|
reflect new syntax and to explain the Table of Final Question Options more
|
|
fully.
|
|
|
|
### Examples
|
|
|
|
- "Entrevaux" added to demonstrate a system of scenes where each scene has a
|
|
list of props, a location, and some starting text, and scenes are set up
|
|
and struck automatically.
|
|
- "Wainwright Acts" added to demonstrate a quirk of using doors with NPCs.
|
|
- "Number Study" added to demonstrate conditional relations between numbers.
|
|
- "For Demonstration Purposes" added to show the use of relations applying to
|
|
stored action names.
|
|
- "The Undertomb 2" added to demonstrate properties of values.
|
|
- "Finality" added to demonstrate how to strip out the offer of UNDO.
|
|
- "Pot of Petunias" added to demonstrate "set pronouns from..." and point to
|
|
the more abstruse methods available in Plurality, if the author needs them.
|
|
- "Unblinking" added to demonstrate the use of best route through...
|
|
described rooms, and to explain a tricky point about determining light
|
|
levels in a room.
|
|
- "Lethal Concentration 2" edited to produce more attractive grids.
|
|
- "Bic" modified to reflect the new behavior of description properties.
|
|
- "Kiwi" revised to be more accurate about when it prints its parser error.
|
|
- "Waterworld" extended to show how to add new accessibility rules. (The old
|
|
version of this example was simple but not the most trustworthy
|
|
implementation.)
|
|
- "Stately Gardens" revised to handle "look towards [something]" better, and
|
|
to print a response to looking towards a room that contains nothing notable.
|
|
- "Paddington", "Sushi" and "Crusoe" slightly rewritten to account for changes
|
|
to the carry out examining rulebook (see above).
|
|
- "Ferragamo Again": removed bug whereby it was possible to get "You sighs
|
|
heavily." as output.
|
|
- "Bowler Hats and Baby Geese": removed bug that caused the eggs still to be
|
|
visible after they were made into the omelet.
|
|
- "Pine 4": removed bug that made the brothers invisible because they were
|
|
not starting in the Woodcutter's Shack.
|
|
- "Strictly Ballroom": removed bug that made it possible for one of the other
|
|
characters to dance with "yourself".
|
|
- "Entrapment": made a very slight tweak to syntax to clarify what is
|
|
happening at one point for the reader.
|
|
- "Tilt 3": removed a comment that pasted incorrectly into the main window,
|
|
causing compilation to fail when compiling for Glulx.
|
|
- "The Cow Exonerated": removed a bug such that the game text always assumed
|
|
you'd been burning multiple matches.
|
|
- "Further Reasons All Poets Are Liars": added tweaks to prevent moving the
|
|
box while standing on the bed, and to give a more sensible response to PUSH
|
|
BOX alone (formerly this gave "It is fixed in place.", which was clearly
|
|
wrong).
|
|
- "Hayes Code": revised to add an indefinite article ("a thong", "a
|
|
pin-striped suit") rather than the inexplicably bare version given before.
|
|
Also, it should have been "Hays Code" all along. Oops.
|
|
- "Under Contract": revised to include a test for the situation in which the
|
|
player tries giving her dress to Clark. This actually tests an improvement
|
|
to the Standard Rules.
|
|
- "The Cactus Will Outlive Us All": tweaked to replace the somewhat
|
|
disappointing message "Nothing obvious happens" after we pull the cactus to
|
|
kill Luckless Luke.
|
|
- "AARP-Gnosis": bug fixed whereby taking all but one of the volumes from the
|
|
encyclopedia would produce a delay of one turn before proper collection
|
|
descriptions kicked in.
|
|
- "Cloves": modified to automatically list the adverbs that the game knows
|
|
rather than hard-coding the list, now that this is possible.
|
|
- "Bumping Into Walls" very slightly revised because the previous phrasing
|
|
would create output like "From here, the only way out is to the down"
|
|
if vertical directions were included.
|
|
- "Whence?" and "Whither?" simplified considerably thanks to the use of
|
|
built-in phrases about door directions.
|
|
- "Boston Cream", "Text Foosball", "Patient Zero", "Nickel and Dimed", "Four
|
|
Stars" tweaked to include the "end the story finally saying..." phrase to
|
|
mark successful endings apart from unsuccessful ones.
|
|
- "Patient Zero" edited to excise an unused phrase definition.
|
|
- "The Facts Were These" edited to deal more gracefully with the problem of
|
|
giving items that are on the ground, if no other items not on the ground match.
|
|
- "Cave-Troll", "Kiwi", and "WXPQ" edited to handle new treatment of parser errors.
|
|
|
|
### Extensions
|
|
|
|
- The definition of kHz in "Metric Units" was wrong: it thought 1 kHz was a
|
|
thousandth of a Hz, not a thousand Hz.
|
|
- "Locksmith" advanced to version 9: additional rules so that the player can
|
|
learn the function of a passkey by using it to lock or observing it being
|
|
used to lock. (Formerly only unlocking identified the passkey.)
|
|
Name given to one rule for which a name had been omitted. (Sorry about that.)
|
|
- Tweak to "Basic Screen Effects" to get rid of a bug to do with the styles of
|
|
status text in Glulx when an extended status bar was employed (thanks to
|
|
Erik Temple for the patch). Version advanced to 6.
|
|
- "Plurality" advanced to version 8:
|
|
- A couple of minor bugs expunged.
|
|
- Extension documentation improved to show how to check the plural status of
|
|
objects.
|
|
- Adjusted to use the phrase "set pronouns from...".
|
|
- Deprecates phrases using "Cap ...", as in "Cap it-they", instead allowing
|
|
the author to capitalize normally for the same effect ("It-they").
|
|
- Adds a contracted 's-'re form in addition to is-are, and extends the example
|
|
in the documentation.
|
|
- "Glulx Text Effects": minor changes to the documentation to clear up some
|
|
confusion in the discussion of colors as rendered in hex; and revised to
|
|
allow the user to modify the built-in styles. Version number advanced to 4.
|
|
- "Glulx Entry Points" given a new example and better explanation of what the
|
|
gestalt checks about multimedia ability will actually do. Version number
|
|
increased to 8.
|
|
|
|
## Problem messages
|
|
|
|
Problem messages reformatted to give more information in case of complicated
|
|
ambiguities to do with phrases; and problems suppressed when they are
|
|
follow-on problems arising only because variables weren't created properly.
|
|
For example, this source text:
|
|
```
|
|
Every turn:
|
|
repeat with X running from 1 to "fish":
|
|
say "Hello! [X].";
|
|
let Y be X plus X;
|
|
increase score by Y;
|
|
```
|
|
would throw four problem messages in previous builds, but now it throws only
|
|
one. Inform realises that the author intends to create X, and even though he
|
|
botched it, Inform suppresses what would otherwise be problem messages in the
|
|
next two lines; it further realises that the idea is to create Y as well, and
|
|
suppresses the problem message that the last line would otherwise lead to.
|
|
|
|
Problem message added (in place of sometimes mysterious other problem
|
|
message(s)) to catch attempts to use "called" to make a name which already
|
|
has another meaning and where confusion may occur. For example, an attempt
|
|
to write:
|
|
```
|
|
Instead of giving something (called the number): ...
|
|
```
|
|
cannot possibly end well, but Inform would previously allow the calling, then
|
|
throw problem messages later on when it was used.
|
|
|
|
Problem message added to catch unused timed events. This is an arguable case,
|
|
because perhaps it could be said that it's legal to create timed events which
|
|
are never used. But it's a better idea to catch mistakes like this:
|
|
```
|
|
At the time when supply of the air tank is -4:
|
|
end the game saying "You have suffocated."
|
|
```
|
|
where the author believes incorrectly that the rule will fire when the
|
|
condition is true, whereas actually he has created a timed event with the
|
|
exotic name of "supply of the air tank is -4".
|
|
|
|
Problem message added (in place of Inform 6 errors) to catch attempts to
|
|
change the bibliographic data for a story during play. A shame, this; it
|
|
would be coolly interactive to be able to change the story's title and
|
|
author halfway through, but it would make the Library Card, the IFDB entry,
|
|
and so on, wrong.
|
|
|
|
Problem message added (in place of internal error) when attempting to solve
|
|
an equation which is given as the result of some further calculation, rather
|
|
than being explicitly named.
|
|
|
|
Problem message added (in place of internal error) when the title, author,
|
|
or other bibliographic data for a project contains a text substitution -
|
|
again, these have to be fixed text.
|
|
|
|
Problem message added (in place of internal error) when a door is said to
|
|
be "south of nowhere", or for other such formulations involving "nowhere" as
|
|
the source of a map connection.
|
|
|
|
Problem message added (in place of what was in some circumstances an internal
|
|
error) when an either/or property is assigned using "has" instead of "is",
|
|
e.g., "The teddy bear has fuzzy."
|
|
|
|
Problem message added for misunderstandings like "When the play begins..."
|
|
instead of "When play begins...".
|
|
|
|
Problem message added (in place of internal error) when a declaration
|
|
contains only variables, e.g., "To (N - a number): ...".
|
|
|
|
Problem message added (in place of run-time problem) when a variable is
|
|
created with kind "list of topics", or other such constructions. (Variables
|
|
of kind "topic" are forbidden; it was an oversight that these more complex
|
|
variations weren't rejected at compile-time in earlier builds. They were let
|
|
through, but didn't work at run-time.)
|
|
|
|
Problem message added for non-thing objects being created inside or on top
|
|
of other objects. (The world model requires that the contents of a room must
|
|
be things, but earlier builds didn't check this; at run-time, strange things
|
|
could then occur.)
|
|
|
|
Problem message added to explain oddball mistakes like "A thing is a waiting
|
|
receptacle if it is an open container.", which in previous builds were met
|
|
with a rather vague and unhelpful complaint.
|
|
|
|
Problem message added (in place of internal error) for understanding a
|
|
property in the description of something, when the property is one whose
|
|
value is an object of a kind outside the usual spatial model (i.e., neither
|
|
room, thing, region nor direction).
|
|
|
|
Problem message added (in place of internal error) for making a direction
|
|
whose opposite does exist, but isn't a direction.
|
|
|
|
Problem message added for attempts to release along with an existing story
|
|
file when in Glulx mode: Inform supports this for Z-machine story files, but
|
|
not Glulx, at present. (There are so few Glulx story files not generated by
|
|
I7 that it's never seemed worth it, but get in touch if you do need this.)
|
|
|
|
Problem message added (in place of internal error) for a malformed inline
|
|
Inform 6 phrase definition with redundant text after the "-)" marker.
|
|
|
|
Problem message added for definitions which try to use "or more" or "or less"
|
|
with non-arithmetic values, e.g.,
|
|
```
|
|
Definition: a person is cool if his callsign is "dude" or more.
|
|
```
|
|
|
|
Problem message added to catch attempts to give properties to a set of owners
|
|
which changes during play, e.g.,
|
|
```
|
|
Colour is a kind of value. The colours are red and green.
|
|
A thing has a colour.
|
|
Taste is a kind of value. The tastes are sweet and sour.
|
|
A thing has a taste.
|
|
The taste of a red thing is usually sweet.
|
|
```
|
|
|
|
Problem message added to catch attempts to file rules about out-of-world
|
|
actions into the before, instead or after rulebooks (where they can have no
|
|
effect under any circumstances, since these aren't consulted for OOW actions).
|
|
|
|
Problem message added to catch mixtures of in-world and out-of-world actions:
|
|
```
|
|
Instead of requesting the pronoun meanings or taking inventory: ...
|
|
```
|
|
|
|
Problem message added for attempts to look up a value corresponding to a
|
|
key in a table when the kind of the column concerned makes that impossible,
|
|
e.g., for "the price corresponding to a shopkeeper of 4 in Table 1" where
|
|
the shopkeeper column doesn't contain numbers, so that 4 can't possibly be
|
|
there.
|
|
|
|
Problem message added to catch mistakes like this:
|
|
```
|
|
Happiness is a kind of value. Disappointment is a scene.
|
|
Disappointment begins when happiness ends.
|
|
```
|
|
|
|
Problem message added (in place of internal error) when a declaration
|
|
contains only variables, e.g., "To (N - a number): ...".
|
|
|
|
Problem message added (in place of internal error) when a circularity is
|
|
asked for by using "[something related by equality]", e.g.:
|
|
```
|
|
Understand "[something related by equality]" as a person.
|
|
```
|
|
|
|
## Bug fixes
|
|
|
|
### Source text and punctuation
|
|
|
|
Bogus times of day such as "minus 6:23 PM" are no longer recognised; "minus"
|
|
can only be used with relative times, as in "minus six minutes".
|
|
|
|
The I6 template reader has been made more forgiving of what it considers
|
|
malformed headings - marked by the use of an "@" character in the leftmost
|
|
column; some users ran into this by accidentally placing Z-machine or Glulx
|
|
assembly language, also marked by an "@" in I6, unindented on the left
|
|
margin of material included using "(-" and "-)". The template reader will
|
|
now handle any such material correctly, and a more helpful problem message
|
|
is produced if it nevertheless runs into trouble because of a stray "@".
|
|
|
|
### Headings
|
|
|
|
Bug fixed whereby it's impossible to use a heading to replace an existing
|
|
heading in an extension if that existing heading contains the words "in"
|
|
or "by" in its name; and problem messages related to heading tricks made
|
|
more explanatory.
|
|
|
|
Part 3 of the Standard Rules now has slightly better section divisions,
|
|
making it easier to replace smaller chunks.
|
|
|
|
### Assertions and creations
|
|
|
|
Bug fixed whereby "There are ..." sentences might fail if a number of things
|
|
were created with some modifying adjective, e.g. "There are four closed doors."
|
|
|
|
Bug fixed whereby a player declared to be a particular person would not
|
|
always be placed into relationships asserted for "the player". For example,
|
|
```
|
|
The player is a woman called Edna Marsh. The player holds a wrench.
|
|
```
|
|
...not resulting in Edna carrying the wrench.
|
|
|
|
### Model world
|
|
|
|
Bug fixed whereby generalising about the "map region" property could cause
|
|
an internal error; for instance,
|
|
```
|
|
The map region of a room is usually Jaguar Creek Valley.
|
|
```
|
|
Setting "map region" is not the preferred way to put rooms into regions,
|
|
but the above did work in past builds (and the "Permission to Visit" extension
|
|
apparently made use of that); the practice is hereby legalised, and the World
|
|
index now properly maps the result.
|
|
|
|
Bug fixed whereby the fast route-finding algorithm for finding routes through
|
|
the map (the default route-finder in Glulx, but only used if the "Use fast
|
|
route-finding" option is chosen in the Z-machine) would always use doors,
|
|
even when not allowed to, and would return 0 rather than -1 for a count of
|
|
the number of steps of an impossible route.
|
|
|
|
Bug fixed whereby the fast route-finding algorithm for finding routes through
|
|
the map would sometimes return "north" as the "best route from X to Y" in cases
|
|
where no route exists, rather than returning "nothing".
|
|
|
|
Bug fixed whereby sudden movements of the player from a dark room into a
|
|
lighted one, which happen other than by the usual actions, could result in
|
|
the new room's description being shown twice over.
|
|
|
|
Bug fixed (if it was really a bug) whereby the "maximum score" could not be
|
|
changed during play.
|
|
|
|
Bug fixed whereby UNDO would be disallowed in a story where the "advance
|
|
time rule" had been unlisted, with Inform thinking that (since no time had
|
|
passed) there was nothing to UNDO back to.
|
|
|
|
### Properties
|
|
|
|
Bug fixed whereby Inform confuses a property of an object with a use of a
|
|
value phrase containing the word "of" - for example, misreading "room
|
|
illustration of the location" as an attempt to use the phrase "room D of R"
|
|
(for looking up the map) rather than an attempt to access a property called
|
|
"room illustration".
|
|
|
|
Bug fixed whereby property declarations such as "A room that is dark can be
|
|
dangerous." would wrongly be accepted, but would have adjectives or qualifiers
|
|
such as "that is dark" ignored. (It's incorrect to make a declaration like
|
|
this because the owner of a property has to own it all of the time, no
|
|
matter what; it can't have it only when it's dark.)
|
|
|
|
Bug fixed whereby adjectives declared in the form "...if its P is V" (which
|
|
check that a property P has value V) would always be false for text properties;
|
|
thus, "Definition: a childhood memory is forgotten if its recollection is ""."
|
|
would fail to work.
|
|
|
|
Bug fixed whereby antonyms of adjectives declared in a way which laid them
|
|
out as phrases, like so...
|
|
```
|
|
Definition: A thing (called the item) is handy rather than useless:
|
|
if the item is openable, decide yes;
|
|
decide no.
|
|
```
|
|
...would fail to work: "handy" would work perfectly, but not "useless", which
|
|
would in some circumstances produce I6 errors.
|
|
|
|
Bug fixed whereby descriptions implicitly given to kinds are now taken as
|
|
being likely but not certain; as a result, the following is now possible,
|
|
whereas previously it was reported as a contradiction:
|
|
```
|
|
A folding metal chair is a kind of supporter.
|
|
"The chair looks only moderately uncomfortable."
|
|
The small chair is a folding metal chair in test room.
|
|
"The chair looks painful to sit in."
|
|
```
|
|
|
|
### Actions
|
|
|
|
Bug fixed whereby variable declarations for actions whose names include the
|
|
words "with" or "having" (either not at the end, or not after "it") would
|
|
produce spurious problem messages.
|
|
|
|
Bug fixed whereby an action in which the player asks someone else to do
|
|
something, which then fails because the persuasion rules halt the process,
|
|
would result in "reason the action failed" not properly being set. (It's now
|
|
set to the identity of the persuasion rule which stopped the action.)
|
|
|
|
Bug fixed whereby Inform would fail to recognise actions involving actors
|
|
whose names include words with an "-ing" suffix, and where the longhand
|
|
"trying" syntax isn't being used. Thus if somebody's full name is "Regional
|
|
Training Officer Tina", Inform was failing to recognise "Tina examining the
|
|
clipboard" as an action, simply because of the word "Training" in her full
|
|
name. Inform now allows such readings in any case except where the action
|
|
verb is itself part of the actor's full name; thus, if there were an action
|
|
called "training", Inform wouldn't like "Tina training Kevin", which would
|
|
look to Inform like a row of names of people; and the author would have
|
|
to rephrase in the longhand form, "Tina trying training Kevin".
|
|
|
|
Bug fixed whereby actions out of world applying to a topic would have the
|
|
topic noun empty, rather than containing the text of the topic as they
|
|
should; for instance, in this combination:
|
|
```
|
|
Helping is an action out of world applying to one topic.
|
|
Understand "help [text]" as helping.
|
|
```
|
|
the command HELP RICHARD STRAUSS would fail to have the noun set to the
|
|
snippet RICHARD STRAUSS of the command, as would happen for an action
|
|
in world. This wasn't a deliberate restriction - it was a bug.
|
|
|
|
Bug fixed whereby out of world actions in one pass of the turn sequence
|
|
rules could sometimes cause the next pass of the turn sequence to begin
|
|
as if we were still out of world, making it difficult to try in-world
|
|
actions before a command had been typed; this caused the following not
|
|
to work -
|
|
```
|
|
This is the Luciano's actions rule: try Luciano singing.
|
|
The Luciano's actions rule is listed before the parse command rule
|
|
in the turn sequence rules.
|
|
```
|
|
- in the turn after a command like VERSION or VERBOSE.
|
|
|
|
Bug fixed (or perhaps it's really that Inform's specification has been
|
|
clarified) so that a rule like this:
|
|
```
|
|
Every turn jumping for three turns: say "A demon appears!"
|
|
```
|
|
does take effect if the player jumps twice, types SAVE, and then jumps a
|
|
third time; that is, the saving the game action does not interrupt the
|
|
count up to three. (Because saving the game is out-of-world, and so doesn't
|
|
take up a turn.) On the other hand, a rule like this is fine:
|
|
```
|
|
Check requesting the pronoun meanings for the first time:
|
|
say "The PRONOUNS command is very useful. To explain: ...";
|
|
continue the action.
|
|
```
|
|
since although "requesting the pronoun meanings" happens out-of-world and
|
|
can't take place for a number of turns, it does take place for a number
|
|
of times.
|
|
|
|
Bug fixed whereby references to things having happened "for exactly 0 turns"
|
|
would fail to work, e.g.:
|
|
```
|
|
if the rose has been visible for exactly 0 turns
|
|
```
|
|
Bug fixed whereby "try", when used to cause an out-of-world action by the
|
|
player during an existing action by somebody else, could sometimes cause a
|
|
consecutive in-world action by that other person to be misconstrued as
|
|
being out-of-world. For example:
|
|
```
|
|
Instead of an actor waiting:
|
|
try requesting the pronoun meanings;
|
|
try the actor saying yes.
|
|
```
|
|
might result in the "saying yes" action being rejected as out-of-world and
|
|
thus unavailable to an actor other than the player.
|
|
|
|
Bug fixed whereby before, instead or after rules would sometimes be included
|
|
on the Index pages for out-of-world actions, despite the fact that they
|
|
cannot affect these.
|
|
|
|
Bug fixed whereby lists of actions would sometimes be misread if entries
|
|
were ambiguous as to which action was meant, e.g.,
|
|
```
|
|
Instead of doing something other than waiting or examining or taking
|
|
inventory or looking: ...
|
|
```
|
|
was misread as if "taking inventory" were simply "taking".
|
|
|
|
Bug fixed whereby a stored action which involved a value would sometimes be
|
|
said incorrectly (though in other ways it was okay): for example,
|
|
```
|
|
Factoring is an action applying to one number.
|
|
...
|
|
let the best idea be the action of factoring 15;
|
|
say "You consider [the best idea].";
|
|
```
|
|
would say the action as "factoring -23145", or some other mysterious number.
|
|
|
|
### Activities
|
|
|
|
Bug fixed whereby global variables could not appear in "... while ..."
|
|
clauses to do with activities, so that this for instance would not work:
|
|
```
|
|
For printing the name of the banana while listing contents of the player:
|
|
say "yummy banana".
|
|
```
|
|
...whereas the same thing with "yourself" instead of "the player" would work.
|
|
They now both do.
|
|
|
|
### Rules and rulebooks
|
|
|
|
A minor change which looks like a bug fix, but isn't, strictly speaking:
|
|
when a bare adjective is used as a condition attached to an action, as here -
|
|
```
|
|
Instead of doing something when off-stage:
|
|
say "After the thrill of the spotlight, life seems not to exist."
|
|
```
|
|
- the adjective is now assumed to apply to the person performing the action.
|
|
(In this case that's the player, who can never be off-stage, so that the
|
|
message can't be said. But the principle is the important thing.)
|
|
|
|
Bug fixed whereby compound conditions which included spurious additional
|
|
"when" or "while" words could cause Inform to hang, or crash; for example,
|
|
```
|
|
Test Scene begins when the player is in the First Room or when the
|
|
player is in the Second Room.
|
|
```
|
|
(It should be just "or the player...", not "or when the player...". Inform
|
|
now catches this with a more on-point problem message.)
|
|
|
|
Bug fixed whereby rules using "going nowhere in R" for some room R, or
|
|
"going somewhere in R", would fail to be matched correctly; so that this, for
|
|
example, wouldn't work:
|
|
```
|
|
Instead of going nowhere in the Home: say "You'd just get homesick."
|
|
```
|
|
For clarity's sake: rules written thus...
|
|
```
|
|
Instead of yourself going: ...
|
|
```
|
|
where the actor is explicitly named as "yourself" (or "the player"), now work
|
|
as the writer might expect (i.e., as if it just read "Instead of going: ...").
|
|
Hard to know whether this is a bug fix or not - arguably it's less consistent
|
|
this way, because the convention is that an action is by the player unless
|
|
a specific actor is named. But what matters is that the sense should
|
|
be right for the reader.
|
|
|
|
Bug fixed whereby rules depending on something in the past tense being true
|
|
over a period which is itself in the past would sometimes not fire. For
|
|
example,
|
|
```
|
|
Before doing something when the hat has been worn for three turns: ...
|
|
```
|
|
Bug fixed whereby an I7 name given to a rule defined by an I6 routine would
|
|
sometimes be confused with the name of a new object, if used as the value
|
|
of a property, or in some other assertion sentence contexts.
|
|
|
|
### Lists
|
|
|
|
Bug fixed whereby lists of lists of indexed texts (and similar constructions)
|
|
could lose their identities when printed.
|
|
|
|
Bug fixed whereby accesses of entries from very long lists, when performed
|
|
repeatedly, could become unacceptably slow.
|
|
|
|
Bug fixed whereby sorting a list of objects using "sort L in P order",
|
|
where P is a property whose value is an indexed text, would produce
|
|
incorrect results.
|
|
|
|
Bug fixed whereby sorting a list of indexed text initialised from a list
|
|
of literal texts would produce incorrect answers. (Actually it was the list
|
|
which was incorrect, but in a way which only affected sorting.)
|
|
|
|
Bug fixed whereby peculiar messages about being unable to cast or copy block
|
|
values would sometimes appear when passing a list of K to a phrase which
|
|
expects its token to have kind "list of objects", but where K is something
|
|
more specific; for example, passing a list of rooms where a list of objects
|
|
was expected.
|
|
|
|
Two bugs fixed whereby Inform would be picky about whether or not the contents
|
|
of, say, a constant list of things were valid, in cases where the entries
|
|
were not obviously things but would be proved to be by the end of compilation;
|
|
this affected initial values of properties and of global variables. For
|
|
example, the following threw a spurious problem message in earlier builds:
|
|
```
|
|
The Place is a room. Hall is south of the Place.
|
|
The destination wishlist is a list of rooms that varies.
|
|
The destination wishlist is { the Place, the Hall }.
|
|
```
|
|
The problem here was that the Hall wasn't known to be a room at the time when
|
|
the constant list was read; this has now been resolved.
|
|
|
|
### Tables
|
|
|
|
The maximum number of columns per table has been raised from 20 to 99.
|
|
(There are run-time implementation reasons why a maximum has to exist, but
|
|
99 ought to be enough.)
|
|
|
|
Bug fixed whereby table entries containing literal values would sometimes be
|
|
confused with names of objects, if they could also be read as part of an
|
|
object's name: for example, if an object called False Door existed, then the
|
|
table entry "false" might be misread as this object rather than as the
|
|
truth state for falsity.
|
|
|
|
Bug fixed whereby tables used to define things or values could not have
|
|
a column which contained stored actions, e.g., like so:
|
|
```
|
|
A task is a kind of value. Some tasks are defined by the Table of
|
|
Unfinished Tasks.
|
|
|
|
Table of Unfinished Tasks
|
|
task relevant action
|
|
boulder-touching touching the large boulder
|
|
boulder-recovering taking the large boulder
|
|
```
|
|
Bug fixed whereby, on Glulx only and then only sometimes, looking up a
|
|
value corresponding to another value would produce spurious "programming
|
|
errors" on screen in cases where the column looked at included blank entries.
|
|
|
|
Bug fixed whereby attempts to use "an X listed in table T", in the context
|
|
of a value, would wrongly be allowed even where this doesn't identify which
|
|
value is meant.
|
|
|
|
Bug fixed whereby the "number of rows in T" would produce a more or less
|
|
random answer if T were the empty table used as a default value of the
|
|
"table name" kind; and this could cause "number of filled rows in T" to
|
|
hang, in unlucky cases.
|
|
|
|
Bug fixed whereby increasing or decreasing a table entry by a given amount
|
|
in fact set it to that amount (but only in cases where the entry was looked
|
|
up with "corresponding to").
|
|
|
|
Bug fixed whereby various sorting tricks with tables would fail if the
|
|
column sorted on contained indexed text. Inform now requires such tables
|
|
to be sorted before being iterated through using "repeat through T in
|
|
C order", where C is a column holding indexed text, and issues a helpful
|
|
run-time problem message explaining what to do; previously it simply gave
|
|
incorrect results.
|
|
|
|
Bug fixed whereby sorting tables in random order would be slow if they
|
|
contained large numbers of blank rows.
|
|
|
|
Bug fixed whereby sorting a table on a column which contained some blank
|
|
entries (other than as part of blank rows) would move these to the top,
|
|
rather than to the bottom, of the table.
|
|
|
|
### Scenes
|
|
|
|
Bug fixed whereby scene endings predicated on the player's command would
|
|
sometimes fail on the initial pre-turn, before anything had been typed, e.g.:
|
|
```
|
|
Act I ends when the player's command includes "bug/bugs".
|
|
```
|
|
### Kinds and typechecking
|
|
|
|
Bug fixed whereby defining more than 50 new kinds could sometimes cause
|
|
Inform 6 errors or other aberrant behaviour, in a not-very-repeatable way.
|
|
|
|
Bug fixed whereby nested bracketed compound phrases failed to be read
|
|
properly. It's often poor prose style to write messy phrases full of brackets
|
|
to disambiguate them, but it ought to work, and it seems that this long-standing
|
|
bug made Inform a little unpredictable here.
|
|
|
|
Bug fixed whereby spurious problem messages would sometimes be produced
|
|
when matching adjective-qualified descriptions in the tokens for a phrase;
|
|
for instance, in matching "analyse X" against
|
|
```
|
|
To analyse (N - even number): ...
|
|
```
|
|
...in cases where X is clearly a number, but may or may not be even.
|
|
|
|
Bug fixed whereby temporary variables made with "let" or "repeat" whose names
|
|
clashed with valid descriptions would be disallowed. This doesn't sound
|
|
problematic, but actually it was: for example, if you write
|
|
```
|
|
let held item be ...
|
|
```
|
|
in an extension, say, you don't want this to work most of the time, but then
|
|
to fail when somebody uses the extension with a story including an object
|
|
called "item" (because then "held item" is a valid description - it means
|
|
the item when in a state of being held).
|
|
|
|
Bug fixed whereby "some" used as an indefinite article inside a condition
|
|
might be confused with "some" as a determiner, e.g., in the "now" here:
|
|
```
|
|
Some tea is in the kitchen.
|
|
When play begins: now the player has some tea.
|
|
```
|
|
Bug fixed whereby spurious kind mismatch problems would be produced when
|
|
named objects were used as cases, where a particular kind was needed. For
|
|
instance,
|
|
```
|
|
To decide if (D - a direction) looks to windward:
|
|
if D is:
|
|
-- northeast:
|
|
decide no;
|
|
```
|
|
Bug fixed whereby an attempt to really violate dimensional rules about the
|
|
way numerical values combine could, in some circumstances, throw an internal
|
|
error; for example, using the Metric Units extension to set up standard SI
|
|
units, but then adding "A force times a mass specifies a force.", thus making
|
|
mass dimensionless. (Newton's Laws become not just invalid but inexpressible
|
|
in such a universe... but that's no reason for Inform to fold up its tent.)
|
|
|
|
### Phrases and functional programming
|
|
|
|
Perhaps this was a bug fix, perhaps a small new feature, but it likely won't
|
|
be controversial: local variable names (created by "let", and such) now take
|
|
precedence over global names of physical objects even in descriptions of
|
|
essentially physical situations. For example, in the fragment
|
|
```
|
|
To sweep (staircase - a supporter):
|
|
let the debris be a random thing that is supported on the staircase;
|
|
```
|
|
...Inform now reads "staircase" as the supporter appearing as a token in the
|
|
expansion of "sweep", even if there is an object in the world called "the
|
|
staircase".
|
|
|
|
Bug fixed whereby implicit attempts to repeat through a domain which can't
|
|
be iterated through would produce incorrect results at run-time. What now
|
|
happens is that a run-time problem message is generated. For example,
|
|
"let L be the list of texts" can't be done because the possible texts
|
|
can't be iterated through. (In general not all descriptions are used for
|
|
iteration, which is why this isn't caught with a problem message in the
|
|
compiler.)
|
|
|
|
Bug fixed whereby a small number of obviously true conditions would produce
|
|
Inform 6 errors in compilation: for example,
|
|
```
|
|
if 1 is a number, say "Hi."
|
|
```
|
|
would fail. (What happens here is that Inform simplifies the proposition
|
|
until it becomes universal truth, then compiles that to an empty string of
|
|
Inform 6 code; which is correct for doing nothing, but not for testing nothing,
|
|
since it isn't a valid I6 condition. It now tests universal truth as "if (true)".)
|
|
|
|
Bug fixed whereby spurious problem messages, apparently though not actually
|
|
the result of memory being corrupted, would sometimes appear if there were
|
|
large numbers of very memory-costly definitions such as this one:
|
|
```
|
|
To dribble/drabble an/-- image-map in (WIN - a number) at (X1 - a
|
|
number) by/x (Y1 - a number) using (WDT - a number) wide data
|
|
of/from/-- from (IMG_MAP - a list of figure names) with tile-width
|
|
(W - a number) by/x tile-height (H - a number) pixel/pixels/px/--:
|
|
do nothing.
|
|
```
|
|
(It's quite expensive on memory to write definitions like this: it has nearly
|
|
200 possible wordings.)
|
|
|
|
Bug fixed whereby using "whether or not..." in a "now" would sometimes
|
|
cause a spurious internal error: e.g., setting a truth state variable "T" with
|
|
```
|
|
now T is whether or not location is Stage.
|
|
```
|
|
Bug fixed whereby the "Runtime problems" pages displayed in the user interface
|
|
have title numbers which are out by one. Thus the explanation page for
|
|
"P17 - Can't divide by zero" was headed "P18 - Can't divide by zero"; which
|
|
was needlessly confusing, though it did no harm otherwise.
|
|
|
|
Bug fixed whereby definitions of phrases given as inline I6 code would not
|
|
properly cast word values to pointer values where necessary. For example...
|
|
```
|
|
To announce (event - indexed text):
|
|
(- print "I declare ", (INDEXED_TEXT_TY_Say) {event}, ".^"; -).
|
|
When play begins, announce "Saturnalia".
|
|
```
|
|
...would not work because "Saturnalia" would be expanded into {event} as
|
|
text rather than indexed text. This looks like an obscure bug, but in fact
|
|
caused some phrase definitions in the Standard Rules to go wrong, e.g.,
|
|
```
|
|
let L be a list of indexed text;
|
|
let L be {"oranges", "apples", "bananas"};
|
|
add "pears" to L;
|
|
```
|
|
would create L having three indexed texts and then one unindexed one, because
|
|
the inline definition of "add ... to ..." was failing.
|
|
|
|
The (+ ... +) syntax for embedding I7 source text within I6 code was previously
|
|
not allowed in I6 inline definitions of phrases, which was an odd anomaly,
|
|
because it was allowed in other I6 inclusions. It's allowed now.
|
|
|
|
Bug fixed whereby the literal Inform 6-to-7 escape "(+ V +)", where V is a
|
|
value stored on the heap, produced an attempt to block-copy an independent
|
|
instance of V, rather than producing a pointer to the existing instance;
|
|
this, in particular, making it difficult to use the notation for global
|
|
variables holding indexed text, and the like.
|
|
|
|
Bug fixed whereby the literal Inform 6-to-7 escape "(+ A +)", where A is an
|
|
adjective, would produce I6 code which failed to compile, rather than the
|
|
name of the routine to test the adjective. Since Inform 6 is typeless,
|
|
there's no good way to choose which sense of the adjective is meant, if
|
|
several exist for different kinds of value (as for instance with the
|
|
adjective "empty"). The convention is: the meaning for objects, if there
|
|
is one; and otherwise the first-declared meaning.
|
|
|
|
### Equations, units and arithmetic
|
|
|
|
Bug fixed whereby printing units scaled by factors which aren't powers of 10
|
|
tended to produce somewhat wildly approximate results - for example, that
|
|
printing the value "90 min" in the unit "hours" would produce "1.36 hr".
|
|
Integer arithmetic makes this necessarily only an approximation, but the
|
|
new algorithm is better; for example, 90 seconds is rendered as 0.0010418
|
|
days, the true figure being 0.0010416666...
|
|
|
|
Bug fixed whereby numerical parts of literals which were both optional and
|
|
had optional preamble would sometimes match if the preamble was there but
|
|
the number wasn't, and would sometimes not respect the optionality: for example,
|
|
```
|
|
A die roll is a kind of value. 3d20+9 specifies a die roll with
|
|
parts dice, sides (without leading zeros), adds (without leading zeros,
|
|
optional, preamble optional).
|
|
```
|
|
...would allow "2D6+2" and "2D6+" but not "2D6" in typed commands; it now
|
|
allows "2D6+2" and "2D6" but not "2D6+".
|
|
|
|
Bug fixed whereby units given in singular and plural forms would sometimes
|
|
have only the singular form used in saying, e.g.,
|
|
```
|
|
An age is a kind of value. 1 year old (singular) or 2 years old (plural)
|
|
specifies an age. Every person has an age. Suzie is a woman. Suzie is
|
|
8 years old.
|
|
```
|
|
would result in "[the age of Suzie]" being "8 year old", not "8 years old".
|
|
|
|
### Understanding
|
|
|
|
Bug fixed whereby commands using numbers spelled out in digits as noun
|
|
phrase determiners wouldn't always work: e.g., TAKE FIFTEEN PLANTS would
|
|
be recognised, but not TAKE 15 PLANTS.
|
|
|
|
Bug fixed whereby the Understand token "[any ...]" would ignore any
|
|
constraint made about visibility in the "..." part; for example, "[any
|
|
person who is not visible]" would be read as "[any person]".
|
|
|
|
Bug fixed whereby the pronoun IT would sometimes wrongly be set during
|
|
play to the identity of a backdrop item which, though present, was not
|
|
explicitly mentioned; for instance, IT might be set to the sun in some
|
|
outdoor room.
|
|
|
|
Bug fixed whereby understanding units which contained mixed case lettering
|
|
in their notations didn't always work on the Z-machine; for instance,
|
|
```
|
|
100kHz specifies a frequency.
|
|
```
|
|
would lead to commands like "tune to 79kHz" not being recognised.
|
|
|
|
Bug fixed whereby an empty player's command (resulting from the player simply
|
|
pressing enter instead of typing), which then produces an empty snippet, would
|
|
result in run-time problem messages if this were matched against. That made
|
|
it difficult to write rules like:
|
|
```
|
|
Rule for printing a parser error when the player's command includes
|
|
"please": ...
|
|
```
|
|
|
|
### Glulx issues, file I/O, figures, sounds
|
|
|
|
Bug fixed whereby handling of external files with the Glulx setting would
|
|
tend not to work after a game had been saved and then restored. (Particular
|
|
thanks to Erik Temple and Andrew Plotkin for helping with this.)
|
|
|
|
Formatting improved on the Problems page for the case of running out of
|
|
readable memory in the Z-machine. In 5Z71 the message for this was, due to
|
|
a text editor accident, full of words run together without spaces; which
|
|
"creates the alarming impression of a nervous breakdown" (Eric Eve).
|
|
|
|
### Spacing and printing
|
|
|
|
Bug fixed whereby a serial comma would wrongly be used when saying a list
|
|
which contained exactly two items, if the "Use the serial comma." option
|
|
is in force - thus "Starsky, and Hutch".
|
|
|
|
Bug fixed whereby printing numbers in excess of 1,000,000 "in words" would
|
|
describe them in thousands; Inform now uses the words "million" and "billion"
|
|
as necessary. (This only affects Glulx games, since the Z-machine can't hold
|
|
numbers that high.)
|
|
|
|
### Indexing
|
|
|
|
Bug fixed whereby links to extension documentation inside the application
|
|
would be broken if the extension's name or author included an apostrophe
|
|
(as in the case of "Poor Man's Mistype by Aaron Reed").
|
|
|
|
Bug fixed whereby rules such as "Instead of doing something other than
|
|
singing..." would appear in the Actions Index as if they affected singing but
|
|
not other actions, the exact reverse of the truth.
|
|
|
|
Bug fixed whereby certain built-in adjectives would have their indexed
|
|
Phrasebook definitions truncated by one word, though surprisingly often they
|
|
still made sense that way.
|
|
|
|
Bug fixed whereby tool-tips displayed when the mouse arrow hovers above a
|
|
map connection in the World index would show garbled names of rooms or
|
|
directions when these included accented characters.
|
|
|
|
### Testing commands
|
|
|
|
Bug fixed whereby the "Use predictable randomisation." option caused I6
|
|
errors in build 5Z71; it works again now.
|
|
|
|
The trace file has been abolished; in trace mode, Inform copies the same
|
|
information to the debugging log instead. (Only affects Inform maintainers.)
|
|
|
|
### Releasing, bibliographic data, and cBlorb
|
|
|
|
Bug fixed whereby, similarly, pasted code from extension documentation
|
|
examples would come out with accented characters garbled in the paste process.
|
|
Sorry about this: it was particularly bad for examples like "Cursillo Mini
|
|
Juego", supplied with the documentation for Sebastian Arg's Spanish extension.
|
|
|
|
Bug fixed whereby releasing with a website would sometimes produce web pages
|
|
with the wrong character encoding; typically with UTF-8 for the source text,
|
|
but with ISO Latin-1 headings.
|
|
|
|
Bug fixed whereby releasing with template websites was not working unless
|
|
the template was placed inside the application, which users should never
|
|
have to do.
|
|
|
|
## Mac OS X app
|
|
|
|
The user interface has been tidied up in a number of small but, we hope,
|
|
pleasing ways, and the menu structure should be easier to navigate,
|
|
especially for newcomers:
|
|
```
|
|
File Edit Format Play Replay Release Window Help
|
|
```
|
|
The preferences have similarly been reorganised, and the Settings panel is
|
|
more explanatory. Numerous features useful only for I6 projects are now
|
|
invisible for I7 projects, which makes the system much easier to learn.
|
|
(But it won't take experienced users long to find everything again.)
|
|
|
|
A new setting, for Randomness, makes it possible to fix the random numbers
|
|
generated within Inform so that repeat runs produce the same "random" outcomes,
|
|
which sometimes makes testing easier. (This only applies within the application,
|
|
and it's switched off by default; it never affects a Released story file.)
|
|
|
|
## Windows app
|
|
|
|
The code for the source tabs has been rewritten to make use of the open
|
|
source text editing component "Scintilla". This allows a number of missing
|
|
features to be implemented, and will allow further changes to support all
|
|
of the features available in the OS X version of the application.
|
|
|
|
Making a selection in the contents pane now causes the source pane to show
|
|
that selection only. The old behaviour, of showing the whole source but
|
|
going to the selection, can be obtained by holding down the shift key when
|
|
selecting.
|
|
|
|
Wrapped lines are now slightly indented by default, and new lines start
|
|
auto-indented to the same extent as the line above: both these options can
|
|
be disabled from the preferences dialog.
|
|
|
|
The new Format menu allows lines to be indented left and right.
|
|
|
|
Editing the skein now marks the project as being changed.
|
|
|
|
The background colours in the transcript now follow the same logic as
|
|
for the OS X application. The left hand column, showing the output
|
|
from the game, is coloured light blue if the output is the same as the
|
|
previous run-through of the game, and light red if the output now differs.
|
|
The right hand column, showing the "blessed" transcript, is coloured blue
|
|
if the transcript matches the game's output, red if it differs, and
|
|
yellow if it differs but only due to trivial whitespace changes.
|
|
|
|
The "Replay Commands Blessed in Transcript" option, which is on the new
|
|
Replay menu, now plays all skein threads that contain at least one blessed
|
|
knot. After playing, if any blessed knots fail to match, the skein shows
|
|
the first such knot.
|
|
|
|
On the new Replay menu are commands to show the last played command in
|
|
the skein and the transcript, and to change the selected knot in the
|
|
transcript to step through changed commands and commands for which the
|
|
transcript does not match the blessed text.
|
|
|
|
The new Release menu has commands to open the Materials folder in a new
|
|
Explorer window, and to export the game's iFiction record to a new file.
|
|
|
|
The Window menu has been re-arranged so that access to all tabs, and all
|
|
the Index sub-tabs, is available from sub-menus and shortcut keys.
|
|
|
|
Pressing F4 now shows the whole of the source text in the Source tab. This
|
|
is equivalent to bringing up the Contents view and clicking on the very
|
|
top heading.
|
|
|
|
## Linux app
|
|
|
|
The menus and dialogs have undergone various rearrangements similar to
|
|
those of the OS X version.
|
|
|
|
The Glulxe and Git interpreters that run in the Game tab have been updated
|
|
to version 0.4.5 and 1.2.6 respectively. Likewise, the Gargoyle system that
|
|
runs them has been updated to a more recent revision, which supports
|
|
hyperlinks, and copying and pasting from the Game tab.
|
|
|
|
The Documentation tabs now always show scrollbars, to prevent the "next"
|
|
arrow from changing places when you are paging through the documentation
|
|
quickly and land on a section that is short enough to fit on one page.
|
|
|
|
If an error message references an extension, then clicking on the arrow
|
|
next to it will now open the extension and highlight the offending line.
|
|
|
|
Various minor bugs and memory leaks have been fixed.
|