mirror of https://github.com/ganelson/inform.git synced 2024-07-03 07:24:58 +03:00

Graham Nelson fa6d9f95a5 Migrated archive of past release notes

2022-08-08 08:59:55 +01:00

35 KiB

Raw Blame History

Release notes for Inform v4.2 (builds 4U65 and 4U67)

This release was made on 7 May 2007, before Inform was open-sourced. At that time versions of Inform were identified by build codes in the form NLNN.

This is part of the historical archive of release notes.

Overview

This build once again fixes all bugs reported up to 22 April, but in fact few were found in 4S08; and it removes a hole in the type-checking system, to do with phrases to make decisions, but this will have affected few users. The main aim is an across-the-board reform of how actions are handled and implemented in Inform. Proposals (6.33), (6.35), (6.37) and (6.39) from the January 2007 consultation document are all carried through. It is now much easier to create actions which work equally for all actors, and which need a complicated interaction of rules to work.

Language

Documentation, examples and extensions

Examples

New example "Croft" added to demonstrate action variables.
The now usually unnecessary word "trying" (see above) has been removed from most of the examples involving actions.

Mac OS X app

Build 4U67, for Mac OS X only, is identical to 4U65 except for the OS X user interface, in which the secondary controls in the various different panels have been harmonised into new-style bar icons. (In addition, new forward and back arrows provide the long-requested "browser-style history buttons".) We are releasing this now rather than waiting because it also fixes the minor but annoying bug to do with selecting detail pages in the Actions index (see the 4U65 release notes).
A minor bug in the OS X application means that viewing the new details pages for actions in the index will cause the application to think we have switched to the Documentation panel, with the effect that the tabs normally present for switching between index pages will disappear: switching panel and going back to the Index will cure this. Apologies for the inconvenience: the bug will be fixed in the next release.
Fixed bug in 4S08 for OS X only which caused Inform to create spurious empty Materials folders in cases where this was not really necessary (although this did no harm, and could not damage any existing Materials folder).

Windows app

Skein and Transcript improvements:
A single click on a red badge in the skein is enough to go to the knot in the transcript, rather than a double click as before.
Any knot can be shown in the transcript by selecting "Show in transcript" from the context menu or clicking on a red badge, not just knots in the current thread.
A knot selected in the above way is now indicated in the transcript by having a thin blue border around it.
The last played knot is now indicated in the transcript by having a yellow border around it.
The thick line in the skein now always shows the thread that is visible in the transcript.
The new menu item "Play All Blessed" plays through all threads that end in a knot with an expected transcript.
If the expected text in the transcript tab is double clicked on, the window goes into edit mode, in which the expected text can be amended.
When editing the expected text in the transcript tab, holding Ctrl+Enter adds a carriage return to the expected text.

Linux app

i7 now has the -r story-directory and -c story-directory command-line options. These force it into non-interactive mode, where it compiles or releases the story file and exits. They can be combined with -s (for settings) and -p (for prefix of installed inform7 package); see the man page for details. It is hoped that these options will be useful for IDE authors.

Rulebooks

Variables can now be given to rulebooks. For instance:
```
	The every turn rulebook has a number called accumulated bonus.
```
creates a variable called "accumulated bonus", which holds a number. Such variables are initialised to the default values for the relevant kind when the rulebook starts, and are accessible only within rules belonging to that rulebook (or which have historically belonged to it, but been displaced by a "listed in... instead" sentence). Rulebook variables have a namespace of their own: so their names can freely clash with those of things, rooms, etc.) If the rulebook should recursively start again within itself, each new run-through of the rulebook has its own set of variables. In short, they behave exactly like "let" values except that they last for a whole rulebook, not an individual rule or To phrase. (This was (6.33) in the January document.)
As we can now add a potentially unlimited number of new clauses to the descriptions of actions to say whether or not rules apply (see below), Inform must refine its method for sorting rules in order of how specific they are. The rules on "going" are unchanged and we believe that no pair of existing rules not using the new features will have their orderings changed in any rulebook. Rules which do use new clauses are now subject to a new sorting principle, "III.2.4 - Action/Where/Other Optional Clauses". This follows the standard conventions.

Activities

Variables can also now be given to activities. These are created just before the "before" rules for the activity begin, and destroyed when the "after" rules end (or when the activity is abandoned, though this is a rare occurrence). They are visible to the rules for that activity, and nowhere else, and again they have their own namespace; again, if the activity should happen a second time within its first run, that second occurrence gets its own copies of the variables. A simple example of an activity variable:
```
	Analysing something is an activity.
	The analysing activity has a text called first impression.
	Before analysing: now the first impression is "unremarkable".
	Rule for analysing someone: now the first impression is "living tissue".
	After analysing something (called the sample):
		say "Your professional opinion of [the sample] is that it is
		[first impression]."
	Instead of examining something (called the sample):
		carry out the analysing activity with the sample.
```
If an activity is called X, we can now also refer to it as "the X activity" for clarity's sake. (As with rulebooks called Y, which can already be called "the Y rulebook". This has been done in order to make the syntax for creating activity variables more explicit in its intentions.)

