26.4. What's new in build 5U92 (September 2008)

| Chapter 26: What's New in Inform? |

| 26.4. What's new in build 5U92 (September 2008)

As this release was being prepared, King Tupou V of Tonga was crowned, but Nepal became a Republic; climbers were lost to avalanches on K2 and Mont Blanc; Australia became perplexed at winning fewer Olympic medals than Great Britain; the most wanted man in Greece, who had escaped from prison by helicopter, was recaptured; a 50-foot spider spent a week crawling at 2 mph across the Liverpool skyline, spraying random passers-by with water; and many journalists had to learn how to spell "Ossetia" at a time when they would rather have been watching the sports channels.

In the world of Inform, a set of related improvements was made to the way adjectives, nouns and verbs combine in descriptions. This lifted many restrictions which made talking about values less flexible than talking about objects, and showed the language gradually becoming more general. In addition, directions could now be created freely. All 110 issues arising from bug reports since build 5T18 were closed out.

See Conditions of things for creating more than one condition for the same thing, and for giving them better names

See Using new kinds of value in properties for making either/or and value properties for values

See During scenes for some benefits of this applying to scenes, in particular

See Defining new adjectives for defining the opposite of an adjective at the same time as the original

See Defining adjectives for values for examples of defined adjectives applying to values, and for the built-in adjectives positive, negative, even, odd, empty and non-empty

See Counting the number of things for counting the number of values matching some description

See Repeat running through for repeating through the values matching some description

See Lists of values matching a description for using "list of..." to bring together all values matching some description

See Existence and there for using "there is" or "there are" to talk about whether objects or values exist

See Directions for much improved facilities for creating new directions, like CLOCKWISE, STARBOARD or NNE

See Understanding kinds of value for the new Understand token "[a time period]", which matches text such as 20 MINUTES or AN HOUR instead of specific times of day like MIDNIGHT or 11:24 AM

See Blank rows for the adjectives "empty" and "non-empty" as applied to tables

See New rulebooks for the adjectives "empty" and "non-empty" as applied to rulebooks

See New activities for the adjectives "empty" and "non-empty" as applied to activities

See Lists and entries for the adjectives "empty" and "non-empty" as applied to lists

See Inform 6 adjectives for low-level ways to define new adjectives based on I6 code rather than I7 source text

See Inform 6 Understand tokens for a new low-level way to add an I6 general parsing routine as a token of Understand grammar

160
| Example Bowler Hats and Baby Geese Creating a category of scenes that restrict the player's behavior. |
RB

150
| Example Elsie A door that closes automatically one turn after the player opens it. |
RB

124
| Example Extra Supplies A supply of red pens from which the player can take another pen only if he doesn't already have one somewhere in the game world. |
RB

258
| Example Fabrication A system of assembling clothing from a pattern and materials; both the pattern and the different fabrics have associated prices. |
RB

360
| Example North by Northwest Creating additional compass directions between those that already exist (for instance, NNW) -- and dealing with an awkwardness that arises when the player tries to type "north-northwest". The example demonstrates a way around the nine-character limit on parsed words. |
RB

364
| Example Pizza Prince Providing a pizza buffet from which the player can take as many pieces as he wants. |
RB

75
| Example Versailles A mirror which will reflect some random object in the room. |
RB