Actions

Variables can also now be given to actions. These are created just before the "before" rules for the action begin, and destroyed when the action ends (by whatever means that should happen). If one action is interrupted by another, the new action gets its own copies of these variables. The names of action variables are visible only within rules in action-based rulebooks ("before", "carry out", etc.). But note that every action's variables are visible to every such rule - as has to be true, because we can have "before" rules which take effect for many different actions, for instance, and such rules might need access to any of their variables. In consequence, there is only one namespace for all action variables: if two different actions name a variable "item", say, clashes will occur. As a result, action variables should be named in a way marking out to which action they belong, and we recommend including the past participle of the action name - so for instance, "vehicle gone by", "door gone through", "sticky item taken", etc. A simple example of an action variable:
```
	The singing action has a text called the lyric sung.
	Before singing: now the lyric sung is "Destruction of the empty spaces
		is my one and only crime."
	The block singing rule is not listed in any rulebook.
	Carry out singing: say "You cheerfully warble: [quotation mark]
		[lyric sung][quotation mark][paragraph break]".
```
One more warning: since any action-based rule can see all the action variables, it's possible to refer to the variables for an action which is not actually happening. For instance:
```
	Before doing something when the lyric sung is "Yesterday..."
```
would compile without problems, but fail at run-time when any action other than singing was tried.
In the above example, the variable "lyric sung" was set in a before rule. In practice, though, it might be needed by other before rules, and then the order of operation of before rules would become uncomfortably important. To get around this, a new rulebook has been created: the "setting action variables" rulebook. For instance, we could write:
```
	Setting action variables for singing:
		now the lyric sung is "Mystifying eyes."
```
This rulebook is run through before even the before rules, and could be used to detect the context and set variables accordingly: but it does not have any power to stop or change the action, and its rules should ideally say nothing and do nothing other than set rulebook variables, please. (Such a rulebook must work for any actor, not just the player: so if the idea is to set variables based on the local situation where the action will take place, look to see where the "actor" is, not where the "player" is.)
There is a new kind of value built into Inform: "action-name". (As its hyphenated name suggests, this is primarily intended for internal use, but there are no restrictions on it.) An action-name identifies the particular action but none of the nouns attached: it corresponds to numerical Inform 6 values such as ##Go. When an action called X is created, the constant value "the X action" is also created: thus "the looking action", "the putting it on action", etc., are all valid constant values of this kind. (For those who wish to make variables properties, table columns, etc., of this kind, the default value is "the waiting action", that being a sort of zero among actions.)
It is now legal to declare a "specification text" for an action, analogously with kinds, and this is used in the Actions index.

Action-Based Rules

Inform source text describes actions with so-called "action patterns", and these specify among other things who the actor must be. Up to now, there have only been two ways to specify the actor, as in these examples:
```
	taking a container
	X trying taking a container
```
The former means the actor must be the player: the latter allows any description X so long as X is not the player. Thus,
```
	someone trying taking a container
```
allows the actor to be any person in play except the player. This made it impossible to write a single rule applying to any actor equally. A new third form has been added to allow for this:
```
	an actor taking a container
```
For instance, we could write:
```
	Instead of an actor jumping: ...
```
This implements proposal (6.35) in the January document.
The second form of actor description above is often found to be clumsy:
```
	Before X trying taking a container...
	try X trying eating the cake...
```
Here the word "trying" is cumbersome. In a few cases it is needed to make the text unambiguous, and if the description of the actual action is the name of a kind of action, it is positively a good thing:
```
	Before X trying risky behaviour...
```
but very often it is a nuisance. The word is now optional provided that:
- (a) the actor is described using a description ("someone", say, or "Captain Haddock") or a variable name;
- (b) the eventual action is something explicit (like "taking...") rather than a named kind of action (like "risky behaviour");
- (c) the action is being used in a "try" (or other phrase with an action as its parameter) or as the premiss for a rule. In other cases, "trying" will remain obligatory, but in practice they will be very few. The Examples for 4S08 contained some 120 uses of "trying" between them: this reform enabled every "trying" to be removed except one,
```
	Instead of someone trying disorderly conduct in the presence of
		the policeman:
```
where it would clearly not be grammatical to remove it anyway.
As mentioned above, every action variable is visible from every action rule. But so far they have all been specific in nature to particular actions: for instance "lyric sung" makes no sense for non-singing actions. But we can also make general action variables, also visible from all action rules, by creating variables for the "action-processing rulebook". This is really a concept which has always existed - "noun" and "second noun" are exactly such variables. Joining them henceforth is "actor": the person trying the action.
Thus if existing source text contains references to something called simply "actor", perhaps in a work of IF about the theatre, it may now fail to work. (Something like "stage actor" or indeed "thespian" would of course work instead. When we made this change it affected only one of the Inform examples: Ballroom, which was previously using "actor" as a let value in just such a rule - we changed it to read "dancer" instead.)
Although the following is a bug fix, it is worth recording as a change in behaviour. The room description at the end of a going action to a new location is not technically the result of a looking action. (It doesn't quite do a LOOK: for instance, it suppresses the body text for a room visited before, and the paragraph spacing is different, etc.) In principle, then, during such a room description the action ought still to be "going", but that means that a rule such as
```
	After printing the name of a person while looking: ...
```
would not take effect, which is clearly incorrect. This bug has been fixed and such a rule now takes effect.
It has always been the case up to now that the "going" action had a special status in Inform: it allowed special clauses such as "... through ..." (for the door gone through) not allowed for any other action, and this behaviour was hard-wired into the syntax of the language. The ability to create such clauses is now available to any action. For instance, the following adds "...into..." and "...onto..." to Inform's syntax for writing rules about dropping:
```
	The dropping action has an object called the container dropped into
		(matched as "into").
	The dropping action has an object called the supporter dropped onto
		(matched as "onto").
	Rule for setting action variables for dropping:
		if the actor is in a container (called C), now the container dropped
			into is C;
		if the actor is on a supporter (called C), now the supporter dropped
			onto is C.
```
What's new here is the "(matched as...)" clause attached to the action variable. We have declared that "... into X" should test to see if the action variable "container dropped into" matches X, and similarly for "onto". As a result, we can now write:
```
	Instead of dropping something onto something, say "Don't drop things
		onto platforms or ledges."
	Instead of dropping something into an open container, say "Don't drop
		things into open containers."
```
(Note that these clauses are only descriptions of the action: it makes no sense to write
```
	try dropping A onto B;
```
since the question of whether or not B is dropped onto depends on where the player is, and is not something we can choose. Note that this is exactly the same position as "going" was in before: for instance,
```
	try going east from the Ballroom;
```
was and is not allowed, because the question of whether it's from the Ballroom or not depends on where the player happens to be.) This change implements proposal (6.37) in the January document.
In previous builds, Inform has used a messy compromise in its handling of check, carry out and report rules. These sometimes look to the user as if they are single rulebooks: as if "check", for instance, is on a par with "before" (which is indeed a single rulebook). In fact, for efficiency reasons, there are individual check rulebooks for each action, as shown by the diagram at 12.2 in the documentation. Up to now, it has been legal to write a rule like
```
	Check doing something: ...
```
even though this clearly can't belong to any rulebook in the diagram at 12.2. What was actually happening was that the checking stage used both a single generic "check" rulebook and a family of rulebooks with names like "check taking". Rules defined in the Standard Rules would always go into the individual rulebooks, but most (not quite all) rules created by the user would end up in the generic "check" rulebook. While this gave a pretty convincing illusion that all was well, it led to violations of the rule-sorting principle that specific rules come before generic ones ("check doing something" would come before "check taking an open container in the presence of a vehicle when the time of day is 11:13 AM", say), and attempts to explicitly list rules into these rulebooks could have odd consequences because of misunderstandings between "check" and "check taking", say. Moreover, for implementation reasons, the actions in the Standard Rules created check, carry out and report rulebooks with funny properties which no other rulebooks had. All of this has been abolished:
- the position is now strictly as shown in the diagram at section 12.2: there are now no generic "check", "carry out" or "report" rules.
- all such rules are now placed into rulebooks specific to the actions they belong to. Thus, e.g.,
```
	Check an actor going: ...
```
  is filed in the "check going" rulebook.
- problem messages now result from creating rules such as
```
	Carry out doing something: ...
	Report dropping or taking a container: ...
```
  which cannot be filed into single unambiguous rulebooks;
- the Standard Rules now use the same action-creating syntax and semantics as anyone else. The one respect in which "check A", "carry out A" and "report A" rulebooks are unlike other rulebooks is that rules in them do not check that the action is indeed A. This is partly because there is no need (if we are looking at the check taking rulebook, the action must be taking) but mostly so that a single rule can be explicitly placed in the check (etc) rules for more than one action at once. For instance, if we write:
```
Check an actor taking (this is the hypothetical rule): ...
```
and then say The hypothetical rule is listed in the check removing it from rulebook. the rule can be effective in both rulebooks: if it tested to see that the action was taking, it would never have any effect in the check removing it from rulebook, and thus it would be impractical to share rules between more than one of these rulebooks - which would be inconvenient to the Standard Rules, and also to extensions wanting to consider or abide by rules from one action while processing another.
We appreciate that this will cause a small amount of pain (we had to change 7 not-specifically-action-worded rules in the Inform examples) but we think the pain is worth it for the simplification resulting, and most such rules are fairly easy to recast. For instance, Carry out doing something: ... can probably become Instead of doing something: ... continue the action. without any practical change in the outcome.
Detailed index pages on individual actions now appear in the Index. We hope these give a truer picture of what happens to any given action, by showing every rule which can affect it, and making the sequence more explicit.
Problem message added to catch action descriptions which name unknown actors (e.g. "Xerxes the Otherwise Never Mentioned examining the bucket" was being read as simply "examining the bucket").

The Built-In Actions

Inform provides about 70 built-in actions which form part of the model world. (That is, not counting out-of-world actions such as saving the game.) In previous builds these have been implemented using a special action definition syntax reserved for use of the Standard Rules only, and consisting essentially of tables of rule names against I6 identifiers: all the rules involved were implemented by I6 code. This was bad because it meant that the built-in actions were treated as special in all sorts of ways (not a very clean design technique) and because it was quite hard to work out how the built-in actions worked, since one needed to be able to puzzle out the I6 code at the bottom of all this. On the other hand, it had the advantage of speed, since Inform did not have to read and compile the built-in action rules from I7 source text. As discussed in the January document at (6.39), there are trade-offs here, but we have now bitten the bullet and reimplemented all of the (not out of world) actions in I7 source text.

The Going Actions

The "going" action is the second most complex in Inform ("looking" probably takes the palm) and the re-implementation in I7 has turned up two bugs which have also been fixed. In addition, numerous rules have been renamed or removed:
- the can't go through concealed doors rule has been renamed the can't go through undescribed doors rule ("undescribed" being the I7 word for what I6 called "concealed");
- the following rules have been abolished:
```
	set up going rule
	check to see if in a vehicle rule
	determine direction property rule
	print textual map connections rule
	consult routine map connections rule
	determine what's through door rule
```
  These all clumsily worked out what we now regard as action variables, except for the textual and routine map connections rules, which were to provide backwards compatibility with traditional I6 use of the map properties, which I7 doesn't recognise or use; however, we retain the
```
	determine map connection rule
```
  whose purpose now is to recalculate the "room gone to" variable immediately before the "can't go" check. (This is done because people often use before rules to modify the map, in order to make dynamic map structures which respond to movement.)
- in the check rules, the can't go that way rule has been moved to after the rules checking on undescribed and closed doors: after all how is one to know that a door leads nowhere if it is closed? But if you do succeed in opening such a door and try going through it, the traditional I6 response "You can't, since the X leads nowhere." has been restored in place of I7's recent practice of simply saying "You can't go that way."
A bug has been fixed which caused a person other than the player getting off something to be reported as if he were getting out of it.

The Looking Actions

The following rules have been abolished:
```
	consult LookRoutine entry point rule
	standard searching rule
```
The former provided vestigial I6 support; the latter in all cases did nothing.

The Object Movement Actions

Under the taking action, actors other than the player can now also use a "player's holdall" (if carried) to overcome carrying capacity limits.

The following rules have been abolished:

	default inventory style rule
	check let-go-before rule
	check let-go-after rule
	check receive-before for supporter rule
	check receive-after for supporter rule
	check receive-before for container rule
	check receive-after for container rule

These provided vestigial I6 library support and are irrelevant for I7.

The following rules for the removing it from action have been abolished:
```
	can't remove from closed containers rule
	check after-rules for taking too rule
	standard report removing rule
```
They had no effect in 4S08, having been pre-empted for some time by the automatic conversion of removing to taking: they had been left in the Standard Rules by accident but could never have any effect.
Similarly: the
```
	can't insert component parts rule
```
was redundant in 4S08 and has been removed.

The Actions Which Change the State of Things

When the opening action by the player is successful, Inform shows the contents of what was opened, provided it was opaque (so that the contents were previously not visible) and provided that the player is not inside it. The rule causing this was called the
```
	reveal any newly visible exterior rule
```
which is a misleading - it has been renamed the
```
	reveal any newly visible interior rule
```

The Actions Involving Other People