39
| Example The World of Charles S. Roberts Replacing the ordinary compass bearings with a set of six directions to impose a hexagonal rather than square grid on the landscape. |
RB

    5U92 (10 September 2008)

    This build makes a set of related improvements to the way adjectives, nouns
    and verbs combine in descriptions. This lifts many restrictions which made
    talking about values less flexible than talking about objects, and shows the
    language gradually becoming more general. This brings only subtle (if nice
    to have) improvements for authors, but improves the coherence of the design
    of Inform. In addition, directions can now be created freely, fulfilling the
    last outstanding promise made in the January 2007 consultation document.
    There are miscellaneous minor improvements, and five months' worth of
    maintenance changes. All 110 issues arising from bug reports received up to
    7 September 2008 have been closed out.

    INFORM FOR WINDOWS

    Added a preferences dialog, allowing the tab size in the source panel to be set.
    Drag and drop in the source panels now follows the usual Windows conventions:
    	by default the operation is a move, and holding down the 'Ctrl' key
    	during the drag makes it a copy.
    Fixed a bug in the built-in Glulx interpreter that generated
    	spurious timer events.
    Accented characters in the user's name should no longer cause the compiler
    	to crash.

    INFORM FOR LINUX

    Internationalized all the strings in the user interface, so that translators
    	can if they wish translate these. (A Spanish translation has been started,
    	thanks to Ángel Eduardo.)
    The Documentation text will now still be visible when using a light-on-dark
    	desktop theme.
    The dialog that appears when you start the program can now be closed, in case
    	you started the program by accident.
    Bugs fixed that caused some preferences to revert to their default values
    	every time the application started.
    Bug fixed that caused a crash when deleting some items from the Skein.
    Various minor bugs and crashes fixed.

    NATURAL LANGUAGE

    Descriptions and adjectives have each been expanded in scope, so that many
    	kinds of value can now be handled in ways which previously only worked
    	for objects. Specifically:
    Either/or and value properties can now be given to any kind of value
    	with named, enumerated outcomes. So for instance:
    		A scene can be thrilling or dull.
    		A scene has a text called cue speech.
    	or:
    		Colour is a kind of value. The colours are red, blue and green.
    		A colour has a number called frequency. The frequency of a colour
    		is usually 130.
    	As with objects, the names of either/or properties act as adjectives
    	describing a scene.
    Descriptions can now talk about values as well as objects. So:
    		if N is an even number, ...
    		if the score is positive, ...
    		let L be the list of thrilling scenes;
    		repeat with S running through non-recurring scenes: ...
    		if more than three scenes are dull, ...
    	all now work. Repeating through and listing require that the possible
    	range of the kind of value is finite - so you can't write
    		let L be the list of numbers;
    	(which would have to be infinite). See the chart at the bottom of the
    	redesigned Kinds index page to see when repeating and listing are allowed.
    The same adjective can now have multiple independent meanings, and there is
    	no difficulty provided that these apply to different things. Thus a
    	definition of "fancy" for a colour would not obstruct a definition of
    	"fancy" for a door, for instance.
    The Standard Rules now define the following adjectives for values as built-in:
    		even, odd, positive, negative - for numbers
    		empty, non-empty - for texts, indexed texts, tables, rulebooks,
    			activities, and lists
    		recurring, non-recurring, going on - for scenes
    	(Note the six independent definitions of "empty" depending on context.)
    	"Recurring" used to be an adjective which could be used only when creating
    	a scene, as in:
    		Train Stopping is a recurring scene.
    	It is now an either/or property, which means we can change it at run-time:
    		now Train Stopping is non-recurring;
    Now that scenes can be described in flexible ways, we can use the "during ..."
    	clause of a rule flexibly, too. For instance:
    		Before going north during a dull non-recurring scene, ...
    	(Previously "during" could only name a single explicit scene.)
    There is now a short-hand way to define the antonym of an adjective, that is,
    	the name of its opposite. For instance, the Standard Rules include:
    		Definition: a number is even rather than odd if the remainder after
    		dividing it by 2 is 0.
    	The optional part here is "rather than odd", which saves us writing:
    		Definition: a number is odd if it is not even.
    	(Note that different meanings of an adjective can have different opposites.
    	We could, if we wanted, write
    		Definition: a stored action is empty rather than purposeful if ...
    	and then the opposite of "empty" would be "purposeful" in the context
    	of stored actions, but "non-empty" for the other cases above.)

    Inform has always supported a convenient quick way to create a property,
    	sometimes specific to a single thing, which have three or more named
    	possibilities:
    		A fruit can be citrus, berry, melon, or pome.
    	This actually makes a property called "fruit condition" and creates a
    	new kind of value whose possibilities are enumerated as "citrus", "berry"
    	and so on. The author often never needs to use the name "fruit condition",
    	because the adjectives "citrus", "berry", ..., are convenient enough by
    	themselves.
    	But because Inform forms the property name in this way, there's a
    	collision if two different ranges are created:
    		A fruit can be unripened, ripe, overripe, or mushy.
    		A fruit can be citrus, berry, melon, or pome.
    	In previous builds this prevented two such conditions from existing at once
    	for the same thing or kind. Inform now allows any number of conditions to
    	exist independently of each other; if the author supplies an explicit name,
    	that's used, and otherwise Inform automatically makes names. Thus:
    		A fruit can be early, summer or late.
    		A fruit can be unripened, ripe, overripe, or mushy (this is its
    		squishiness property).
    		A fruit can be citrus, berry, melon, or pome.
    	creates three properties, called "fruit condition", "squishiness" and
    	"fruit condition 2" respectively.
    	This means that an extension author can write, say,
    		A vehicle can be brand new, roadworthy, battered or wrecked (this is
    		its serviceability property).
    	without "using up" the eventual user's ability to make his own "vehicle
    	condition".
    	Conditions like these can be created for anything which can have a property,
    	and in particular for scenes and enumerated kinds of value as well as
    	for objects (see above).

    It is now possible to use "there", as in "there is" or "there are", to
    	talk about whether or not something exists. Here are some examples in
    	assertion sentences:

    		There is a room called the Shadow World.
    		There is a box in the Shadow World.
    		There is a jigsaw puzzle in the box.

    		A coin is a kind of thing. There are two coins on the crate.

    		Incrimination relates various things to various people. The verb to
    		incriminate (he incriminates, they incriminate, he incriminated, it is
    		incriminated, he is incriminating) implies the incrimination relation.

    		There is a man called Mr Darcy. There is a pair of boxer shorts which
    		incriminates Mr Darcy. There is a fishing rod incriminating Mr Darcy.

    	And here are some examples in conditions:

    		if there is a man, ...
    		if there are vehicles, ...
    		if there is nothing in the box, ...
    		if there are three coins in the box, ...
    		if there are exactly three coins in the box, ...
    		if there are at least three coins in the box, ...
    		if there is something incriminating Mr Darcy, ...
    		if there is nothing incriminating Mr Darcy, ...
    		if there are fewer than two things which incriminate Mr Darcy, ...

    	Note that

    		if there are three coins in the box, ...
    		if there are at least three coins in the box, ...

    	have the same meaning: if the number of coins in the box is four, then
    	there do exist three coins in the box, which is what these are testing.
    	"Exactly" is more precise:

    		if there are exactly three coins in the box, ...

    As some of these examples suggest, the handling of "nothing" has been
    	improved so that it can be used in a wider range of contexts, and a few
    	bugs have been fixed in the process. For instance, the following now works:

    		now nothing incriminates Mr Darcy;

    	And similarly for "nowhere", "nobody", "no-one" and even "no one" -

    		now nobody in the Temple is surprised;
    		if nowhere is dark, ...
    		if no one is in the Temple Annexe, ...

    It has always been legal to use "not all" in a condition - for instance,
    		if not all of the coins are in the box, ...
    	"Not every" has been added, so that this has the same meaning:
    		if not every coin is in the box, ...
    	And similarly, we can now if we wish write
    		if not more than four coins are in the box, ...
    	or (equivalently)
    		if not fewer than six coins are in the box, ...
    		if not less than six coins are in the box, ...
    	Those are the only determiners to which "not" can be applied. So this,
    	for instance, continues not to be allowed:
    		if not some of the coins are in the box, ...
    There was previously a hard limit of 32 on the maximum number of relations
    	"in groups" which could be created in any single compilation: this has
    	been removed and there is now no limit.
    The relation which tests whether two things are equal now has a name: it is
    	the "equality" relation. So for instance it's now possible to define -
    		The verb to be identical to implies the equality relation.
    	(There's no obvious reason for doing this, but it was anomalous that it
    	couldn't be done before.)
    When a verb is created in the form "to be able to...", as the Standard Rules
    	does with the line:
    		The verb to be able to see (he is seen) implies the visibility relation.
    	then the following prepositional forms can be used:
    		"to be able to see"
    		"to be unable to see"
    		"to be able to be seen by"
    		"to be unable to be seen by"
    	The last of these, "to be unable to be seen by", did not work in previous
    	builds, having been overlooked. So it is now possible to write, e.g.,
    		if Peter is unable to be seen by Paul, ...
    		if Peter had not been unable to be seen by Paul, ...

    DIRECTIONS

    Directions have been reformed. In earlier builds it was difficult to create new
    	directions (and the documentation officially said that this could not be
    	done at all); I6 hacks were needed, and the results sometimes failed.
    	Directions can now be created freely, or at any rate pairs of them can:

    		Turnwise is a direction. The opposite of turnwise is widdershins.
    		Widdershins is a direction. The opposite of widdershins is turnwise.

    	- To create a direction, a simple sentence in the form "X is a direction."
    		must be given.
    	- Each direction has to have a value for the "opposite" property, which
    		has to be another direction; these must be in matched opposing pairs.
    	- The maximum length of a direction name used to be 1 (i.e., they had to
    		be single words); now it is 3.
    	- The maximum number of directions used to be 16; now it is 100.
    	- New directions are exactly as good as old ones: for instance we can
    		write "to be mapped turnwise of", or use route-finding through new
    		directions.
    	- Each direction automatically makes a relation, the "mapping-turnwise
    		relation" (or similar), which is the meaning of "to be mapped
    		turnwise of". This enables us to define prepositional forms; for
    		instance, the Standard Rules includes the line:
    			The verb to be above implies the mapping-up relation.
    	- The I6 implementation beneath the surface is new: there are no "n_to",
    		"s_to", etc., I6 properties any longer; the "door_dir" property for
    		doors now holds a direction object, not a direction property as it did
    		in the I6 library; the map is stored in a flat array instead. See
    		the template file "WorldModel.i6t".

    MINOR NEW FEATURES

    Scenes can now be said - that is, if X is a scene, then "[X]" now expands
    	to the name of the scene.
    It is now possible to have "let" and global variables of the kind of value
    	"sound-name", which hold sound effects. (The default value for this is
    	a special silent sound, the playing of which has no effect, but which
    	is present in all compilations regardless of whether they use sounds
    	or not.) And similarly for "figure-name" and "external-file". "Scene",
    	which up to now could be held in a global but not a local variable
    	(an oversight) can now be either.
    Truth states (both of them) can now be understood, so actions can be made
    	which are applicable to them, and "[truth state]" is a valid Understand
    	token.
    The Understand token "[a time]" matches a time of day, such as "10:15 AM"
    	or "midnight". But the "time" kind of value can hold relative times as
    	well as absolute ones -- for instance, 10 minutes is a time, but it is
    	not recognised by "[a time]" since it isn't a specific moment in the day.
    	A new Understand token called "[a time period]" has been added for this,
    	so for instance
    		Understand "wait for [a time period]" as ...
    	would match WAIT FOR AN HOUR or WAIT FOR TWO HOURS 12 MINUTES.
    The handling of mixed-case notations has been improved - for instance, given
    		Acidity is a kind of value. pH 7 specifies an acidity.
    	the "p" will always be printed in lower case, and the "H" upper case.
    	Printing back always respects the case in the original specification;
    	but parsing is always case-insensitive.
    Repeating through tables used to carry the risk that if something in the body
    	of the loop changed the row selection, the loop would break, since it used
    	the row selection itself as an iterating variable. This has been corrected.
    	A "repeat through" loop can now be nested inside other "repeat through"
    	loops; the body of the loop can change the row selection without harm;
    	moreover, a "repeat through" loop preserves the row selection, so that
    	on exit, the same row (if any) is selected as was selected before the
    	loop began.
    When tables are sorted "in random order", blank rows are now automatically
    	moved to the bottom. The non-blank rows occur in a uniformly random order
    	at the top of the table.
    When "Include ... instead of ..." is used to replace a part or segment from
    	the I6 template, a subsequent "include... instead..." on the same part or
    	segment now overrides an earlier one. (In 5T18 both would be applied, but
    	this almost never led to valid I6 code, and it's hard to think of
    	circumstances when users would want that behaviour.) It continues to
    	be the case that "Include ... after ..." and "... before ..." allow
    	multiple inclusions attached to the same part or segment.

    INTERFACE TO I6 INTERNALS

    There are now two ways to specify that an adjective is defined at the I6 level:
    		Definition: a rulebook is empty rather than non-empty if I6 routine
    			"RulebookEmpty" says so (it contains no rules, so that following
    			it does nothing and makes no decision).
    	The part in brackets does nothing, but is the text used in the Phrasebook
    	index for the user's benefit; it should be a brief definition. The I6
    	routine should take one parameter, the value on which the adjective is
    	being tested, and should return true or false as appropriate.
    		Definition: a rulebook is exciting if I6 condition
    			"excitement_array-->*1==1" says so (it is really wild).
    	The condition is given as a "schema", in which the escape "*1" is
    	expanded to the value on which the adjective is being tested. (This is
    	usually faster than calling a routine, but in case of side-effects, the
    	*1 should occur only once in the condition, just as with a C macro.)
    The "translates into I6 as" verb now has another possible use: for Understand
    	tokens. This is how the Standard Rules sets up the new "[a time period]"
    	token, for instance:
    		The Understand token a time period translates into I6 as
    		"RELATIVE_TIME_TOKEN".
    	(The I6 routine of this name can be found in the Time.i6t template file.)
    	This might be of use to extensions which want to add very rich parsing
    	possibilities which break existing conventions.

    PERFORMANCE

    The run-time storage of relations, kind membership and the map has been
    	made slightly more efficient. The gain has been used to make projects with
    	"use memory economy" in force run a little faster - previously, memory
    	economy blocked Inform from generating faster searches through objects
    	by using precompiled linked lists. That still leaves a memory saving of
    	around 2.5K in a completely full Z-machine story file. This is not as
    	ridiculous as it sounds, since the Z-machine has only 64K of dynamic
    	memory to play with, and this tends to be the limiting factor on the
    	size of projects which Z can handle. A minimal I7 project needs 24K of
    	this, so a saving of 2.5K out of the remaining 40K represents room for
    	maybe a 6% larger design. (Of course for Glulx projects this is all
    	irrelevant - there are really no size limits at all.)

    Some users observed that the 5T18 build compiled more slowly, and this was
    	a large enough effect to make a considerable difference to novel-sized
    	projects (with 200,000-word source texts). This proved to be an accidental
    	side-effect of internal consistency checks only really needed when
    	debugging Inform itself. This has been fixed, and large projects should
    	once again compile at roughly the same speed as in 5J39 and previous
    	builds.

    MAINTENANCE

    Problem messages added for attempts to write constant values in notations
    	where the second or subsequent numerical element runs out of the legal
    	range, or where the total value exceeds the maximum or minimum range
    	which Glulx can hold. (There was already a similar check for Z-machine
    	projects - for Glulx, of course, the bounds are larger.)
    Similarly, run-time parsing of values in such notations is also checked
    	more carefully to see that it remains in range.
    Finally, the Kinds page of the Index now quotes the maximum possible
    	value for both Z-machine and Glulx use. (It previously quoted this only
    	for Z, thus giving a misleading answer if Glulx was used.)
    Problem message added to explain what's wrong when the source text tries to
    	provide command grammar for a word reserved as an Inform testing command,
    	such as SHOWME. (And the indexing of these reserved commands on the
    	Actions index page has also been improved.)
    Problem message improved when "try" is applied to something which ought to
    	be a valid action, but which isn't for type-checking purposes - for
    	instance,
    		try taking 22;
    Problem message added (in place of an internal error) to catch cases where
    	a verb is missing from a condition so that it otherwise forms a
    	description with no obvious subject:
    		if the player not carrying a thing, ...
    	(which of course is missing an "is".)
    Problem message added to block the use of "called" when it is being used
    	only to rename one specific item, e.g.,
    		if the Z-Boson Destructorator (called the gun) is carried, ...
    	Previously this sometimes worked, but sometimes didn't, and in any case
    	wasn't ideal from a stylistic point of view.
    Problem message added to block the use of implications based on information
    	not available at compile-time, such as:
    		A room in the Garden is usually lighted.
    	(Previously this disregarded the relation information - the "in the Garden"
    	part - and therefore wrongly read the sentence as "A room is usually
    	lighted", a valid but different implication.)
    Problem message added to catch attempts to equate two kinds of variable, as in:
    		The stored actions variable is a truth state that varies.
    	(This has happened because the user didn't realise that "stored actions
    	variable" was a general category of variables, and thus not a good name
    	to choose for a specific one. In 5T18 it produced an internal error.)
    Problem message added to object to saying that things are to be defined by
    	a table, but also saying how many there are (which may of course be in
    	conflict with the number of rows in the table):
    		Three berries on the bush are defined by the Table of Tasty Berries.
    	The word "three" is either redundant or contradicts what the Table says,
    	and the problem message says it should be removed, e.g., by writing:
    		Some berries on the bush are defined by the Table of Tasty Berries.

    Run-time problem message added to explain why only things can be moved during
    	play (not for instance rooms, regions or directions). (Although people very
    	seldom try this deliberately, they do sometimes accidentally ask for it
    	because of misunderstandings about short forms of names of rooms.)

    Bug fixed whereby a small number of rules formed like this one:
    		Before printing the name of an object: say "Print."
    	would cause a spurious internal error; and similarly for rules such as
    		Before listening to nothing: ...
    	which can't in fact be useful (because "listening" always takes a noun),
    	but ought not to trip over the compiler; and similarly for clauses
    	such as:
    		Instead of going east by nothing: ...
    	in which optional details are added to an action (and these can indeed
    	be useful: this example means going east on foot, i.e., with no vehicle).
    	This was all one single bug, and was the one most experienced by users
    	of 5T18 - apologies.
    Bug fixed whereby and "[end if]" adjacent to an "[or]" in text, as here:
    		"[one of][if the location is Lab]Lab[end if][or]blah[at random]"
    	would cause an I6 compilation error. This was another very popular one.
    Bug fixed whereby "try" with an action which applies to a topic would not
    	work if applied to a snippet variable, so, for instance,
    		try asking Bob about the topic understood;
    	would fail.
    Bug fixed whereby large rulebooks would in some cases misfile rules which
    	depended on a single action _not_ being the current one, such as:
    		Before doing something other than examining to the mercenary: ...
    	(While this was a serious bug, it occurred only rarely, depending on
    	complicated combinations of other rules also being in force.)
    Bugs fixed to do with table columns holding indexed text, so that some attempts
    	to look for corresponding values, or to search for values, or to copy a
    	non-blank value into a blank, would fail with spurious run-time problem
    	messages.
    Bug fixed whereby sections replacing those in extensions:
    		Section 1 - New foo (in place of Section 1 - Foo in Bar by Tina Banana)
    	were not in fact always doing so in 5T18; and relatedly, when such
    	heading tricks were used, were sometimes causing source text to be lost
    	from the main text, resulting in spurious problem messages complaining
    	that no room had been created. (It had, but in a sentence wrongly removed.)
    Bug fixed whereby paragraph spacing would go wrong - usually with the expected
    	gap between paragraphs going missing - in cases where a text substitution
    	is defined which itself includes a "[paragraph break]" substitution. For
    	instance, redefining:
    		To say p -- running on:
    			say paragraph break.
    	ought to give "[p]" exactly the same effect as "[paragraph break]", but in
    	5T18 the spacing after "[p]" would in some cases go missing.
    Bug fixed whereby "resume the game", a phrase to be used in the "when play
    	ends" rulebook to cause it not to end but to carry on after all, had
    	stopped working. Particular apologies for this: we hadn't realised that
    	nothing in the 5T18 test suite verified its behaviour.
    Bug fixed whereby the "carrying capacity" for a container or supporter could
    	not be read without run-time problem messages if it was not set explicitly
    	in the source text. (It should have, and now does, default to 100.)
    Bug fixed whereby a container called "sack" would sometimes wrongly be treated
    	as if it were a player's holdall, if it were carried alongside a genuine
    	player's holdall.
    Bug fixed whereby a rule depending on something having happened for a small
    	number of times only would not always apply if the action is silent, e.g.,
    		Instead of taking the top hat less than three times:
    		say "The top hat resists!"
    	...would fail to apply if the top hat were being taken silently as a
    	result of a command like WEAR HAT. (Apologies: this bug was introduced
    	inadvertently as part of a bug fix made in 5T18, and did not occur in
    	earlier builds.)
    Bug fixed whereby the Standard Rules read
    		A door is never pushable between rooms.
    	instead of
    		A backdrop is never pushable between rooms.
    	(Both are true. In 5T18, the sentence was given for doors twice and for
    	backdrops not at all.)
    Bug fixed whereby the Standard Rules wrongly put the "switch the story
    	transcript off rule" in the "carry out switching the story transcript
    	on rulebook", not the one for "...off", so that in 5T18 the transcript
    	once started couldn't be stopped.
    Bug fixed whereby table sorting might fail if the table contained consecutive
    	blank rows within the body of non-blank rows.
    Bug fixed whereby the phrase
    		let maximum score be a number;
    	which fails because "maximum score" is already a global variable, so can't
    	be a temporary one as well, would give both a problem message and also an
    	internal error. It now just gives the problem message.
    Bug fixed whereby source text such as:
    		The Lab is a room. The barrel is a vehicle in the Lab. Sir John is a
    		man in the barrel. The player is Sir John. The player is in the barrel.
    	would create a bogus "yourself" object in the barrel, other than Sir John.
    Bug fixed whereby Understand grammar using "[any ...]" would wrongly match
    	all items within those specified, as well as the items themselves. For
    	instance, "[any adjacent room]" would match not just the rooms, but also
    	their contents. Apologies for this bug, which was introduced by accident
    	in the template rewrite for 5T18.
    Bug fixed whereby rules depending on actions which involve the text of the
    	player's command would sometimes throw internal errors if they also
    	required the use of named "Understand" tokens which weren't used in any
    	of the ordinary command verb grammar. For instance:
    		Understand "i7" or "inform" or "inform 7" as "[inform]".
    		After asking Edsger about "[inform]":
    			say "Projects promoting programming in 'natural language' are
    				intrinsically doomed to fail."
    Bug fixed whereby "does the player mean" rules would sometimes disambiguate
    	the second noun of an action as if it were the first, in cases where
    	the action uses "[things inside]" or "[other things]" as the first token
    	(which the inserting action does, in particular). The documentation does
    	warn that this might not work; it will now sometimes work, with care.
    Bug fixed whereby a table with a number but not a name (say, "Table 5") could
    	not be referred to elsewhere in the source in the same form (e.g.,
    	"The utensils are defined by Table 5").
    Bug fixed whereby "does the player mean" rules would not be applicable to
    	going actions implied by commands consisting of a direction alone, such
    	as SOUTH.
    Bug fixed whereby, in complicated circumstances, two ordinarily identical
    	things are wrongly considered still identical even after one has
    	changed its property value for a property declared as describing them.
    	(But only where this property is inherited from a mutual kind, which
    	in turn has other "Understand" grammar defining it.)
    Bug fixed whereby releasing a project with both a website and auxiliary files
    	would produce links in the website which, though working for some browsers,
    	failed for others, and which were local "file:" links rather than "http:",
    	so that the result would not work when uploaded.
    Bug fixed whereby an UNDO which takes us back to a position where the player
    	is in darkness would print the location as "(darkness object)" rather
    	than running the appropriate activity to describe darkness.
    Bug fixed whereby "Use authorial modesty" did not always work when given
    	in the main source text of a work by an author wanting to be modest
    	about his own extensions, included from it.
    Bug fixed whereby negative values of literals would sometimes be printed
    	incorrectly (e.g., "-10.123" might be printed "-10.00-123").
    Bug fixed whereby in rare cases the text of previous commands might be
    	mingled with the text of a literal value being read in the current
    	command.
    Bug fixed whereby conditions for start and end of scenes would not properly
    	work if they needed to manipulate indexed text, lists or stored actions,
    	either throwing spurious problem messages or simply failing to match.
    Bug fixed whereby, similarly, conditions for start and end of scenes would
    	throw spurious internal errors if they contained table lookups.
    Bug fixed whereby complex specifications of "in the presence of" people
    	which involve callings or manipulate similarly complicated values would
    	cause internal errors.
    Bug fixed whereby relations applied to kinds rather than instances would in
    	some cases throw an internal error rather than generate a problem message
    	as being too unspecific:
    		A supporter usually allows sitting.
    Bug fixed whereby memory allocation would sometimes fail, in Glulx, when
    	existing memory was sufficient but too fragmented to hold a large single
    	block of data.
    Bug fixed whereby Inform would refuse to create "let" variables called "nd",
    	"st" or "th". (Exercise for the reader: can you guess why?)
    Bug fixed whereby "Understand ... when ..." sentences would sometimes, if
    	the condition was invalid, throw an internal error as well as a problem
    	message.
    Bug fixed whereby the sentence
    		Here is everywhere.
    	would crash Inform rather than produce an outraged problem message.
    	(Yes, somebody tried this.)
    Bug fixed whereby extension documentation would be wrongly punctuated around
    	displayed example source text which contained explicit I6 inclusions,
    	with a spurious "-)" to close the I6 inclusion, added at the wrong point.
    Bug fixed whereby spurious "details" icons appeared after the names of kinds
    	in the Lexicon index.
    Bug fixed to do with the status line sometimes disappearing on the Z-machine.
    Bug fixed to do with cursor movements in unusual font sizes in v6 of the
    	Z-machine.
    On Glulx works only, the "emphasised" type style now has the style hints
    	weight 0 and oblique 1 set automatically when Glulx starts up: the point
    	of this is that I7 uses this style to implement the text substitution
    	"[italic type]". (Yes, yes, so the 5T18 change log made the same promise.
    	But with any luck it will work this time.)

    EXAMPLES AND EXTENSIONS

    Examples:
    	Added "Fabrication" to demonstrate the use of values which themselves have
    		properties.
    	Added "Bowler Hats and Baby Geese" to demonstrate the use of scenes with
    		properties.
    	Added "Elsie" to demonstrate a sliding door that closes automatically
    		after being open for one turn.
    	Added "Versailles" to demonstrate a mirror the player can look into.
    	Added "Pizza Prince" to demonstrate a near-infinite supply from which
    		the player can go on taking instances.
    	Added "Extra Supplies" to demonstrate a supply from which the player
    		can take one instance at a time.
    	Added "North by Northwest" to demonstrate compass directions between
    		the usual set, and how to deal with the nine-character limit on names.
    	Added "The World of Charles S. Roberts" to demonstrate a hexagonal
    		direction system.
    	Modified "Copper River", "One Short Plank", "Mr. Burns' Repast", "Yolk
    		of Gold", "Depth", and "Xylan" to use the new "there is..." syntax in
    		places where the old syntax seemed a bit stilted.
    	Modified "Solitude" to correct some errors in the comments caused by an
    		over-zealous search and replace when truth states were introduced.
    	Modified "Copper River" to list all objects explicitly while taking
    		inventory, even if they are otherwise referred to as "assorted dull
    		items".
    	Modified "Bumping into Walls" to get rid of some inelegant grammar in
    		the definition of viable directions, which is no longer necessary
    		because of syntax improvements.
    	Rewrote "Fore" completely to take advantage of new direction-defining
    		abilities, rather than presenting the rather hackish methodology
    		originally on offer.

    Extensions:
    	"Glulx Text Effects" updated to deal with an indentation bug. The version
    		number is now 3.
    	"Glulx Entry Points" updated to handle a bug introduced by the treatment
    		of templates. The version number is now 6.
    	"Locksmith" edited to bring conditional syntax in line with the new
    		Pythonesque standard, and (more importantly) to give explicit names
    		to a couple of rules that still lacked them. Version number is now 7.

    Recipe Book:
    	Expanded the contents of the section on ending the game to lay out more
    		of the ways in which the final text can be altered.

Previous | Contents | Next