mirror of
https://github.com/ganelson/inform.git
synced 2024-06-17 07:40:47 +03:00
Initial commit
This commit is contained in:
commit
114e94f090
25
.gitignore
vendored
Normal file
25
.gitignore
vendored
Normal file
|
@ -0,0 +1,25 @@
|
|||
# This gitignore was automatically written by inweb -gitignore
|
||||
# and is not intended for human editing
|
||||
|
||||
.DS_Store
|
||||
gameinfo.dbg
|
||||
Changes/Output/
|
||||
Changes/Output/META-INF/
|
||||
Changes/Output/OEBPS/
|
||||
Changes/Output/OEBPS/Images/
|
||||
Documentation/Output/
|
||||
Documentation/Output/META-INF/
|
||||
Documentation/Output/OEBPS/
|
||||
Documentation/Output/OEBPS/Images/
|
||||
Documentation/Examples/_Results_Actual/
|
||||
*/_Results_Actual/
|
||||
|
||||
Internal/Extensions/Graham Nelson/Standard Rules.i7x
|
||||
Internal/I6T/
|
||||
Internal/Languages/English/Syntax.preform
|
||||
Internal/Miscellany/definitions.html
|
||||
|
||||
retrospective/*/cBlorb
|
||||
retrospective/*/ni
|
||||
retrospective/*/*.o
|
||||
|
2
Changes/Change Logs/3K27.txt
Normal file
2
Changes/Change Logs/3K27.txt
Normal file
|
@ -0,0 +1,2 @@
|
|||
3K27 (30 April 2006)
|
||||
First Public Beta build, and the baseline for this log.
|
27
Changes/Change Logs/3K56.txt
Normal file
27
Changes/Change Logs/3K56.txt
Normal file
|
@ -0,0 +1,27 @@
|
|||
3K56 (4 May 2006)
|
||||
|
||||
(Mac OS X only) Support for OS 10.3.9 restored.
|
||||
(Mac OS X only) Build number now correct in Finder's Information window
|
||||
for the application file.
|
||||
Changed the "tieing" action to "tying". (Inform's British author thought
|
||||
this was an American spelling, and vice versa. Sorry.) This entailed
|
||||
changes to examples Otranto, Brown, Snip, Snip Snip, and Under Contract.
|
||||
Bug in U-Stor-It example fixed, and Disappointment Bay 12 slightly improved.
|
||||
Tidied up documentation of Basic Screen Effects and Plurality extensions.
|
||||
Fixed the "South is a dead end with printed name "Collapsed Dead End"."
|
||||
bug causing the Undertomb example in the main text to fail to compile.
|
||||
Fixed problem with the "Early Childhood 4" example.
|
||||
Fixed compiler hang to do with misunderstood sentences setting the kind
|
||||
of a kind to itself.
|
||||
Fixed internal error on "now X is P", where X is a thing and P an
|
||||
property which isn't an either/or property.
|
||||
Fixed problems with defining a kind which includes the word "object".
|
||||
Fixed internal error on sentences using "to have" incorrectly.
|
||||
Fixed internal error on assertions giving inexplicit information about
|
||||
the kinds of things (asserting kind(f(x)) = y where f(x) is unknown).
|
||||
Fixed failure to object to malformed sentences caused by misunderstanding
|
||||
of the punctuation convention about quoted text ending sentences.
|
||||
Fixed failure to object to names of things or rooms containing literal
|
||||
double-quoted text (which then failed to compile through I6).
|
||||
Fixed failure to object to negative assertions in the form "The P is not
|
||||
X.", where P is a property taking a value.
|
129
Changes/Change Logs/3L95.txt
Normal file
129
Changes/Change Logs/3L95.txt
Normal file
|
@ -0,0 +1,129 @@
|
|||
3L95 (14 May 2006)
|
||||
|
||||
(Windows only) If compilation fails, index pages from the previous compilation
|
||||
are kept.
|
||||
(Windows only) Invalid characters cannot now be entered into the new project
|
||||
name field.
|
||||
(Windows only) The File/Revert menu item has been removed, as it was
|
||||
misleading quite a few people.
|
||||
(Windows only) Characters input with the AltGr key held down (such as ']' on
|
||||
a Spanish keyboard) can now be entered in the Source and Game panels.
|
||||
(Windows only) Inform 6 code is coloured grey in the Source tab.
|
||||
(Windows only) The application now works with IE7 installed.
|
||||
(Windows only) The installer would sometimes fail to reinstall a new version
|
||||
if the old version was not uninstalled, leading to an incorrect install
|
||||
and two entries in "Add and Remove Programs". This should now be fixed.
|
||||
(Windows only) The application should now cope if the "My Documents" path is
|
||||
something like "G:\".
|
||||
(Windows only) Replace now works if the string being searched for is only a
|
||||
case insensitive match.
|
||||
(Windows only) The Source tab now has the standard edit context menu available
|
||||
if you right click on it with the mouse.
|
||||
(Windows only) Fixed mis-addressing of the blue "go to documentation"
|
||||
links, which always linked two pages after the one intended.
|
||||
(Mac OS X only) Added a "Prune" button to the skein, with a slider control
|
||||
for the severity of pruning required.
|
||||
(Mac OS X only) Added a font size option in the Preferences, affecting all
|
||||
the panels simultaneously.
|
||||
(Mac OS X only) Removed the spurious error on the extensions contents page
|
||||
about incorrect extension "Standard Rules.zip".
|
||||
Various minor clarifications added to documentation, and new section 3.24
|
||||
("Directions") added.
|
||||
As the beginnings of a process of adding reviews at the end of each chapter,
|
||||
brief notes are added to the ends of chapters 9 and 10.
|
||||
Fixed bug in extension Plurality by Emily Short which involved noticing the
|
||||
plurality of items mentioned by the player but not printed in the text.
|
||||
Added two new Examples: "Feline Behavior" and "Panache".
|
||||
Minor changes to Examples:
|
||||
Being Prepared, Model Shop, Ballpark: added comments.
|
||||
Crane's Leg I and Eddystone: modified because of type-checking bug.
|
||||
U-Stor-It: fixed bug to do with cards appearing on all of the chests.
|
||||
Fussy Table: added understanding of "chair" as a chair.
|
||||
Yolk of Gold: rearranged rule order.
|
||||
Added the implication that something locked is usually lockable. This in
|
||||
practice means that doors and containers described as being locked at
|
||||
the start of play are considered to be something which the player
|
||||
could in principle lock or unlock, given the correct key. (In the
|
||||
absence of information about that key, the player will still not be
|
||||
able to lock or unlock them, but will get a more realistic reply
|
||||
from the game in response to attempts to unlock.)
|
||||
Added "persons" as an alternative plural of "person" (the usual one being
|
||||
"people").
|
||||
Fixed nested comments: thus "[This [even so] is all one comment.]"
|
||||
Improved the "hawk is a handsaw" problem message.
|
||||
Improved the problem messages for incorrectly specified rules.
|
||||
Improved problem messages for "now ..." used with a condition which cannot
|
||||
be directly arranged during play, such as "now Scene IV is happening",
|
||||
and for "now ... and ...".
|
||||
Improved problem messages for assertions where it seems possible that the
|
||||
wrong primary verb has been construed.
|
||||
Problem message for understand followed by an incorrect action corrected
|
||||
(it was previously recommended as correct usage something which wasn't).
|
||||
More explicit problem message for an attempt to create a "part" of a room.
|
||||
Added run-time problem message for using the bare condition "in R" where
|
||||
R is neither a room nor a region.
|
||||
Fixed bug whereby an assertion containing three or more consecutive
|
||||
property adjectives ("a red rough square block is on the table")
|
||||
would have only the first two acted upon.
|
||||
Fixed bug in which rules whose premiss contained an unrecognised action
|
||||
plus the explicit word "rule" would activate every turn, rather than
|
||||
produce a problem message.
|
||||
Fixed bug to do with rules beginning "Check/report/carry out", then an
|
||||
action name including "it", then a conditional clause with "when" or
|
||||
"while".
|
||||
Fixed bug in which using a "To say ..." phrase in the middle of a complex
|
||||
say would cause it to lose track of conditional saying, sometimes
|
||||
resulting in both "[if ...]" and "[otherwise]" parts being printed.
|
||||
Fixed bug in previous fix for failure to object to names of things or
|
||||
rooms containing literal double-quoted text (which then failed to
|
||||
compile through I6).
|
||||
Fixed bug to do with assigning properties to a null object when "it" is
|
||||
currently undefined.
|
||||
Fixed bug to do with incorrect sorting of rules as between a rule
|
||||
specifying "going ... in..." and one specifying "going ... from...",
|
||||
where there are at least three such defined in a particular order.
|
||||
Fixed bug in which run-time type-checking did not resolve which phrase
|
||||
definition to use where they differed only in properties of objects
|
||||
(for instance, distinguishing "To recite (something - closed container)"
|
||||
and "To recite (something - open container)").
|
||||
Fixed bug which very occasionally caused a "bad check-against in run-time
|
||||
type check" internal error.
|
||||
Fixed crash if a Table is improperly named (or not named at all), and
|
||||
added checking to enforce the rules on Table names.
|
||||
Fixed bug confusing ordinal and cardinal numbers in assertions (so that
|
||||
"The third man is here." would be misread as if "Three men are here.").
|
||||
Fixed bug if a region is created whose name begins with a direction or
|
||||
other indication of location ("East of Eden is a region.", say, or
|
||||
"On the Prairie is a region.").
|
||||
Fixed crash if a room is created only by implication and with no name.
|
||||
Fixed failure of sentences like "East of the Garden is the Gazebo." to
|
||||
establish which room is currently under discussion (the Garden): this
|
||||
meant that some source text in the documentation and website failed.
|
||||
Fixed bug in which if pronouns would sometimes be assigned to implicitly
|
||||
created things: for instance, in "A nose is part of every person. ...
|
||||
George is a man. He wears a shirt and a pair of pants.", "he" was
|
||||
incorrectly thought to refer to George's nose rather than George.
|
||||
Fixed bug (or arguably added feature) so that named rules can be property
|
||||
values, that is, so that a property can have "rule" as its kind of value.
|
||||
Fixed bug in which values that vary, such as "location", were allowed
|
||||
by I7 as table entries, only to fail to compile through I6; and added
|
||||
problem message for the special case of "player".
|
||||
Fixed bug in which initialising a value that varies to itself, or to another
|
||||
value that varies, was not reported as a problem, and fell through to
|
||||
fail in I6.
|
||||
Fixed bug in which attempts to manipulate the properties of kinds would
|
||||
sometimes not be reported as problems, and fall through to fail in I6.
|
||||
Fixed bug in which properties of indefinitely described objects, used as
|
||||
the subjects of verbs, failed to compile in I6.
|
||||
Fixed bug in which, in some circumstances, the character "@" used in text
|
||||
failed to compile in I6 (making it hard to write email addresses).
|
||||
Fixed bug in which "(called ...)" used improperly in adjective definitions
|
||||
was not reported as a problem, and fell through to I6.
|
||||
Fixed bug in which doors described both as one- and two-sided would not be
|
||||
picked up as a problem.
|
||||
Fixed bug in which explicitly starting the player in a container which is not
|
||||
contained in any room would fall through to an error in I6.
|
||||
Added a very limited ability to cope with "if X has P greater than N", where
|
||||
P is a property, and fixed bug whereby uses of "to have P" resulted
|
||||
in internal errors: those which cannot be compiled now result in better
|
||||
problem messages.
|
79
Changes/Change Logs/3M43.txt
Normal file
79
Changes/Change Logs/3M43.txt
Normal file
|
@ -0,0 +1,79 @@
|
|||
3M43 (21 May 2006)
|
||||
|
||||
(Windows only) Search highlighting in the documentation tab doesn't keep
|
||||
applying to further pages as you nagivate around.
|
||||
(Windows only) If nothing is found when searching, a dialog appears as feedback.
|
||||
(Windows only) Replacing text in the source tab no longer goes into an
|
||||
infinite loop if the new text contains the old text as a substring.
|
||||
(Windows only) If the registry string value
|
||||
"HKCU\Software\David Kinder\Inform\Window\Font Name"
|
||||
is set, its value is used as the application font.
|
||||
(Windows only) If the registry DWORD value
|
||||
"HKCU\Software\David Kinder\Inform\Window\Font Size"
|
||||
is set, its value is used as the application font point size.
|
||||
Fixed example "Pink or Blue" to deal correctly with one-letter inputs.
|
||||
Added a few words of explanation to example "Crusoe" to help people find the
|
||||
bit of the action that needs replacing.
|
||||
Twelve new Examples added, as straightforward demonstrations:
|
||||
"Escape" - the most basic imaginable window.
|
||||
"Down Below" - the most basic light switch.
|
||||
"Replanting" - changing the results of trying to take an immovable object.
|
||||
"Up and Up" - a travel description printed before moving between rooms.
|
||||
"Neighborhood Watch" - a door lockable without a key but only on one side.
|
||||
"Slightly Wrong" - a room whose description is unusual on the first visit.
|
||||
"Laura" - use of a printed name and understand to get around particularly
|
||||
awkward-named objects.
|
||||
"Tamed" - enterable containers and supporters and to explain a few details
|
||||
of when we might say something was transparent.
|
||||
"Grace" - preventing the player from traveling to a distant location
|
||||
without a vehicle.
|
||||
"Verbosity" - using full-length room descriptions.
|
||||
"Infiltration" - how to change a room description on each of several visits.
|
||||
"MRE" - various timing things, heavily commented.
|
||||
Minor changes to examples "Finishing School" and "Lean and Hungry" to address
|
||||
the complaint that general rules were being written but only really made
|
||||
sense for specific individual NPCs.
|
||||
Minor changes to "Garibaldi" examples to correct a terrible error (the Medlab
|
||||
being called Sickbay, in violation of the game's nominal setting).
|
||||
Typo removed from example "Get Me to the Church on Time".
|
||||
Correction of "Hagia Sophia" example to try exiting the chair silently.
|
||||
Review sections added to chapters 3 and 17 of the documentation.
|
||||
By popular demand (two people asked for this) "now X is not P" is now legal,
|
||||
where P is an either/or property: thus "now the four-poster bed is not
|
||||
scenery", for instance.
|
||||
Extended "let" to allow "rule" as one of the kinds of value allowed.
|
||||
Changed rules on the ' character so that it is not translated into " when it
|
||||
begins text and is immediately followed by s and a space. (This so that
|
||||
the apostrophe in "[The Kitchen]'s decor is awful." is not converted to
|
||||
a double-quote.)
|
||||
Improved behaviour of "called", so that sentences involving relationships
|
||||
with objects which are "called" now work: for instance, "The white door
|
||||
is north of a room called the Hot and Cold Room."
|
||||
Unexpectedly capitalised articles following "called" are now no longer read
|
||||
as articles. Thus, "South of the Passageway is a room called The Great
|
||||
Hall of Infinity." will preserve the capitalised "The" in the room's name.
|
||||
Adjusted priorities in parsing so that table column names are considered less
|
||||
likely to be intended than kind names. (This affects works where a kind
|
||||
has its instances created by a table, since column 1 of that table will
|
||||
quite likely have the same name as the kind.)
|
||||
When things are created by table (as in the example to do with Tour de France
|
||||
jerseys), any articles in front of their names are now recognised, just
|
||||
as if they had been created by regular sentences.
|
||||
Fixed crash on "Yourself is nowhere" (sic).
|
||||
Fixed crash sometimes occurring in indexing of rulebooks attached to scenes.
|
||||
Fixed crash (or sometimes other misbehaviour) on an over-complicated say.
|
||||
Fixed compiler hang when complicated assemblies never end.
|
||||
Fixed failure to check incorrect usage of 'called' in defining one-to-one
|
||||
relations which are not reciprocated.
|
||||
Fixed failure to report improper usages of the (supposedly internal use only!)
|
||||
syntax "...an action corresponding to...".
|
||||
Fixed failure to reject matches of vague descriptions against specific
|
||||
ones in type checking, so that (e.g.) "an open door" would be accepted
|
||||
against "(D - a door)" in a phrase definition.
|
||||
Fixed a bug in which complicated creations of kinds sometimes ignored their
|
||||
adjectives: e.g., 'A radiant panel is a kind of backdrop which is lit.'
|
||||
would sometimes silently ignore the "lit" part.
|
||||
Fixed a bug - well, arguably clarified an ambiguous specification - so that a
|
||||
printed name for a kind is now inherited by things (or rooms) of that kind.
|
||||
Restored the (nowhere documented and theoretically unofficial) debugging
|
||||
command RULES to working again.
|
125
Changes/Change Logs/3P53.txt
Normal file
125
Changes/Change Logs/3P53.txt
Normal file
|
@ -0,0 +1,125 @@
|
|||
3P53 (9 June 2006)
|
||||
|
||||
(Windows only) The Transcript tab is now added - a major feature, and the
|
||||
only one omitted from the Windows application in the first public
|
||||
beta release. (There is one caveat: the transcript does not yet underline
|
||||
differences when the game text does not match the blessed text.)
|
||||
(Windows only) Switched to using the NullSoft Installer System to create the
|
||||
installer. If you have a previous version installed, you should uninstall
|
||||
it from "Add or Remove Programs" in the Control Panel before installing
|
||||
this version.
|
||||
(Windows only) The "Install Extension" menu item no longer rejects extensions
|
||||
with Unix-style line endings.
|
||||
(Windows only) The "Install Extension" menu item shows the installed extensions
|
||||
documentation page after a successful install of an extension.
|
||||
(Windows only) Clicking on an item in the search results window now always
|
||||
brings the appropriate tab to the front.
|
||||
(Windows only) Compiling a game no longer steals the input focus from the
|
||||
Source tab.
|
||||
(Windows only) It is no longer possible to put the edit windows into "smart
|
||||
quotes" mode.
|
||||
(Windows only) The Game and Build menus have been merged.
|
||||
(Mac OS X only) Mechanism for installing extensions now added: simply click
|
||||
the [+] button in the Extensions panel of the application Preferences.
|
||||
Installed extensions may also be edited using "Open Extension >" in
|
||||
the File menu.
|
||||
(Mac OS X only) The 'Standard' library is now standard for Inform 6 projects.
|
||||
(Mac OS X only) Projects with a setting for a version of the Inform 6 compiler
|
||||
that is not installed no longer crash the application (and choose a
|
||||
sensible alternative version).
|
||||
(Mac OS X only) I6 compiler used internally is now bi-platform 6.31, not 6.30.
|
||||
Improved "Help" menu offers short-cuts to the Recipe Book and the Installed
|
||||
Extensions documentation.
|
||||
Examples:
|
||||
"The Abolition of Love" added, as a thorough exploration of all the kinds
|
||||
of relations which can be set and unset.
|
||||
"Beachfront" added to demonstrate finding an object in a room which was
|
||||
not there before;
|
||||
"Van Helsing" added to demonstrate a character who follows the player
|
||||
from room to room.
|
||||
"Exit Strategy" added to demonstrate the beginning of scenes once in more
|
||||
detail, and to describe what it means when the scene change machinery
|
||||
is stuck (and how to diagnose and fix the problem).
|
||||
"Otranto": dealt with a bug such that a rope tied to a door did not
|
||||
restrict the player's movement appropriately.
|
||||
"Tamed": typo fixed.
|
||||
"Up and Up": minor fix for a description assigned to the wrong object.
|
||||
"Day One": waiting added to the selection of acceptable activities for
|
||||
which Freitag will not glare at the player.
|
||||
"Stately Gardens": typo fixed.
|
||||
"Sybil 1": additional comments and code to demonstrate some expanded
|
||||
forms of keyword matching.
|
||||
"Port Royal 3": fixed a typo that was causing part of the source not to
|
||||
copy properly into the code window.
|
||||
"Odyssey": minor syntax improvement to get rid of ugly legacy form.
|
||||
Extensions:
|
||||
Basic Screen Effects (now version 2):
|
||||
modified so that local variable names are less likely ever to conflict
|
||||
with globals or other names in the author's work;
|
||||
"clear only the status line" added;
|
||||
"left alignment depth" variable added, allowing the author to print
|
||||
status elements at a different spacing than 14 spaces from the
|
||||
left edge of the screen;
|
||||
Menus:
|
||||
added arrow and escape keys as viable means of input;
|
||||
rule names added to several rules to make modification easier;
|
||||
local variable names made less likely to conflict.
|
||||
Plurality:
|
||||
changed "acts plural" phrase to apply to all objects, not just "things".
|
||||
Complex Listing (now version 2):
|
||||
corrected erroneous documentation;
|
||||
added "enumerated listing" option.
|
||||
Made a general rewrite of the type-checking machinery: the new version is
|
||||
more extensively tested than the old (and produces slightly better
|
||||
Problem messages), but otherwise there should be no perceptible change.
|
||||
Made it possible to unset a wider range of relations with "now". For
|
||||
instance, if "loving" is a one-to-one relation, then "now Elizabeth
|
||||
does not love Darcy" is now allowed, if sad.
|
||||
Added a new text substitution "[conditional paragraph break]".
|
||||
Problem message added for tables defined with names which already have a
|
||||
meaning, leading to ambiguity (e.g., "Table of Three", since "three"
|
||||
is a number), with specific checking for clashes between table and kind
|
||||
named (e.g. "Table of Rooms").
|
||||
Problem message added for use of 'either' on a list of 3 or more possibilities.
|
||||
Problem message added where "number of ..." or "total ...", etc., are used
|
||||
with a determiner which makes this nonsensical ("number of at least three
|
||||
rooms", etc.).
|
||||
Problem message added for contradictory redefinition of global variables.
|
||||
(Non-contradictory redefinitions are superfluous but legal.)
|
||||
Problem message added for incorrect uses of "with", and an explanation
|
||||
supplied (where previously an internal error would sometimes occur).
|
||||
Fixed bug whereby '(called ...)' used incorrectly in a scene beginning
|
||||
or ending condition could cause an internal error, and added a
|
||||
suitable Problem message.
|
||||
New phrase option for "list the contents of...": "with extra indentation",
|
||||
which increases the left margin by 1 level of indentation - which
|
||||
simulates the way that the standard inventory listing looks.
|
||||
References to tables can now refer to the table in question using a local
|
||||
or global variable, or a phrase to decide which table to look at.
|
||||
Fixed bug whereby certain names consisting only of an article would lead
|
||||
to an internal error (thus producing the record-holder for shortest
|
||||
source text breaking I7: "A is a room."); and similarly for a name
|
||||
which includes parentheses "(" or ")", also not allowed.
|
||||
Fixed bug: it's now possible to release a game with a website and cover
|
||||
art in PNG format, where previously the website assumed JPGs were
|
||||
used (although the compiled game itself was fine all along).
|
||||
Fixed bug to do with return values from activities being lost (with thanks
|
||||
to Jesse McGrew, who provided the solution).
|
||||
Fixed bug whereby a complex listing early in a "say" would cause a
|
||||
conditional [if] to go wrong later in the "say".
|
||||
Fixed bug in the debugging command RELATIONS causing it to print some
|
||||
relations the wrong way round, and to omit some relationships with
|
||||
reciprocal various-to-various relations.
|
||||
Fixed bug whereby released story files still contained some debugging verbs.
|
||||
Also accidentally left in was the I6 verb FULLSCORE: this no longer works,
|
||||
and is deprecated now that there are better ways to achieve the same
|
||||
effect. In this build, the action and corresponding grammar are removed,
|
||||
leaving it open for designers to provide their own versions if they
|
||||
choose to do so.
|
||||
Fixed bug in which "X are not Y" would sometimes complain of unproductive
|
||||
negative even if Y is such that not-Y is unambiguous, whereas "X is not
|
||||
Y" would work in similar circumstances.
|
||||
Fixed bug where attempts to unlock something with the wrong key produced
|
||||
the wrong pronouns in the failure message.
|
||||
Fixed bug where "each turn" and "check" rules were confused in the Rules
|
||||
index, and straightened out the spacing of this index.
|
137
Changes/Change Logs/3R85.txt
Normal file
137
Changes/Change Logs/3R85.txt
Normal file
|
@ -0,0 +1,137 @@
|
|||
3R85 (26 June 2006, a rapid replacement for a mis-uploaded 3R84)
|
||||
|
||||
(Mac OS X only) Direct "Install Extension..." option added to the File menu.
|
||||
(Mac OS X only) Extension documentation auto-updated when any file added to
|
||||
the extensions area, even if dragged by hand in the Finder.
|
||||
(Mac OS X only) Bug fixed that was causing Inform projects sometimes to appear
|
||||
as directories, and to fail to open on double-clicking.
|
||||
(Windows only) Differences between the game's current text and the blessed
|
||||
text in the transcript tab are now underlined.
|
||||
(Windows only) The transcript is now saved in the same format as the OS X
|
||||
application. (This means that any blessed transcript text saved from an
|
||||
earlier version will have to be recreated.)
|
||||
(Windows only) The source tab now correctly colours nested comments.
|
||||
(Windows only) Entering a carriage return with the shift key held down no
|
||||
longer results in text that the compiler rejects.
|
||||
(Windows only) Setting the focus on the game tab by clicking in it with the
|
||||
mouse now keeps the input cursor on the input line being edited.
|
||||
(Windows only) Added a warning dialog to the "Bless All" button on the
|
||||
transcript tab.
|
||||
(Windows only) The bless buttons on the transcript tab are now disabled if
|
||||
there is nothing to do.
|
||||
(Windows only) If the registry DWORD value
|
||||
"HKCU\Software\David Kinder\Inform\Start\Open Last Project"
|
||||
exists and is not set to zero, then when starting the application just
|
||||
opens the last project, rather than displaying the splash screen. If the
|
||||
registry DWORD value
|
||||
"HKCU\Software\David Kinder\Inform\Window\Clean Up Indexes"
|
||||
exists and is set to zero, then when closing a project the index files are
|
||||
not deleted. (Based on patches by Dan Shiovitz.)
|
||||
Documentation on newly installed extensions, not yet used, is now much
|
||||
fuller. This breaks the impasse of "can't use this until I read the
|
||||
documentation, can't read the documentation until I use this".
|
||||
Examples:
|
||||
"Abolition of love": removed comment that shouldn't have been there
|
||||
"Bruneseau's Journey" slightly modified for tidiness
|
||||
Minor errors exposed by the improved type-checker fixed in "Prague",
|
||||
"Glass", "Crusoe", and "Underlying"
|
||||
Extra commentary and new material added to "Laura" to explain parsing of
|
||||
complex phrases better
|
||||
"Would you...?" added to demonstrate checking for the existence of a
|
||||
property
|
||||
"First Name Basis" added to demonstrate how to assign synonyms to objects
|
||||
"Tiny Garden" added to demonstrate a very simple implementation of
|
||||
continuous space
|
||||
"Equipment List" added to demonstrate and explain variant inventory styles
|
||||
"Tense Boxing" added to demonstrate past and present tense rules more
|
||||
completely
|
||||
"Grilling" added to demonstrate a supporter from which the player cannot
|
||||
take things
|
||||
"Removal" added to demonstrate a revised taking report
|
||||
"Nameless" added to demonstrate an ASK verb that works on objects, like
|
||||
SHOW
|
||||
"Stone" added to demonstrate rules used as properties of things
|
||||
Extensions:
|
||||
"Basic Screen Effects": minor errors exposed by the new type-checker fixed
|
||||
"Locksmith": added yet more rule names; substantially updated to provide
|
||||
better defaulting and add a "keychain" kind; advanced to Version 2.
|
||||
"Rideable Vehicles": added rules to prevent mounting when already mounted,
|
||||
and to convert the exiting action to dismounting; added example.
|
||||
Two new adjectives, "on-stage" and "off-stage", have been added to the stock
|
||||
of those built in to Inform. See 7.9 in the documentation, "Removing
|
||||
things from play", for more on this; in particular, note that the
|
||||
previous reference in 7.9 to testing whether a thing is "somewhere"
|
||||
has been withdrawn. (This led to numerous difficulties with ambiguity,
|
||||
and in any case was not very explanatory.) We now test whether a thing
|
||||
is "on-stage" or "off-stage".
|
||||
Type-checking for conditions has been substantially rewritten. This mainly
|
||||
affects "if", "when" and "now", but other phrases too, and generally
|
||||
makes Inform stricter: for instance, "if the time since Escalating Danger
|
||||
began is greater than 1" used to work - but now I7 points out that a
|
||||
time cannot be compared with a number, and insists on "1 minute"
|
||||
rather than "1". This picked up minor errors in "Glass", "Reliques of
|
||||
Tolti-Aph" and the examples "Underlying" and "The Prague Job".
|
||||
The check removing rules have been rewritten. Previously, these duplicated
|
||||
the check taking rules, almost right down the line: in effect the two
|
||||
actions did the same thing, though being reported slightly differently.
|
||||
In the new version, a new rule called the "convert remove to take rule"
|
||||
actually converts the action from removing into taking at an early
|
||||
stage: the practical effect of this is that any before or instead
|
||||
rules written to cover taking now also cover removing. This is good
|
||||
because it means one no longer needs to remember to cover both these
|
||||
actions to be sure of handling the case of an actor picking something up.
|
||||
The scope of the "removing" action is changed so that if something is part
|
||||
of X, then it is in scope for "remove -- from X": previously, only
|
||||
the things inside X qualified. Being in scope for the action does not
|
||||
mean that the attempt to remove the part will succeed, of course, and
|
||||
it will normally fail the "can't take component parts rule": but being
|
||||
in scope does mean that the designer can write rules to allow removal
|
||||
after all.
|
||||
Problem messages improved for mysterious problems arising from trying to
|
||||
use local "let" variables in substituted text which turns up elsewhere
|
||||
in the source, i.e., in places where those variables do not exist.
|
||||
Problem message added if two rules are being added with the same name.
|
||||
Fixed bug which caused negated conditions in the past and perfect tenses to
|
||||
fail: I7 would read, e.g., "if the box had not been open" as "if the box
|
||||
had been not open", which would generally be true much more easily.
|
||||
Fixed bug whereby actions declared without any mention of what they applied
|
||||
to (e.g., "Requesting help is an action out of world." rather than
|
||||
"Requesting help is an action out of world applying to nothing.")
|
||||
would sometimes lead to spurious incompatibility Problem messages when
|
||||
grammar is defined for the action. To clarify: from now on, an action
|
||||
which does not say what it applies to, applies to nothing. (This is
|
||||
tacitly assumed by some of the extensions source text already.)
|
||||
Fixed bug in which I7 allowed names with double-quoted text in, only to
|
||||
crash at the I6 stage; when the cause was actually a misunderstanding of
|
||||
the punctuation rules by the user.
|
||||
Fixed bug to do with names beginning with the word "kind", such as "kind
|
||||
gentleman".
|
||||
Fixed bug which caused properties declared by the "(called ...)" text in a
|
||||
new relation to have not quite the right type, causing odd type-checking
|
||||
problems elsewhere.
|
||||
Fixed bug in which negatively phrased implications would sometimes be read
|
||||
as if positive (e.g., "Scenery is never cold" is an implication not an
|
||||
inference because it concerns all things which have a given property
|
||||
at the start of play, not all things of a known kind; and it was being
|
||||
misread as if "Scenery is always cold").
|
||||
Fixed bug to do with initialising variables whose kind of value is
|
||||
"miscellaneous-value" or "string-of-text" (though the author of Inform
|
||||
wishes people wouldn't use hacky internal kinds of value with hyphens
|
||||
in the name, really).
|
||||
Fixed bug in which spurious problem messages occasionally occur when
|
||||
giving grammar which specifies only one of two required things to
|
||||
which an action will apply; and generally improved the previously
|
||||
uninformative "not compatible" grammar Problem message.
|
||||
Fixed bug in which "now" does not always set properties correctly.
|
||||
Fixed bug whereby Problems in the final chunk of a text with substitutions
|
||||
used explicitly as a value were not always reported.
|
||||
Fixed bug to do with relative clauses in property values (which are not
|
||||
allowed, but used to cause an internal error rather than a proper problem.)
|
||||
Fixed bug in which errors on grammar verbs were sometimes reported quoting
|
||||
the previous Understand... sentence in the source, not the one in which
|
||||
the error occurred.
|
||||
Fixed bug in sentence-breaking, whereby text ending with sentence-closing
|
||||
punctuation, immediately followed by a single word sentence in which the
|
||||
word was capitalised, would cause that single word to be ignored.
|
||||
Fixed bug whereby "else" was not always equivalent to "otherwise".
|
||||
Fixed bug to do with permissions for the "initially carried" property.
|
104
Changes/Change Logs/3T38.txt
Normal file
104
Changes/Change Logs/3T38.txt
Normal file
|
@ -0,0 +1,104 @@
|
|||
3T38 (10 July 2006)
|
||||
|
||||
(Windows only) Boxed quotations are now correctly displayed in the game tab.
|
||||
(Windows only) Extensions can be created, opened and edited within the
|
||||
application.
|
||||
(Windows only) If an error occurs in an extension, clicking on the link in the
|
||||
problem report opens that extension.
|
||||
(Windows only) The file dialog for installing extensions now allows multiple
|
||||
files to be selected at once.
|
||||
(Windows only) Undo and redo in the source tab now works correctly with Unicode
|
||||
characters.
|
||||
(Windows only) Added a "Trim skein" button to the skein tab, which removes all
|
||||
unlocked skein knots.
|
||||
The "means" and "means that" syntaxes are being withdrawn. These were always
|
||||
rather crude word-substitution devices: to quote the documentation,
|
||||
"now deprecated... may be withdrawn". In this release, the Standard Rules
|
||||
no longer use the syntaxes even internally, and this prevents a number
|
||||
of slightly odd side-effects related to the words "above" and "below".
|
||||
In the next release, the ability to use the "means" and "means that"
|
||||
syntaxes will be removed altogether.
|
||||
Two new relations are built in to Inform to handle doors and locks; the
|
||||
verbal forms "to be through D" and "to unlock D" express these. This
|
||||
mimics syntax previously achieved using "means that", but works in a
|
||||
much tidier way, and is more flexible: for instance, "things which
|
||||
unlock the Great Gate" is now a legal description.
|
||||
Type-checking extended further into the descriptions D used in constructions
|
||||
such as "total P of D" or "a random D", and into complicated descriptions
|
||||
given as part of the conditions for rules to apply. (For instance,
|
||||
"Instead of taking a container in 100" - clearly absurd, as how can
|
||||
a container be inside a number? - now produces a problem message.)
|
||||
Examples:
|
||||
"Uptempo" given a better "fast time rule".
|
||||
In some 21 of the examples, the syntax "-- has a property called --" has
|
||||
been rewritten to be more specific about what kind of value is involved.
|
||||
(For instance, to say "-- has some text called --" if the property
|
||||
will hold text.) This is better style, and allows Inform to check
|
||||
usage more carefully.
|
||||
Unnecessary Inform 6 general parsing routines are no longer compiled for
|
||||
kinds of value which are not ever parsed: under some circumstances
|
||||
this can save a significant amount of space at run-time.
|
||||
Problem message added for grammar token trying to understand a kind of
|
||||
value which cannot be parsed, such as 'rule' or 'scene'.
|
||||
Improved problem messages for property declarations, and allowed property
|
||||
declarations to create properties whose values have to objects of a given
|
||||
kind.
|
||||
Improved problem message for when "Understand the command..." goes bad.
|
||||
Improved problem message for incorrect usage of "... condition" names.
|
||||
Added problem message if a verb is defined with two present plurals (as
|
||||
this can't be right, and usually means that someone has tried to define
|
||||
the past tense using "they" rather than "he", "she" or "it").
|
||||
Added problem message for an attempt to "change O to A", where O is an object
|
||||
and A is an adjective the truth of which can be tested, but not changed
|
||||
(e.g. "change O to visible").
|
||||
Added problem message for creating a kind of value containing "of". (This
|
||||
never worked, due to all kinds of grammatical ambiguities, but used to
|
||||
fail with an inexplicable problem message: now it fails with an apology.)
|
||||
Extended the range of what can be negated using "now", so that, e.g.,
|
||||
"now Elizabeth does not love anyone" is now allowed. (An obvious feature
|
||||
whose absence was reported as a bug, but technically it's new.)
|
||||
Removed spurious problem message claiming that certain "after" rules would
|
||||
have no effect.
|
||||
Fixed bug whereby arbitrary text could, under some circumstances, match the
|
||||
"[number]" token of grammar.
|
||||
Fixed bug under which rules applying to actions done for the Nth time
|
||||
might fail to apply if these actions had been interrupted by other
|
||||
actions earlier in the same turn (e.g., to implicitly take something
|
||||
before moving on to do something with it).
|
||||
Fixed bug whereby specifying that one of the named built-in rules belongs
|
||||
to another rulebook (i.e., as well as its usual one) would result in
|
||||
one of the two rulebooks being a partial duplicate of the other.
|
||||
Fixed bug causing "item described" (and the thing implicitly meant by a
|
||||
bare property name) in a text with substitutions to refer to the
|
||||
wrong thing, when this text is being printed from within another text
|
||||
with substitutions.
|
||||
Fixed bug in which tests such as "if not visited" sometimes lost the
|
||||
sense of the "not" and instead tested "if visited".
|
||||
Fixed bug whereby route-finding and counting steps through reciprocal
|
||||
various-to-various relations would sometimes give incorrect results if
|
||||
the relation had been changed from its initial state at run-time.
|
||||
Fixed bug by which "everything" was not always equivalent to "every thing",
|
||||
and similarly for "everyone", "everybody" and "everywhere".
|
||||
Fixed bug to do with parsing times of day around midnight and midday.
|
||||
Fixed obscure bug to do with editing the player's command. (Well, in fact
|
||||
Jesse McGrew fixed it.)
|
||||
Fixed bug in which a property is being declared as possible but whose name
|
||||
coincides with a participle of one of the containment verbs. (E.g.,
|
||||
"A weapon can be worn.")
|
||||
Fixed bug whereby a rule about "doing something" (unspecified) to some
|
||||
specific kind of noun would result in run-time errors if the current
|
||||
action did not take a noun, e.g., when looking.
|
||||
Fixed bug whereby setting the printed plural name of a kind might lead
|
||||
to a failure to compile through Inform 6 (due to a duplicated "plural"
|
||||
property).
|
||||
Fixed two unrelated bugs to do with apostrophes inside commands leading
|
||||
to grammar declarations which failed to compile through Inform 6.
|
||||
Fixed bug causing spurious problem messages with garbled text: this
|
||||
affected the examples "Table Foosball" and "Air Conditioning is Standard".
|
||||
(We believe the bug only manifested itself under Mac OS X running on an
|
||||
Intel processor.)
|
||||
Fixed bug causing scene begin/end conditions to go wrong if they tried to
|
||||
use the "location of X" phrase.
|
||||
Fixed bug causing problems with scene begin/end conditions to be reported
|
||||
at the wrong sentence of the source text.
|
||||
Spurious newline after "That noun did not make sense in this context." removed.
|
89
Changes/Change Logs/3V01.txt
Normal file
89
Changes/Change Logs/3V01.txt
Normal file
|
@ -0,0 +1,89 @@
|
|||
3V01 (2 August 2006)
|
||||
|
||||
Rather than being a bug-fixing build, this build carries out a number of
|
||||
significant internal reforms, some outwardly visible and some not.
|
||||
For the first time, compilation to the Glulx virtual machine rather than
|
||||
the Z-machine is possible. As the option on the Settings panel for a
|
||||
project suggests, we had always intended this to be a possibility,
|
||||
but too much was involved to get Glulx working in time for the public
|
||||
beta. In the future, we hope that Glulx will provide a solidly
|
||||
reliable platform for larger and for multimedia works: at present,
|
||||
though, our aim is simply to allow larger works to be compiled:
|
||||
and there are a few restrictions on screen effects, with some code
|
||||
(particularly to do with coloured text) not yet working.
|
||||
Glulx support in this build is experimental at best: we ask users
|
||||
not to send bug report forms yet, and would advise that people avoid
|
||||
publishing works compiled to Glulx rather than Z. With that said, we
|
||||
do believe that worthwhile progress is being made.
|
||||
The most important change in adapting to Glulx was the switch to an
|
||||
Inform 6 library derived from library 6/11, the current biplatform
|
||||
I6 library: up until now, Inform 7 has used a heavily adapted I6
|
||||
library referred to as "6/10N", derived from both 6/9 and 6/10.
|
||||
The new library, "6/11N", is the work of Jesse McGrew: our intention,
|
||||
once Glulx support is stabilised a little, is that this will
|
||||
eventually become library 6/12 - that is, the standard I6 library
|
||||
for use by both I6 and I7 authors alike. This should finally bring
|
||||
together branches of work on the I6 library which have been divergent
|
||||
for three years now.
|
||||
For the most part, the change of library will be invisible to I7
|
||||
users, but the adoption of various I6 bug-fixes and improvements
|
||||
between 6/9 and 6/11 should subtly improve the behaviour of Inform
|
||||
story files at run-time.
|
||||
Inform now reacts more helpfully to various overflows in Inform 6: thus, if
|
||||
Inform generates code which overflows the size of the Z-machine or
|
||||
breaks one of Inform 6's memory settings, rather more useful pages of
|
||||
advice are displayed.
|
||||
As promised, the deprecated "means" and "means that" features have been
|
||||
withdrawn, and removed from Chapter 19 of the documentation.
|
||||
The meanings of "in" and "on" have been made stricter: in past builds, the
|
||||
test "if A is in B" would pass if, e.g., A was being carried by a person
|
||||
B: this now fails. "A is in B" requires B to be a room or container;
|
||||
or else requires A to be a room or region, and B a region. Similarly,
|
||||
"A is on B" now requires B to be a supporter. The point of these reforms
|
||||
is that the built-in relations (well, all relations, really) ought to
|
||||
test as the same relation that they assert: asserting "The spanner is
|
||||
in the box." implies that "the box" is definitely not a person, so it
|
||||
is wrong for "if the spanner is in Fred" to succeed where Fred clearly
|
||||
is a person.
|
||||
Because it is, nevertheless, useful to be able to test "by whatever means
|
||||
A is immediately carried by B", the meaning of "to hold" has been
|
||||
changed to this relation. This accords with the meaning of the existing
|
||||
construction "the holder of A": thus "B holds A" if and only if B is
|
||||
"the holder of" A, and one can talk about "things held by B", and so on.
|
||||
In previous builds, "to hold" was synonymous with "to carry", and
|
||||
implied that the holder was a person: clearly, this is no longer true.
|
||||
A bucket can "hold" sand, a table can "hold" place settings, and so on.
|
||||
Note that, as with "holder of", the parts of something are also deemed
|
||||
to be "held" by it.
|
||||
Examples:
|
||||
Minor changes have been made to a small number of examples to reflect
|
||||
this stricter sense of "in";
|
||||
Two new examples, "Bees" and "Zqlran", demonstrate a random maze and
|
||||
and an exotic time notation respectively.
|
||||
Bug fixed so that "now" is able to change variables and properties, e.g. by
|
||||
writing "now the score is 132" or "now the carrying capacity of the
|
||||
player is 10". (In general, the "now" mechanism for asserting things
|
||||
has been rewritten, and should be more capable all round.)
|
||||
When Inform deals with descriptions such as "the people who are in lighted
|
||||
rooms", it compiles code using Inform 6's "objectloop" construct. The
|
||||
running speed of the result depends in part on the form of objectloop
|
||||
used, and in general it is fastest to try to minimise the size of the
|
||||
set of the objects looped through. Inform 7 now does a better job of
|
||||
minimising this set, and tries to avoid circumstances in which it is
|
||||
forced to loop through every object in searching for a match to a
|
||||
pattern. (It is possible that, in a limited number of cases, a
|
||||
description such as "if a woman (called the shopper) is in a shop, ..."
|
||||
will now result in a different woman being written into the "shopper"
|
||||
value than would have happened under previous builds - still a
|
||||
woman who is in a shop, but maybe not the same one. This might possibly
|
||||
affect Transcripts being used for testing.)
|
||||
Because this optimisation trades memory space for time, it is switched
|
||||
off if "use memory economy" has been requested.
|
||||
Values of kind "rule" can now be said - the result being to print their
|
||||
names: e.g., "can't turn scenery rule". This will probably only be
|
||||
useful for debugging, or the writing of surrealist competition pieces.
|
||||
The scene icons missing in build 3T38 for OS X have been restored.
|
||||
The crash occurring in build 3T38 for Windows to do with "a, b, and c" has
|
||||
been fixed.
|
||||
Bug in listing installed extension documentation fixed.
|
||||
Problem messages in the EPS map-maker generally tidied up.
|
247
Changes/Change Logs/3Z95.txt
Normal file
247
Changes/Change Logs/3Z95.txt
Normal file
|
@ -0,0 +1,247 @@
|
|||
3Z95 (14 September 2006)
|
||||
|
||||
(Mac OS X only) A new toolbar gadget, Headings, provides a breadcrumb-style
|
||||
drop-down menu to navigate the headings and subheadings in the source.
|
||||
A new toolbar button, Index, (re-)makes the current project, but shows the
|
||||
revised index rather than the ensuing game. It's useful when, for
|
||||
instance, laying out rooms and map connections, as it allows for an
|
||||
easier comparison of the source text with the World map.
|
||||
A new chapter (Chapter 5: Text) has been created in the documentation: this
|
||||
is made up of material previously in the middle of Chapter 4, with a
|
||||
variety of sections (on Unicode, quotations, "say" and text substitutions)
|
||||
pulled in from surrounding chapters.
|
||||
More detailed material has been added to the chapter on Rulebooks to cover
|
||||
the distinction between object- and action-based rulebooks.
|
||||
Review sections added to chapters 2, 5, 6, 7, 8 and 9.
|
||||
The unsupported types "object-specification" and "object-specification-unsub"
|
||||
have been withdrawn. In all cases where a phrase takes a description of
|
||||
a set of objects - for instance as what to list in a "[list of S]",
|
||||
or as what to repeat through in a "repeat with X running through S" -
|
||||
this is now called simply "description". Moreover, the operations
|
||||
"random S", "number of S", "total P of S" and "(superlative) S" -
|
||||
such as "number of men", "a random man", "total carrying capacity of
|
||||
men", "the heaviest man" - are all now defined as phrases like any other,
|
||||
rather than being special constructions inside Inform. (This should ease
|
||||
slightly odd problems experienced by a few people where Inform's parser
|
||||
could not cope with phrases whose names were too similar to these four
|
||||
constructions.) Finally, although "description" is not a kind of value,
|
||||
it is legal to use "description" in new phrases:
|
||||
To enumerate (collection - a description):
|
||||
repeat with the item running through the collection
|
||||
begin;
|
||||
say "-- [The item].";
|
||||
end repeat.
|
||||
We could then "enumerate lighted rooms", say. Note that "collection"
|
||||
here stands for whatever description is used when the phrase is invoked:
|
||||
it can in turn be used wherever a description is needed. We could,
|
||||
for instance, evaluate "the total carrying capacity of the collection".
|
||||
Actions can now require three levels of access to something in order to
|
||||
work, rather than two:
|
||||
- "Visible" and "touchable" (the default) are as before, and "carried"
|
||||
has been added. (E.g., "Assaying is an action applying to one carried
|
||||
thing.") Carried implies touchable which implies visible, in this sense.
|
||||
- A new accessibility rule, the "carrying requirements rule", checks that
|
||||
this requirement is met.
|
||||
- Should it fail, a new activity, "implicitly taking something", will
|
||||
attempt to have the actor silently take the item(s) required.
|
||||
- Should this in turn fail, the action as a whole will fail the "carrying
|
||||
requirements rule".
|
||||
- In Understand sentences, the tokens "[something held]" and "[things
|
||||
held]" have been withdrawn. If used, they now produce an explanatory
|
||||
Problem message which lays out what must change. In most cases, what
|
||||
will be needed is for the action's declaration to include the carrying
|
||||
requirement, and then these tokens to revert to plain "[something]"
|
||||
or "[things]"; but new tokens "[something preferably held]" and
|
||||
"[things preferably held]" have been created which, though they can
|
||||
match anything visible, will prefer items held when ambiguous names
|
||||
are used.
|
||||
These changes make little difference to the player's perception of what
|
||||
is happening. They have two advantages: first, it is conceptually clearer
|
||||
for the action to be where realism constraints are declared, rather than
|
||||
in grammar for parsing, and it ensures that all grammar using the same
|
||||
action follows the same rules; second, it moves implicit taking from the
|
||||
I6 library into more modern I7 terms, thus making it much easier to adapt
|
||||
and modify the behaviour of implicit taking: this has been a frequent
|
||||
request.
|
||||
The actions "throwing X at Y" and "showing X to Y" now require Y only to
|
||||
be visible, not to be touchable. (We envisage daggers thrown across
|
||||
chasms, security passes shown through windows, and so forth.)
|
||||
The "blowing" action, intended for woodwind instruments and perhaps the
|
||||
occasional siphon, has been withdrawn from the built-in set: it no
|
||||
longer seems to us part of the essential core of actions. We have
|
||||
similarly removed praying, digging, jumping over, filling and
|
||||
swimming. (Our main concern with these was that, besides being of
|
||||
marginal use, they tended to result in inappropriate text being
|
||||
produced in the few cases where they were relevant.)
|
||||
Finally, "remove X" (as distinct from "remove X from Y") is no longer
|
||||
understood as referring to the taking action. (It caused confusions
|
||||
with removing in the sense of removing an item of clothing, and
|
||||
hardly anybody ever used it.)
|
||||
Further work has been carried out on providing Glulx support. We now
|
||||
believe that any work written without the explicit use of Z-code
|
||||
assembly language (or extensions themselves containing such) should
|
||||
compile, run and release correctly in with "Glulx" selected on the
|
||||
Settings panel.
|
||||
Moreover, there is (as yet limited) support for displaying images, which
|
||||
Inform calls "Figures", following an analogy with book conventions. To
|
||||
use these:
|
||||
- Place an image file, which must be a JPEG or PNG, in a subfolder
|
||||
called Figures of the Materials folder for the project. Suppose
|
||||
this is "Woodlands.png".
|
||||
- Add the sentence:
|
||||
Figure of Woodlands is the file "Woodlands.png".
|
||||
to the source text. (Figure names can consist of any text so
|
||||
long as they start with the word "Figure": "Figure 3 - Woodlands",
|
||||
for instance, or "Figure W" would have been just as good.)
|
||||
- The phrase
|
||||
display the Figure of Woodlands;
|
||||
will now show the image, when the work is compiled to Glulx. When
|
||||
compiled to the Z-machine (which is the default setting on the
|
||||
Settings panel, of course), nothing will happen: the phrase will
|
||||
do nothing. The phrase option
|
||||
display the Figure of Woodlands, one time only;
|
||||
causes the image to be shown only the first time this phrase is
|
||||
reached.
|
||||
- A list of figures, with thumbnails and dimensions, appears in the
|
||||
Contents index; a warning triangle is shown for any images in the
|
||||
wrong format, or which are missing from the Figures folder.
|
||||
- When a Glulx work is released as a blorb (the default setting for the
|
||||
way releases occur), any such images are automatically included.
|
||||
- The new kind of value "figure-name" can be used to define phrases
|
||||
which work with Glulx pictures:
|
||||
To do something funny with (F - a figure-name): ...
|
||||
Figure names compile to resource ID numbers as used in the final
|
||||
released blorb; these will usually be integers 2, 3, 4, ...,
|
||||
since picture resource number 1 is reserved for the cover art.
|
||||
- We would like to thank John Cater for contributing his infglk.h
|
||||
definitions to the project: these definitions are included in the
|
||||
I6 source code compiled by I7 on any project set to Glulx.
|
||||
In line with the existing text substitutions "[the Thing]", "[The Thing]",
|
||||
"[a Thing]", "[an Entity]", for the name of something together with the
|
||||
given article and casing, "[A Thing]" and "[An Entity]" have been added,
|
||||
providing for a capitalised indefinite article.
|
||||
Technically a new feature rather than a bug fix: if an object is established
|
||||
as a proper noun, in that its name as specified by "called" does not
|
||||
begin with a standard English article - for instance "A man called your
|
||||
local vicar is in the Belfry", where "your local vicar" is treated as
|
||||
a proper noun - then this name will be capitalised if the object's
|
||||
name is printed with "[The whatever]", "A whatever" or "An whatever".
|
||||
(Thus "Your local vicar" would be printed instead of "your local vicar".)
|
||||
Kinds can now have plural names. This will relatively seldom be useful, but
|
||||
the result is that the text "A house is a kind of thing. Some windows
|
||||
are a kind of thing. Some windows are part of every house." - will now
|
||||
result in a house's windows being deemed to have plural names (which for
|
||||
instance means they will produce better messages with the Plurality
|
||||
extension).
|
||||
Conversely, fewer plural names are now understood by the run-time parser:
|
||||
an over-eagerness to recognise plurals of the names of unique, one-off
|
||||
items was sometimes leading to name clashes and consequently misinterpreted
|
||||
input.
|
||||
Examples:
|
||||
"Alpaca Farm" -- modified for new held rules
|
||||
"Ballpark" -- added commentary to better explain the function of
|
||||
the table
|
||||
"Beachfront" -- added commentary to explain the order of
|
||||
operations of the rules
|
||||
"Beneath the Surface" -- modified to account for changes to the
|
||||
held token
|
||||
"Big Sky Country" -- modified to account for the removal of the
|
||||
DIG action
|
||||
"Bruneseau's Journey" -- modified for the fact that BLOW has been
|
||||
removed
|
||||
"Bumping into Walls" -- substantially simplified entire example to
|
||||
demonstrate simpler handling of the problem
|
||||
"Cloak of Darkness" -- modified for new held rules
|
||||
"Crane's Leg 1" and "Crane's Leg 2" -- removed "a thing has a
|
||||
thing called the ideal" and replaced this with a relation and some
|
||||
discussion of why it is better to use relations than object
|
||||
properties
|
||||
"Curare" -- added to demonstrate a possible use of descriptions
|
||||
"Dig" -- removed, since it showed how to get around a problem that
|
||||
is no longer a problem
|
||||
"Down Below" -- added a demonstration of >FLIP grammar for the
|
||||
light switch, and corrected a bug that would have allowed the
|
||||
switch to be interacted-with from rooms other than the basement
|
||||
"Lakeside Living" -- modified to account for the removal of the
|
||||
swimming action
|
||||
"Model Shop" -- added a few extra lines showing how to make
|
||||
alternative names for the created buttons
|
||||
"Morning After" -- comment added to explain the meaning of "carry
|
||||
out"
|
||||
"Pine" -- modified to account for the removal of the swimming action
|
||||
"Polarity" -- comment added to explain "first carry out going
|
||||
rule"
|
||||
"Reflections" -- modified to account for the removal of the blowing
|
||||
action
|
||||
"Revenge of the Fussy Table" -- redundancy removed from one
|
||||
definition
|
||||
"Space Patrol - Stranded on Jupiter!" -- modified to account for
|
||||
the removal of the DIG action
|
||||
"Tamed" -- modified also to model the case of a room whose
|
||||
exterior is visible in another room (ie, nested locations)
|
||||
"3 AM" -- modified to reflect the changes to the held token
|
||||
"Trachypachidae Maturin 1803" -- modified to reflect changes in
|
||||
the held token
|
||||
"Transmutation" -- added example on group relations, thanks to
|
||||
Jesse McGrew
|
||||
"Under Contract" -- modified for the fact that various actions
|
||||
have been removed
|
||||
"The Unexamined Life" -- modified to reflect changes in the held
|
||||
token
|
||||
"A View of Green Hills" -- comment added explaining what noun
|
||||
means in this context
|
||||
"Waterskin" -- modified to reflect removal of blowing action
|
||||
"Would you...?" -- more comment added explaining the behavior of
|
||||
edible things
|
||||
"Zodiac" -- added missing line to the first version of the
|
||||
scenario
|
||||
"Zorn of Zorna" -- modified to reflect removal of blowing action
|
||||
A new information-only example has been added to the chapter on Rulebooks,
|
||||
giving a Backus-Naur form grammar for Inform's rule preambles
|
||||
Worked Examples:
|
||||
"Bronze" -- modified to reflect myriad changes to action definitions
|
||||
and held tokens
|
||||
"Glass", "When in Rome 1", "When in Rome 2" -- modified to remove a few
|
||||
responses to now-undefined actions
|
||||
"Damnatio Memoriae" -- modified to reflect changes to held tokens; fixed
|
||||
minor bug about thinking on the first turn
|
||||
"Reliques of Tolti-Aph" -- modified to reflect action changes
|
||||
Extensions:
|
||||
"Complex Listing" modified to deal with the new specification type, and
|
||||
advanced to version 3. Please note that "register things marked for
|
||||
listing" is now not necessary in most cases: see the documentation.
|
||||
The SCENES testing command now summarises the current situation when scene
|
||||
tracing is switched on - the story so far, as it were.
|
||||
Changes in the type-checker should cause Inform to compile slightly more
|
||||
efficient code: it also checks a few more cases, and notably that the
|
||||
parameters of an action in a "try" phrase are genuinely of the right
|
||||
kind of value for the action in question.
|
||||
Bug fixed in which phrases to decide if something-or-other would sometimes
|
||||
not properly be parsed where they naturally begin with "the": so that,
|
||||
for instance, the condition "if the action requires a touchable noun..."
|
||||
would sometimes fail because of the "the".
|
||||
Bug fixed to do with spurious paragraphs such as "On the mantelpiece is a
|
||||
brass clock." being produced in room descriptions when the mantelpiece
|
||||
is scenery, and the brass clock has already been mentioned.
|
||||
Bug fixed whereby the creation of three things X, Y and Z with text in the
|
||||
pattern "an X of Y and a Z" would sometimes cause Z to be created with
|
||||
no article, i.e., as if its name were a proper noun - ignoring the "a".
|
||||
Bug fixed whereby testing if "X is in R", where X is a thing and R is a
|
||||
region, would always come up negative even if X was in a room inside
|
||||
that region. It now makes the obviously intended test.
|
||||
Bug fixed to do with incorrect casing when printing a literal value in a
|
||||
pattern which includes words already occurring earlier in the source
|
||||
with different casing from that in the pattern.
|
||||
Bug fixed causing programming errors to appear at run-time when attempting
|
||||
to push an enterable container between rooms while within it (by
|
||||
punting down a river, perhaps).
|
||||
Bug fixed causing occasional hangs, under Glulx only, when the player
|
||||
character in inside or on something and also has component parts.
|
||||
Bug fixed causing snippet replacement to leave the wrong number of words
|
||||
behind, under Glulx only.
|
||||
(Windows only) Clicking on a link in a problem report that points to an
|
||||
extension does not open a new window if the extension is already open in
|
||||
another window.
|
||||
Problem messages added for duplicate definitions of verbs or prepositional
|
||||
usages.
|
||||
Problem messages to do with misphrased property declarations improved.
|
162
Changes/Change Logs/4B91.txt
Normal file
162
Changes/Change Logs/4B91.txt
Normal file
|
@ -0,0 +1,162 @@
|
|||
4B91 (10 November 2006)
|
||||
|
||||
(Windows only) Images now appear in the game tab when running a Glulx game,
|
||||
rather than the place holder "[Image n]" text. (This brings the Windows
|
||||
application into line with the OS X one.)
|
||||
(Windows only) The right-click menu for the source tab now includes a sub-menu
|
||||
to change the size of the text.
|
||||
(Windows only) Ctrl-Delete and Ctrl-Backspace in the source tab no longer
|
||||
confuse the undo logic.
|
||||
(Windows only) The cursor arrow keys now work in the game tab.
|
||||
(Windows only) The toolbar should no longer appear corrupted on 24-bit displays.
|
||||
(Windows only) When running Glulx games in the game tab, the
|
||||
stylehint_Proportional flag is now respected.
|
||||
(Windows only) When running Glulx games in the game tab, glk_window_clear()
|
||||
now works.
|
||||
On both the Mac OS X and Windows applications, documentation searches now
|
||||
cover the examples as well as the main text, and search results are
|
||||
more clearly displayed.
|
||||
The Glulx story file format is fully supported by Inform for textual works,
|
||||
and we have therefore documented it as a choice available for designers:
|
||||
see section 2.13, now retitled "Limits and the Settings panel".
|
||||
The commonest source of problems with Glulx to date has been to do with
|
||||
screen effects such as coloured text and menus, and in particular to
|
||||
do with the extension "Basic Screen Effects", which works only for the
|
||||
Z-machine formats. Because of this, and because we expect that people
|
||||
will want to write other extensions providing unusual effects, two
|
||||
new features have been added:
|
||||
- An extension can describe itself, in its top line declaration, to
|
||||
be for a limited range of story file formats. This is displayed in
|
||||
the "Installed Extensions" documentation chapter, and an attempt to
|
||||
use an extension with a story file format which does not match will
|
||||
produce an explanatory problem message.
|
||||
- Individual headings can specify that they contain material to be
|
||||
used only with certain story file formats. This allows extensions, in
|
||||
particular, to provide different implementations of the same idea -
|
||||
for instance, a Glulx version and a Z-machine version - so that the
|
||||
user will get the same behaviour whatever the current project Settings.
|
||||
See the new section 21.6: "Extensions and story file formats".
|
||||
The use of illustrations is now officially supported. This was implemented
|
||||
in 3Z95 but documented only in the change log; for this build a new
|
||||
chapter on illustrations, Chapter 19, has now been added to the
|
||||
documentation.
|
||||
The "Release along with an existing story file" option has been improved,
|
||||
and is now fully documented for the first time: see the new section
|
||||
20.15, "Republishing existing works of IF". This enables Inform 6
|
||||
users, or those with old games compiled using Informs 1 to 6, to
|
||||
repackage them with cover art and bibliographic data for modern
|
||||
interpreters such as Zoom, Spatterlight or Windows Frotz.
|
||||
"When play ends" rules are now run when play ends "in victory"; previously,
|
||||
they were run on every other outcome but not this one. This is a change
|
||||
in the design rather than a bug fix, so it may cause existing source
|
||||
text to change its behaviour: if you are using "when play ends" rules
|
||||
in a work in progress, you may want to test to see if victory is still
|
||||
presented as you would wish it.
|
||||
If a scene is created with a name such as "Grand Finale", one can now
|
||||
write rules for "When the Grand Finale begins: ...", etc., equivalently
|
||||
to "When Grand Finale begins: ...". (This is in effect a bug fix, since
|
||||
the same text would previously have created a spurious rule called
|
||||
'Grand Finale begins' which was never invoked, rather mysteriously.)
|
||||
The syntax "otherwise if" (or "else if") is now allowed. This divides up
|
||||
an "if ... begin; ...; end if", for instance as follows:
|
||||
if the player is in the Garden
|
||||
begin;
|
||||
say "The wind rustles the long grass.";
|
||||
otherwise if the player is in the Gazebo;
|
||||
say "The wind catches at the canvas roof of the Gazebo.";
|
||||
end if.
|
||||
There can be any number of "otherwise if"s within an "if... end if".
|
||||
(Note the lack of a "begin" at the end of each "otherwise if" - the "if"
|
||||
is all one block of phrases.)
|
||||
This new syntax is somewhat experimental, so will be documented in the
|
||||
next build rather than this one.
|
||||
Problem messages have been added for use of '[if ...]' inside an existing
|
||||
'[if ...]', and for '[otherwise]' or '[end if]' used with no matching
|
||||
'[if ...]'.
|
||||
Extensions:
|
||||
Basic Screen Effects revised to compile correctly under both Glulx and
|
||||
Z-machine; documentation updated; version number advanced to 3. (Thanks
|
||||
to Eric Eve for his contributions.)
|
||||
Plurality revised to include additional management for pronoun behavior
|
||||
(providing wrappers for Inform 6's MANUAL PRONOUNS constant and the
|
||||
PronounNotice() routine), and to print "you" when the item described is
|
||||
the player, in it/them phrases; documentation updated; version number
|
||||
advanced to 2.
|
||||
Punctuation Removal revised to indicate that it is for the Z-machine only.
|
||||
Examples:
|
||||
"Garibaldi" altered to reflect that colored lettering can be used only
|
||||
under the Z-machine.
|
||||
"Scooby" reworded slightly to avoid a conflict with the new "otherwise if".
|
||||
The limit on the size of a single I6 code inclusion, previously 10K, has
|
||||
been substantially raised (to 200K): this for the benefit of one or
|
||||
two complex extensions needing to incorporate very long hand-coded
|
||||
I6 routines.
|
||||
Problem message added for actions applying to two non-object values at once,
|
||||
and bug fixed which (sometimes) caused this to generate a spurious
|
||||
problem message on the wrong action.
|
||||
Problem message added for "...an X with L", where L is a literal value
|
||||
such as a number, rather than the previous internal error.
|
||||
Problem message added for "X is a value that varies", which doesn't say
|
||||
what kind of value it is, rather than the previous internal error.
|
||||
Problem message added for relations created between kinds of value with
|
||||
an infinite range, in those cases where this is forbidden because
|
||||
the run-time storage needed would be impracticable.
|
||||
Problem message added for compiled descriptions which contain local variables
|
||||
(which will no longer exist when these descriptions need to be used:
|
||||
this resulted in enigmatic "subtype of oversized local" internal errors).
|
||||
Problem message added for calling a variable simply "variable", as in
|
||||
"The favourite son is a variable."
|
||||
Bug fixed in which I7 could sometimes crash on being asked to place rule A
|
||||
after or before rule B in rulebook R, when B is not in fact in R: an
|
||||
explanatory problem message has been added to respond to this.
|
||||
Bug fixed in which a room could not be called simply "Void".
|
||||
Bug fixed in which boxed quotations would sometimes produce array lookup
|
||||
errors. (A bug introduced only in 3V01: apologies.)
|
||||
Bug fixed in which text containing an "[if ...]" and then an "[otherwise]"
|
||||
but no "[end if]" and finally a substitution containing an ambiguity
|
||||
not soluble at compile time would sometimes generate I6 code missing
|
||||
a label definition, causing I6 to reject the output of I7.
|
||||
Bug fixed in which number variables initialised to negative numbers would
|
||||
be created with the wrong value.
|
||||
Bug fixed in which attempts to match a snippet against a non-topic would
|
||||
crash the virtual machine: they now produce a new run-time problem.
|
||||
Bug fixed in which reaching inside rules affected removing differently from
|
||||
taking.
|
||||
Bug fixed in which RELATIONS testing command gives incorrect output for
|
||||
some object-to-value relationships.
|
||||
Bug fixed in which actions applying to two values, and using the word "with"
|
||||
in their names, were not always possible to categorise as named actions.
|
||||
Bug fixed whereby "(with nouns reversed)" did not work when applied to actions
|
||||
whose names consisted of a single word.
|
||||
Bug fixed to do with "P of the X of Y", e.g., "price of the bag of sweets",
|
||||
being misread.
|
||||
Bug fixed whereby "let Name be Value" would sometimes create Name with the
|
||||
wrong kind of value (e.g. a time instead of an object) in cases where
|
||||
the Value part was susceptible to multiple interpretations.
|
||||
Bug fixed causing a value consisting of the lone word "entry" to cause an
|
||||
internal error.
|
||||
Bug fixed whereby setting a description for generic player-characters would
|
||||
cause I6 to fail to compile I7's output.
|
||||
Bug fixed whereby a test scenario specifying that the player must be "in the
|
||||
Holding Cell", etc., would crash due to misreading "holding" as the
|
||||
start of a requirement about what is being held; also, if a capital H is
|
||||
used for Holding, then this ambiguity no longer arises.
|
||||
Bug fixed in which the problem message for an object whose name is purely
|
||||
textual would be followed by a spurious internal error.
|
||||
Bug fixed in which a wrongly phrased condition followed by a "try ..."
|
||||
would sometimes produce an internal error as well as the intended
|
||||
problem message.
|
||||
Bug fixed in which an "accidental clash of names" problem would similarly
|
||||
sometimes cause an internal error as well.
|
||||
Bug fixed in which, once again, a problem reported in a "let X be Y" phrase
|
||||
might also lead to a bogus internal error later.
|
||||
Bug fixed in which 'Definition:' at the end of the source, with no definition,
|
||||
would crash Inform.
|
||||
Bug fixed in which a nameless new phrase, defined by just 'To:', would
|
||||
cause an internal error.
|
||||
Bug fixed causing a close quotation mark to be omitted when quoting an
|
||||
incorrect "Understand..." sentence in certain problem messages.
|
||||
Bug fixed in which definitions wrongly referring to properties would cause
|
||||
the right problem message to be reported, but on the wrong sentence.
|
||||
Bug fixed in which I6 library (as included in 3Z95) failed to compile for
|
||||
purely I6 projects.
|
151
Changes/Change Logs/4F59.txt
Normal file
151
Changes/Change Logs/4F59.txt
Normal file
|
@ -0,0 +1,151 @@
|
|||
4F59 (21 December 2006)
|
||||
The main purpose of this build is to publish a redesigned system for
|
||||
phrase and rule declarations, fixing a number of miscellaneous bugs,
|
||||
removing some exceptions and clarifying ambiguities in the existing design.
|
||||
Chapter 18 of the documentation is substantially rewritten as a result, and
|
||||
the Rules page of the index has been redesigned. We believe that the new
|
||||
design is much less ambiguous and, as a result, more fully explained than
|
||||
the old, but the removal of some of these ambiguities does mean that minor
|
||||
changes to some existing source text will be needed. If you have a work in
|
||||
progress nearing its completion, you may need to test that the new rules
|
||||
system does not change its behaviour.
|
||||
|
||||
Phrases can be defined by "To ...:" (declaring a new phrase to be used in
|
||||
the definitions of other phrases), by "Definition:" (defining adjectives),
|
||||
by "At ...:" (declaring events to happen at given times) or as rules
|
||||
to go into rulebooks (for instance, "Instead of taking:" goes into the
|
||||
"instead" rulebook). In order to make it easier to tell immediately
|
||||
which of these four forms is intended:
|
||||
(i) Rulebook names are now forbidden to begin with the words
|
||||
"To", "At" or "Definition". (So far as we are aware, nobody
|
||||
has ever done this, so this should not cause inconvenience.)
|
||||
(ii) Events happening at a fixed time are written "At 3:02 AM:" or
|
||||
similar: events happening at some time not yet determined are
|
||||
now written "At the time when the clock chimes:" rather than,
|
||||
as in previous builds, just "When the clock chimes:". This
|
||||
removes the confusing ambiguity with scene start/end rules
|
||||
(e.g. "When Scene IV begins:") and with "When play begins:", etc.
|
||||
When Inform adds rules to rulebooks, it sorts them so that more specifically
|
||||
applicable rules (say, "instead of taking the fish") come before vaguer
|
||||
ones ("instead of taking or dropping something"). The method of sorting
|
||||
used was largely unchanged from 3K27 to 4B91, but has now sharpened
|
||||
in the following ways:
|
||||
(i) being "in" a room is considered more specific than in a region,
|
||||
(ii) and in a subregion more specific than in a super-region,
|
||||
(iii) "during..." clauses are now taken account of,
|
||||
(iv) "in the presence of..." clauses are now taken account of,
|
||||
(v) rules attached to a wider range of actions ("taking or dropping")
|
||||
are less specific than rules attached to a narrower range
|
||||
("taking"),
|
||||
(vi) rules with longer or more complicated "when" conditions are
|
||||
considered more specific than those with shorter,
|
||||
(vii) rules applying in a limited range of turns or for a limited
|
||||
number of times are considered more specific than other such
|
||||
rules if the number of turns in which the rule could apply
|
||||
is smaller.
|
||||
Though these changes may change the effect of some complicated source
|
||||
texts now standing, they should only really affect cases where rules
|
||||
were previously considered equally applicable.
|
||||
When the Index shows the contents of a rulebook, it now uses a graphical
|
||||
notation to show which rules are considered more specific than which
|
||||
others. Hovering the mouse over one of the icons used in this notation
|
||||
causes a "tool tip" to be displayed which explains on what basis the
|
||||
decision was taken.
|
||||
The special verb "to be listed", used to specify how named rules are listed
|
||||
in rulebooks, is now more flexible. The existing syntax remains:
|
||||
The summer breeze rule is listed in the every turn rules.
|
||||
The summer breeze rule is listed after the chirping magpie rule
|
||||
in the every turn rules.
|
||||
The summer breeze rule is listed before the chirping magpie rule
|
||||
in the every turn rules.
|
||||
And the following possibilities are added:
|
||||
The summer breeze rule is listed first in the every turn rules.
|
||||
The summer breeze rule is listed last in the every turn rules.
|
||||
The can't eat unless edible rule is not listed in the check eating rules.
|
||||
The can't eat unless edible rule is not listed in any rulebook.
|
||||
The refined palate rule is listed instead of the can't eat unless
|
||||
edible rule in the check eating rules.
|
||||
The last three possibilities allow rules to be abolished for the whole
|
||||
game without the need for procedural rules. (A rule abolished in this way
|
||||
still exists, it merely isn't found in rulebooks at the start of play.)
|
||||
This will make extensions which carry out large-scale library changes
|
||||
more efficient.
|
||||
A "when/while" clause can now be attached to a rule in an object-based
|
||||
rulebook not derived from an activity. (These used to be the only
|
||||
rulebooks whose rules were not allowed a "when" clause, so the change
|
||||
removes an unnecessary exception.)
|
||||
The synonym "final" for "last", in the context of rulebook placements, has
|
||||
been withdrawn - it was an unnecessary complication. Thus "The last
|
||||
chirping magpie rule:" still works, but "The final chirping magpie rule:"
|
||||
does not.
|
||||
The new text substitution "[otherwise if ...]" has been added: this can be
|
||||
used in text, between "[if ...]" and "[end if]" substitutions, in just
|
||||
the same way that the phrase "otherwise if ..." can be used between
|
||||
"if ..." and "end if" phrases.
|
||||
A new rulebook, "does the player mean", has been added to give the parser
|
||||
clues on how to disambiguate commands. (This offers facilities analogous
|
||||
to those provided by ChooseObjects in Inform 6, but applying to whole
|
||||
actions and not to nouns alone.) See the new section 16.16 in the
|
||||
documentation.
|
||||
Changes to the examples are as follows:
|
||||
Masochism Deli added to demonstrate "does the player mean..." rules.
|
||||
Flotation added to demonstrate an object-based rulebook and named outcomes.
|
||||
Being Peter added to demonstrate an action-based rulebook with named
|
||||
outcomes.
|
||||
Bronze, 3 AM, MRE, Mr Spruce's Non-Modal Question, Chronic Hinting
|
||||
Syndrome, Fifty Times Fifty Ways, Happy Hour, Lakeside Living,
|
||||
Lemonade, Noisy Cricket, Patient Zero, Y Ask Y modified to show
|
||||
"otherwise if" better.
|
||||
Barter Barter, Bribery, Bruneseau's Journey, The Dark Ages Revisited,
|
||||
Emma, Fragment of a Greek Tragedy, Mimicry, Minimal Movement,
|
||||
Nickel and Dimed, Stately Gardens, Under Contract, Waning Moon
|
||||
modified to get rid of now-unnecessary procedural rules and use
|
||||
"is not listed..." instead.
|
||||
Aftershock, Crusoe, Get Axe, The Hang of Thursdays, Panache, Swigmore U,
|
||||
Uptempo, Zqlran Era 8 modified to get rid of now-unnecessary
|
||||
procedural rules and use "is listed instead of..." instead.
|
||||
Instant Examine and Look modified to get rid of procedural rule in favor
|
||||
of a first rule in the turn sequence rules. Commentary added to
|
||||
explain how the procedural rule might be used and why the first-rule
|
||||
method might be preferable.
|
||||
No Place Like Home reassigned to the Awarding Points section, as being
|
||||
more relevant there.
|
||||
Strictly Ballroom corrected for a missing word.
|
||||
Up and Up modified to use after going rather than before, as this is more
|
||||
reliable.
|
||||
Beneath the Surface improved to make the chair a supporter.
|
||||
Witnessed 1 expanded to include new "does the player mean..." rules,
|
||||
improving parsing behavior of the example.
|
||||
The Night Before added to demonstrate "does the player mean..." rules to
|
||||
lower the parsing significance of body parts belonging to the player
|
||||
compared to those of other people;
|
||||
Hudsucker Industries substantially updated to simplify logic, provide
|
||||
better parsing behavior using "does the player mean..." rules, and
|
||||
allow the player to refer to sorted letters by property.
|
||||
Costa Rican Ornithology given slightly more explanation of the topic
|
||||
column, since this appears before the format has been fully introduced.
|
||||
We, and the two gas diffusion examples, moved to a new location.
|
||||
We given slightly more commentary to point users at extensions for
|
||||
changing library messages if they want to do so wholesale.
|
||||
No Relation edited to discuss how Instead of going by... applies to
|
||||
vehicles and other objects.
|
||||
Morning After edited for a typo in the commentary.
|
||||
Uptown Girls edited for a typo in the source text.
|
||||
File extension for blorbed Glulx-format releases changed from ".zblorb"
|
||||
to ".gblorb". (Apologies: an oversight.)
|
||||
The horizontal compass directions can no longer automatically be referred to
|
||||
by the word "wall", so that "examine the north wall" no longer generates
|
||||
the action of examining north. This was an old Infocom convention, carried
|
||||
over into Inform 6 for some years, but which causes problems more often
|
||||
than it confers benefits.
|
||||
Bug fixed by which (on Windows only) accented letters sometimes caused
|
||||
confusion with digits.
|
||||
Bug fixed by which a rule which applied e.g. "for the third to eighth time"
|
||||
(an explicit range of iterations) would generate code which failed to
|
||||
compile in I6.
|
||||
Bug fixed in which rules "listed after" or "listed before" might give
|
||||
spurious problems if the rulebook named had a name including the
|
||||
word "with".
|
||||
Bug fixed whereby the Glulx interpreter was not checked to see if it could
|
||||
provide pictures before being instructed so to do, which produced
|
||||
problems with some text-only Glulx interpreters.
|
113
Changes/Change Logs/4K40.txt
Normal file
113
Changes/Change Logs/4K40.txt
Normal file
|
@ -0,0 +1,113 @@
|
|||
4K41 (23 January 2007)
|
||||
|
||||
4K40 contained a bug making it unreliable under Mac OS X on G4 or G5
|
||||
processors: 4K41 is believed to fix this, with our apologies for the
|
||||
inconvenience. In all other respects it is identical to 4K40 and
|
||||
Mac OS X users with Intel processors need not download again.
|
||||
|
||||
4K40 (23 January 2007)
|
||||
|
||||
(Mac OS X only) The Skein's appearance has been redesigned, and an illustrated
|
||||
tutorial to the new-look Skein now appears as section 1.8 of the
|
||||
documentation for the OS X application. (We hope that similar changes
|
||||
will be made shortly in the Windows application.)
|
||||
(Mac OS X only) The Skein panel now has a Layout... button for customising
|
||||
the width and height proportions of the skein display.
|
||||
(Windows only) Documentation links from the Index tab now work with Internet
|
||||
Explorer 7.
|
||||
(Windows only) The size, italic, text colour and background colour style hints
|
||||
are now supported when running a Glulx game in the game tab.
|
||||
New activities "clarifying the parser's choice of something" and "asking
|
||||
which do you mean" allow customisation of the familiar messages:
|
||||
(the mahogany inlaid box)
|
||||
and
|
||||
Which do you mean, the mahogany inlaid box or the icebox?
|
||||
Extensions:
|
||||
Punctuation Removal made bi-platform (and version number advanced to 2).
|
||||
Version 4 of Plurality by Emily Short now responds correctly to
|
||||
male/female settings even if the items in question are not of the
|
||||
man/woman kind, and adds several further tokens.
|
||||
Examples:
|
||||
Magneto's Revenge fixed to use "the person reaching" rather than "the
|
||||
person asked".
|
||||
Changes to Waning Moon, Air Conditioning is Standard, and Fifty Times
|
||||
Fifty Ways to correct typos.
|
||||
Veronica added to demonstrate leaving a region.
|
||||
Numberless added to demonstrate two ways to emulate a switch statement.
|
||||
Pine4 given a tiny fix to make its articles behave better.
|
||||
The rules for the sorting of grammar lines in the grammar for command verbs
|
||||
have been slightly changed. Few users should notice any difference, but
|
||||
one change means that grammar added to cover "mistakes" should now no
|
||||
longer be able to "mask" grammar for non-mistaken commands, something
|
||||
which had been reported previously as a bug.
|
||||
Problem message added for attempting to use "Understand the command ... as
|
||||
... when ...", where some condition follows the "when": this has never
|
||||
been supported, but in previous builds the "when" clause was silently
|
||||
ignored.
|
||||
Problem message added for attempting to use the "[text]" token in a
|
||||
table entry or a ... matches ... condition, where it is not allowed.
|
||||
A new rule called the "very unlikely to mean taking what's already carried
|
||||
rule" improves the parser's handling of TAKE SPLODGE when there are
|
||||
several splodges in different places, some of them carried.
|
||||
Blue "help" icon added to "Does the player mean..." in the Rules index.
|
||||
A long-standing bug fixed whereby things introduced without an article would
|
||||
sometimes be given one, rather than being consider proper nouns (or mass
|
||||
nouns): for instance, in "The player carries a small key, a tent, and
|
||||
Variety Magazine.", the source text clearly suggests that Variety
|
||||
Magazine is a proper noun, and I7 now recognises this.
|
||||
Two bugs fixed to do with "when..." clauses attached to rules in unusual
|
||||
situations - both bugs having appeared only in 4F59. One related to
|
||||
rules in the form "check A when B", where A is an action including
|
||||
the word "it" (such as "telling it about") and B a condition; the
|
||||
other to "when" clauses attached to object-based rulebooks known never
|
||||
to run during activities, notably the reaching inside rules. In each
|
||||
case spurious problem messages were generated.
|
||||
Bug fixed so that things are no longer "lockable" by default. (Instead,
|
||||
locked containers and locked doors are lockable by default.)
|
||||
Bug fixed whereby an instruction like "Understand "[any actor]" as James
|
||||
Bond." would generate I6 code failing to compile through I6.
|
||||
Bug fixed whereby one token to match an object making use of another one
|
||||
would sometimes find the result corrupted: for instance,
|
||||
Understand "leg of [person]" as a leg.
|
||||
would get confused between the leg and the person whose leg it is said
|
||||
to be.
|
||||
Bug fixed whereby some combinations of name words and tokens to match the
|
||||
names of objects did not work.
|
||||
Bug fixed whereby meaningless text would sometimes match a "[number]" token
|
||||
when parsing. Moreover, "[number]" has been improved so that it now
|
||||
matches any literal decimal between -32768 and 32767 inclusive (i.e., the
|
||||
full 16-bit range of signed integers supported by the Z-machine) rather
|
||||
than duplicating the peculiar behaviour of the I6 number-parser, which
|
||||
worked only on non-negative numbers up to 10000.
|
||||
Bug fixed which caused too many things (and rooms) to have plural forms of
|
||||
their names recognised: for instance, a "red chair" would be referrable
|
||||
to in the plural as "red chairs" even if it was the only one, and this
|
||||
would cause ambiguity if a second object were in the same place and
|
||||
with its main singular name coincidentally "chairs". The convention
|
||||
now is that an object can be referred to in the plural with a name
|
||||
inherited from its kind if and only if it has no name of its own. (This
|
||||
change sounds substantial, but in fact did not change the behaviour of
|
||||
any of the examples.)
|
||||
Bug fixed whereby large numbers of identical objects could cause mysterious
|
||||
things to happen if ever 64 of them are in the same place at the same
|
||||
time. (In fact an I6 library bug: thank due to Martin Bays for his fix,
|
||||
which is patch L61125.)
|
||||
Bug fixed in which two things without names of their own were sometimes
|
||||
considered "indistinguishable" by the I6 parser, and therefore grouped
|
||||
into a plural (e.g., "six red blocks"), when in fact they were
|
||||
distinguishable by virtue of having a visible property which differed
|
||||
between the two (e.g., some being red, some being blue).
|
||||
Bug fixed causing documentation of examples in extensions to have any
|
||||
Inform 6 fragments in (- ... -) brackets lose the -). In particular,
|
||||
this affected the example in Menus by Emily Short.
|
||||
A limit on the number of different "in the presence of..." clauses
|
||||
allowed in a single source text has been removed. (Previously it stood
|
||||
at 100: now there is no limit.)
|
||||
A limit on the number of different noun- and scope-filtering tokens
|
||||
allowed in a single source text has been removed. (Previously it stood
|
||||
at 100: now there is no limit.)
|
||||
A limit on the number of new kinds of value which could be created by a
|
||||
single source text has been removed. (Previously it stood at 400: now
|
||||
there is no limit.)
|
||||
Two bugs fixed causing crashes in unlikely circumstances after a problem
|
||||
has been encountered.
|
992
Changes/Change Logs/4S08.txt
Normal file
992
Changes/Change Logs/4S08.txt
Normal file
|
@ -0,0 +1,992 @@
|
|||
4S08 (25 March 2007)
|
||||
|
||||
This build represents a substantial update in five respects: it fixes all
|
||||
known bugs - some 335 bug reports have been acted on since 4K41 and the
|
||||
database of open bug report forms is now empty for the first time since
|
||||
the public beta was released as 3K27; it introduces the first batch of
|
||||
improvements proposed in the January 2007 consultation document (called
|
||||
simply "the January document" below); it makes the first real reform of
|
||||
paragraph-spacing since 3K27; it makes the first tentative steps towards
|
||||
Inform 7 for Linux, though at present as a command-line system without the
|
||||
graphical user interface; and it is accompanied by more supporting
|
||||
materials than previous builds, notably free-standing documentation and a
|
||||
formal grammar.
|
||||
|
||||
Inevitably it has a lengthy change log, which is grouped thematically below.
|
||||
Enough minor changes have been made to the interpretations of syntax that
|
||||
authors of any large work in progress will find at least one or two things
|
||||
they need to change. Possible trouble-spots are marked with an arrow >-->.
|
||||
|
||||
|
||||
INFORM 7 FOR LINUX
|
||||
|
||||
Inform 7 is now available for Linux for the i386, ppc, armv5tel, and s390
|
||||
architectures. All compilers and interpreters supplied as part of the
|
||||
Inform 7 package are statically linked and should have no dependencies
|
||||
beyond stdio. The i7 shell itself is written in Perl, but does not
|
||||
require any modules not customarily shipped as part of the Perl
|
||||
distribution. The only additional dependency is the uuidgen program;
|
||||
this is part of the ext2tools package and has so far been present as
|
||||
part of the default installation on all systems we have examined.
|
||||
Installation instructions can be found in the file INSTALL, and
|
||||
operational instructions in README or the manual page installed by
|
||||
the Inform installer.
|
||||
Users on Intel 386-and-descendants machines should download the package
|
||||
I7_4S01_Linux_i386.tar.gz. All users on other architectures
|
||||
should download I7_4S01_Linux_all.tar.gz. The difference between
|
||||
these two is simply whether or not non-i386 compilers and interpreters
|
||||
are bundled - the "all" version will function perfectly well for Intel
|
||||
users, but it is substantially larger to download. The correct set for
|
||||
your architecture will be detected at installation time.
|
||||
|
||||
|
||||
INFORM 7 FOR MAC OS X
|
||||
|
||||
The OS X application contains a number of bug fixes in the CocoaGlk layer,
|
||||
that is, to the underlying interpreters used in the Game panel.
|
||||
|
||||
|
||||
INFORM 7 FOR WINDOWS
|
||||
|
||||
Pasting text into the source panel should no longer lose any trailing
|
||||
carriage returns.
|
||||
Echo streams are supported in the game panel's Glk implementation.
|
||||
Skein and transcript improvements:
|
||||
Knots that have been played in a game session are coloured
|
||||
yellow, and all other knots are coloured green.
|
||||
Knots with blessed text are lighter than those without.
|
||||
If the last played text for a knot does not match the blessed text,
|
||||
the node is shown with a red badge. Double clicking the red badge
|
||||
goes to the appropriate point in the transcript tab.
|
||||
The skein's context menu has been reworked to match the OS X
|
||||
application.
|
||||
A confirmation dialog appears when deleting a locked knot.
|
||||
Threads are automatically locked when blessed or when a label is added
|
||||
or changed.
|
||||
Bug fixed whereby blue "link to documentation" icons were, in the most recent
|
||||
Windows build, in some cases off by one or two sections.
|
||||
|
||||
|
||||
SUPPORTING DOCUMENTATION
|
||||
|
||||
As from this build, we are uploading the "Writing with Inform" documentation
|
||||
in two plainer formats than those already available: plain text, and
|
||||
a zipped archive of minimally-tagged HTML files. We hope that this will
|
||||
make reference easier for those using screen-reading software, in
|
||||
particular. (This was (6.7) in the January document.)
|
||||
We are also uploading a PDF document extracted from the NI source code which
|
||||
specifies the formal grammar read by NI (or rather, that part of it not
|
||||
already specified in the Phrasebook index): in the January document we
|
||||
expressed scepticism that this would really be useful, but responders
|
||||
disagreed. We continue to be sceptical, but it wasn't too hard to generate
|
||||
the document, so here it is.
|
||||
|
||||
|
||||
EXAMPLES AND EXTENSIONS INCLUDED WITH INFORM
|
||||
|
||||
Examples:
|
||||
Added "Apples" to demonstrate "asking which do you mean" rules.
|
||||
Added "Ahem" to demonstrate phrases with alternate elements
|
||||
(the 300th example to be written).
|
||||
Added "Pages" to demonstrate phrases pertaining to specific values
|
||||
Added "Hover" to demonstrate interior descriptions of vehicles placed
|
||||
before the rest of a room description.
|
||||
Added "Walls and Noses" to demonstrate advanced modification of the
|
||||
disambiguation question.
|
||||
Added "Electrified" to demonstrate modification of the action-processing
|
||||
rule sequence.
|
||||
Added "Straw Boater" to demonstrate testing for the default text "".
|
||||
Added "Ferragamo Again" to demonstrate phrases applying to specific objects.
|
||||
Added "Mattress King" to demonstrate modifying the action to push things
|
||||
between rooms.
|
||||
Added "Lollipop Guild" to demonstrate turning off implicit takes when
|
||||
eating an object that is fixed in place.
|
||||
Modified "Abolition" to reflect changes in the handling of "to" in
|
||||
action names.
|
||||
Corrected "Neighborhood Watch" to add a check for cases where the door
|
||||
is already locked or unlocked.
|
||||
Assorted minor changes to examples to handle spacing changes.
|
||||
Extensions:
|
||||
Locksmith: advanced to version 3 and made modifications due to the new
|
||||
spacing mechanisms.
|
||||
Glulx Image Centering: Corrected documentation.
|
||||
Rideable Vehicles: advanced to version 2. Rules added for people other
|
||||
than the player to mount and dismount vehicles; rule names given to
|
||||
the existing rules, so that they may be more easily revised or
|
||||
replaced by the user of the extension.
|
||||
>--> Plurality: advanced to version 5, and forms of phrases changed to is-are
|
||||
(etc) rather than is/are. This will require authors using Plurality
|
||||
to do a search and replace to change formats. (Sorry.)
|
||||
>--> Complex Listing: advanced to version 4, and forms of phrases change to
|
||||
is-are (etc) rather than is/are. This will require authors using
|
||||
Complex Listing to do a search and replace to change formats. (Sorry.)
|
||||
Behavior of "[prepared list]" changed to use no articles, just as
|
||||
"[list..." uses no articles now in Inform by default. More flexible
|
||||
phrasings added to several phrases, so that "prepare list..." is
|
||||
accepted as well as "prepare a list...", and "register the things..."
|
||||
is accepted alongside "register things...".
|
||||
Menus: advanced to version 2. Added options allowing up and down arrows
|
||||
to function properly under Glulx.
|
||||
|
||||
|
||||
KINDS OF VALUE
|
||||
|
||||
When Inform has to initialise variables or property values, but the source
|
||||
gives no value, it uses a default value for the appropriate kind of value.
|
||||
For instance, a number is 0 unless otherwise specified, and a text is
|
||||
the empty text "". The Kinds index (in which a number of minor bugs have
|
||||
been fixed) now tabulates the default values used for each kind of value
|
||||
which can be stored in variables or properties. (This and related changes
|
||||
following cover (6.34) in the January document.)
|
||||
It is now legal to declare a "specification text" for a kind of value,
|
||||
analogously with kinds of object, and this is used in the Kinds index.
|
||||
New scene "Entire Game" created which, as the name implies, contains the
|
||||
whole of play except for the posthumous restart, restore or quit
|
||||
conversation. (This is the default value for scenes.)
|
||||
The constant "nothing" now means the absence of an object, in the context
|
||||
of testing an object-valued variable or property to see if it holds the
|
||||
default value for "object", and is also useful when looking at the
|
||||
result of things like "best route from the Drawbridge to the Keep"
|
||||
(if there is in fact no route).
|
||||
Problem message added to explain more fully when an action name is used as a
|
||||
new value (for instance, if we write "Lamp strength is a kind of value.
|
||||
The lamp strengths are burning and gone out.", then "burning" would clash
|
||||
with the name of the action).
|
||||
Bug fixed (in consequence of above) whereby creating but not initialising a
|
||||
scene variable or property caused an internal error.
|
||||
Bug fixed whereby comparison of a text with "" often gave false negatives.
|
||||
|
||||
|
||||
NAMED VALUES
|
||||
|
||||
>--> When ambiguous values occur, local variable names (created by 'called'
|
||||
or by 'let') are now given priority over other possibilities.
|
||||
When a "(called...)" name appears in a rule, any article used will not be
|
||||
taken as an immutable part of the name. For instance, "Instead of examining
|
||||
a door (called the portal): ..." will now create a temporary value called
|
||||
just "portal", not "the portal". Of course, "the portal" can still be
|
||||
used to describe this value, but now being parsed as "the" + "portal",
|
||||
and this means that text substitutions "[a portal]" and "[the portal]"
|
||||
can differ.
|
||||
Problem message added to forbid the use of "(called ...)" when giving a
|
||||
complex range of things to be repeated through: this was accidentally
|
||||
allowed in previous builds, and produced subtly incorrect results.
|
||||
Problem message added (in place of internal error) to catch attempts to use
|
||||
local values created by 'let' or 'repeat' or 'called' in past-tense
|
||||
references which pertain to times when they did not exist.
|
||||
Problem message added to report contradictions of kind when a variable is
|
||||
declared more than once and each time as a kind of object.
|
||||
Bug fixed whereby conditions involving negated existential quantifiers, and
|
||||
giving called names to the results, would sometimes incorrectly fail.
|
||||
(For instance, "a person who is not wearing anything" would work but
|
||||
"a person (called the extrovert) who is not wearing anything" would fail.
|
||||
The negated existential here is the clothing being worn - which is
|
||||
required not to exist.)
|
||||
Bug fixed whereby "a random D", where D is a description including a
|
||||
"(called ...)" clause, would (although legal) cause I6 errors.
|
||||
Bug fixed whereby variables set up with non-existent kinds ("Z is a
|
||||
bogosity that varies") would sometimes produce internal errors rather
|
||||
than a problem message.
|
||||
|
||||
|
||||
TEXT
|
||||
|
||||
>--> Inform has a fairly delicate mechanism for placing paragraph breaks
|
||||
automatically at "the right" points in text produced by various different
|
||||
rules. Its aim is to save the writer from having to think about this.
|
||||
Four main defects have been found in the original Public Beta algorithm,
|
||||
and in this build we address all of them. We believe the result is a
|
||||
better system, but it does mean that the dodges people have used up to
|
||||
now to compensate for faults of the old algorithm will need to be
|
||||
removed or changed. (We had to remove a dozen or so spurious
|
||||
"[line break]"s from the Examples, for instance: the end result was
|
||||
much less intervention in how paragraphs were being broken, and this
|
||||
suggests that the automatic system is now more trustworthy.) This
|
||||
addresses proposal (6.45) in the January document.
|
||||
When defining a new text substitution, it is now legal to add "-- running on"
|
||||
as a note at the end of the preamble. The effect of this is that any
|
||||
newline implied by the immediately preceding text is ignored. Thus
|
||||
To say note -- running on: say "(1)".
|
||||
can be used in text such as
|
||||
"I prefer to avoid footnotes.[note]"
|
||||
without a newline being forced after the full stop under the "sentence
|
||||
ending punctuation at the end of literal passages of text implies a
|
||||
newline" convention.
|
||||
This has been applied to the following character-level text substitutions in
|
||||
the Standard Rules:
|
||||
[unicode N]
|
||||
[bracket] [close bracket] [apostrophe] ['] [quotation mark]
|
||||
[line break]
|
||||
[conditional paragraph break] [paragraph break] [run paragraph on]
|
||||
[bold type] [italic type] [roman type]
|
||||
[fixed letter spacing] [variable letter spacing]
|
||||
As a result, [line break] now does just and only what it suggests: prints a
|
||||
line break, regardless of circumstances, and with no side-effects for
|
||||
subsequent paragraph breaking. [paragraph break] is now the better way
|
||||
to force a paragraph break, and various bugs have been fixed so that it
|
||||
can more reliably be used in mid-string, in table entries, in values,
|
||||
more than once in the same quoted text, etc.
|
||||
A new form of paragraph break has been created for one special circumstance:
|
||||
printing clarificatory text after a command, when we are guessing what
|
||||
was meant. For instance:
|
||||
> N
|
||||
(first opening the Wicket Gate)
|
||||
Conventional spacing here is that text should immediately follow on the
|
||||
next line, unless we are going to a different room and looking around,
|
||||
in which case a line break should be added. We can get this spacing
|
||||
convention using the text substitution "[command clarification break]";
|
||||
for instance:
|
||||
say "(first opening [the noun])[command clarification break]";
|
||||
Another change made to the paragraph breaking mechanism removes the previous
|
||||
discrepancy between the effect of printing an object property which does
|
||||
contain a text substitution, and one that doesn't; and similarly for texts
|
||||
used as values in miscellaneous other circumstances.
|
||||
Finally, the text substitution "[no line break]" suppresses a line break
|
||||
which might otherwise arise under the sentence-ending punctuation rule
|
||||
as it applies to literal text in a "say", so:
|
||||
say "This is not the end![no line break]";
|
||||
leaves the printing position after the exclamation mark.
|
||||
>--> The meaning of the text substitution "[list of ...]" has been changed so
|
||||
that it now lists the items referred to without articles: for instance,
|
||||
it might produce "apple, orange and nectarine" rather than "an apple,
|
||||
an orange and a nectarine". (Which is what would have been produced in
|
||||
previous builds: to obtain the articled list, use "[a list of ...]"
|
||||
or "[the list of ...]" according to whether indefinite or definite
|
||||
articles are wanted. This was (6.21) in the January document.)
|
||||
The text substitution ['] is now synonymous with [apostrophe], and makes
|
||||
extended runs of Cockney dialogue easier to type ("put down that bleedin[']
|
||||
[']eavy Joanna", and so forth).
|
||||
Problem message added for using 'say' (or a text substitution) to print a
|
||||
value of a kind which cannot be printed up (such as a parsing topic).
|
||||
(This already produced a problem message, but a generic unhelpful one.)
|
||||
Problem message added for using a comma inside a text substitution, which
|
||||
in previous builds concatenated the items in the substitution - but that
|
||||
was almost invariably not what people expected, and it was being reported
|
||||
as a bug. (Thus previously "[1, 3]" was a legal substitution and printed
|
||||
up "13", for example.)
|
||||
Bug fixed whereby text substitutions which ended with one digit and were
|
||||
immediately followed by another digit in literal text would be corrupted.
|
||||
(For instance, in "[if x is 2]2".)
|
||||
Bug fixed whereby the little-used but legal "say X, Y, Z" comma-separated list
|
||||
form of "say" would lose some text substitutions occurring in terms in the
|
||||
list before the final one.
|
||||
Bug fixed whereby replacing or cutting snippets in the player's command could
|
||||
cause spurious line breaks to be printed if the new text contained text
|
||||
substitutions.
|
||||
Bug fixed whereby long texts containing almost the maximum legal number of
|
||||
text substitutions could crash NI.
|
||||
Bug fixed whereby improperly closed double-quoted text, e.g., "'fish"' (note
|
||||
the mismatch of quotation marks) could produce I6 errors rather than a
|
||||
problem message.
|
||||
Bug fixed whereby specifying literals involving double-quotes could cause
|
||||
I6 errors (e.g., writing: 5'10" specifies a height). Still not a good
|
||||
idea since it throws syntax-colouring, but it's not meant to be illegal.
|
||||
Bug fixed whereby the activity "printing the name of something" now applies
|
||||
to the player - previously, it applied to everything except the player.
|
||||
|
||||
|
||||
PROPERTIES
|
||||
|
||||
>--> The ability to create a property without specifying its kind (by writing,
|
||||
say, "A room has a property called history.") has been withdrawn. This
|
||||
was an undocumented syntax which gave the property the kind
|
||||
"miscellaneous-value", whose use has for some time been deprecated.
|
||||
(In almost all cases, the property will be storing either objects or text,
|
||||
and should be given a kind accordingly. The Standard Rules no longer
|
||||
use properties or variables of this kind, and this change improves the
|
||||
reporting of problems in assertions using the properties in question.)
|
||||
>--> We can now test to see if an object provides a property using the syntax
|
||||
if O provides the property P
|
||||
so for instance "if the noun provides the property lockable" - which a
|
||||
container or door would pass, but which a person would not, and so on.
|
||||
This was previously allowed as "if O has a/an P", but that was too
|
||||
ambiguous and has been withdrawn. (It made grammatical sense only for
|
||||
value properties P. "if the noun has a lockable" not only read badly,
|
||||
but due to a bug (now fixed) it also compiled to an incorrect test.)
|
||||
An indefinite article is now permitted in a negated assertion which sets the
|
||||
converse of an either/or property: thus "X is not a P" is permitted,
|
||||
just as "X is not P" would be. Grammatically this is incorrect if P is
|
||||
an adjective, which is what the original design of Inform intended, but
|
||||
people occasionally use nouns in an adjectival sort of way - for instance,
|
||||
"A monkey can be a hairy critter. The ape is a monkey in the Serengeti.
|
||||
The ape is not a hairy critter." (Here P is "hairy critter".) We continue
|
||||
to think this is poor style, but since the assertion would be allowed
|
||||
if in the positive sense, it seemed better to legalise it in the negative
|
||||
sense as well.
|
||||
Problem message added for writing 'X can have P' rather than 'X has P' to
|
||||
create a property, since this is a common mistake and currently produces
|
||||
rather unhelpful problem messages.
|
||||
Problem message rather than I6 errors for using a non-constant value (say,
|
||||
a variable) as the initial value of a property.
|
||||
Problem message rather than I6 errors for creating a property with a name
|
||||
consisting solely of an article (e.g.: "A thing has a number called the."),
|
||||
and similarly for property names containing commas or quoted text.
|
||||
Problem message added to clarify what kind of contradiction has occurred
|
||||
when the same property is set to different values in different sentences.
|
||||
Problem message added to report that new either/or properties or possible
|
||||
conditions (created by 'X can be Y or Z'-style sentences) clash with
|
||||
existing meanings - something which previously led to peculiar errors.
|
||||
Run-time problem messages now result from attempting to change (with "now")
|
||||
either/or properties for objects which are not permitted to have them.
|
||||
Run-time problem messages now result from attempting to read or write value
|
||||
properties for the "nothing" non-object. (Previously writes were ignored
|
||||
and reads produced 0, but this was unsafe for kinds of value where 0 was
|
||||
not valid, and in any case allowing people to treat "nothing" as an
|
||||
object seems unwise.)
|
||||
Bug fixed whereby "now X is Y" would compile I6 code which failed at run-time
|
||||
if X is a K that varies (K being some new kind of value) and Y is one
|
||||
possible value of K, in circumstances where K is also a property of objects.
|
||||
For instance, suppose we have colours blue and red, and colour is a
|
||||
property of cars. Suppose "jalopy" is a car that varies, "hue" a colour
|
||||
that varies. Then "now the jalopy is blue" and "now the hue is blue" are
|
||||
semantically very different - one changes a property, the other assigns
|
||||
a value - and this difference was being missed, hence the bug.
|
||||
Bug fixed whereby tests of whether something has an either/or property would
|
||||
compile to code failing at run-time (whereas value properties would work).
|
||||
Bug fixed whereby I6 errors might result from heavily ambiguous source texts
|
||||
where confusion could occur between wording of one phrase which does not
|
||||
include a property and another which does, where that property usage is
|
||||
itself incorrect.
|
||||
Bug fixed whereby giving a property of something with an additional clause
|
||||
requiring it to be somewhere (e.g. "the Portable Lamp in the Yard")
|
||||
would cause an internal error rather than produce a problem message.
|
||||
Bug fixed (see KINDS OF VALUE) whereby creating but not initialising a
|
||||
scene property caused an internal error.
|
||||
|
||||
|
||||
DEFINED ADJECTIVES
|
||||
|
||||
In "Definition:" sentences, it's now possible to refer to the object to which
|
||||
the definition applies as "he", "she" or "they", or indeed "him", "her"
|
||||
or "them", and no longer only as "it". Thus "Definition: a person is other
|
||||
if he is not the player." is legal, as is, and let's not squabble over the
|
||||
rightness of this, "Definition: a person is other if they are not the
|
||||
player." The accusative forms mean that "Definition: a person is a target
|
||||
if the player can see him.", etc., should also work now.
|
||||
A problem message has been added to forbid ambiguous settings of
|
||||
properties for adjective-qualified kinds, as in "The description of an
|
||||
open door is ...": such a sentence looks as if it might create a rule
|
||||
which would dynamically check the door during play, but in fact being
|
||||
an assertion it only looks at the initial state. (In previous builds,
|
||||
a bug caused this to set the description for every door, initially open
|
||||
or not: rather than fix this, it seemed better to forbid this form of
|
||||
assertion entirely, since if it worked it would still not do what it
|
||||
looked as if it did.)
|
||||
Similarly, a problem message has been added to forbid assertions at compile
|
||||
time about adjective-qualified kinds where the adjective cannot be
|
||||
determined until run-time (because it is created with "Definition:" and
|
||||
involves some computation to decide whether an object satisfies it or not).
|
||||
Problem message rather than I6 errors for using "change O to P" where O is
|
||||
an object and P is a defined adjective (rather than a property), so that
|
||||
it is not logically possible to change P by merely saying so.
|
||||
Run-time problem messages now result from attempting to change (with "now")
|
||||
adjectival properties which cannot be forced to come true, since their
|
||||
truth is governed by a fixed definition.
|
||||
Bug fixed whereby definitions of adjectives based on testing a property to
|
||||
see if it equals some specific value (e.g. "Definition: A container is
|
||||
standard if its carrying capacity is 7.") would in fact test a range
|
||||
of values with this as boundary (e.g. capacity <= 7).
|
||||
Bug fixed whereby definitions of adjectives with a specific object as domain
|
||||
(e.g. "Definition: the Ballroom is dusty if...") would not always be given
|
||||
priority over definitions with a more general kind as domain (e.g.
|
||||
"Definition: a room is dusty if...").
|
||||
|
||||
|
||||
HEADINGS
|
||||
|
||||
Problem message added to report that a heading stops before the end of its
|
||||
line, something which generally happens when a full stop has been misread.
|
||||
Bug fixed whereby an author name including a comma would be mis-spaced in the
|
||||
banner (for instance if the first line is: "Trio" by Rod, Jane and Freddy).
|
||||
Bug fixed whereby a heading which followed a long comment without an intervening
|
||||
skipped line would sometimes wrongly be rejected as containing a line break.
|
||||
|
||||
|
||||
ASSERTION SYNTAX
|
||||
|
||||
When ambiguous assertion sentences occur, where more than one word is in
|
||||
principle valid as the primary verb, we now assume that "to have" is the
|
||||
most likely verb, followed by "to be", and then the other built-in verbs.
|
||||
This replaces the previous doctrine that the earliest valid verb in the
|
||||
sentence was the true one. For instance, "The last support is a thing
|
||||
that varies." is now read with "is" as the primary verb, not "support".
|
||||
Problem message added to catch what look like mistaken uses of the pronoun
|
||||
"they". (E.g., in "A and B are things. They are portable.", I7 can't
|
||||
cope with "they" as meaning the collection of A and B, and would previously
|
||||
latch onto some other meaning, e.g., either A or B alone.)
|
||||
Problem message added for using 'every' on the wrong side of the verb in an
|
||||
assertion sentence (mostly to take the opportunity to explain how to
|
||||
reword such a sentence so that it works).
|
||||
Problem message added (in place of internal error) to catch misreadings of
|
||||
'of' leading to misunderstood property values in assertions, e.g. in
|
||||
"The dining room is a room in the house east of the kitchen."
|
||||
Problem message added (in place of internal error) to catch relative clauses
|
||||
which seem to express a location in a way too complicated to follow, e.g.
|
||||
"Sleeping Beauty is a woman who is asleep in the Spinning Tower."
|
||||
Bug fixed whereby listing complicated descriptions of things which involved
|
||||
at least one negated property would cause I6 errors.
|
||||
Bug fixed whereby negated relative phrases would mistakenly be read as
|
||||
positive, so that for instance "The broken box is a container which is
|
||||
not openable." would, very unfortunately, make an openable container.
|
||||
Bug fixed whereby implications in the form of "An X is usually Y", where X
|
||||
involves a kind and also properties, would in fact cause all things of
|
||||
that kind to be Y, whether they matched or not. (For instance, "an open
|
||||
container is usually lockable" would cause all containers not otherwise
|
||||
described to be lockable.)
|
||||
Bug fixed whereby "some" as an article would be confused with "some" as a
|
||||
determiner in such a way that the actual object being referred to was
|
||||
lost: this especially happened with singular mass nouns, e.g. "some clay",
|
||||
where "if the player is carrying some clay" would be misread as "if the
|
||||
player is carrying something" if the clay was a single thing, not a kind.
|
||||
Bug fixed whereby the assertion "X is here." might fail if X had already
|
||||
been defined before the room denoted by "here" had been declared; and
|
||||
also another case in which the room, having been mentioned long ago,
|
||||
is only recently made the subject of discussion again.
|
||||
Bug fixed whereby descriptions with multiple relative clauses, some of them
|
||||
ambiguous, could result in an interpretation which is none of the
|
||||
possibilities an English speaker would choose. (This is difficult to
|
||||
define, but for instance, "a random woman who is not Zoe in the location
|
||||
of Zoe" was being interpreted in such a way that "in the location of Zoe"
|
||||
was being applied neither to the random woman, nor to Zoe. Inform now
|
||||
applies it to Zoe. This affects only a handful of sentences - e.g., it
|
||||
makes no difference to any sentence in any of the examples - and only
|
||||
to sentences which are fairly evidently risky in the first place.)
|
||||
Bug fixed whereby object names containing "with" could, in the middle of
|
||||
lists, crash NI.
|
||||
|
||||
|
||||
PLURALS
|
||||
|
||||
The previous requirement that a plural definition sentence had to appear before
|
||||
it could be used has been lifted. Such definitions now apply throughout
|
||||
the source text, wherever they appear. This avoids traps like the following:
|
||||
"Clothing is a kind of thing. The plural of clothing is clothes. Clothes
|
||||
are wearable." In previous builds, this would have created an object called
|
||||
"Clothes", which is wearable but is not of the kind "clothing", and a
|
||||
kind called "clothing" with the plural "clothings".
|
||||
Bug fixed whereby non-specific references to properties in "every turn" rules
|
||||
would be taken to be properties of the I6 library placeholder object,
|
||||
usually leading to strange I6 veneer errors: they are now assumed to be
|
||||
properties of the player. Thus for instance
|
||||
A person can be poised or flustered. Before jumping: now the player
|
||||
is flustered. Before waiting: now the player is poised.
|
||||
Every turn when flustered: say "You feel flustered."
|
||||
...now works as expected.
|
||||
Bug fixed whereby ordinal numbers were being taken as counting determiners
|
||||
for noun phrases, so for instance "2nd Room" was being read as if it
|
||||
had the same meaning as "two rooms". This led to confusion when room
|
||||
names (in particular) began with an ordinal, e.g., "2nd Floor Balcony".
|
||||
Bug fixed whereby words which indicate plurals will not always be recognised
|
||||
as such if the object whose name is being parsed has a complex range of
|
||||
possible names (i.e., if I7 is obliged to compile a parse_name routine to
|
||||
handle it).
|
||||
|
||||
|
||||
RELATIONS, PARTS AND REGIONS
|
||||
|
||||
>--> Some people have had problems with the relation "in", when applying it
|
||||
to regions. Inside Inform, there are two forms of "in": there is object
|
||||
containment - the ball is in the box, the box is in the Summer House -
|
||||
and also region containment - the ball is in the Garden Area, the
|
||||
Summer House is in the Garden Area. These two forms of "in" are not
|
||||
as similar as they look - object containment has the property that a given
|
||||
X can be "in" Y for at most one possible Y, and Inform makes heavy use
|
||||
of this in optimising searches and loops; but region containment does
|
||||
not, becase the Summer House could be in the Garden Area and also in
|
||||
the super-region the Outside World, say. In practice, Inform always
|
||||
reads "X in Y" as object containment except when Y is the literal name
|
||||
of a region. Up to now, there has been no way to describe the hidden
|
||||
internal relation for region containment: in this build, we provide
|
||||
"regionally in" to allow users to clarify what sense they mean. Thus
|
||||
"repeat with P running through the rooms regionally in R begin; ..."
|
||||
makes clear that we are talking about all rooms in R (and not, for
|
||||
instance, rooms immediately in R rather than in some subregion of R).
|
||||
"A part of" is now synonymous with "part of": for instance, one can now write
|
||||
"if the tail is a part of the fish", with the same effect as "if the tail
|
||||
is part of the fish".
|
||||
Problem message added to prevent foundational errors involving an object being
|
||||
indirectly a part of itself ("X is a part of Y. Y is a part of X.", and
|
||||
so on).
|
||||
Problem message added to report that a region has been placed inside more than
|
||||
one other region. (This is forbidden because it could lead to configurations
|
||||
whereby regions overlap, whereas they are required always to include each
|
||||
other or else be disjoint.)
|
||||
Problem message added for an attempt to declare an already-existing object as
|
||||
a region. (This is never necessary, and when it occurs it is almost always
|
||||
a symptom of an inadvertent clash of names.)
|
||||
Run-time problem message added for attempts to find routes or count steps
|
||||
through relations not permitting this. (Previously such attempts would
|
||||
be allowed but, not very helpfully, invariably come back as finding no
|
||||
possible route. This was misleading.)
|
||||
Bug fixed whereby finding best routes through the map from A to B would fail
|
||||
with a programming error at run-time if A or B were nothing: Inform now
|
||||
works in these cases, returning the information that no route exists.
|
||||
(Similarly for counting steps, and for finding routes through relations.)
|
||||
Bug fixed whereby the built-in relations were not being given names as values,
|
||||
so that for instance Inform would fail to understand "containment
|
||||
relation" even though there is a relation called "containment".
|
||||
Bug fixed whereby relations defined by a condition would, if defined between
|
||||
different kinds of thing, sometimes lose track of what kinds they were
|
||||
defined over: so that run-time type-checking errors could be produced
|
||||
because the definition was applied to objects of the wrong kind.
|
||||
Bug fixed whereby some tests amounting to seeing whether a given room is in
|
||||
a given region, in the course of a condition, would fail.
|
||||
Bug fixed whereby a backdrop asserted as being in more than one region would
|
||||
only appear in the first region asserted (though also in any rooms it was
|
||||
asserted as being in: the bug applied only to multiple regions).
|
||||
|
||||
|
||||
TABLES
|
||||
|
||||
"Increment" and "decrement" are now synonyms for "increase" and "decrease".
|
||||
Moreover, they can now also be used on table entries (e.g. "increase
|
||||
pollen count entry by 2").
|
||||
"Choose the row with..." is now synonymous with "choose row with...".
|
||||
Problem message added for placing blank entries in the first column of a table
|
||||
which is creating named objects or values, something which makes no sense
|
||||
since the first column provides the names.
|
||||
Problem message added to report duplicated table names (which are not
|
||||
continuations of each other).
|
||||
Problem message for using a table reference at a time when no row has been
|
||||
selected has been clarified to explain why text substitution can make
|
||||
this time not the time which several users thought.
|
||||
Problem message for using a table reference in a condition set in the past
|
||||
tense and thus relating to a time when no row had been chosen.
|
||||
Problem message for using a table reference in a complex condition which
|
||||
requires loops over objects in ways very likely resulting from a
|
||||
misunderstanding (and which in any case can't be compiled safely if
|
||||
taken at their literal meanings).
|
||||
Problem message added for "Some X are defined by the Table of T" where X is
|
||||
something unrecognised, and another for where X describes a specific
|
||||
object rather than a kind. (It needs to be a kind of object or value.)
|
||||
Bug fixed whereby repeating through a table "in reverse order" (not in reverse
|
||||
order of any specific column, just in reverse order of its natural order)
|
||||
would produce I6 errors.
|
||||
Bug fixed whereby sorting a table would (almost) always move blank rows to
|
||||
the top: it now invariably moves blank rows to the bottom, regardless of
|
||||
the direction or column of sorting, as the documentation implies it should.
|
||||
Bug fixed whereby any continuation of a table was being treated as if written
|
||||
under the same heading in the source text as the start of the table:
|
||||
which meant that any problem messages, and also any object name
|
||||
disambiguation, would be handled at the wrong position.
|
||||
Bug fixed whereby "change TE to V", where TE is a table entry and V is some
|
||||
value to be put there, was not being type-checked - so that one could,
|
||||
for instance, change a textual entry to a number, with subsequently
|
||||
unfortunate results. (This is particularly insidious in the case of
|
||||
changing a topic entry to a textual string, which can't safely be done
|
||||
at run-time, and will crash the interpreter during later parsing.)
|
||||
Bug fixed whereby the condition "if S is a topic listed in T", where S is a
|
||||
snippet (e.g. "the player's command") and T has a topic column, would
|
||||
produce programming errors at run-time rather than perform the necessary
|
||||
matching.
|
||||
Bug fixed whereby the condition "if there is an X of Y in T", to see if the
|
||||
X column of table T ever contains Y, failed to compile if T was
|
||||
expressed in a way not using the word "table" (for instance, if T was
|
||||
a table-name which varies).
|
||||
Bug fixed whereby naming a table in such a way that the first word of the
|
||||
name was an article (e.g. "Table of A Students") would make that table
|
||||
subsequently difficult to refer to.
|
||||
Bug fixed whereby some properties given by columns in tables which define
|
||||
a batch of objects would, if they seemed always to contain other objects,
|
||||
sometimes cause an internal error and so fail to compile.
|
||||
Bug fixed whereby references to entries in tables in the past could produce
|
||||
internal errors.
|
||||
Bug fixed whereby defining a quoted text as an enumerated value of a kind of
|
||||
value using a table (a foolish but just about legal thing to do) caused
|
||||
I6 errors.
|
||||
|
||||
|
||||
TO... PHRASES
|
||||
|
||||
>--> Phrase declarations can also now give literal values as the only possible
|
||||
match. For instance, defining:
|
||||
To hazard (N - a number): say "[N]! That's Numberwang."
|
||||
To hazard (N - 14): say "[N]... oh, sorry, Julie, that's NOT Numberwang."
|
||||
means that using a phrase like
|
||||
hazard X;
|
||||
will produce the exceptional message if X is 14, and the standard one
|
||||
otherwise. For instance, if we tried this with X repeating through a
|
||||
loop, we might see:
|
||||
13! That's Numberwang.
|
||||
14... oh, sorry, Julie, that's NOT Numberwang.
|
||||
15! That's Numberwang.
|
||||
If we had not defined the general case ("To hazard (N - a number)"), then
|
||||
attempting to use
|
||||
hazard X;
|
||||
for any value of X other than 14 would have produced a run-time problem.
|
||||
(This was (6.29) in the January document.)
|
||||
Phrase declarations can now give alternatives for any single literal word
|
||||
using slashes (using the same convention that grammar tokens follow).
|
||||
For instance,
|
||||
To pour (N - a number) gallon/gallons: ...
|
||||
makes the phrase match with either "gallon" or "gallons" as the last
|
||||
word; except that "say" is never permitted as the first word of a
|
||||
phrase, just as now, because "To say ..." declares a text substitution
|
||||
instead. (This was (6.26) in the January document.)
|
||||
>--> Because of this, all existing To... definitions containing words with
|
||||
a slash in them, such as "and/or", will need to be changed. In particular
|
||||
the text substitution "[is/are a list of...]" and similar forms have been
|
||||
changed to "[is-are a list of...]", and the same principle (exchanging
|
||||
slashes for hyphens) has also been followed for the extensions: see above.
|
||||
Problem message added to prevent source text trying to redefine "now ..." by
|
||||
creating "To now X is 2" and similar constructions - these tend not to
|
||||
work, and are highly misleading when they do.
|
||||
|
||||
|
||||
IF AND OTHERWISE
|
||||
|
||||
An additional problem message has been added to catch a subtle syntax mistake
|
||||
which previously led in some cases to I6 errors. This is to do with the
|
||||
possible interpretations of "otherwise if", as shown by the following:
|
||||
Report going from Alpha to Omega:
|
||||
if Omega is visited begin;
|
||||
say "You retrace your steps, but it's just not the same.";
|
||||
otherwise if turn count < 2, say "Unhesitatingly, you set out.";
|
||||
end if.
|
||||
This is actually illegal, because "otherwise (phrase)" can only occur
|
||||
immediately following an "if (condition), (phrase)": the form of otherwise
|
||||
used to divide up cases within a blocked if (such as the "Omega is visited"
|
||||
one) is just "otherwise if (condition)". The new problem message intercepts
|
||||
this mistake. The correct text would be:
|
||||
Report going from Alpha to Omega:
|
||||
if Omega is visited begin;
|
||||
say "You retrace your steps, but it's just not the same.";
|
||||
otherwise if turn count < 2;
|
||||
say "Unhesitatingly, you set out.";
|
||||
end if.
|
||||
(While at first sight the incorrect syntax looks innocuous enough - why not
|
||||
simply allow both forms? - this becomes ambiguous if the statement does
|
||||
indeed follow a simple "if" within the larger "if" block.)
|
||||
The problem message arising from "if C", where C is not recognised as a
|
||||
condition, has been made more helpful in the case where C is a compound
|
||||
condition. (For instance: "I was expecting that 'score is 1 or 2 or lemon
|
||||
sherbet explodes in the dark' would be a condition, but I couldn't make
|
||||
sense of it that way. 'score is 1' was okay; '2' only made sense as a
|
||||
value, which can't be used as a condition; 'lemon sherbet explodes in the
|
||||
dark' did not make sense; and nor did the condition make sense as all
|
||||
one text.")
|
||||
Problem message rather than I6 errors for using "otherwise ..." as following
|
||||
immediately on an "if ... begin" block opening. (It would be legal to
|
||||
use "otherwise", or to use "otherwise ..." after a non-blocked "if".)
|
||||
Bug fixed whereby "if ..." might fail to yield problem messages where a
|
||||
complicated condition included arithmetic performed on named values
|
||||
which do not exist.
|
||||
Bug fixed whereby giving more than one "otherwise;" clause in an "if" block
|
||||
did not provoke any problem message. (It now does.)
|
||||
|
||||
|
||||
CONDITION SYNTAX
|
||||
|
||||
When a phrase can be used as a condition (i.e. when it is a phrase "to decide
|
||||
if..."), "not" followed by that phrase can also be used as a condition.
|
||||
In particular, "when not in darkness", "if not using the memory economy
|
||||
option", etc., now work.
|
||||
"Can not" is now synonymous with "cannot": for instance, "if the player can
|
||||
not see the fish" is equivalent to "if the player cannot see the fish",
|
||||
and similarly for "if the player can not be seen by the fish".
|
||||
Problem message added to catch accidental omissions of verbs in some
|
||||
descriptive conditions (say, writing "if small key inside box" instead
|
||||
of "if small key is inside box": it would open the door to too many
|
||||
ambiguities to allow these customary omissions in general).
|
||||
Bug fixed whereby tests of whether "A is unable to B" would be parsed as if
|
||||
they were "A is able to B", i.e., with the negation lost: for instance,
|
||||
"...when Peter is unable to see the bridge" would be read as if "...when
|
||||
Peter is able to see the bridge".
|
||||
Bug fixed whereby testing whether something unlocks something else would
|
||||
compile through I7 but then cause I6 errors.
|
||||
|
||||
|
||||
MISCELLANEOUS SYNTAX
|
||||
|
||||
An explanatory problem message, rather than an internal error, now results
|
||||
from using 'total ... of' in a way too complicated to handle.
|
||||
Bug fixed whereby clashes of names as between ordinary phrases and arithmetic
|
||||
phrases could result in unhelpful problem messages on legal source text:
|
||||
for instance, creating a property called "times played" and then
|
||||
evaluating "total times played of all tracks" would be confused with
|
||||
trying to multiply "total" by "played of all tracks", even though this
|
||||
interpretation made no sense.
|
||||
A name-space clash causing the Standard Rules to conflict with any kind whose
|
||||
name included the word "item" has been removed.
|
||||
|
||||
|
||||
RULES AND RULEBOOKS
|
||||
|
||||
Problem message rather than internal error for the case of a rule which
|
||||
happens when an activity is being applied to X, but X is not a
|
||||
description of something.
|
||||
Problem message rather than I6 errors for attempting to write an inline
|
||||
I6 definition of a rule. (Only allowed when defining "To..." phrases.)
|
||||
Problem message added for a rule whose name contains a comma. (No, really.
|
||||
People have tried to do this.)
|
||||
Bug fixed whereby saying that a named rule is listed first, in a rulebook
|
||||
already containing other named rules, would sometimes have no effect.
|
||||
Bug fixed whereby declaring that a new named rule should be listed instead
|
||||
of an existing (and built-in) action rule, e.g. the "can't go that way
|
||||
rule", would sometimes cause the new rule not to have the same implied
|
||||
actor conventions as the old one - for instance, even though the "can't
|
||||
go that way rule" applies to all actors, its replacement might only
|
||||
apply to the player, so that NPCs were able to walk through walls.
|
||||
Bug fixed whereby the result of a rule was not allowed to be another rule,
|
||||
so that "rule succeeds with result X" would fail in the case of X being
|
||||
a rule - while printing a problem message explicitly claiming that a rule
|
||||
was one of the legal alternatives here.
|
||||
Bug fixed whereby rules attached to actions happening "for the first time"
|
||||
(or with similar stipulations) would sometimes, in the case of complex
|
||||
actions, fire more than once during the same turn. This bug has been
|
||||
seen particularly in response to "After going from X to Y for the first
|
||||
time", where the rule fired both after the going, and then also after
|
||||
the subsequent looking action in the same turn.
|
||||
Typo fixed in Rules index: it should be "action-processing rules", not
|
||||
"action processing rules". (Some people thought this rulebook could not
|
||||
legally be referred to as a value - actually it can, but this typo
|
||||
caused them to get the name wrong. Apologies.)
|
||||
|
||||
|
||||
ACTIONS
|
||||
|
||||
>--> The relationship between the actions "getting off" and "exiting" has been
|
||||
reversed. Suppose the player is on a chair, a supporter. In previous
|
||||
builds, EXIT would cause the exiting action directly, but GET OFF CHAIR
|
||||
would cause the getting off action, which would quickly convert into an
|
||||
exiting action. This worked fine, but meant that a rule like:
|
||||
Instead of getting off the sticky chair, say "You can't! It's too
|
||||
sticky."
|
||||
would only apply to one of the two commands, anomalously. In this build,
|
||||
it is exiting which converts to getting off (provided that the actor is
|
||||
indeed on a supporter). (This also fixes a bug to do with NPCs and the
|
||||
convert get off to exit where possible rule, which no longer exists.)
|
||||
The problem message for mis-describing an action with the form "A or B or ..."
|
||||
now itemises the listed actions to say which are valid and which not,
|
||||
and also warns if one of these is a named kind of action (which is not
|
||||
allowed in a list like this). It also handles the case of "doing something
|
||||
except A or B or ...".
|
||||
Problem message added for past-tense references to the "noun" or "second
|
||||
noun" which certainly will not do what their authors intend, because
|
||||
the values of these quantities have changed over time.
|
||||
Problem message added for complicated past-tense references to the "going"
|
||||
action. (The old problem message amounted to "I don't understand this",
|
||||
the new one "I do understand this, but I'm still not going to do it".)
|
||||
Problem message added for describing a "going" action in terms of objects
|
||||
which are of the wrong kind to make sense - going from or to a non-room-
|
||||
or-region, through a non-door, with or by a non-thing. This only catches
|
||||
cases which the compiler can spot, involving specific named items, but
|
||||
this is more useful than it sounds (especially if a room name includes
|
||||
the word "by" in lower case, and Inform has wrongly taken this as a
|
||||
preposition).
|
||||
Bug fixed whereby moving the player during the course of a rule attached
|
||||
to an action being carried out by somebody else would cause any resultant
|
||||
looking action to apply to that other person, rather than the player,
|
||||
so that instead of a description of the player's new room we might either
|
||||
see nothing or something like "Miss Marple looks around.", depending
|
||||
on where the third party is at that point in the action.
|
||||
Bug fixed whereby somebody arriving in the player's room as a result of a
|
||||
"going" action would always be described as arriving from the opposite
|
||||
direction as that of initial travel - so if he had gone east, he would
|
||||
now be said to have arrived from the west, for instance. This is fine
|
||||
for untwisted, two-way routes, but not otherwise. Inform now only does
|
||||
this where the reverse journey can be made in the reverse direction,
|
||||
possibly via a two-way door; and otherwise simply says that the person
|
||||
"arrives".
|
||||
Bug fixed whereby a spurious "You must name an object." error would be printed
|
||||
in response to a command requesting somebody to carry out an action which
|
||||
applied only to a single topic.
|
||||
Bug fixed whereby "try looking" would sometimes fail with a spurious "You
|
||||
must name an object." error if it occurred during an action which applied
|
||||
to a value rather than a thing.
|
||||
Bug fixed whereby an action caused by "try" would sometimes not have the
|
||||
appropriate "... understood" values correct if the action applied to a
|
||||
value rather than a thing.
|
||||
Bug fixed whereby an action whose name takes the form "... to something"
|
||||
could be referred to without the "to". As a special case and because
|
||||
of its status as an optionally-nouned action, this is still allowed
|
||||
for "listening" (properly speaking the action is called "listening to"),
|
||||
but forbidden for new actions.
|
||||
Bug fixed whereby lists of actions would sometimes, in certain orders and
|
||||
where ambiguity between different length actions occurred, wrongly cause
|
||||
problem messages. For instance, "Instead of taking off or dropping the
|
||||
jodhpurs" would fail (note ambiguity between "taking" and "taking off")
|
||||
whereas "Instead of dropping or taking off the jodhpurs" would work.
|
||||
Bug fixed whereby ambiguities caused by abbreviation of action names
|
||||
(for instance if we have actions "weighing" and "weighing it with",
|
||||
what do we say that the rule "Before weighing" applies to?) are now
|
||||
resolved in favour of the least abbreviated name (here, "weighing").
|
||||
Bug fixed whereby tests of intransitive past tense actions (e.g. "we have
|
||||
woken up", no object, rather than "we have taken the box") were
|
||||
performed incorrectly, usually producing false negatives.
|
||||
Bug fixed whereby action reporting would suddenly cease after a NPC tried
|
||||
an action involving a door or backdrop. (The mystically-named "untouchable
|
||||
silence" bug, which Khelwood posted a (correct) fix to RAIF for.)
|
||||
Bug fixed in the implementation of the ACTIONS testing command whereby
|
||||
the information that a tried action had just failed would sometimes be
|
||||
destroyed by the act of printing things information out.
|
||||
Bug fixed whereby some complicated check, carry out or report rules would
|
||||
fail to appear in the Actions index.
|
||||
Bug fixed whereby check rules applying to the final action performed would be
|
||||
posthumously applied also to the attempt at restoring the game produced
|
||||
by typing RESTORE in reply to the post-game question "Would you like to
|
||||
RESTART, RESTORE a saved game or QUIT?"
|
||||
|
||||
|
||||
SCENES
|
||||
|
||||
>--> A small but quite important change has been made to the scene changing
|
||||
mechanism which affects the order in which things happen when there are
|
||||
multiple scene endings. For instance:
|
||||
Home is a room. The cube and the ball are here.
|
||||
Shape Choice is a scene. Shape Choice begins when play begins.
|
||||
Shape Choice ends roundly when the player carries the ball.
|
||||
Shape Choice ends squarely when the player carries the cube.
|
||||
Consequence is a scene. Consequence begins when Shape Choice ends.
|
||||
When Consequence begins:
|
||||
if Shape Choice ended roundly, say "Roundly.";
|
||||
if Shape Choice ended squarely, say "Squarely."
|
||||
Suppose the cube is taken. This used to cause the following sequence of
|
||||
events:
|
||||
Shape Choice ended
|
||||
Consequence began
|
||||
Shape Choice ended roundly
|
||||
It was necessary for Shape Choice to end the regular way before the exotic
|
||||
way, so that consequent rules could happen, but the ordering was unfortunate,
|
||||
because it meant that the rule in the source above happened at a time when
|
||||
it wasn't known whether the scene had ended roundly or squarely - only that
|
||||
it had ended. Since it's very useful to know how the previous scene ended
|
||||
in order to begin the next one, this is unfortunate. The change means that
|
||||
the sequence is now:
|
||||
Shape Choice ended
|
||||
Shape Choice ended roundly
|
||||
Consequence began
|
||||
and so the rule above works after all, printing "Roundly."
|
||||
It is now possible (optional, that is) to use a "the" in giving a rule for
|
||||
a scene beginning or ending: thus "When the Afternoon begins:" is now
|
||||
synonymous with "When Afternoon begins:".
|
||||
Two new phrases for scenes have been added: "the time since S ended" and "the
|
||||
time when S ended", exactly parallel to "the time since S began" and "the
|
||||
time when S began". (Previously, the "began" time was being interpreted as
|
||||
the most recent time at which S either ended or began - this was a bug, and
|
||||
has been fixed.)
|
||||
New scene "Entire Game" created: see KINDS OF VALUE.
|
||||
Bug fixed whereby a scene which begins "when play begins" and also when a
|
||||
condition holds now begins in either case (previously, the condition was
|
||||
being ignored, and some users thought it was illegal to specify a condition
|
||||
in this case - actually it was a bug).
|
||||
Bug fixed whereby begin/end conditions of scenes would not be properly
|
||||
disambiguated if relying on an ambiguously phrased phrase to decide
|
||||
the outcome, resulting in I6 errors for what was correct source text.
|
||||
Bug fixed whereby begin/end conditions of certain forms, such as past tense
|
||||
actions, were rejected altogether with spurious problem messages.
|
||||
Bug fixed whereby if scene A is set to end when scene B ends, but in fact
|
||||
B ends at a time when A has never started, ending rules for A would be
|
||||
erroneously run anyway.
|
||||
Bug fixed whereby creating a scene that varies called X could sometimes also
|
||||
create a scene called X. (Except for cluttering the index, this would
|
||||
only be harmful if the name of X happened to end with "scene", but of
|
||||
course people do tend to name such things "current scene", etc., so...)
|
||||
Bug fixed (see KINDS OF VALUE) whereby creating but not initialising a
|
||||
scene property or variable caused an internal error.
|
||||
|
||||
|
||||
WHEN PLAY BEGINS
|
||||
|
||||
Bug fixed whereby attempting to enter a closed container which in fact
|
||||
already enclosed the actor (but indirectly so) would fail the "can't enter
|
||||
closed containers rule" rather than the "can't enter what's already
|
||||
entered rule", resulting in a slightly misleading reply.
|
||||
Bug fixed whereby calculations of visibility made during "when play begins"
|
||||
rules would be incorrect because the player object had not yet been put
|
||||
into its starting position.
|
||||
Bug fixed whereby changing the player to a new player-character and then
|
||||
moving that PC during "when play begins" rule to a container or supporter
|
||||
would have the final movement disregarded.
|
||||
|
||||
|
||||
OBJECT MOVEMENTS
|
||||
|
||||
>--> Scenery is now usually "fixed in place". This makes little difference
|
||||
since it can't normally be taken, but in previous builds it usually had the
|
||||
"portable" property, and this meant that (for instance) "repeat with the
|
||||
item running through the portable things in the location ..." would
|
||||
unexpectedly include scenery.
|
||||
Bug fixed whereby moving an object from room to room (say, by writing "now
|
||||
the row-boat is in the Rapids") would cause the location to be wrongly
|
||||
set internally if the object contained the player (because an I6 PlayerTo
|
||||
call would never occur), which would make certain room descriptions print
|
||||
wrongly.
|
||||
Bug fixed whereby "remove D from play", where D is only a vague description
|
||||
of things, would compile I6 code which failed at run-time rather then
|
||||
produce a problem message.
|
||||
|
||||
|
||||
LIGHT
|
||||
|
||||
Bug fixed whereby another person in the same room, openly carrying a light
|
||||
source, was not counted as lighting that room.
|
||||
|
||||
|
||||
UNDERSTANDING
|
||||
|
||||
In previous builds, the activity "reading a command" has happened only around
|
||||
the original command being typed. If the player types TAKE POLISH, the
|
||||
activity winds up: if, later, the parser asks a follow-up question such
|
||||
as "Which do you mean, the Polish sausage or the shoe polish?", this
|
||||
question is not framed by the activity. That remains the case, but if
|
||||
the question results in a rewritten command, Inform now - exceptionally -
|
||||
follows the "after reading a command" rulebook for a second time.
|
||||
Problem message rather than internal error for confusing an activity with an
|
||||
action in an "Understand ... as ..." sentence.
|
||||
Bug fixed whereby, if we give define a noun as a legal command by writing e.g.
|
||||
"Understand "[something]" as examining." and then the player types
|
||||
something unrecognisable, the parser replies "You can't see any such
|
||||
thing." (presuming we were intending to type a noun) rather than "That's
|
||||
not a verb I recognise." (presuming a verb - which seems more likely).
|
||||
Bug fixed whereby the message "** Warning: grammar properties might not work
|
||||
correctly **" would occasionally appear when a game began playing (but
|
||||
not in a released version).
|
||||
|
||||
|
||||
USE OPTIONS
|
||||
|
||||
The "the" in the condition "using the ...option name... option" has been
|
||||
made optional: for instance, "if using no scoring option" is now allowed.
|
||||
Bug fixed whereby using memory economy did not suppress all the RULES ALL text,
|
||||
thus not economising as much as it might.
|
||||
|
||||
|
||||
EXTENSIONS
|
||||
|
||||
Problem message added to explain that extension names should be unquoted
|
||||
in Include sentences.
|
||||
Bug fixed whereby extensions ending without documentation would sometimes
|
||||
produce a spurious problem message on their end lines, unless these
|
||||
were followed by at least one one blank line.
|
||||
|
||||
|
||||
PUBLISHING
|
||||
|
||||
Bug fixed whereby releasing along with a website stopped working in 4K40/1.
|
||||
Particular apologies for this.
|
||||
Bugs fixed whereby Unicode translations were not properly preserved in
|
||||
released websites, notably in title, blurb and source text when written
|
||||
as HTML.
|
||||
|
||||
|
||||
WORLD INDEX
|
||||
|
||||
Problem message added to clarify that mapping hints can only be given laterally
|
||||
(so e.g. "Index map with Overlook mapped above Great Plain" does not work).
|
||||
Bug fixed causing "yourself" (the player) to appear twice in the World index
|
||||
in some situations.
|
||||
Bug fixed whereby disconnected areas of map would sometimes appear on vastly
|
||||
distant vertical levels from each other, with peculiar resulting map
|
||||
legends. (See e.g. the map for "Port Royal 2" under 4K41 or earlier.)
|
||||
|
||||
|
||||
PROBLEM MESSAGES
|
||||
|
||||
Bug fixed whereby some problem messages concerning phrases would be reported
|
||||
as being in the text under the final heading in the source text, rather
|
||||
than the headings under which they actually occurred.
|
||||
Bug fixed whereby problems occurring in text substitutions inside quoted text
|
||||
which forms a whole sentence (e.g., as an implicit room description)
|
||||
were reported as being at peculiar sentences.
|
||||
A number of problem messages which users reported as unclear have been reworded.
|
651
Changes/Change Logs/4U65.txt
Normal file
651
Changes/Change Logs/4U65.txt
Normal file
|
@ -0,0 +1,651 @@
|
|||
4U67 (7 May 2007)
|
||||
|
||||
This build, 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).
|
||||
|
||||
|
||||
4U65 (27 April 2007)
|
||||
|
||||
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.
|
||||
|
||||
|
||||
INFORM 7 FOR MAC OS X
|
||||
|
||||
>--> 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).
|
||||
|
||||
|
||||
INFORM 7 FOR LINUX
|
||||
|
||||
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.
|
||||
|
||||
|
||||
INFORM 7 FOR WINDOWS
|
||||
|
||||
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.
|
||||
|
||||
|
||||
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
|
||||
|
||||
The following rules have been abolished:
|
||||
check life property for giving rule
|
||||
check life property for showing rule
|
||||
check life property for waking rule
|
||||
check life property for throwing at rule
|
||||
check life property for attacking rule
|
||||
check life property for kissing rule
|
||||
check life property for answering rule
|
||||
check life property for telling rule
|
||||
check life property for asking rule
|
||||
check thrown-at rule
|
||||
These provided vestigial I6 library support and are irrelevant for I7.
|
||||
As for the do-nothing actions (see below), these are now also handled
|
||||
symmetrically for all actors. (Thus, for instance, the block attacking
|
||||
rule now blocks any actor attacking any other.)
|
||||
|
||||
|
||||
THE DO NOTHING ACTIONS
|
||||
|
||||
The actions indexed as "Actions which always do nothing unless rules
|
||||
intervene", which consist only of a single checking rule to block them,
|
||||
behaved asymmetrically in previous builds since they blocked the
|
||||
action for the player, but allowed it to run through untouched and
|
||||
with no rules applying for any other actor. This could result in odd
|
||||
transcripts such as:
|
||||
> SING
|
||||
Your singing is abominable.
|
||||
> PETER, SING
|
||||
>
|
||||
...because no rules at all fire for Peter trying singing, so the
|
||||
action succeeds by default, and nothing is said or done.
|
||||
In this build, the blocking rules for do-nothing actions now block
|
||||
all actors. Thus:
|
||||
> PETER, SING
|
||||
Peter is unable to do that.
|
||||
or with ACTIONS switched on:
|
||||
> PETER, SING
|
||||
[asking Peter to try singing]
|
||||
[(1) Peter trying singing]
|
||||
[(1) Peter trying singing - failed the block singing rule]
|
||||
Peter is unable to do that.
|
||||
[asking Peter to try singing - succeeded]
|
||||
This affects the actions:
|
||||
Saying yes, Saying no, Burning, Waking up, Thinking, Smelling,
|
||||
Listening to, Tasting, Cutting, Jumping, Tying it to, Drinking,
|
||||
Saying sorry, Swearing obscenely, Swearing mildly, Swinging,
|
||||
Rubbing, Setting it to, Waving hands, Buying, Singing,
|
||||
Climbing, Sleeping
|
||||
>--> While this is much more logical, and means that every (non-out-of-world)
|
||||
action in the Standard Rules now works equally for all actors, it does
|
||||
mean that a rule in the form:
|
||||
After Peter trying singing: ...
|
||||
will no longer work, because Peter's singing action will be blocked and
|
||||
never reach the "after" stage. To get around this:
|
||||
Instead of Peter trying singing:
|
||||
...
|
||||
the rule succeeds.
|
||||
Note the last line, forcing the action to be considered a success: actions
|
||||
stopped by instead rules are normally deemed to fail, but making this
|
||||
succeed means that no "Peter is unable to do that." text will be printed.
|
||||
|
||||
|
||||
PHRASES
|
||||
|
||||
Inform has been made a little stricter in when it allows certain phrases
|
||||
to be used. For instance, the phrase "decide on X", which chooses a
|
||||
value X, is now only allowed in a phrase "To decide which ..." - of
|
||||
course it didn't make sense anywhere else, but this is now policed.
|
||||
Similarly, "decide yes" is now restricted to phrases which need to
|
||||
decide if something is or isn't true, and so on. (We're pretty certain
|
||||
that this new check only rejects uses which do not at all achieve what
|
||||
they look as they ought to do.)
|
||||
Similarly, "decide on X" now checks the kind of X to see if it matches the
|
||||
required kind. This may produce problems either at compile time, or
|
||||
at run-time. Note in particular that "nothing" is forbidden as a
|
||||
value to decide on if we are required to produce a particular kind
|
||||
of object such as, say, a "room", but is allowed if we are only required
|
||||
to produce an "object". (This agrees with the conventions used for
|
||||
variables.)
|
||||
Finally, phrases to decide a value now return the default value of the
|
||||
appropriate kind if execution runs through to the end of the definition
|
||||
without having reach any "decide on X" phrase.
|
||||
Problem message added to explain why two bracketed phrase terms immediately
|
||||
next to each other, with no word in between, is against the rules -
|
||||
e.g. "To combine (X - a number) (Y - a number)". (Previously Inform
|
||||
would allow the definition, but then never recognise it in source text,
|
||||
which was not a very helpful way of rejecting it.)
|
||||
Bug fixed whereby setting up a phrase "To decide what X is ..." might
|
||||
read X as a description of a thing rather than a kind of value in
|
||||
cases where X is both the name of such a kind, and also part of the
|
||||
name of a thing. (For instance, if there is an object somewhere called
|
||||
"number puzzle", then a phrase "To decide what number is ..." was
|
||||
being misread as if its type had to be always the number puzzle object,
|
||||
not a number.)
|
||||
|
||||
|
||||
PROPERTIES
|
||||
|
||||
Two changes have been made to the way that assertions about either/or
|
||||
properties of kinds are read. To demonstrate, consider the sentence in
|
||||
the Standard Rules which reads
|
||||
A thing is usually inedible.
|
||||
What if we want to contradict this? In previous builds, we could write:
|
||||
A thing is never inedible.
|
||||
This worked, but owing to a bug,
|
||||
A thing is always edible.
|
||||
did not work - this bug has now been fixed. In either of these sentences,
|
||||
we undo the sentence in the Standard Rules by writing a sentence which is
|
||||
more definite - certain ("never", "always") rather than merely likely
|
||||
("usually"). But what if we don't want extra certainty? In previous builds,
|
||||
writing
|
||||
A thing is usually edible.
|
||||
would have no effect, because when two inferences are drawn about the
|
||||
same property which contradict but which are each uncertain, the original
|
||||
first-drawn inference is allowed to stand, and the second is ignored.
|
||||
This convention has been reversed in the case of inferences drawn about
|
||||
properties of kinds:
|
||||
A later uncertain assertion about a property of a kind beats
|
||||
an earlier uncertain assertion about the same property.
|
||||
Problem message added for saying that a kind has an either/or property
|
||||
without previously having said that it can have that property. This
|
||||
would usually not work anyway, but in previous builds, saying "K is
|
||||
usually openable." would make it so: Inform now insists that we write
|
||||
"K can be openable. K is usually openable.", as the documentation implies.
|
||||
(The examples A Haughty Spirit and Disappointment Bay 12 needed to be
|
||||
corrected in just this way.)
|
||||
Problem message added (rather than internal error) to reject implications
|
||||
where the implied outcome is a value property rather than a simple
|
||||
either/or property like open/closed.
|
||||
Problem message added to explain why "D can be X or Y" makes no sense if
|
||||
D is something qualified by adjectives - e.g. "An open door can be
|
||||
rickety or sturdy" makes no sense because the door still has to have the
|
||||
property even at times when it is not open. (Previously Inform simply
|
||||
ignored the adjectives, and assigned the property to the underlying kind.)
|
||||
Bug fixed whereby saying "now X is P" could be misconstrued if P refers to a
|
||||
property but does so inexplicitly: for instance, "now X is the colour of
|
||||
the button" would try to change X to be equal to this colour whereas
|
||||
"now X is green" would simply change the colour of X. Both forms now
|
||||
change the properties, not the identity, of X.
|
||||
Bug fixed whereby large numbers of either/or properties created for things,
|
||||
followed by an either/or property being created for rooms, would sometimes
|
||||
lead to bogus programming errors at run time.
|
||||
Bug fixed whereby creating a new either/or property but giving its antonym
|
||||
as an existing one would sometimes wrongly be allowed, leading to
|
||||
peculiar run-time problem messages. (E.g. writing "The Catwalk can be
|
||||
flaming or unlit." causes this, because "unlit" is already the antonym
|
||||
of "lit", a property of things.)
|
||||
Bug fixed whereby certain complicated forms of property assignment in
|
||||
assertions could cause an internal error (e.g., "Blinky is an ephemeral
|
||||
ghost with reaction "Boo!".").
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
MISCELLANEOUS
|
||||
|
||||
Problem messages added for creating table columns whose names are articles
|
||||
or existing values such as literal numbers.
|
||||
Problem message added (rather than internal error) for initialising a
|
||||
K that varies (where K is a kind) to the value "nothing". This is legal
|
||||
for an object that varies (though in 4S08 a bug blocked this), but not
|
||||
where the variable always has to hold something of a given kind.
|
||||
Problem message added (rather than internal error) for an attempt to total
|
||||
the column of a table rather than a property.
|
||||
Problem message added (rather than eventual I6 errors) for defining plurals
|
||||
using quotation marks, e.g., writing 'The plural of "coin" is monies.'
|
||||
rather than 'The plural of coin is monies.'
|
||||
Better problem message added for close square brackets used wrongly as
|
||||
literals in quoted text.
|
||||
Bug fixed whereby continuations of tables would sometimes wrongly be reported
|
||||
as containing columns not found in the original tables, and would
|
||||
sometimes (even when they worked) have their columns incorrectly matched
|
||||
up to the original table, in cases where the columns had been reordered.
|
||||
Bug fixed whereby a compound sentence asserting a relationship both with a
|
||||
new specific object and also a new object described only generically by
|
||||
naming its kind, as in:
|
||||
The big box contains a container and Peter.
|
||||
...would fail complaining of an overly complicated relationship.
|
||||
Bug fixed whereby the word "visible", redundantly used in a grammar token
|
||||
as in e.g.
|
||||
Understand "inspect [any visible thing]" as examining.
|
||||
would cause a hang because I6 scope loops can't be nested.
|
||||
Bug fixed whereby hanging dependent clauses which depended on local variables
|
||||
would sometimes be construed unexpectedly. (This really only affected
|
||||
descriptions which were not very useful anyway, e.g., "the number of
|
||||
things worn by X which fit Y", which is not good style since it in
|
||||
fact evaluates the number of things worn by an X-which-fits-Y - that
|
||||
is, the "which fit Y" clause appends to X and not the things.)
|
||||
Bug fixed whereby the "after reading a command" rulebook would sometimes
|
||||
fail to be able to replace matched text in a command in cases where it had
|
||||
been rewritten as a result of a "Which do you mean...?" question.
|
||||
Bug fixed whereby the character @ could not be parsed at run-time, and an
|
||||
attempt to write something like 'Understand "@" as the giant at-symbol'
|
||||
would produce I6 errors.
|
||||
Bug fixed whereby expressions containing more than one bracketed subexpression
|
||||
would sometimes be misparsed: e.g. "let a be (x + y) / (x - y)" would
|
||||
produce spurious problem messages despite being legal syntax.
|
||||
Bug fixed whereby Definitions involving looking up entries in tables would
|
||||
sometimes compile through I7 but cause I6 errors.
|
||||
Bug fixed whereby calculations of the other side of a door, or the direction
|
||||
taken by a door, would sometimes be incorrect in darkness.
|
||||
Bug fixed whereby problems to do with variable initialisation were
|
||||
reported at the correct sentences but under the wrong headings.
|
335
Changes/Change Logs/4W37.txt
Normal file
335
Changes/Change Logs/4W37.txt
Normal file
|
@ -0,0 +1,335 @@
|
|||
4W37 (27 July 2007)
|
||||
|
||||
This build adds 21 new examples and provides miscellaneous new features.
|
||||
Chief among these are substantial improvements to the parsing of names:
|
||||
nouns can now be recognized by their number or unit properties, and also by
|
||||
their relations, so that 'Understand "bottle of [something related by
|
||||
containment]" as the bottle' will parse BOTTLE OF SAND if and only if the
|
||||
sand is contained in the bottle. We have also made a tentative beginning on
|
||||
support for sound effects to match the existing support for illustrations.
|
||||
As usual a number of bugs are fixed, and although a few issues still remain
|
||||
(the current tally of open issues stands at 13, as compared with a peak of
|
||||
about 330 earlier this year) none are severe and most users seem to find
|
||||
that Inform is fairly reliable, so recent effort has gone into advancing
|
||||
the language rather than maintaining the compiler.
|
||||
|
||||
INFORM FOR WINDOWS
|
||||
|
||||
All tabs (save the settings tab) have a row of buttons at the top of the
|
||||
tab, allowing navigation and access to common functionality,
|
||||
similar to the OS X application.
|
||||
Fixed a bug preventing the installation of an extension with brackets in
|
||||
its name.
|
||||
Added support for multiple windows to the game tab. Any combination of
|
||||
text, grid and graphics windows can be opened by a game running
|
||||
within the application.
|
||||
Added support for graphics windows to the game tab. As a result, games
|
||||
using Emily Short's "Simple Graphical Window" and "Location Images"
|
||||
extensions will now work when run within the application.
|
||||
Added support for timer events to the game tab. Combined with the above,
|
||||
games using the "Graphical Window Animation" extension will now work
|
||||
when run within the application.
|
||||
If saving a project fails, the application now shows an error message.
|
||||
If the project was being saved as part of being closed, then
|
||||
after the error you get a chance to save to a different place.
|
||||
|
||||
GENERAL
|
||||
|
||||
>--> The kind "player-character" has been abolished. Previously, this was a
|
||||
kind of person able to be the player's persona in the model world: for
|
||||
most games, there was only one player-character in existence, the one
|
||||
automatically created by Inform and called "yourself". From this point
|
||||
onwards, any "person" can be the player, and indeed "player" is now
|
||||
a person variable, not a player-character variable. This means that the
|
||||
player object can now be any man, woman or animal in the source text,
|
||||
and these can be switched between freely in play. Moreover, we can
|
||||
much more simply specify who the protagonist is:
|
||||
Lord Bowler is a man in the Pavilion. The player is Lord Bowler.
|
||||
If we do not specify the player's identity, the "yourself" is still
|
||||
created and used as before.
|
||||
This change will affect only works which create "player-characters" in
|
||||
their source text: to adapt them to work again, it should be enough
|
||||
simply to change every usage of the kind name "player-character" to
|
||||
"person", "man", "woman" or "animal" as appropriate.
|
||||
This change implements proposal (6.56) from the January 2007 consultation
|
||||
document.
|
||||
>--> Up to now, all scenes have been able to take place many times: if a
|
||||
scene ends, and then later on its starting conditions once again hold,
|
||||
then it will start all over again. This is sometimes very useful, but
|
||||
also a source of confusion, and it has led to people writing "S begins
|
||||
when ... for the first time" over and over to stop S from recurring.
|
||||
As from this build, a scene can be declared either as recurring or not
|
||||
when it is first created. So for instance:
|
||||
Hourly Patrol is a recurring scene.
|
||||
Apocalyptic End is a scene.
|
||||
makes one of each kind of scene. (An ordinary scene can also be declared
|
||||
as a "non-recurring scene" for clarity's sake.) Note that any scene
|
||||
declared as just "scene", and in particular any scene declared in
|
||||
source text for previous builds of Inform, is now non-recurring: so if
|
||||
you need a scene to recur in a work-in-progress, you need to insert the
|
||||
word "recurring" into its definition.
|
||||
This change implements proposal (6.52) from the January 2007 consultation
|
||||
document, though in a slightly different way from that proposed.
|
||||
Partial sound support has been added to Inform: see the new sections 19.6
|
||||
and 19.7 of the documentation. As with picture support, Inform provides
|
||||
the groundwork and leaves it for more sophisticated extensions to go into
|
||||
more elaborate facilities. The present state of completion is that Inform
|
||||
can, on all platforms, read Ogg Vorbis or AIFF sound files from the
|
||||
Materials/Sounds folder for a project, and embed them correctly into a
|
||||
Blorbed Glulx story file, compiling correct code for the Glulx machine
|
||||
to play the sounds back at the appropriate moment. However, these
|
||||
sounds will only be audible in Windows Inform, or when playing a
|
||||
released Glulx story file in Windows Glulxe or Spatterlight for OS X:
|
||||
Glulx support for sound has been implemented in the glulx interpreter
|
||||
used in both Inform and Zoom for OS X, so that placeholder text is
|
||||
printed instead.
|
||||
Sound support was proposal (6.61) from the January 2007 document.
|
||||
Up to now, the only properties which could be used as part of an object's
|
||||
name for parsing purposes were either/or properties and enumerated named
|
||||
properties. This restriction has been almost completely lifted: we
|
||||
can now understand properties whose kind is number, time, or a unit.
|
||||
For example:
|
||||
An aspect ratio is a kind of value. 16:9 specifies an aspect ratio.
|
||||
A television is a kind of thing. A television has an aspect ratio.
|
||||
The widescreen TV is a television in the Office. The fifties TV is
|
||||
a television in the Office. The widescreen TV is 16:9. The fifties
|
||||
TV is 4:3. Understand the aspect ratio property as referring to
|
||||
a television.
|
||||
...allows us to type EXAMINE 16:9 TV, for instance.
|
||||
In addition, further grammar used to specify unusual values is now
|
||||
recognised in such situations: for instance if we wrote...
|
||||
Understand "European standard" as 16:9.
|
||||
the EXAMINE EUROPEAN STANDARD TV would also work. (Previously this did
|
||||
not work, because the implementation was incomplete.)
|
||||
Finally, a problem message has been added for the (now fairly few) cases
|
||||
where the property still does have a kind which cannot be parsed:
|
||||
previously no problem was issued in cases Inform could not handle, and
|
||||
the feature simply did not work.
|
||||
(This change did not appear in the January document, but has been much
|
||||
requested since.)
|
||||
A new form of grammar token has been added to enable names of objects (and
|
||||
rooms) to include names of other objects (and rooms) related to them.
|
||||
For instance, if we write:
|
||||
A box is a kind of container. Understand "box of [something related
|
||||
by containment]" as a box. The Toyshop is a room. The red box is a
|
||||
box in the Toyshop. Some crayons are in the red box.
|
||||
then TAKE BOX OF CRAYONS will work, because CRAYONS matches against
|
||||
"[something related by containment]" for the red box - or it does for
|
||||
as long as the crayons are there. We can have similar matches against
|
||||
relations of all kinds, but have to name the relation explicitly, using
|
||||
its one-word name. We can also reverse the sense:
|
||||
A box is a kind of container. Understand "box in [something related
|
||||
by reversed containment]" as a box. The Toyshop is a room. The crate
|
||||
and the hammock are in the Toyshop. In the crate is a box. In the
|
||||
hammock is a box.
|
||||
makes TAKE THE BOX IN THE HAMMOCK work. (Where more than one object
|
||||
matches the criterion, for instance if the original box contained both
|
||||
crayons and chalk, any of the names can be used.)
|
||||
Inform normally decides whether an object has a singular or plural name,
|
||||
or whether it has a proper name, by looking at how it is first
|
||||
introduced. This mainly works well, but people have also asked for
|
||||
more explicit control, especially to cope with changes in an object
|
||||
during play. Accordingly, there are now two new either/or properties
|
||||
for all things:
|
||||
A thing can be plural-named or singular-named.
|
||||
A thing can be proper-named or improper-named.
|
||||
This change implements proposal (6.46) from the January 2007 document.
|
||||
The phrase for changing the exits of a room can now accept "nothing" or,
|
||||
equivalently, "nowhere" as the new exit, thus allowing map connections
|
||||
to be explicitly deleted in play. For instance:
|
||||
change the east exit of Stage to nowhere;
|
||||
Bugs in type-checking to do with the handling of "nothing" have been
|
||||
removed.
|
||||
Some authors have recently asked for the facility to make extensions go
|
||||
uncredited in the VERSION command output, since this might give away
|
||||
story details, or generally produce verbosely self-laudatory output.
|
||||
A new "authorial modesty" use option has been created for this purpose.
|
||||
Inform has to tread a careful line here, because people make extensions
|
||||
available under a Creative Commons licence which requires that they be
|
||||
credited: so you can only be modest about your own work. If the sentence:
|
||||
Use authorial modesty.
|
||||
is found in an extension, then its credit line is omitted from the VERSION
|
||||
output of any game using it. If the same sentence is found in the main
|
||||
source text of a work, then credits are omitted for every extension with
|
||||
the same author's name as the work itself. (In other words, it credits
|
||||
everyone else's extensions, but suppresses mention of your own.)
|
||||
The "say" phrase "[list of extension credits]" uses the same convention,
|
||||
but the new "say" phrase:
|
||||
"[complete list of extension credits]"
|
||||
ignores all these efforts at modesty and prints the whole list. (An
|
||||
otherwise modest author might want to print this posthumously after the
|
||||
end of play, for instance, or in response to a secret debugging command.)
|
||||
The the ambient odour rule, the ambient sound rule and the block vaguely
|
||||
going rule now apply to actions by all actors, not just the player, so
|
||||
that (for instance) the command XERXES, LISTEN will be read as a
|
||||
request to listen to the ambient location, rather than printing out a
|
||||
parseresque objection such as "What do you want Xerxes to listen to?"
|
||||
The grammar "switch on [something]" has been added to the standard rules,
|
||||
and has the same effect as "switch [something] on". This is more consistent
|
||||
with switching off.
|
||||
The maximum length for an extension rubric has been increased from 250 to
|
||||
500 characters. (Rubrics exceeding that length are silently truncated
|
||||
in extension documentation.)
|
||||
It is now allowed to create a temporary value (i.e., a local variable) with
|
||||
"let" whose name coincides with that of a thing, room or property.
|
||||
Previously this triggered problem messages, and was a particular problem
|
||||
for extensions and the Standard Rules, which had to avoid "let" names
|
||||
that might hit any of the things created by the user. (For instance,
|
||||
several people reported it as a bug that creating a property called
|
||||
"target" caused problems - this was because the Standard Rules use a
|
||||
"let" variable called "target" in places.)
|
||||
The resolution of noun phrases has been slightly changed so that a single-word
|
||||
kind of value name will take precedence over the name of a thing or room
|
||||
in an assertion sentence. For instance:
|
||||
The scene script is in the wardrobe.
|
||||
Grand Finale is a scene.
|
||||
would previously have read "scene" as a reference to the scene script,
|
||||
a physical thing, not the kind of value "scene". (This in practice makes
|
||||
it easier to have rooms and things whose names include the names of
|
||||
kinds such as "number", "time" and so on.)
|
||||
Examples:
|
||||
"Lanista" parts 1 and 2 added to demonstrate randomized combat, first in
|
||||
a simple form and then with weaponry and an ATTACKING IT WITH action
|
||||
"Night and Day" added to demonstrate recurring sequences of scenes
|
||||
"Candy" added to demonstrate making a randomly selected item poisonous
|
||||
"Puff of Orange Smoke" added to demonstrate redirecting all actions from
|
||||
one object to another
|
||||
"Disappointment Bay" examples changed to the more geographically accurate
|
||||
Disenchantment Bay; typo fixed in the final, finished example
|
||||
"Entrapment" modified to correct a bug due to changed handling of actions
|
||||
in recent releases of Inform
|
||||
"Terror of the Sierra Madre", which demonstrates player-switching,
|
||||
greatly simplified as a result of the abolition of player-character
|
||||
"Exit Strategy", demonstrating how to set up non-recurring scenes, removed
|
||||
(since all scenes are now non-recurring unless otherwise stated)
|
||||
"Pine 3", "Pine 4", "The Prague Job", and "Space Patrol" modified to
|
||||
reflect the usage of "recurring" scenes
|
||||
"Snip" modified to remove bugs and make use of the new ability to
|
||||
understand unit properties; "Snip Snip" withdrawn, as the hack it
|
||||
demonstrates is no longer needed and the same functionality was
|
||||
achieved instead by a single line added to "Snip"
|
||||
"Totality" (example about scheduling an eclipse) given a "test me" script,
|
||||
and a syntax bug removed
|
||||
"Dinner is Served" revised to work better when the object reached for
|
||||
is the second noun rather than the noun, and also to have less
|
||||
cryptic syntax; the test for the example has been extended
|
||||
"Tilt" added to demonstrate an implementation of a deck of cards using
|
||||
individual card objects, in which ranks and suits of cards are
|
||||
automatically parsed
|
||||
"Tilt 2" added to demonstrate an implementation of poker hands, where
|
||||
the cards in a player's inventory are described according to their
|
||||
value; illustrates use of a complex rulebook
|
||||
"Tilt 3" added to demonstrate use of text colors to make poker suit
|
||||
symbols appear in red, under both Glulx and the Z-machine
|
||||
"Aspect" added to demonstrate the automatic parsing of unit properties
|
||||
"Channel" added to demonstrate the automatic parsing of number properties
|
||||
"Channel 2" added to demonstrate a combination of advanced parsing
|
||||
features, in the creation of tunable televisions
|
||||
"Cheese-makers" added to demonstrate a TALK TO action tied to a
|
||||
scene-structured plot
|
||||
"Alias" added to demonstrate telephone-number-sized units functioning
|
||||
under Glulx
|
||||
"Claims Adjustment" added to demonstrate a camera that produces instant
|
||||
photographs of things; the photographs can then be referred to as
|
||||
in X PHOTOGRAPH OF APPLE
|
||||
"Puncak Jaya" added to demonstrate characters who can be referred to in
|
||||
their absence
|
||||
"Cinco" added to demonstrate containers referred to by their contents
|
||||
"Originals" added to demonstrate disambiguating objects from models of
|
||||
those objects
|
||||
"Removal" simplified to use action variables rather than the more
|
||||
complicated source
|
||||
"Gopher-wood" added to demonstrate the use of the proper-named attribute
|
||||
to change someone's name during play
|
||||
"Carnivale" added to demonstrate the simple scoping case of a large object
|
||||
that should be visible from other rooms
|
||||
"Rock Garden" added to demonstrate the simple scoping case of multiple
|
||||
rooms that can see into one another (as opposed to the rather more
|
||||
complex "Stately Gardens" which autogenerates a lot of room
|
||||
description as well)
|
||||
"Latin Lessons" added to demonstrate supplying a missing noun when the
|
||||
action is being performed by someone other than the player
|
||||
"Uber-Complete Clavier" (the big Unicode test) slightly changed so that
|
||||
it can now be compiled for Glulx as well as the Z-machine
|
||||
Paragraph breaking adjusted in "In Fire or in Flood", "Misadventure",
|
||||
"Goat-Cheese and Sage Chicken", "Owen's Law"
|
||||
Minor typos removed from "Wight", "Alpaca Farm", "Apples"
|
||||
Extensions:
|
||||
"Glulx Text Effects" modified to make it easier to set custom colors
|
||||
for text in Glulx; this appropriates the color-management source from
|
||||
the extension "Simple Graphical Window" by Emily Short, so those
|
||||
using Simple Graphical Window should update to version 4 of the
|
||||
extension in order to avoid overlap. Advanced to version 2.
|
||||
"Punctuation Removal" revised to include a phrase that corrects
|
||||
instances of "mr.", "mrs.", etc., to "mr", "mrs", and the like, to get
|
||||
around parsing frustrations commonly encountered with these titles.
|
||||
Also added the means to remove apostrophes as well as the other
|
||||
punctuation marks; example added for parsing such phrases as "Jack's
|
||||
tie" if and only if Jack is currently wearing the tie object. Version
|
||||
number advanced to 3.
|
||||
A bug fixed in "Complex Listing to deal with the marking of regions";
|
||||
version number advanced to version 5.
|
||||
Bug fixed in the screen-width-determining routine of "Basic Screen Effects".
|
||||
Bug fixed whereby past tense conditions in the form "in ... for the first time"
|
||||
would sometimes have the temporal requirement ignored, particular in the
|
||||
preambles to rules like:
|
||||
Every turn when in the Hall of Mists for the first time;
|
||||
Bug fixed whereby rules which depend on action taking place at the same time
|
||||
as a compound condition would sometimes produce spurious problem messages:
|
||||
for instance,
|
||||
Check turning the dial to when the number understood < 0 or the
|
||||
number understood > 99:
|
||||
...is valid but generated a problem message in 4U67.
|
||||
Bug fixed whereby "otherwise if ... begin" (which is incorrect since otherwise
|
||||
if divides the existing code block, rather than beginning a new one) led
|
||||
to I6 errors rather than a problem message.
|
||||
Bug fixed whereby using "(called ...)" to create temporary named values at
|
||||
a time in the past such that they could not survive to the present
|
||||
would lead to I6 errors rather than a problem message.
|
||||
Bug fixed whereby rules taking effect if "doing something to ..." and some
|
||||
description would sometimes false take effect when the action took a
|
||||
non-object as its noun, when the value which happened to have been
|
||||
typed coincided with the internal object number of an item matching
|
||||
the description.
|
||||
Bug fixed whereby changing player to someone else and then back again, and
|
||||
then using the short name of the player, would crash both the Z and
|
||||
Glulx virtual machines at run-time.
|
||||
Bug fixed whereby I7 would crash if told to understand empty text as something.
|
||||
(This is not allowed, and a problem message has been added.)
|
||||
Bug fixed whereby scenes predicated on past tense actions ("Mayhem begins when
|
||||
we have waited") would cause an internal error.
|
||||
Bug fixed whereby the condition "we have taken inventory" gave false positives
|
||||
after the first turn.
|
||||
Bug fixed whereby nameless variables attached to activities gave internal
|
||||
errors rather than a problem message.
|
||||
Bug fixed whereby creating an object called "nowhere" caused a crash rather
|
||||
than a problem message.
|
||||
Bug fixed whereby grammar introducting alternative textual names for numbers
|
||||
(e.g. 'Understand "a/b/c" as 2.') could lead to I6 errors.
|
||||
Bug fixed whereby vaguely named properties in adjective definitions would
|
||||
result in internal errors rather than a problem message.
|
||||
Bug fixed whereby naming actions which happen to include "with" can create
|
||||
spurious out-of-play things (doing no harm, but doing no good either):
|
||||
for instance, "Unlocking the box with the key is bizarre behaviour."
|
||||
would create an object called "Unlocking the box", in addition to doing
|
||||
what it was supposed to do.
|
||||
Bug fixed whereby matching the player's command against text rather than a
|
||||
topic would cause an interpreter crash at run-time.
|
||||
Bug fixed whereby verbs defined as auxiliaries required participles to be
|
||||
named unnecessarily, contrary to the documentation: thus "The verb to be
|
||||
able to approach implies the approachability relation." would fail for
|
||||
no good reason.
|
||||
A bug introduced by the actions rewrite in 4U65 caused player's holdall
|
||||
objects not to work properly if they were being worn rather than carried
|
||||
(as in the documentation's example "Sackcloth"). This is fixed: apologies.
|
||||
In past builds the grammar token "[a number]", in Understand sentences, has
|
||||
required the number in question to be something which can be stored in
|
||||
a signed 16-bit variable, that is, to be between -32768 and 32767. This
|
||||
is correct for story files running on all versions of the Z-machine, but
|
||||
the Glulx virtual machine has 32-bit variables, so for Glulx the
|
||||
restriction is unnecessary. It has now been lifted: thus on Glulx, we
|
||||
can parse numbers in the range -2147483648 to 2147483647 inclusive.
|
||||
The Inform 6 debugging verb DAEMONS (aka TIMERS), which is undocumented and
|
||||
meaningless in I7 since this lacks either daemons or timers in the crude
|
||||
I6 sense, could under some circumstances crash if tried in an I7 game.
|
||||
The verb is now removed altogether.
|
305
Changes/Change Logs/4X60.txt
Normal file
305
Changes/Change Logs/4X60.txt
Normal file
|
@ -0,0 +1,305 @@
|
|||
4X60 (23 August 2007)
|
||||
|
||||
This build adds 19 new examples and modernises a dozen others, and presents
|
||||
a new volume of built-in documentation: the Inform Recipe Book. It also
|
||||
provides new features for variable text, improves and extends table-handling,
|
||||
allows Glulx-format games to read and write files and communicate with
|
||||
external programs, and allows extensions to create more readable and
|
||||
useful documentation.
|
||||
|
||||
(Windows only) Added support for Glulx mouse events and hyperlinks to the
|
||||
game tab.
|
||||
(Windows only) The justification style hint is now supported when running
|
||||
a Glulx game in the game tab. As a result, games using Emily Short's
|
||||
"Glulx Image Centering" will now work when run within the application.
|
||||
|
||||
A new manual, The Inform Recipe Book, has been added to the application. It
|
||||
sits alongside the previous manual (Writing with Inform) and presents
|
||||
the examples thematically, with connecting advice and comparisons of
|
||||
techniques to achieve a wide range of IF effects. This should make the
|
||||
(now 357) examples much easier to browse and to borrow from.
|
||||
The "[one of]" text substitution previously provided by Jon Ingold's
|
||||
extension "Text Variations", which built on code by Andrew Plotkin and
|
||||
Roger Firth, has now been adopted into Inform's core language. Examples
|
||||
of its use include:
|
||||
say "You flip the coin. [one of]Heads[or]Tails[purely at random].";
|
||||
say "[one of]The phone rings[or]The phone rings a second time[or]The
|
||||
phone rings again[stopping].";
|
||||
say "You turn the light switch [one of]off[or]on[cycling]. Nothing
|
||||
happens.";
|
||||
say "The newspaper headline is: [one of]War Casualties
|
||||
[or]Terrorists[or]Banks[sticky random] [one of]Continue To Expand
|
||||
[or]Lose Out[sticky random].";
|
||||
say "The light changes randomly again; now it's [one of]green
|
||||
[or]amber[or]red[at random].";
|
||||
say "Zorro strides by, [one of]looking purposeful[or]grim-faced[or]deep
|
||||
in thought[or]suppressing a yawn[or]scratching his ribs[or]trying
|
||||
to conceal that he has cut himself shaving[as decreasingly
|
||||
likely outcomes].";
|
||||
say "You dip into the chapter on [one of]fish[or]mammals[or]birds
|
||||
[or]reptiles such as the black salamander[in random order]."
|
||||
See the new section 5.6 in the documentation: note that "[as decreasingly
|
||||
likely outcomes]" and "[in random order]" are new options, the former
|
||||
using a tapering probability distribution, the latter a random permutation.
|
||||
>--> It should be noted that the new implementation of this substitution is
|
||||
completely different to the one provided by the extension. The previous
|
||||
method involved printing all the text to a buffer array, then hash-coding
|
||||
it and taking choices based on this hash, which meant that the same
|
||||
sequence of choices occurring twice in the same text would be effectively
|
||||
the same (because of having the same hash code); thus
|
||||
"This is [one of]A[or]B[at random] versus [one of]A[or]B[at random]."
|
||||
could never print "This is A versus A." or "This is B versus B." The new
|
||||
implementation treats each "[one of]..." individually. To get around this,
|
||||
define
|
||||
To say A-or-B: say "[one of]A[or]B[at random]".
|
||||
and then change the text to
|
||||
"This is [A-or-B] versus [A-or-B]."
|
||||
Furthermore, there is no buffer array, no hash code, and it is no longer
|
||||
possible to extract state information by deliberately printing the text
|
||||
with an incomplete "[one of]" construction. (To quote the Text Variations
|
||||
documentation: "a terrible way to solve that kind of problem", so we don't
|
||||
feel too bad about withdrawing it.) Thus the phrases "the index of the
|
||||
last buffer" and "the index of the buffer" no longer exist.
|
||||
In any case, the new implementation polices the use of the construction
|
||||
so that leaving it incomplete is no longer possible. "[one of]" must be
|
||||
matched by one of its possible conclusions "[purely at random]",
|
||||
"[stopping]", ..., or problem messages will be generated; similarly,
|
||||
"[or]" can only legally be used inside the construction. On the other
|
||||
hand, the new implementation does allow the construction to be nested, both
|
||||
explicitly in a single text and also implicitly (where a text substitution
|
||||
inside one of the options itself does something which also involves a
|
||||
"[one of]"), where the old implementation would silently have failed.
|
||||
As an explicit example:
|
||||
"[one of]A palace on the [one of]Nile[or]Euphrates[purely at random]
|
||||
delta[or]A hovel by the [one of]Tigris[or]Rhine[purely at random]
|
||||
river[purely at random]."
|
||||
In practice, if a work in progress used "Text Variations" and did not
|
||||
try to use "the index of the last buffer" then there is a good chance
|
||||
that simply deleting the line
|
||||
Include Text Variations by Jon Ingold.
|
||||
will be the only change required.
|
||||
We thank Jon Ingold and his collaborators for donating their design. The
|
||||
extension "Text Variations" will continue to be available from the website
|
||||
for the time being, but marked as no longer needed or compatible with
|
||||
builds from here onwards. We suggest that users uninstall it once they
|
||||
are sure that any works in progress continue to work without.
|
||||
This change implements proposal (6.20) from the January 2007 consultation
|
||||
document.
|
||||
The run-time code for handling tables has been rewritten to improve its
|
||||
reliability and efficiency. A number of minor bugs have been fixed in
|
||||
the process, notably a failure to sort correctly on tables which contain
|
||||
mixed blank and non-blank rows, and a rarely occurring problem to do with
|
||||
storing the number 32739 in table entries under the Z-machine.
|
||||
Table sorting is now carried out using a hybrid algorithm: insertion sort
|
||||
from 1 to 11 rows, and in-place mergesort for 12 rows and up. This is
|
||||
much faster on even medium-sized tables (e.g. about ten times faster on
|
||||
tables of 200 rows), and is also stable in all cases: that is, if
|
||||
two rows have the same value in the X column of a table, and that
|
||||
table is then sorted (forwards or backwards) on the X column, then
|
||||
they will stay the same side as each other. As a consequence, all sorts
|
||||
are idempotent, that is, performing the same sort operation twice always
|
||||
results in the second operation making no changes at all. (The previous
|
||||
algorithm was idempotent but, owing to a bug, not in all cases stable.)
|
||||
Insertion/in-place mergesort was chosen because we needed stability,
|
||||
O(n log n) average running time (together with good performance
|
||||
on nearly-sorted tables, which are the commonest usage cases in
|
||||
actual Inform source text), O(1) storage overhead (the Z-machine is
|
||||
extremely short of table space), and reasonably predictable stack usage.
|
||||
Projects compiled for Glulx rather than the Z-machine now have the ability
|
||||
to make use of external files. Like sound effects and figures, these
|
||||
are declared and given names before use:
|
||||
The File of Glaciers is called "ice".
|
||||
This creates a new named constant "File of Glaciers" (whose kind of value
|
||||
is "external-file") for use in file contexts. (The prefix "binary file"
|
||||
rather than "file" can be used to make the file binary in the Glk sense,
|
||||
but the default is to use text files for all purposes.) Each file is
|
||||
considered to be owned by some project, identified by its IFID. By
|
||||
default, a newly declared file is owned by its own project, but we can
|
||||
also specify that we want to use somebody else's file, either explicitly
|
||||
or vaguely:
|
||||
The file of Spectral Sequences (owned by project
|
||||
"4122DDA8-A153-46BC-8F57-42220F9D8795") is called "adams".
|
||||
The file of Boundaries (owned by another project) is called "milnor".
|
||||
We can write or append to a file owned by anyone, but can only read a
|
||||
file whose ownership matches this description.
|
||||
External files are indexed in the Contents index, alongside figures and
|
||||
sound effects.
|
||||
Files sometimes exist, and sometimes do not: they are sometimes complete,
|
||||
sometimes only partly written. (For a file shared between two games
|
||||
running simultaneously, one might try to read a file the other is still
|
||||
in the middle of writing.) We can test this with:
|
||||
if the file of Invariants exists...
|
||||
if ready to read the file of Invariants...
|
||||
A file cannot be ready if it does not exist, so the latter is a stronger
|
||||
condition.
|
||||
Tables can be saved to external files, and loaded them back in again, during
|
||||
play: all file-handling is done automatically. The user only needs to use
|
||||
the phrases:
|
||||
read the File of Glaciers into the Table of Antarctic Features;
|
||||
write the File of Glaciers from the Table of Antarctic Features;
|
||||
Blank entries are preserved; it is legal to write a small file into a
|
||||
large table, and if so, all unwritten entries are blanked; a run-time
|
||||
problem is shown if the file contains more rows or columns than will
|
||||
fit into the table which it is being loaded into; similarly, a run-time
|
||||
problem is shown on trying to write a table which contains data not
|
||||
safely exchangeable with other story files (or other compilations of
|
||||
itself).
|
||||
Text can also be saved to a file, and again all file-handling is automatic:
|
||||
write "Jackdaws love my big sphinx of quartz." to the file of
|
||||
Abecedary Wisdom;
|
||||
append "Jinxed wizards pluck ivy from the big quilt." to the file of
|
||||
Abecedary Wisdom;
|
||||
The quoted text can, of course, contain substitutions, so can be
|
||||
long and complex if need be. On an append, the file is created if it does
|
||||
not already exist.
|
||||
Text from a file is printed back with the text substitution:
|
||||
"[text of the File of Abecedary Wisdom]"
|
||||
To copy one file to another, for instance,
|
||||
write "[text of the file of Abecedary Wisdom]" to the file of
|
||||
Secondary Wisdom;
|
||||
>--> The implications to do with lockability have been improved:
|
||||
A locked thing is usually lockable.
|
||||
A locked container is usually closed.
|
||||
A locked door is usually closed.
|
||||
A lockable container is usually openable.
|
||||
A lockable door is usually openable.
|
||||
Thus writing "The ballot box is a locked container." will now deduce that
|
||||
the box is probably lockable, closed but openable. These are only guesses
|
||||
by Inform, and can be overridden by giving explicit instructions to the
|
||||
contrary: "The ballot box is a locked unopenable container."
|
||||
Definitions of adjectives, which previously had to refer to their subjects
|
||||
only by the pronoun "it" (or in some cases "his", "her", etc.), can now
|
||||
make callings. For instance:
|
||||
Definition: a direction (called thataway) is viable if the
|
||||
room thataway from the location is a room.
|
||||
is a good deal easier to read than
|
||||
Definition: a direction is viable if the room it from the location
|
||||
is a room.
|
||||
which was previously the only way to write this. Only a single calling
|
||||
can be made, and it must refer to the specific object to which the
|
||||
definition applies.
|
||||
A new rule in the Standard Rules, the "can only take things rule", prevents
|
||||
the taking of objects which are not things - for instance, rooms or
|
||||
directions. (Such an action can never normally be generated by the
|
||||
grammar for typed commands, but if Understand sentences are written
|
||||
to open the possibility then the player will see ugly "programming error"
|
||||
messages: the new rule prints a more suitable reply.)
|
||||
Extension documentation can now request "paste into the source text" icons
|
||||
like those found in the main documentation and its examples. If an
|
||||
indented paragraph of quoted source text begins with an asterisk and
|
||||
then a colon, like so...
|
||||
*: A dog is a kind of animal.
|
||||
...then the asterisk-and-colon are replaced in the final documentation
|
||||
by a paste icon: clicking this will insert the copy which follows into
|
||||
the source text. The text to be pasted is considered to begin after the
|
||||
colon, and to continue until the next unindented text, i.e., it can
|
||||
run for many quoted paragraphs, but as soon as the quotation is broken
|
||||
the paste extent will end. Any tables within the quoted range should
|
||||
be safely rendered with tabs in between the columns.
|
||||
Large extensions which need to include a large amount of documentation
|
||||
can now subdivide it using headings and/or subheadings, like so:
|
||||
Chapter: Pesky Meddling Kids
|
||||
Section: Dog Food
|
||||
A suitable table of contents with navigation links will be automatically
|
||||
added to the extension documentation, if so.
|
||||
The Extensions chapter of the documentation has, appropriately enough, been
|
||||
extended: it now opens up a limited number of previously restricted
|
||||
syntaxes to public use. These will only be useful to experienced Inform 6
|
||||
programmers.
|
||||
Fixed a further namespace clash: a "let" name can now coincide with the
|
||||
column name of a table. (This was preventing John Clemens's extension
|
||||
"Scheduled Activities" from working in recent builds.)
|
||||
Extensions:
|
||||
"Basic Screen Effects" very slightly updated so that the documentation
|
||||
is clearer about the lack of colored letters in Glulx, and suggests
|
||||
that the author turn to Glulx Text Effects for these capabilities
|
||||
instead; also given a new example to demonstrate forcing the player
|
||||
to type what we want him to type (since this is becoming something
|
||||
of a frequently-asked question); chapter and section headings and
|
||||
paste-able examples added.
|
||||
"Basic Help Menu", "Glulx Text Effects", "Locksmith", "Menus",
|
||||
"Punctuation Removal" tagged so that the example can be pasted.
|
||||
"Complex Listing", "Plurality" tagged and given chapter and section
|
||||
headings.
|
||||
Examples:
|
||||
"Radio Daze" example from Jon Ingold's Text Variations extension brought
|
||||
into the main documentation.
|
||||
"Camp Bethel" added to demonstrate several other common applications of
|
||||
text alternatives.
|
||||
"Chanel version 1" added to demonstrate paired "[i]...[/i]" and
|
||||
"[b]...[/b]" italic and boldface tags, similar to HTML's.
|
||||
"Blink" added to demonstrate creating one's own text variations keyed
|
||||
to values, using the special terminology explained in the Extensions
|
||||
chapter.
|
||||
"Uncommon Ground" added to demonstrate creating one's own text variations
|
||||
keyed to the identity of the player character.
|
||||
"Labyrinth of Ghosts" added to demonstrate recording the deaths of all
|
||||
previous players of the story file by storing them in a file.
|
||||
"Alien Invasion Part 23" added to demonstrate saving preference files
|
||||
from one game in a series for use in the next episode.
|
||||
"Flathead News Network" added to demonstrate communicating with a simple
|
||||
Unix script running in the background, in order to provide live news
|
||||
headlines (drawn from RSS feeds) inside a story file.
|
||||
"Ferragamo Again", "Straw Boater" slightly cleaned up to be better filed
|
||||
in the Recipe Book.
|
||||
"Cinco" edited to fix a particularly bone-headed bug that vitiated the
|
||||
whole point of the example.
|
||||
"When?" adjusted to slightly improve the way the example is described.
|
||||
"Modern Conveniences" added to demonstrate standard kitchen and bathroom
|
||||
appliances.
|
||||
"Do Pass Go" added to demonstrate a pair of dice.
|
||||
"Mirror, Mirror" added to demonstrate remembering the current room
|
||||
description by preserving it in an external file.
|
||||
"The Unbuttoned Elevator Affair" added as an example of a simpler lift
|
||||
than the elaborate one in "Dubai".
|
||||
"Further Reasons Why All Poets Are Liars" added as an example of using
|
||||
action variables for an action which moves a box around internal
|
||||
positions inside a location; a much thinner version of this example,
|
||||
"A pushable box", has been removed.
|
||||
"M. Melmoth's Duel" added, similarly to replace "Tinted wallpaper".
|
||||
"The Second Oldest Problem" added to demonstrate using action variables
|
||||
to make the going action react to moving between dark rooms.
|
||||
"Saint Eligius" added to demonstrate an additional comment added to a
|
||||
room description when the player first enters.
|
||||
"Baritone, Bass" added to demonstrate defining the character at the
|
||||
start of play.
|
||||
"Bic" added to demonstrate testing whether any defined objects are missing
|
||||
description properties.
|
||||
"Meet Market" added to demonstrate relations involving multiple values.
|
||||
"Depth" rewritten to improve the simulated geometry used to test whether
|
||||
an item could fit inside a container.
|
||||
"Patient Zero," "Today Tomorrow," "Reporting rules for other characters'
|
||||
behavior," "Uptown Girls", "Full Moon" edited to take advantage of
|
||||
new text variation features.
|
||||
"Belfry", "Bikini Atoll", "Dearth and the Maiden", "Hayes Code",
|
||||
"Lies", "Safety", "Undertomb" and "Weathering" all made into formal
|
||||
numbered examples rather than, as in previous builds, appearing in
|
||||
the running text of the manual.
|
||||
Bug fixed (or, if you prefer, feature added) whereby sentences providing
|
||||
alternative names for times of day, like:
|
||||
Understand "lunch time" as 11:30 am.
|
||||
...now work as might be expected.
|
||||
Bug fixed whereby Understand ... as a person would fail with I6 errors.
|
||||
(Apologies for this: an oversight in 4W37's abolition of the
|
||||
player-character kind, which had the same flaw, but nobody noticed
|
||||
because it was so little used.)
|
||||
Bug fixed whereby "if S is not happening", for S a scene, would incorrectly
|
||||
think that a completed once-only scene was still happening.
|
||||
Bug fixed whereby implications would in some cases be ignored in circumstances
|
||||
which it would be tiresome to write out, but to do with multiple things
|
||||
being simultaneously present, some qualifying and some not.
|
||||
Bug fixed whereby using I7 to rerelease an existing I6 story file in
|
||||
blorbed format with bibliographic data would fail because of the lack
|
||||
of a room (needed to initialise certain room variables).
|
||||
Bug fixed whereby a few either/or properties could not be changed in play
|
||||
without spurious run-time problems being produced. (In particular,
|
||||
"now X is transparent" or "now X is opaque" caused problems.)
|
||||
Bug fixed whereby declaring that the player is a person who happens to be
|
||||
initially somewhere other than in the earliest-created room, or outside
|
||||
the map altogether, would cause programming errors or other strange
|
||||
phenomena at run-time.
|
||||
Bug fixed where a player attempting to UNLOCK a door which is "locked" but
|
||||
which, unbeknownst to the player, has no matching key, would cause a
|
||||
run-time problem complaining about the lack of a "matching key" property.
|
||||
Problem message added for trying to use "[something related by...]" to
|
||||
understand something which can have no relations.
|
722
Changes/Change Logs/5G67.txt
Normal file
722
Changes/Change Logs/5G67.txt
Normal file
|
@ -0,0 +1,722 @@
|
|||
5G67 (10 November 2007)
|
||||
|
||||
This build presents substantially richer support for handling text: for the
|
||||
first time, arbitrary and manipulable strings of text are first-class values
|
||||
in Inform. Substantial internal reforms, notably a new implementation of
|
||||
the type-checker (now the third such), lead also to other improvements:
|
||||
notably the ability to store and play back entire actions, and a form of
|
||||
boolean type for the first time - "truth state". Finally, Inform is now
|
||||
available for three new operating systems: Mac OS X Leopard (10.5), and
|
||||
Fedora and Ubuntu Linux. We welcome Philip Chimento to the Inform team as
|
||||
the author of the Gnome user interface for Linux.
|
||||
|
||||
MAC OS X
|
||||
|
||||
Mac OS 10.5 (Leopard) incompatibilities corrected; support added for
|
||||
QuickLook viewing of Inform projects, and for content-reflecting icons.
|
||||
Bug fixed whereby replay and double-clicking in the skein sometimes failed to
|
||||
do anything.
|
||||
Provisos such as "(for Glulx only)" are now removed from extension titles when
|
||||
making filenames for newly installed extensions.
|
||||
The '+' button now works when adding Inform 6 extensions: in previous versions
|
||||
the only way to install a new Inform 6 extension was by dragging it to the
|
||||
window. Additionally, a bug has been fixed that was making it hard to
|
||||
add ORLib as a complete directory: in this new release it should be
|
||||
possible to just drag the ORLib directory to the Extensions pane and then
|
||||
use it by switching it on in the Settings tab of an Inform 6 project.
|
||||
CocoaGlk 1.0.4 adopted, which includes a number of fixes:
|
||||
Fixed an issue that could cause a crash if a text grid window ends up with
|
||||
a negative size
|
||||
Fixed a problem that was causing games to crash under Leopard
|
||||
Various stream calls will now produce a warning when they are passed a NULL
|
||||
stream instead of crashing with an error. (The old behaviour was
|
||||
technically correct, but gwindows was passing in NULL streams quite often)
|
||||
Fixed an issue that was causing script files to be left empty until the
|
||||
user typed "script off"
|
||||
Other minor changes:
|
||||
(I6 projects) "Add breakpoint" in the main menu now works in either pane
|
||||
Extensions are now displayed in alphabetical order
|
||||
The "Open Extensions" menu can now view built-in extensions
|
||||
Bug fixed whereby Glulx games were not saving transcripts correctly
|
||||
|
||||
|
||||
WINDOWS
|
||||
|
||||
Fixed an intermittent crash in the I7 application, where it would stop
|
||||
with a dialog complaining about a "pure virtual function call".
|
||||
Thanks to Maryam Gousheh-Forgeot for helping track this problem
|
||||
down.
|
||||
Added a headings menu to the source tab, following the similar menu on
|
||||
OS X. The menu initially shows the top-level headings in the
|
||||
source. Select a heading to go to it, or click on an arrow to
|
||||
see the sub-headings below that heading.
|
||||
|
||||
|
||||
INDEXED TEXT
|
||||
|
||||
A new kind of value, "indexed text", exists to hold text which can be internally
|
||||
examined or changed. Ordinary text values are automatically converted to
|
||||
indexed text format when necessary. For instance,
|
||||
if character number 1 in "[score]" is "7", ...
|
||||
implicitly converts the text of the current score to indexed form, allowing
|
||||
it to be looked at character-by-character, and then examines the first
|
||||
character: so the test passes if the first digit of the score is a 7.
|
||||
Memory is dynamically allocated to allow for such manipulations in a way
|
||||
transparent to the user (and on the Glulx virtual machine 3.1.0 or better,
|
||||
Inform story files can allocate arbitrarily large memory heaps).
|
||||
See the new Chapter 19, "Advanced Text", in the documentation.
|
||||
Indexed text can be accessed by character, word, line or paragraph, with
|
||||
further options to allow for punctuation; and we can search text to see
|
||||
if it contains any other text, and if so, how many times.
|
||||
Moreover, indexed texts can be matched against regular expressions, with
|
||||
replacement also possible. For instance: if V is indexed text, then
|
||||
replace the regular expression "\d+" in V with "roughly \0"
|
||||
inserts the word "roughly" in front of any number in V. The regular
|
||||
expression language supported by Inform is essentially that of Perl
|
||||
(once multiline mode, a Perl eccentricity, and hooks to embedded Perl
|
||||
code have been removed) and Inform's algorithm has been verified against
|
||||
Perl's own compliance tests: see the notes in section 19.6 for details.
|
||||
A particularly interesting text to manipulate is the command most recently
|
||||
typed by the player. Inform stores such text in a kind of value called a
|
||||
"snippet", and - like "text" - this automatically converts to indexed text
|
||||
when necessary. Moreover, rules in the "reading a command" activity are
|
||||
allowed to rewrite the text and reparse the command - for instance,
|
||||
After reading a command:
|
||||
let T be indexed text;
|
||||
let T be the player's command;
|
||||
replace the text "\p" in T with "";
|
||||
change the text of the player's command to T.
|
||||
removes any punctuation characters from what the player has typed.
|
||||
Indexed text table columns can be written to, and read in from, external files.
|
||||
|
||||
|
||||
STORED ACTION
|
||||
|
||||
A new kind of value, "stored action", holds actions - not action names,
|
||||
but fully-specified actions, including the information about who does what
|
||||
and with what. (The default value is the player waiting.) If V is any
|
||||
value of this kind, then
|
||||
try V
|
||||
try silently V
|
||||
silently try V
|
||||
all work in the obvious way. The phrase
|
||||
current action
|
||||
returns the action currently under way. Stored actions can do anything
|
||||
that actions can do: in particular, they remember, if necessary, the exact
|
||||
wording of the player's command at the time they were stored - so that
|
||||
actions like "looking up 'x100' in the code book" can be stored and tried
|
||||
later on. Stored actions can be used in "let" variables, in table columns,
|
||||
in global variables, and also in properties. See the new section 12.20
|
||||
in "Writing with Inform".
|
||||
To make an explicit stored action, we use the form of words "action of ...":
|
||||
for example,
|
||||
The best idea yet is a stored action that varies.
|
||||
The best idea yet is the action of pushing the button.
|
||||
When making comparisons, we can of course compare any two stored action values:
|
||||
let C be the current action;
|
||||
if C is the action of pushing the button, ...
|
||||
Although "action of ..." specifies an exact action, we can omit this if
|
||||
we want to write a vague description of an action instead - but only when
|
||||
writing it in a condition:
|
||||
if C is taking something, ...
|
||||
if C is doing something to the lever, ...
|
||||
(If we had written
|
||||
if C is the action of taking something, ...
|
||||
Inform would have thrown up a Problem, because "taking something" is not
|
||||
a single, definite action, so cannot be a stored action.)
|
||||
The constituent parts of a stored action can be accessed with the phrases:
|
||||
action-name part of S
|
||||
noun part of S
|
||||
second noun part of S
|
||||
actor part of S
|
||||
As a convenient abbreviation for testing these, the condition
|
||||
S involves X
|
||||
is true if the object X appears as any of the noun, second noun or actor
|
||||
in S, and false otherwise.
|
||||
The "try" and "action of" constructions are now allowed to specify explicit
|
||||
text in place of a topic in actions such as asking. (Beginners to Inform
|
||||
often think this must be possible, but up to now it hasn't been, because
|
||||
of the difference between a snippet and a text, etc.) For instance,
|
||||
Instead of asking Biggles about "German flying machines":
|
||||
try asking Biggles about "aircraft".
|
||||
The kind of value "action-name", used to denote not a complete action but
|
||||
simply what form of action it is ("taking", "throwing it at", etc.) can
|
||||
now be said for the first time.
|
||||
The premiss for a rule about actions can now make use of variables which
|
||||
exist only inside action rules: for instance,
|
||||
Check an actor waving when the noun is not held by the actor: ...
|
||||
which was previously not allowed because the second mention of "the actor"
|
||||
referred to an action variable which, in a strict reading of the Inform
|
||||
syntax, existed only inside the rule (i.e., after the colon). This seemed
|
||||
an unnatural restriction.
|
||||
The change log for build 4U65 claimed that:
|
||||
the can't go through concealed doors rule has been renamed the
|
||||
can't go through undescribed doors rule.
|
||||
This turns out to have been completely untrue. We meant to, but forgot.
|
||||
The name change has now been effected. (For the reason why, see 4U65.)
|
||||
Lastly, either a bug fix or a redefinition, according to taste: an action
|
||||
description using "... in ..." refers to the room where the action is to
|
||||
happen; up to now this has always meant the room where the player is, but
|
||||
that went contrary to the principle that actions ought to treat people
|
||||
equally. "... in ..." clauses now refer to the room which is the actor's
|
||||
location. Thus
|
||||
Instead of an actor going east in the Vast Nothingness, ...
|
||||
now has effect if the actor tries this in the V. N., not if the player
|
||||
happens to be there at a time when the actor (who might be anywhere)
|
||||
tries going east. This sounds a complicated change, but it's clearly much
|
||||
more logical, and we doubt if anyone relied on the old behaviour.
|
||||
|
||||
|
||||
OTHER CHANGES TO DO WITH KINDS OF VALUE
|
||||
|
||||
A new kind of value, "truth state", represents one of two possible values:
|
||||
the constants "true" and "false". (By default, truth state variables and
|
||||
properties are false.) We can convert any condition to a truth state thus:
|
||||
let victory be whether or not all the treasures are in the cabinet;
|
||||
We can then examine a truth state by comparing it against true or false:
|
||||
if victory is true, ...
|
||||
In fact, this kind of value is not new, but is merely coming out into the
|
||||
open. If we try to write (say)
|
||||
To decide what truth state is time is short: ...
|
||||
then Inform will tell us to rewrite it in the more traditional form:
|
||||
To decide if time is short: ...
|
||||
A phrase to decide if something-or-other is exactly the same thing as a
|
||||
phrase to decide a truth state, and indeed, if we want to then we can use
|
||||
"decide on T", where T is a truth state, in its definition. For instance:
|
||||
To decide if time is short:
|
||||
if the time of day is after 10 PM, decide on true;
|
||||
...
|
||||
decide on whether or not Jennifer is hurried.
|
||||
"Decide on true" is exactly equivalent to the more normally used "decide
|
||||
yes", and of course it is optional. The last line is more interesting
|
||||
since it effectively delegates the answer to another condition.
|
||||
>--> The kind of value "object-based-rulebook" has been withdrawn: instead, such
|
||||
a value is now called an "object-based rulebook" and is a special case
|
||||
of a "rulebook". (The double hyphen was generally found to be clumsy, and
|
||||
often led to mistakes.)
|
||||
The deprecated kind of value "string-of-text", which behaved identically to
|
||||
"text" in recent builds, has been withdrawn. It was mentioned in one
|
||||
example ("Panache") through a historical accident, but was otherwise
|
||||
undocumented.
|
||||
A "let" variable can now optionally be created by giving its kind of value
|
||||
rather than its initial value - the initial value is then the default
|
||||
value for that kind. For instance,
|
||||
let T be an indexed text;
|
||||
creates a "let" variable called "T" to hold indexed text, and which is
|
||||
initially holding the blank text "".
|
||||
A table column name can now optionally give its kind of value in brackets.
|
||||
Thus "darts tally (a number)" would create a column called "darts tally"
|
||||
whose contents were required to be numbers.
|
||||
A phrase to decide a value is now checked to make sure that doesn't try to
|
||||
return a type which is not a value (something which typically produced
|
||||
problem messages in earlier builds, too, but less helpful ones).
|
||||
Where a value property is declared for one kind of object as holding a value
|
||||
of kind of value X, and for another as holding kind of value Y, X and Y
|
||||
now have to agree: previously they were allowed to differ as long as they
|
||||
were each kinds of object, but this was not quite type-safe, and led to
|
||||
subtle bugs.
|
||||
In previous builds of Inform, values of units had to be positive or zero:
|
||||
thus defining
|
||||
An elevation is a kind of value. 100 cubits specifies an elevation.
|
||||
creates a kind of value where -10 cubits, say, would not be a legal
|
||||
expression. Owing to a bug, however, no problem message was produced,
|
||||
and the minus sign was simply ignored - the value "-10 cubits" was read
|
||||
as if it were "10 cubits". This bug has been fixed, and a new convention
|
||||
adopted: if the initial specification of the unit is negative, then
|
||||
negative values are permitted, and otherwise not. Thus:
|
||||
An elevation is a kind of value. -100 cubits specifies an elevation.
|
||||
means that (say) "6 cubits" and "-3 cubits" are both legal.
|
||||
When U is a numerical value - a number or a unit, that is - the phrase
|
||||
"random U from X to Y" now gives truer results for very large ranges
|
||||
in the Glulx virtual machine.
|
||||
Bug fixed whereby "random U from X to Y" would sometimes seed the random
|
||||
number generator as a side-effect when X was greater than Y. This is now
|
||||
a symmetrical phrase - "a random number from 5 to 2" now has the same
|
||||
effect as "a random number from 2 to 5". (The phrase "seed the
|
||||
random-number generator with..." is the proper way to seed the RNG.)
|
||||
If U is a unit, the phrases "random U", "U after X" and "U before X" have
|
||||
been withdrawn - these don't really make sense for unbounded ranges. (What
|
||||
is a random height? It's a question which can only be answered in context -
|
||||
a random height for buildings is quite unlike a random height for people.)
|
||||
Problem message added to catch literal numbers (and literal units) which are
|
||||
too numerically large to fit into the Z-machine: for instance,
|
||||
An RGB value is a kind of value. 255-255-255 specifies an RGB value.
|
||||
Scarlet is an RGB value which varies. Scarlet is 255-0-0.
|
||||
...is fine in projects compiled for Glulx, but would overflow the
|
||||
16-bit word size on the Z-machine.
|
||||
Bug fixed whereby nameless properties ("conditions" - not in the sense of
|
||||
"if", but in the sense of something being in good or bad condition, say)
|
||||
specified for kinds but only at the "usually" level of certainty would
|
||||
sometimes have such sentences ignored.
|
||||
Problem message added for unit specifications which overlap or make ambiguous
|
||||
existing ways to write constant kinds of value; for instance,
|
||||
"250" specifies a weight.
|
||||
clearly clashes with Inform's existing notation for text.
|
||||
Problem message added to catch the case of multiple initialisations of the
|
||||
same variable, for instance,
|
||||
Foobar is a number which varies. Foobar is 1. Foobar is 2.
|
||||
Bug fixed whereby no problem was detected if a property required to hold one
|
||||
kind of object as a value (for instance, a property holding a room) was
|
||||
initialised by an assertion with another kind of object altogether (for
|
||||
instance, a container).
|
||||
Bug fixed whereby spurious typechecking problems would be produced if the
|
||||
same kind of value was used both as a self-named property of one kind of
|
||||
thing, and also as the value of other-named properties of other kinds.
|
||||
Bug fixed whereby conditions used for the start and end of a scene would not
|
||||
always be fully typechecked, if it appeared at least syntactically valid.
|
||||
For instance,
|
||||
Fairytale Wedding begins when the player is kissing the frog.
|
||||
looks superficially right, but in fact involves comparing an object
|
||||
(the player) with an action (kissing the frog) - something we may one day
|
||||
legalise in Inform, but which at present should be rejected. In builds
|
||||
before this one, it compiled but to a condition which was always false.
|
||||
A number of subtle bugs have been fixed in handling ambiguous multiple-phrase
|
||||
text; if a phrase can be read as A or B, then A wins if
|
||||
- it has more fixed words;
|
||||
- they have the same number of fixed words, but A has more tokens;
|
||||
- taking fixed words alone, A is lexicographically earlier;
|
||||
- A is a subschema of B in the sense that each value of a token
|
||||
in B can be coerced to the corresponding kind of value in A;
|
||||
- A was created earlier than B in the source text;
|
||||
- fixed words of A occur earlier than B in the actual text parsed.
|
||||
In practice these changes cured some bugs, but did not change the
|
||||
interpretation of any text in the examples, and we expect they will
|
||||
probably not be noticed as changes by users. The final rule is notable
|
||||
for making phrases "right associative" when iterated, so for instance
|
||||
two minutes before three minutes before 12:00 AM
|
||||
is read as
|
||||
two minutes before (three minutes before 12:00 AM)
|
||||
rather than
|
||||
(two minutes before three minutes) before 12:00 AM
|
||||
and thus evaluates to 11:55 PM, not 11:59 PM.
|
||||
|
||||
|
||||
MISCELLANEOUS OTHER CHANGES
|
||||
|
||||
>--> In order to reduce namespace clashes, a fairly significant change has
|
||||
been made to the way Inform reads noun phrases in the source text.
|
||||
Objects can, of course, be referred to using abbreviated names: for
|
||||
instance, if we write
|
||||
The Great Hall of Infinity is a room.
|
||||
then we can also write
|
||||
The Panjandrum is a man in the Hall.
|
||||
where "Hall" is a read as referring to the Great Hall of Infinity. This
|
||||
convention of course remains. However, the same is no longer allowed
|
||||
with names of kinds. Thus:
|
||||
A Scrabble piece is a kind of thing. The Q is a piece.
|
||||
will no longer work: the second assertion must be written out in full as
|
||||
The Q is a Scrabble piece.
|
||||
This led to tiny changes in six of the Examples (and detected a typo in
|
||||
a seventh), but in all cases the change was easily made and the result
|
||||
more legible or no worse than the original, so we hope that users will
|
||||
not find this change to the rules too inconvenient. The point of it is
|
||||
so that text such as:
|
||||
Beautiful scenery is a kind of thing. A wall is a kind of thing.
|
||||
A wall is usually scenery.
|
||||
will now work: previously the "scenery" in "A wall is usually scenery"
|
||||
was taken as referring to the "beautiful scenery" kind, not the built-in
|
||||
"scenery" property. (And so on for many other cases.)
|
||||
>--> An ambiguity has been removed from the syntax for actions. The convention
|
||||
when indicating an action by a character other than the player is that
|
||||
the full form reads like so:
|
||||
Miss Hodges trying taking the lime
|
||||
Inform, however, allows the usually redundant word "trying" to be omitted
|
||||
where this leads to no ambiguity. The change is that, for safety's sake,
|
||||
Inform now forbids this abbreviation where the object's name includes
|
||||
a participle (or indeed any word ending in "...ing"). This prevents, for
|
||||
instance,
|
||||
Mr Geoffrey Taking
|
||||
from being read as an action rather than a noun phrase, or (a case which
|
||||
actually arose for one of our users)
|
||||
newspaper cutting
|
||||
being read as the newspaper itself doing some cutting.
|
||||
>--> The accessibility rules have had one anomalous case removed. Previously,
|
||||
an object in another room was considered inaccessible, yet an object out
|
||||
of play was not. The only reason this rarely caused trouble was that
|
||||
actions involving such objects were seldom generated, because the parser's
|
||||
scope rules would prevent it from recognising commands referring to them.
|
||||
But it could occasionally happen, if a command such as TAKE ALL fired off
|
||||
a run of actions, and the outcome of an earlier take caused the object
|
||||
from a later take to be moved out of play; and with stored actions this
|
||||
sort of thing becomes much more likely to happen. At any rate the anomaly
|
||||
has been removed, but this had the consequence that a few examples
|
||||
which used physical things to represent abstract concepts went wrong.
|
||||
For instance,
|
||||
An emotion is a kind of thing. Envy and gratitude are emotions.
|
||||
is likely to produce a world in which "envy" and "gratitude" both exist
|
||||
as physical things but are permanently out of play. If we then write
|
||||
Understand "experience [any emotion]" as experiencing.
|
||||
then commands like EXPERIENCE ENVY will be recognised, but what happens
|
||||
next depends on how the action is defined. If like so:
|
||||
Experiencing is an action applying to one thing.
|
||||
then I7 will now strictly apply the rule that the thing must be touchable,
|
||||
that is, with no physical barriers between it and the player: which means
|
||||
EXPERIENCE ENVY will now fail accessibility. To get around this, define
|
||||
Experiencing is an action applying to one visible thing.
|
||||
instead: this weakens the requirement to the point where being allowed
|
||||
to refer to the object is enough. ("Visible" here means visible in the
|
||||
sense of parser scoping rules, not with one's own eyes: they are almost
|
||||
always the same thing, but "[any emotion]" overrode that.)
|
||||
>--> Another change which will probably make little difference, but which
|
||||
clears up an ambiguity: given two descriptions in the form (adjectives)
|
||||
plus (kind), which are of different kinds, and where Inform cannot prove
|
||||
that either is necessarily a special case of the other, then the one with
|
||||
more adjectives is now considered more specific - and this affects rule
|
||||
ordering. So, for instance,
|
||||
Instead of examining an open door: ... (A)
|
||||
Instead of examining a vehicle: ... (B)
|
||||
rule (A) is now considered more specific than (B), whereas in previous
|
||||
builds they were equally specific and so would appear in rulebooks in
|
||||
source text order. (This change made no difference to the behaviour of
|
||||
any of the examples, or any other of our test cases: it's pretty esoteric,
|
||||
but we are trying to reduce the number of ways source text ordering is
|
||||
used, where sensible.)
|
||||
We can now give unusual or alternative names for the understanding of either/or
|
||||
properties, when these are used to describe objects. For instance, if we
|
||||
have:
|
||||
The box is a container which is carried by the player.
|
||||
It is openable and closed.
|
||||
Understand the open property as referring to the box.
|
||||
then EXAMINE OPEN BOX will work only if the box is open, and so forth. But
|
||||
we can now add:
|
||||
Understand "opened" as open. Understand "shut/sealed" or "tightly
|
||||
sealed" as closed.
|
||||
and now EXAMINE TIGHTLY SEALED BOX, etc., will work only when the box is
|
||||
closed.
|
||||
"now T is X", to change the value of a table entry T to a value X, now works
|
||||
as might be expected. (This case seems to have been overlooked before: it
|
||||
wasn't intentionally left out of the design, and consistency clearly
|
||||
requires it.)
|
||||
Previous restrictions on the use of "let" names, phrase parameters and
|
||||
table entries in text being written or appended to external files have
|
||||
been lifted. Thus:
|
||||
The currently erased jotter is an object that varies.
|
||||
To erase (pad - a jotter):
|
||||
now the currently erased jotter is the pad;
|
||||
write "[heading of the currently erased jotter][paragraph break]"
|
||||
to the text file of the pad.
|
||||
can now be done more simply thus:
|
||||
To erase (pad - a jotter):
|
||||
now the currently erased jotter is the pad;
|
||||
write "[heading of the pad][paragraph break]" to the text file of the pad.
|
||||
This affects both "write ... to ..." and "append ... to ...".
|
||||
The location of external files written or read by Glulx story files now uses
|
||||
the same convention on both OS X and Windows. (In 4X60, Inform for OS X
|
||||
differed from this.) Such ".glkdata" files are now always stored in the
|
||||
same folder as the project "Whatever.inform", unless the user has created
|
||||
a "Files" subfolder of a "Whatever Materials" folder, in which case that
|
||||
will be used as the location.
|
||||
The Kinds index now presents the initial state of either/or properties
|
||||
associated with kinds in a more legible way, avoiding double negatives.
|
||||
Thus
|
||||
Not normally portable not fixed in place.
|
||||
(which admittedly looks worse without the italic) is now written
|
||||
Usually fixed in place not portable.
|
||||
The SHOWME testing command is now more detailed, and shows what properties
|
||||
an item or room currently possesses. For instance:
|
||||
>showme guide
|
||||
Guide to Desert Fauna - book
|
||||
location: in Death Valley
|
||||
unlit; inedible; opaque; portable; singular-named; improper-named
|
||||
printed name: Guide to Desert Fauna
|
||||
printed plural name: books
|
||||
contents: Table of Critters
|
||||
(This brings it roughly into line with the old I6 verb SHOWOBJ, but has
|
||||
much more legible output, since property values can be printed better.)
|
||||
The syntax of phrases to access tables has tended to be annoyingly picky
|
||||
about prepositions: it has been liberalised a little, so that one can
|
||||
now write "from T" equivalently to "in T" in phrases like
|
||||
choose a random row from the Table of Soft Fruit
|
||||
Similarly, in the phrases with the form "choose ... row ...", either
|
||||
the definite or indefinite article can be used, or omitted altogether:
|
||||
there will be times when any of these may seem clearest. So any of
|
||||
these (for instance) will be allowed:
|
||||
choose a random row from T
|
||||
choose the row with citrus entry of 5 from T
|
||||
choose blank row from T
|
||||
Use options can now specify numerical values, along with default values which
|
||||
the source text can choose to raise: this should help extension-writers
|
||||
who want to provide "enough" storage for the user's needs, since the
|
||||
user can now use such an option to tell the extension exactly how much
|
||||
he does need.
|
||||
Bibliographic data text normally doesn't recognise text substitutions, for
|
||||
obvious reasons: it has to be literal text supplied to outside programs.
|
||||
(The story title, author's name, and so on.) It is now allowed to contain
|
||||
just one text substitution: ['] for a literal apostrophe. (This allows
|
||||
titles like "Summer of [']69" to be handled properly.)
|
||||
The previous maximum of 500 I6 inclusions and use options used all at once
|
||||
in any single source text has now been removed.
|
||||
Inform now chooses further contrasting colours for World Index maps which
|
||||
include more than 10 different regions, and now cycles through its
|
||||
colours rather than reverting to grey for subsequent regions when the
|
||||
shades run out.
|
||||
Bug fixed whereby complicated descriptions involving the contents of a region
|
||||
would fail to work: for instance, "the number of rooms in R", where R
|
||||
is the name of a region, or "a random room in R", would return 0 and
|
||||
nothing respectively.
|
||||
Bug fixed whereby releasing along with a custom website was not working
|
||||
(NI was issuing the wrong instructions to cBlorb, the packaging agent.
|
||||
Standard websites did work: only those with custom templates failed.)
|
||||
Bug fixed whereby assemblies which involved properties as well as kinds
|
||||
would sometimes not always have those properties set, particularly if
|
||||
multiple assemblies took place with similar circumstances. For instance:
|
||||
A box is a kind of container. An open box is in every room. A closed
|
||||
box is in every room.
|
||||
Bug fixed whereby a player's holdall which is a part of the player - rather
|
||||
than being carried or worn by the player - will now function correctly.
|
||||
(This was requested by someone wanting to implement "a robot or marsupial".)
|
||||
Bug fixed whereby recent changes to table-handling caused properties of
|
||||
values to be wrongly read and written. (Typically a property of V would
|
||||
be confused with a property of the value whose numerical form at run-time
|
||||
was one less than V's.)
|
||||
Bug fixed whereby route-finding (and counting shortest distances) through
|
||||
one-to-various relations would give wrong results, usually false claiming
|
||||
that no route existed.
|
||||
Bug fixed whereby the phrase "direction of (D - door) from (R1 - room)"
|
||||
didn't work at all, really (it returned the I6 direction property, not the
|
||||
compass direction object - an elementary I6 mistake).
|
||||
>--> Bug fixed whereby after rules were being applied to out of world actions,
|
||||
in spite of the documentation's clear statement that they would not be.
|
||||
It is just possible that some authors might have relied on this working:
|
||||
to give after-effects to out of world actions, use the report rules.
|
||||
Bug fixed whereby "change ... to ..." would sometimes cause I6 errors where
|
||||
the thing changed was a variable holding an object, and the value changed
|
||||
to was something other than an enumerated property-value constant.
|
||||
Bug fixed whereby "if ...; otherwise if ... begin;" would cause I6 errors
|
||||
rather than produce a Problem message (to point out that "begin" should
|
||||
not be used with "otherwise if ..." clauses).
|
||||
Bug fixed whereby placing items by referring to the currently discussed room
|
||||
as "here" would sometimes give strange results if (i) the current subject
|
||||
of discussion when the sentence is first read is not what will prove to
|
||||
be a room, and also (ii) the room being discussed most recently was
|
||||
created some time ago and other rooms had been created since then. The
|
||||
new interpretation of "here" should be more robust and predictable.
|
||||
Bug fixed whereby restrictions applied to headings, such as
|
||||
Volume 1 - not for release
|
||||
Volume 1 - for Glulx only
|
||||
would be ignored (but only for Volume headings, not for headings of any
|
||||
other level).
|
||||
Bug fixed whereby implications (such as "A locked thing is usually lockable.",
|
||||
an implication in the Standard Rules) are ignored if the thing to which
|
||||
they apply cannot have the property which is given as the consequence;
|
||||
previously, a somewhat mysterious problem message would be produced.
|
||||
Bug fixed whereby implications would sometimes override definite statements
|
||||
made negatively (e.g. "A locked thing is usually openable" overriding
|
||||
"The safe is locked. The safe is not openable"); again, the symptom
|
||||
was usually a mysterious problem message.
|
||||
Bug fixed whereby the use of a relation in an indirect clause with a value
|
||||
of a kind which is also used as a property, and has the same name as
|
||||
that property, would cause I6 errors.
|
||||
Bug fixed whereby grammar using a newly defined token for a value belonging
|
||||
to a new kind of value, would cause I6 errors.
|
||||
Bug fixed whereby giving alternatives in grammar for understanding specific
|
||||
times of day (e.g. 'Understand "lunch" or "lunch time" as 11:30 am.')
|
||||
would cause an internal error.
|
||||
Bug fixed whereby a few malformed assertions involving impossible callings
|
||||
(e.g. 'X (called Y) and X has Y.') produced an internal error rather
|
||||
than a problem message.
|
||||
Problem message added for attempts to create multiple objects with a single
|
||||
'called' clause ('Bill and Ben are men in the Garden.').
|
||||
Bug fixed (or, in a sense, feature added) so that "X is a backdrop which is
|
||||
everywhere" will now successfully create an omnipresent backdrop;
|
||||
previously one had to write "X is a backdrop. X is everywhere."
|
||||
Bug fixed whereby actions sometimes continued and reported even if the
|
||||
carry out rules had already killed the player.
|
||||
Bug fixed whereby 'Understand ... as a mistake' would produce the mistake
|
||||
reply even when the text was being addressed to another person, rather
|
||||
than being intended as a command by the player.
|
||||
Bug fixed whereby tokens for understanding names which involved various-to-one
|
||||
relationships to other objects would not work in concert with specific
|
||||
additional names made using 'Understand'. For example,
|
||||
Understand "[something related by loyalty]" as a team.
|
||||
Understand "Glasgow Rangers" as a team.
|
||||
would correctly match the token, but not the additional name, which would
|
||||
be ignored.
|
||||
Bug fixed whereby "now the player is X" would be read differently from
|
||||
"change the player to X", and would not properly change perspective.
|
||||
Bug fixed whereby an assertion sentence setting the description of the player
|
||||
caused a contradiction with the default setting for this made in the
|
||||
Standard Rules. For instance,
|
||||
The description of the player is "Frankly harrassed-looking."
|
||||
is now legal again. (It was legal in early builds of Inform, too.)
|
||||
Slight anomaly resolved (it wasn't really a bug) in the determination of
|
||||
which items are concealed, using the "deciding the concealed possessions"
|
||||
activity: previously the activity would test items belonging to the player
|
||||
even though a subsequent rule would force them to be unconcealed regardless
|
||||
of the activity's decision - an actor can't conceal something from himself,
|
||||
since concealment in I7 by definition means concealment from the view
|
||||
of other people. Now, the activity is not asked about such items.
|
||||
Bug fixed whereby "( -" was sometimes read as "(-", opening a passage of
|
||||
literal I6 code, which was unfortunate if it had actually been part of
|
||||
a calculation ("let X be ( -1 * count )", say).
|
||||
Various bugs fixed to do with the use of the I6 string escape characters
|
||||
\, @, ~, ^ in I7 source text and quoted text (for instance, these followed
|
||||
by digits would in some cases cause I6 compilation errors).
|
||||
Problem message added to catch situations where the source text would require
|
||||
ridiculous lengths of time to parse, using Inform's normal algorithms:
|
||||
this is something which seems only ever to have happened to one user,
|
||||
through the accidental omission of lots of punctuation, but it had the
|
||||
effect of Inform apparently never completing compilation, which is
|
||||
inconvenient to recover from on some platforms.
|
||||
Problem message added to clarify why some mixtures of actions like 'dropping
|
||||
the CD or inserting the CD into the jewel box' are not allowed as the
|
||||
premiss of a rule; and bug fixed whereby other illegal mixtures, such as
|
||||
'inserting the CD into the jewel box or dropping the CD' were previously
|
||||
miscompiling rather than producing a problem.
|
||||
Problem message added to help diagnose a common mistake with 'if' phrases,
|
||||
missing out the 'begin' at the end.
|
||||
Problem message added to explain why sentences like
|
||||
Understand "take [things]" as "drop [things]".
|
||||
are not allowed.
|
||||
Problem message added to explain why sentences like
|
||||
Understand "trevor, look" as looking.
|
||||
are not allowed.
|
||||
Problem message to catch attempts to use "carry out", "report" or "check"
|
||||
rules applied to named action patterns rather than specific actions;
|
||||
previously these would sometimes be allowed provided that some subset
|
||||
of their names coincided with the name of some actual action (but with
|
||||
unhappy results, since the rule would end up applying to that action,
|
||||
which would certainly not have been what the user intended).
|
||||
The problem message produced by sentences like
|
||||
The coin is in the strongbox.
|
||||
(where "coin" is a kind of thing, so that this is too vague) has been
|
||||
lifted in the case of writing sentences like
|
||||
One coin is in the strongbox.
|
||||
since, after all, higher multiplicities like
|
||||
Two coins are in the strongbox.
|
||||
have always been allowed.
|
||||
Problem message added for trying to define the same test name to mean two
|
||||
different tests.
|
||||
Problem message added for trying to use a kind of thing to relate multiple
|
||||
objects to single values in single sentences. (Ideally this would work,
|
||||
but there are awkward implementation reasons why it doesn't, for the
|
||||
moment, and the problem message replaces a less polite internal error.)
|
||||
Problem message clarified when trying to make a property which must hold an
|
||||
object of a given kind, when no objects of that kind exist anywhere, so
|
||||
that this property can never have a legal value.
|
||||
Problem message added for contradictory indications of where something
|
||||
initially is, for instance,
|
||||
Fred is in the Kitchen. Fred is in the Dining Room.
|
||||
(How we overlooked this obvious case in four years of testing...)
|
||||
Problem message added for an Understand attempting to give a name to
|
||||
an object qualified by a relative clause or properties. (The same effect
|
||||
can be achieved by other means - the problem message explains how.)
|
||||
Problem message added for an attempt to test if a vaguely described past
|
||||
action succeeded. (Previously these apparently compiled, but gave
|
||||
usually wrong answers.)
|
||||
Problem message added to give more helpful diagnosis if an action definition
|
||||
incorrectly gives a past participle longer than a single word.
|
||||
Problem message added (rather than an internal error) for using a relation
|
||||
which relates objects to values in a "[something related by...]" token
|
||||
in an 'Understand' sentence.
|
||||
Bug fixed whereby the parser would give slightly misleading replies if
|
||||
pronouns other than "her" were used in commands before they had ever
|
||||
been set.
|
||||
Bug fixed whereby scenery items, never mentioned in room descriptions, could
|
||||
nevertheless silently become pronoun values. (Thus "it" might mean the
|
||||
sky in a room where the sky was scenery.)
|
||||
Bug fixed whereby the parser would reply "That noun did not make sense in
|
||||
this context." in response to certain scope-filtering tokens where
|
||||
nonsense had been typed, but without a proper paragraph break.
|
||||
Bug fixed whereby duplicate problem messages would result from a phrase
|
||||
defined with alternate wordings, but also defined incorrectly. (The
|
||||
problems would be repeated for each possible wording.)
|
||||
Bug fixed whereby the "Use serial comma" option did not result in a serial
|
||||
comma being used in clarification questions like
|
||||
Which do you mean, the fish, the fowl, the chalk, or the cheese?
|
||||
Documentation bug fixed whereby the "return to contents" links in Writing
|
||||
with Inform would sometimes return to the contents of the Recipe Book
|
||||
instead.
|
||||
|
||||
Examples:
|
||||
"Xot" added to demonstrate storing an erroneous command and replaying it
|
||||
later, as seen in Infocom's HHGttG.
|
||||
"Terracottissima Maxima" added to demonstrate understanding an indexed text
|
||||
property.
|
||||
"Fido" added to demonstrate a dog that the player is allowed to name and
|
||||
re-name.
|
||||
"Pre-alpha" added to demonstrate a beta-testing command that allows the
|
||||
player to preface any line with a punctuation mark to show it is a comment.
|
||||
"Blackout" added to demonstrate replacing letters in a printed name under
|
||||
certain circumstances.
|
||||
"Identity Theft" added to demonstrate asking the player for a name at the
|
||||
start of play.
|
||||
"Mr. Burns' Repast" added to demonstrate a fish that renames itself
|
||||
depending on how the player refers to it.
|
||||
"Endurance" added to demonstrate a way of modeling time so that it depends
|
||||
flexibly on the actions undertaken during a turn.
|
||||
"Uncommon Ground" tweaked to repair a couple of cosmetic flaws held over
|
||||
from earlier versions of the extension
|
||||
"Panache" corrected to remove a reference to the elderly (and now
|
||||
withdrawn) type "string-of-text"
|
||||
"Disenchantment Bay 12" corrected to remove a reference to the captain as
|
||||
"transparent", which was a holdover from a time (before the first public
|
||||
beta of Inform) when characters could be opaque or transparent and this
|
||||
quality would determine whether their possessions could be seen.
|
||||
"Straw Into Gold" added to demonstrate a character whose name is concealed
|
||||
until the player guesses it.
|
||||
"Celadon" added to demonstrate extending DROP to apply even to objects the
|
||||
player is carrying inside a container or on a supporter.
|
||||
"Northstar" added to demonstrate modifying the player's command using a
|
||||
regular expression, so that ASK JOSH TO TAKE INVENTORY will be
|
||||
understood as JOSH, TAKE INVENTORY.
|
||||
"Burning", "Gelato", "Originals", "Solitude", "Stately Gardens", "Tilt 2",
|
||||
and "Tilt 3" revised to make use of the new truth state kind of value.
|
||||
"Cactus Will Outlive Us All" added to demonstrate stored actions and
|
||||
characters who respond when they occur.
|
||||
"Anteaters" added to demonstrate stored actions that include topics.
|
||||
"Bosch" added to demonstrate an alternative full score system using
|
||||
stored actions.
|
||||
"Kyoto" revised to reflect the current state of the actions rules.
|
||||
"Dinner is Served" revised to change the way closed containers are described.
|
||||
"Chronic Hinting Syndrome" "Ferragamo Again", "Being Peter", "The Problem
|
||||
with Edith", and "Introduction to Juggling" revised to reflect new
|
||||
restrictions about acting on out-of-play objects.
|
||||
"Broughton" revised to fix a very tiny bug in which "greeting" was not
|
||||
specified as a subject.
|
||||
"Lucy" added to demonstrate redirecting the ASK command to a new topic
|
||||
other than the one the player typed.
|
||||
"Fine Laid" added to demonstrate redirecting most actions from one object
|
||||
to another.
|
||||
"Mirror, Mirror" revised to use indexed text rather than an external file,
|
||||
which means that it can be used in z-machine games as well.
|
||||
"Actor's Studio" added to demonstrate a video camera that records actions
|
||||
occurring in its presence, then plays them back later.
|
||||
"Capital City" added to demonstrate capitalized text in the status line.
|
||||
"Rocket Man" added to demonstrate sentence- and title-casing for any to-say
|
||||
phrase.
|
||||
"Rubies" added to demonstrate a scoreboard of high-scoring players.
|
||||
"Witnessed", "Sand", "Modern Conveniences", "Hot Glass Looks Like Cold
|
||||
Glass", "Model Shop", "Nickel and Dimed" slightly changed to spell
|
||||
out kind names in full rather than use abbreviations.
|
||||
"Situation Room" added to provide 24-hour time printing.
|
||||
"Tamed" revised to get rid of the magician's booth being closed.
|
||||
"Starry Void" added to demonstrate a simple case of a room whose exterior
|
||||
is visible from another room.
|
||||
"The Cow Exonerated" added to demonstrate matches for starting fires, using
|
||||
indexed text to make the reporting more elegant.
|
||||
"Savannah" added to demonstrate liquid used to put out fires.
|
||||
"Slouching" added to demonstrate sitting, standing, and lying down postures
|
||||
for the player and other characters.
|
||||
"Costa Rican Ornithology", "Crusoe", "Farewell", "Juggling", "Nickel and
|
||||
Dimed", "Money for Nothing", "Aftershock", "Channel 2" edited to make
|
||||
it easier to extract the generalizable portions for use in other games.
|
||||
"Four Cheeses" edited for portability and to clean up a few clumsy
|
||||
phrasings due to the age of the example.
|
||||
"Bogart" edited for portability and to remove a special-case bug.
|
||||
"What Not To Wear" added to demonstrate a more complete clothing system
|
||||
combining layers with a concept of different regions of the body, for
|
||||
whole classes of shirts, trousers, etc.
|
||||
"Port Royal 1" and "Port Royal 2" edited for length and clarity.
|
||||
|
||||
Extensions:
|
||||
"Basic Screen Effects" edited for a small bug that prevented the "show
|
||||
current quotation" phrase from being available under Glulx. Version
|
||||
advanced to 5.
|
||||
"Glulx Entry Points" changed to treat glulx replacement command as indexed
|
||||
text, which means that it can be edited more flexibly or even
|
||||
constructed through multiple hyperlinks. Version advanced to 3.
|
||||
"Locksmith" changed to make the "you lack a key..." message more flexible
|
||||
and keyed to individual objects. Version advanced to 4.
|
||||
Minor one-line addition to the documentation of "Basic Help Menu" to
|
||||
clarify how to replace the enclosed menu with one of our own.
|
123
Changes/Change Logs/5J39.txt
Normal file
123
Changes/Change Logs/5J39.txt
Normal file
|
@ -0,0 +1,123 @@
|
|||
5J39 (1 December 2007)
|
||||
|
||||
This build introduces lists as first-class values. For any kind of value K,
|
||||
"list of K" is now also a kind of value, and rich support is provided for
|
||||
building and iterating over lists, which are dynamically resized as
|
||||
necessary. Otherwise little is new, but once again all known bugs have
|
||||
been fixed.
|
||||
|
||||
For any kind of value K, "list of K" is now also a kind of value. Lists
|
||||
resize automatically, can be iterated through, sorted, searched,
|
||||
reversed or rotated, and they have a notation enabling constant lists
|
||||
to be written down concisely: for instance,
|
||||
let L be {2, 3, 5, 7, 11};
|
||||
gives the temporary variable L the kind of value "list of numbers",
|
||||
and sets it initially to this sequence of five values, whereas
|
||||
let M be the list of open doors;
|
||||
gives M the kind of value "list of objects", and sets its initial
|
||||
contents to be all the doors which are currently open. (Lists can also
|
||||
be used in global variables, in properties, or table entries, and can
|
||||
include each other: "list of lists of numbers", say, is a kind of value.)
|
||||
Values can be added or removed at any point in a list; lists can be merged,
|
||||
or compared for differences; and examples are presented to show the
|
||||
use of lists as queues, stacks, rings, sets, arrays, and so forth.
|
||||
(All memory management is automatic and all bounds are automatically
|
||||
checked.) See the new Chapter 20 ("Lists").
|
||||
Examples:
|
||||
"Eyes, Fingers, Toes" added to demonstrate a multi-number safe using
|
||||
lists to create a log of dialed numbers.
|
||||
"Robo 1" added to demonstrate a programmable robot that will replay the
|
||||
player's behavior.
|
||||
"Robo 2" added to demonstrate a robot that can learn multiple stored
|
||||
action scripts with command names determined by the player.
|
||||
"Rock Garden" reformatted to give the general material at the top.
|
||||
"The Fibonacci Sequence" added to demonstrate using lists as arrays.
|
||||
"I Didn't Come All The Way From Great Portland Street" added to
|
||||
demonstrate using lists as sets.
|
||||
"Lugubrious Pete's Delicatessen" added to demonstrate using lists as
|
||||
queues.
|
||||
"Sieve of Eratosthenes" added to demonstrate using lists as sieves.
|
||||
"Circle of Misery" added to demonstrate using lists as ring buffers.
|
||||
"Lanista 1" corrected to fix a truncated sentence in the commentary.
|
||||
"Leopard-skin" added to demonstrate a log of stored actions.
|
||||
"What Makes You Tick" added to demonstrate building a fishing rod from
|
||||
component parts.
|
||||
"Your Mother Doesn't Work Here" added to demonstrate using a list as a
|
||||
stack to plan character behavior.
|
||||
The previous restriction whereby TEST scripts could not exceed 255 characters
|
||||
in length has been withdrawn. The new maximum is 9999 (a cap intended
|
||||
only to catch accidental runaway cases where the closing quote has been
|
||||
forgotten).
|
||||
Problem message added to prevent the UNDO command being used in a TEST
|
||||
script (which can't safely be done since it undoes progress in the test
|
||||
itself), and also to prevent individual commands in TEST scripts from
|
||||
exceeding 100 characters (since the I6 library would choke on those).
|
||||
Problem message improved for namespace clashes between variable names and
|
||||
descriptions.
|
||||
Problem message added (in place of previous I6 errors) when a
|
||||
description of an action, used as a condition, refers both to the past
|
||||
and to values in the present (by means of "called").
|
||||
Problem message improved for an ambiguity in rule premisses as between
|
||||
a description of an actor followed by an action, and an action name
|
||||
with no actor attached. (This arose in the case of "standing using ...",
|
||||
where "standing" had also been defined so as to describe certain people:
|
||||
was the action here "standing using", done by nobody in particular, or
|
||||
"using", done by a person matching "standing"?)
|
||||
Bug fixed whereby pastes of Example text for examples including backslashes
|
||||
(such as those arising from the introduction of regular expression
|
||||
matching) and, in some cases, other unusual characters would cause
|
||||
the text to be pasted incomplete - so that it did not work as it
|
||||
was claimed to do.
|
||||
Bug fixed whereby two or more consecutive double-quoted texts in a single
|
||||
table entry would lead to an internal error rather than a problem
|
||||
message; something which can happen easily if pasted text converts
|
||||
tabs to spaces, when two adjacent table columns are both supposed to
|
||||
contain text.
|
||||
Bug fixed whereby a rule whose premiss involved clauses of several different
|
||||
sorts, one of them "when", could sometimes produce an internal error.
|
||||
Bug fixed - or, really, feature added, but the lack of it was regarded as
|
||||
peculiar - whereby an action description used in a rule was not allowed
|
||||
to give the name of a kind of value to mean "any value of this kind":
|
||||
for instance, "Instead of dialing something to a code symbol", where
|
||||
"code symbol" is a kind of value and "dialing it to" is an action
|
||||
applying to one thing and one code symbol.
|
||||
Bug fixed whereby "[']" for apostrophe wasn't being allowed in titles given
|
||||
as the opening text of a bibliographic heading.
|
||||
Bug fixed whereby indexed text and stored action variables were not working
|
||||
properly if they belonged to rulebooks, activities or actions.
|
||||
Bug fixed whereby "if there is a [table-reference]" was not working in the
|
||||
case of columns holding indexed text.
|
||||
Bug fixed whereby spurious "no such entry" run-time problems would occur if
|
||||
a table with a column holding indexed text was created with blank rows.
|
||||
Bug fixed whereby ambiguous phrases requiring run-time checking on some
|
||||
arguments would sometimes go wrong if other arguments were stored
|
||||
actions or indexed text.
|
||||
Bug fixed whereby if several "let" variables in a single phrase needed to
|
||||
be indexed text or stored actions, they would sometimes have their kinds
|
||||
of value rearranged between them, with occasionally bizarre results.
|
||||
Bug fixed whereby the dynamic memory allocator would print up debugging
|
||||
information such as "1+128+256+512+1024+2048+4096+8192+16384+65536"
|
||||
after successfully allocating memory via Glulx's @malloc mechanism.
|
||||
Apologies for this.
|
||||
Bug fixed whereby a compound phrase which looks as if it might be in the
|
||||
form "total ...", counting the total of some property - but which isn't -
|
||||
would generate an internal error rather than being rejected in favour
|
||||
of some other interpretation.
|
||||
Bug fixed whereby a rule predicated on a condition about something being
|
||||
listed (or not) in a table would cause I6 errors.
|
||||
Bug fixed whereby an internal error rather than a problem message would
|
||||
sometimes be issued when a condition was used which had no active verb
|
||||
but could be taken as a description of things (typically arising if
|
||||
"is" had been mistyped as "in").
|
||||
Infelicity fixed whereby the problem message about minus signs being
|
||||
wrongly used in unit constants could be repeated (sometimes quite a
|
||||
few times) for the same mistake.
|
||||
Problem message added (rather than I6 error or mysteriously incorrect
|
||||
behaviour) for the case of a phrase so ambiguous that at compile-time
|
||||
it is not possible to tell how many values it takes as arguments.
|
||||
The problem explains this, shows the phrases it cannot choose between,
|
||||
and invites the author to reword one of them.
|
||||
Bug fixed whereby the old I6 debugging commands CHANGES and ROUTINES, which
|
||||
are no longer implemented in I7, still had their grammar visible in
|
||||
I7-compiled games, so that it was possible (but usually quickly fatal)
|
||||
to try using these commands.
|
1265
Changes/Change Logs/5T18.txt
Normal file
1265
Changes/Change Logs/5T18.txt
Normal file
File diff suppressed because it is too large
Load diff
600
Changes/Change Logs/5U92.txt
Normal file
600
Changes/Change Logs/5U92.txt
Normal file
|
@ -0,0 +1,600 @@
|
|||
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.
|
||||
|
919
Changes/Change Logs/5Z71.txt
Normal file
919
Changes/Change Logs/5Z71.txt
Normal file
|
@ -0,0 +1,919 @@
|
|||
5Z71 (18 April 2009)
|
||||
|
||||
INFORM FOR OS X
|
||||
|
||||
A new option on the Advanced panel of the Preferences allows the user to
|
||||
choose between Git and Glulxe as the interpreter used in the Game panel
|
||||
to play back Glulx-format projects.
|
||||
A new option on the Format menu, "Enable elastic tabs", causes Tables in the
|
||||
Source to be shown with elastic-width tabbed columns, which are the
|
||||
right width for their content. (Typing a single tab is enough to mark
|
||||
the end of the contents of a table entry; it's as if the tab is made
|
||||
of something elastic, because it stretches as needed.)
|
||||
Various minor bugs have been removed.
|
||||
|
||||
INFORM FOR WINDOWS
|
||||
|
||||
The spell check dialog now lets the user choose the dictionary language, and
|
||||
whether or not all text is checked, or just the text in quotes.
|
||||
Spell check dictionaries for different languages can be installed by copying
|
||||
the ".aff" and ".dic" files into the "Dictionaries" sub-directory of
|
||||
the Inform 7 installation. Dictionaries can be downloaded from the
|
||||
OpenOffice project at
|
||||
http://wiki.services.openoffice.org/wiki/Dictionaries
|
||||
In the Source tab's Replace dialog, selecting "Replace All" will also replace
|
||||
the currently selected word, if it matches.
|
||||
The interpreter in the Game tab can now play MOD music files.
|
||||
Sounds playing in a game in the Game tab are stopped when the game stops.
|
||||
Interpreter command files (containing a list of commands entered by the user
|
||||
into a game, as recorded by a game interpreter such as Frotz) can be
|
||||
imported into the skein with the File menu item "Import into Skein".
|
||||
There is now a choice of Glulx interpreters for the Game tab: either Glulxe
|
||||
or Git. If there are any problems with games under Git that do not
|
||||
show up under Glulxe, we would be interested to hear of it.
|
||||
The directory that Inform uses to store extensions, documentation, etc, which
|
||||
defaults to the user's "My Documents" folder, can be changed by
|
||||
creating a text file "home.txt" in the same directory as the Inform
|
||||
executable, containing the path to the required home directory.
|
||||
More options added to the preferences dialog.
|
||||
Alt-cursor left and right are now mapped onto the tab's back and forward
|
||||
actions, rather than the web browser's history.
|
||||
|
||||
INFORM FOR GNOME ON LINUX
|
||||
|
||||
Colour now works in the Game tab.
|
||||
The Game tab now has a choice of two Glulx interpreters: in addition to
|
||||
the traditional Glulxe, which has been brought up to date with version 0.4.4,
|
||||
one can now test one's Glulx projects in Git 1.2.2.
|
||||
"Elastic tabstops" have been added as an optional way to display the source
|
||||
text - this makes table columns the right width regardless of where tab
|
||||
positions lie. This feature can be enabled in the Preferences window.
|
||||
|
||||
INDEX
|
||||
|
||||
The most visible change in this build is that the Index for a project now
|
||||
has a new look, and has been reworked throughout. We now have much more
|
||||
experience of working with large projects, and have more feedback from users
|
||||
about what they found helpful and not in the old Index.
|
||||
|
||||
In general, we have tried to improve navigation within the Index pages - each
|
||||
of which contains several different tables or charts - to pack more information
|
||||
into the existing tables, where sensibly possible, and to improve its visual
|
||||
recognisability - to make it easier to see at a glance where you are. Being
|
||||
lost in the Index is no better than being lost in the source text, the whole
|
||||
problem it's supposed to address.
|
||||
|
||||
There are too many changes to itemise, but briefly:
|
||||
|
||||
links to extensions from the Index pages now have a new icon (in place of
|
||||
the old footnotes like [E1]); clicking them jumps to the documentation
|
||||
for the extension;
|
||||
a new use option, "Use numbered rules", indexes rules with identifying
|
||||
numbers alongside their names, and causes the testing command RULES ALL
|
||||
to show these numbers at run-time - which may help in debugging when
|
||||
"Use memory economy" is enforced, so that RULES ALL is unable to quote
|
||||
rule names in full.
|
||||
|
||||
CBLORB
|
||||
|
||||
This build includes version 1.1 of "cblorb", and matching improvements to
|
||||
Inform's system for releasing projects. "cblorb" is an internal tool which is
|
||||
run at the end of the translation process, but only when the Release button
|
||||
rather than the Go or Replay buttons was clicked. It has two main jobs: to
|
||||
bind up the translated project, together with any pictures, sounds, or cover
|
||||
art, into a single file called a "blorb" which can be given to players on
|
||||
other machines to play; and to produce associated websites, solution files
|
||||
and so on as demanded by "Release..." instruction(s) in the source text.
|
||||
|
||||
Previous builds of Inform included a minimal implementation of "cblorb"
|
||||
which, although it mostly worked, was really only a prototype: it was not
|
||||
really flexible or reliable enough to be used in the final system. We have
|
||||
long intended to replace it with a better implementation, and version 1.1
|
||||
is our first draft of that. It is much faster (running in order N time,
|
||||
where N is the line count of the source text, not order N-cubed), and
|
||||
produces much better HTML. This also gave us the opportunity to reform
|
||||
how "Release" works, and to make it easier to produce tidy collections of
|
||||
release material.
|
||||
|
||||
Almost all of the size or complexity limits have been taken out, and in
|
||||
particular:
|
||||
|
||||
the number of audiovisual files embedded in the blorb, previously limited
|
||||
to about 495 (depending on circumstances), is now limited only by the
|
||||
Blorb specification limit of 32765;
|
||||
the number of auxiliary files, previously at most 50, is now unlimited;
|
||||
the numbers of tables and headings in a project released with source in a
|
||||
website, previously 250 each, are now unlimited;
|
||||
the number of knots in the Skein of a project released with a solution,
|
||||
previously at most 10000, is now unlimited;
|
||||
the story description length, previously at most 1000 characters, is now
|
||||
at most 2047 characters;
|
||||
and all filenames can be up to 2047 characters long, which should help
|
||||
if the project is very, very deep in the file system tree.
|
||||
|
||||
Various minor bugs have been removed, of which the most important was a
|
||||
tendency to trim 8 bytes from the end of some audio files when embedding
|
||||
them, which caused some Ogg Vorbis files to be unplayable. The rendering of
|
||||
source text on an accompanying website is also improved somewhat, with
|
||||
various bugs to do with nested comments removed, and support for verbatim
|
||||
I6 code added; text substitutions are also now styled, and hanging
|
||||
indentation for code makes it much easier to read. Particular thanks to
|
||||
David Kinder, who diagnosed the Ogg Vorbis fault, and to Stephen Granade,
|
||||
whose "i7htmltidy.pl" script was a most effective critique of the original
|
||||
"cblorb".
|
||||
|
||||
Internal changes include:
|
||||
|
||||
there are several new placeholders:
|
||||
[PAGENUMBER] and [PAGEEXTENT], for pages in the multi-page source
|
||||
web pages, are such that "page [PAGENUMBER] of [PAGEEXTENT]" produces
|
||||
text such as "page 2 of 7";
|
||||
[TEMPLATE] is the name of the web template in current use;
|
||||
[SMALLCOVER] is the filename of the thumbnail-sized version of the
|
||||
cover art file. (Compare [BIGCOVER], which already exists, and is the
|
||||
filename of the real thing.)
|
||||
[STORYFILE] becomes the "leafname" of the story file, e.g., "Bronze.gblorb"
|
||||
[GENERATOR] becomes the name of the program generating the website, e.g.,
|
||||
"cblorb 1.2"
|
||||
[TIMESTAMP] and [DATESTAMP] are the time and date at which cblorb runs
|
||||
new command-line arguments "-trace", "-help";
|
||||
the user interface is now expected to call with the first option
|
||||
being "-osx", "-windows", or "-unix" as appropriate;
|
||||
a new "style" command in Blurb locates the relevant CSS file to
|
||||
use when releasing with a website;
|
||||
"<img ...>" tags generated by "cblorb" are now self-closing ("<img ... />");
|
||||
"<br>" tags generated by "cblorb" are now self-closing ("<br/>");
|
||||
footnote anchors are now closed, preventing link style from spilling;
|
||||
paragraphs generated by "cblorb" are now always in matching
|
||||
"<p>...</p>" tags;
|
||||
links in the lists of links are now in "<li>...</li>" list item tags in
|
||||
a surrounding "<ul>...</ul>", and similarly for the contents listing
|
||||
in a source website, where nested <ul>s are now used to show the
|
||||
headings hierarchy;
|
||||
"halign" and "valign" markers are not used in tables if a CSS file is
|
||||
present to handle table styling better;
|
||||
auxiliary file sizes displayed better, and file size displayed for the
|
||||
Blorb itself;
|
||||
cblorb no longer generates temporary files in the project's Build
|
||||
directory, so it no longer leaves debris behind for the user interface
|
||||
to tidy up.
|
||||
|
||||
RELEASING
|
||||
|
||||
There are six corresponding changes in Inform itself.
|
||||
|
||||
(1) "Release along with..." has a new option - "library card", which is
|
||||
the iFiction record for the project, an XML file conforming to the Treaty
|
||||
of Babel for bibliographic data.
|
||||
|
||||
(2) In "Release along with..." sentences, the adjectives "private" and
|
||||
"public" can be used when we release along with any of:
|
||||
source text, solution, library card
|
||||
"Public" means that if we release along with a website then the item in
|
||||
question will appear in the links from the home page; "private" means it
|
||||
will be produced but not be mentioned or linked on the website. If neither
|
||||
one is specified, source text is public but everything else is private,
|
||||
which conforms to Inform's traditional practice. If we aren't releasing
|
||||
along with a website, public vs. private makes no difference.
|
||||
|
||||
(3) Suppose Release is clicked in the Inform user interface, and everything
|
||||
works without problem messages. If there are no "Release along with..."
|
||||
sentences in the source text, then the release consists only of a single
|
||||
blorb file. The user interface displays a Save As... dialogue box asking the
|
||||
user where to put this file. But if there are "Release along with..."
|
||||
sentences, then Inform needs to release multiple files, and it puts those
|
||||
in the "Materials" folder for the project. (If the project is, say,
|
||||
"Apricot.inform" then this would be a folder called "Apricot Materials" in
|
||||
the same place.)
|
||||
|
||||
All of that is how Inform has always worked. What's new is that the released
|
||||
material is now all put in a subfolder of "Apricot Materials" called "Release".
|
||||
Anything in "Release" can be thrown away at any time, as it can all be
|
||||
replaced; equally, to upload a website to a server, we only need to copy the
|
||||
contents of the "Release" folder. This is much tidier than the old
|
||||
arrangement, in which released files mingled with other working documents in
|
||||
the root of "Apricot Materials", so that it wasn't easy to see at a glance
|
||||
what was part of the released website and what wasn't.
|
||||
|
||||
Inform automatically generates the Materials folder and its Release subfolder
|
||||
as necessary if they don't already exist.
|
||||
|
||||
(4) Inform has always generated websites using what it calls "templates",
|
||||
and it has always been supplied with a single built-in template called
|
||||
"Standard". This continues to be true, but the new "Standard" is a more
|
||||
modern design, making use of CSS. (The old look is preserved as "Classic",
|
||||
also built-in, in case anyone really wants to keep using it, or needs to
|
||||
generate a website which makes no use of CSS.)
|
||||
|
||||
The form of templates has however changed. A template was previously a pair
|
||||
of HTML files - for instance, "Platinum.html" and "Platinum-Source.html" -
|
||||
containing placeholder text like "[AUTHOR]" where the author's name should
|
||||
appear, and so on. A template is now a folder - "Platinum", say - which can
|
||||
contain any of the following four files:
|
||||
|
||||
index.html - the template for the home page
|
||||
source.html - the template for source text pages
|
||||
(used only when "Release along with a website" is used)
|
||||
style.css - the CSS styles needed by the HTML files
|
||||
(extras).txt - a catalogue of any other files to be added
|
||||
|
||||
If any of these is missing, Inform uses the one in "Standard" instead.
|
||||
In practice, this means the easiest way to create a new template is to
|
||||
supply just a new CSS file, which can change the colour, font, type size,
|
||||
and position of more or less everything in the site.
|
||||
|
||||
The optional "(extras).txt" file - note brackets - is a text file which
|
||||
contains a list of named extras to throw in. For instance:
|
||||
|
||||
easter.html
|
||||
egg.png
|
||||
|
||||
These named files need to be present in the template folder. Files with the
|
||||
extension ".html" go through the placeholder expansion process just like the
|
||||
index and source pages; all other files are copied verbatim. (Extras allow
|
||||
for images, movies, etc., to be added to the template.)
|
||||
|
||||
See 22.12 and 22.13 in the documentation, which have been rewritten.
|
||||
|
||||
(5) Inform knows templates only by their titles ("Standard", say, or
|
||||
"Platinum"). When it needs to find one, it searches the following places
|
||||
in sequence:
|
||||
|
||||
(a) the "Templates" subfolder of the project's Materials folder, if this
|
||||
subfolder should exist;
|
||||
(b) the "Templates" folder in the user's own library - on Mac OS X, this is:
|
||||
~/Library/Inform/Templates
|
||||
and on Windows:
|
||||
My Documents\Inform\Templates
|
||||
(c) the built-in stock of templates, currently "Standard" and "Classic".
|
||||
|
||||
(6) A file released without cover art now has a generic cover image applied.
|
||||
Most people releasing Inform 7 works do now include cover art, and we would
|
||||
like future interpreters and website designs to be able to assume that an
|
||||
image of some kind can be associated with any I7-produced blorb.
|
||||
|
||||
INDEX AND PROBLEMS
|
||||
|
||||
It would not be useful to itemise the changes here, but the design of the
|
||||
Index pages has been heavily revised. The aim is to present more information,
|
||||
but more clearly, and with better navigation and labelling. We'd suggest
|
||||
that anyone used to the old Index might find it worthwhile to explore the
|
||||
new one.
|
||||
|
||||
A process of trying to improve the quality of problem messages is under way,
|
||||
though it's certainly not complete. Here the aim has been to be clearer and
|
||||
more direct, with hints typographically separated from their messages to
|
||||
reduce the tendency of long paragraphs to resist the tired eye. Most problem
|
||||
messages are now accompanied by blue documentation-link icons to relevant
|
||||
passages of the manual.
|
||||
|
||||
KINDS OF VALUE
|
||||
|
||||
Activity names can now be stored in variables.
|
||||
In previous builds, indexed texts, stored actions and lists could not be
|
||||
properties of values - though they could be properties of objects. This
|
||||
anomaly is removed.
|
||||
Inform now makes more apparent that it allows arithmetic on some kinds of
|
||||
value (numbers, times, etc.) but not others (text, scenes, etc.). The
|
||||
new Kinds index page should clarify which.
|
||||
The rounding-off notation "V to the nearest D" now works for any numerical
|
||||
value V, not just for times, as in previous builds. Thus, for instance:
|
||||
the pressurised volume to the nearest 100 cu m
|
||||
the score to the nearest 25
|
||||
Two new operations also act on any numerical value:
|
||||
cube root of V
|
||||
square root of V
|
||||
The results will necessarily be approximate. Square roots of negative
|
||||
numbers throw a run-time problem.
|
||||
It's now legal to declare multiplication rules for any numerical kinds of
|
||||
value, provided this is done consistently. E.g.:
|
||||
|
||||
Bus Stop is a room.
|
||||
Frequency is a kind of value. 40/min specifies a frequency.
|
||||
Bus frequency is a frequency that varies. Bus frequency is 2/min.
|
||||
A frequency times a time specifies a number.
|
||||
When play begins:
|
||||
say "You can expect [bus frequency times 10 minutes] buses to turn
|
||||
up in the next ten minutes."
|
||||
|
||||
This would previously have been rejected as involving the built-in KOVs
|
||||
"time" and "number", which Inform was rather over-protective towards.
|
||||
|
||||
SCIENTIFIC UNITS AND SCALED ARITHMETIC
|
||||
|
||||
Inform now allows a spread of alternative notations for units:
|
||||
|
||||
A weight is a kind of value. 10kg specifies a weight. 1 tonne specifies a
|
||||
weight scaled up by 1000. 1g specifies a weight scaled down by 1000.
|
||||
|
||||
This enables notations such as "0.45kg" to be used, and causes weights to be
|
||||
stored to an accuracy of 1g. These scale factors are kept consistent in all
|
||||
arithmetic, and in particular when different units are multiplied together
|
||||
or divided.
|
||||
|
||||
There can be equivalents on a different scale altogether:
|
||||
|
||||
1 ounce specifies a weight equivalent to 0.028kg.
|
||||
1 pound specifies a weight equivalent to 16 ounce.
|
||||
|
||||
We can also mark some notations as singular or plural, and give them names:
|
||||
|
||||
1 tonne (singular, in tonnes) or 2 tonnes (plural, in tonnes) specifies a
|
||||
weight scaled up by 1000.
|
||||
|
||||
That enables us to say "[weight of the tank in tonnes]", for instance.
|
||||
|
||||
A new built-in extension, "Metric Units by Graham Nelson", makes definitions
|
||||
of kinds of value for most of the scientific quantities needed to make models
|
||||
of the real world:
|
||||
|
||||
length, mass, elapsed time, electric current, temperature, luminosity,
|
||||
angle, frequency, force, energy, pressure, power, electric charge, voltage,
|
||||
luminance, area, volume, velocity, acceleration, momentum, density, heat
|
||||
capacity, specific heat capacity
|
||||
|
||||
The extension defines SI standard notations for all of these, allowing both
|
||||
European and American spellings, and gives them the proper dimensional rules
|
||||
for multiplication (for instance, length times length is an area). "Elapsed
|
||||
time" is much more precise than the built-in "time" kind of value - it measures
|
||||
from 1 centisecond up to about 35 weeks, rather than being a count of minutes
|
||||
in the course of a single day. Use of "Metric Units" requires the Glulx story
|
||||
file format rather than the Z-machine, simply in order to hold large enough
|
||||
numbers to make sensible scientific calculations.
|
||||
|
||||
EQUATIONS
|
||||
|
||||
As trailed, somewhat speculatively, in the January 2007 discussion document,
|
||||
Inform now supports displayed equations. Inform imitates the conventions of
|
||||
printed scientific books and papers, just as it does with tables of data.
|
||||
For example:
|
||||
|
||||
Equation - Newton's Second Law
|
||||
F=ma
|
||||
where F is a force, m is a mass, a is an acceleration.
|
||||
|
||||
Equation - Principle of Conservation of Energy
|
||||
mgh = mv^2/2
|
||||
where m is a mass, h is a length, v is a velocity, and g is the
|
||||
acceleration due to gravity.
|
||||
|
||||
(These equations are dimensionally checked for correctness.) Inform can then
|
||||
solve them to calculate whatever unknown is missing. For instance,
|
||||
|
||||
let v be given by the Principle of Conservation of Energy, where h = 10m;
|
||||
|
||||
is sufficient to determine "v" provided that the quantities other than "v" and
|
||||
"h" are known.
|
||||
|
||||
In cases where we simply want a quick way to write an elaborate one-off
|
||||
formula, we don't need to declare an equation - we can just write it in directly:
|
||||
|
||||
let f be given by V = fL;
|
||||
|
||||
LOGIC
|
||||
|
||||
It is now legal to use "now" in a way involving more than one varying quantity
|
||||
at a time. For example:
|
||||
|
||||
Trail Shelter is a room. Fred and George are men in Trail Shelter. The
|
||||
possum, the skunk and the weasel are animals. Dixville Notch is north
|
||||
of the Shelter. Earl is a man in Dixville Notch.
|
||||
|
||||
Suspecting relates various people to various people.
|
||||
The verb to suspect (he suspects, they suspect, he suspected, it is
|
||||
suspected, he is suspecting) implies the suspecting relation.
|
||||
|
||||
Earl suspects the possum.
|
||||
|
||||
Instead of waiting:
|
||||
say "A sinister odour begins to make itself felt.";
|
||||
now every person in Trail Shelter suspects every animal which is not
|
||||
suspected by Earl.
|
||||
|
||||
Test me with "relations / z / relations".
|
||||
|
||||
Previous builds would have rejected this use of "now" as too complex.
|
||||
|
||||
It's now legal to test if something is "everywhere"; this will only be true
|
||||
for backdrops which are indeed everywhere.
|
||||
|
||||
The Standard Rules now define:
|
||||
|
||||
The verb to provide (he provides, they provide, he provided, it is provided,
|
||||
he is providing) implies the provision relation.
|
||||
|
||||
This in general is a relation. The following are equivalent:
|
||||
|
||||
if carrying capacity is provided by the player
|
||||
if the player provides carrying capacity
|
||||
|
||||
For clarity, "the property ..." can be used, and this is compulsory for
|
||||
either/or properties, since those are otherwise adjectives not nouns:
|
||||
|
||||
if the player provides the property male
|
||||
if the player provides the property carrying capacity
|
||||
|
||||
This makes "to provide" a full verb, whereas previously it was only imitated
|
||||
by a definition of "X provides the property P" in the Standard Rules.
|
||||
|
||||
It's now legal to assert value relations in relative clauses, e.g.:
|
||||
|
||||
Laboratory is a room. Peter is in the laboratory.
|
||||
Colour is a kind of value. Aquamarine is a colour.
|
||||
Annoying relates various colours to various people. The verb to annoy (he
|
||||
annoys, they annoy, it is annoyed, he is annoying) implies the annoying
|
||||
relation.
|
||||
Aquamarine is a colour which annoys Peter.
|
||||
|
||||
MINOR NEW FEATURES
|
||||
|
||||
A new use option allows the parser to handle large numbers of objects better.
|
||||
For instance,
|
||||
|
||||
Use maximum things understood at once of 200.
|
||||
|
||||
enables the parser to handle commands like TAKE ALL to work well in situations
|
||||
where up to 200 items are within view at once. (This number was always 64 in
|
||||
previous builds, and the default level has been raised to 100.)
|
||||
|
||||
Inform has for some time had the phrase
|
||||
|
||||
the room north from the Ballroom
|
||||
|
||||
to look up map connections; it now recognises "north of the Ballroom" as being
|
||||
synonymous. This reports the room which somebody would get to if they could
|
||||
go, in an unimpeded way, north from the Ballroom - perhaps through a door.
|
||||
The result is always a room, or nothing. In similar vein, the new phrase:
|
||||
|
||||
the door D from/of R
|
||||
|
||||
produces the door which lies in direction D from room R, or else nothing if
|
||||
there's no door there.
|
||||
|
||||
It's now legal to set values that vary "usually". For instance:
|
||||
|
||||
The speed limit is a speed that varies. The speed limit is usually 100 mph.
|
||||
|
||||
This should help extension writers who are nervous of setting values which
|
||||
their users might want to alter.
|
||||
|
||||
Inform usually allows "while" as synonymous with "when", but until now an
|
||||
exception has been that it insists on "Understand... when..." rather than
|
||||
"Understand... while...". Both wordings are now allowed.
|
||||
|
||||
Build 5U92 was rather strict about not allowing colons in text substitutions.
|
||||
Usually that's a good thing, as it catches various accidents, and in general
|
||||
text substitutions shouldn't contain punctuation. But that overlooked times
|
||||
of day written with colons, as here:
|
||||
"The stage is [if the time of day is after 8:00 PM]filled[else]empty[end if]."
|
||||
So colons have been allowed again if used in explicit times of day.
|
||||
|
||||
New rules have been added to the Standard Rules:
|
||||
|
||||
standard report preferring abbreviated room descriptions rule
|
||||
standard report preferring sometimes abbreviated room descriptions rule
|
||||
standard report preferring unabbreviated room descriptions rule
|
||||
standard report switching score notification on rule
|
||||
standard report switching score notification off rule
|
||||
|
||||
so that these out of world actions are reported by the report rules, which
|
||||
can then be modified or pre-empted, just as the corresponding rules can for
|
||||
ordinary actions.
|
||||
|
||||
In previous builds, and in keeping with ancient Infocom customs, "leave" was
|
||||
synonymous with "go" when typed as a command. On balance, though, this leads
|
||||
to confusion - especially since "go" often has the sense of "enter", exactly
|
||||
reversing the meaning of "leave". "Leave" is now synonymous with "exit".
|
||||
|
||||
Perhaps this is really a bug fix: the phrase option "if absent" for the phrase
|
||||
"add V at entry N in L" (for adding a value to a list in a given position) was
|
||||
claimed to work in the documentation for previous builds, but in fact it has
|
||||
only just been implemented in this build. (Previous builds did allow "if absent"
|
||||
in the case where V is a list, but not where it is a single entry; and in the
|
||||
case where no entry position is specified.)
|
||||
|
||||
PERFORMANCE
|
||||
|
||||
The Inform 7 compiler is now more economical on memory usage. Previously
|
||||
it consumed around 43MB on a small run, and 78MB on "Bronze", a typically-sized
|
||||
complete work; those figures are now 9MB and 25MB respectively. (This may
|
||||
make Inform more viable on low-memory netbooks.)
|
||||
|
||||
Inform's use of temporary files is more or less abolished in this build;
|
||||
thus a typical problem-free run on a large source text now involves around
|
||||
100 file writes, almost all index pages, where previous builds might make
|
||||
around 1400 file writes. (This may speed Inform up on slow media such as
|
||||
memory sticks.) Internally, Inform now makes use of flexible-sized memory
|
||||
buffers instead, and as a side-effect it should be much harder for
|
||||
maliciously-constructed source text to crash Inform by means of buffer
|
||||
overruns - though nobody at present is trying this, so far as we know.
|
||||
|
||||
The upper limit of 500,000 words of source text has been removed; there is
|
||||
now no upper limit. This once seemed unthinkably large, but the recent
|
||||
release of Aaron Reed's 385,000-word "Blue Lacuna" changed our minds.
|
||||
"A la recherche du temps perdu" is about 1,500,000 words, "Clarissa" about
|
||||
1,000,000, and "War and Peace" about 500,000, so it's not impossible for
|
||||
novels to grow to such sizes.
|
||||
|
||||
"Blue Lacuna" provided some real-world profiling information on how Inform
|
||||
handled very large source texts. Although no major bottlenecks were found,
|
||||
a little tuning produced about a 10% speed gain on these larger projects.
|
||||
|
||||
Inform now takes advantage of a March 2009 extension to the Glulx virtual
|
||||
machine specification which causes certain I6 veneer routines (called very
|
||||
frequently during play) to be implemented natively rather than in Glulx
|
||||
emulation. This can result in speed-ups of a factor of 2 or 3, though those
|
||||
gains will only be realised on a Glulx interpreter which supports the new
|
||||
"acceleration" feature. (The Glulx interpreters built into Inform as the
|
||||
Game panel do support it, and work is under way in making stand-alone Glulx
|
||||
interpreters support this too.)
|
||||
|
||||
OPTIONS AND TELEMETRY
|
||||
|
||||
When Inform starts up, it now looks for a file called Options.txt inside
|
||||
the user's home folder for Inform. (On Mac OS X, this is "~/Library/Inform";
|
||||
on Windows, "My Documents\Inform", and so on.) If the file is present, then
|
||||
the text in it is added to the source text of everything Inform translates.
|
||||
|
||||
This should be used only to set use options, and given the potential for
|
||||
confusion (it's easy to forget that the Options.txt file is there), should
|
||||
only be used if really necessary.
|
||||
|
||||
A new use option, "Use telemetry recordings.", causes Inform to copy its
|
||||
outcome and problem messages to files in the home folder (see above) as
|
||||
they occur. These files are dated, so that for instance
|
||||
|
||||
Telemetry 2009-03-25.txt
|
||||
|
||||
contains all of the recorded activity on 25 March 2009. Telemetry only
|
||||
records the contents of the "Problems" panel - notes of success or failure,
|
||||
and problem messages - and (see below) nothing is transmitted via any network,
|
||||
so it isn't really surveillance. The user can deliberately add a note to
|
||||
the current telemetry file by writing something like this in source text:
|
||||
|
||||
* "I don't get it! What's a kind? Why can't the lamp be lighted?"
|
||||
|
||||
(This is a way to make a note for the benefit of someone who will read the
|
||||
telemetry file - for instance, to comment on a problem message that has just
|
||||
appeared. Note the double-quotes. Otherwise, it's meant to look like the
|
||||
standard way that beta-testers mark up IF transcripts.)
|
||||
|
||||
These two features have been added in response to requests from education
|
||||
users. Let's suppose that Mr Lebling, who teaches 5th grade in Minnesota,
|
||||
wants to set things up just right for his class. He installs Inform on the
|
||||
ten computers they will use, and also copies an Options.txt file from his
|
||||
memory stick onto each one. The Options.txt file reads:
|
||||
|
||||
Use serial comma.
|
||||
Use American dialect.
|
||||
Use telemetry recordings.
|
||||
|
||||
Now Mr Lebling's class won't be confronted with English spellings, and
|
||||
so on. And most of the kids are happy, but Mr Lebling gets the feeling that
|
||||
young Marc wasn't really paying attention, so after class he checks that day's
|
||||
Telemetry file for that computer to see what Marc was up to, and whether he
|
||||
was stuck on something.
|
||||
|
||||
(The Telemetry feature was originally devised to help with testing the
|
||||
response of real users to problem messages, and to find out which problems
|
||||
are most often generated. Telemetry systems like this are often built in to
|
||||
large applications - for instance, Microsoft Word - and the name implies
|
||||
that data can be sent back to the manufacturers, who thus get to look over
|
||||
their users' shoulders. But Inform transmits nothing at all, even if the
|
||||
use option is set, which by default it is not. So this feature really can't
|
||||
invade anyone's privacy. But we would, if people are willing, be very
|
||||
interested to see telemetry files resulting from genuine classroom use, and
|
||||
use by complete newcomers - we'd really like to know which problem messages
|
||||
puzzle people, and what the stumbling blocks are.)
|
||||
|
||||
|
||||
MAINTENANCE
|
||||
|
||||
It's hard to say whether this is a bug fix or not; more a slight change in
|
||||
philosophical outlook. Inform previously rejected this sort of thing:
|
||||
Before taking something:
|
||||
if a block is larger than the noun, say "Look out!"
|
||||
on the grounds that it couldn't know whether the noun was comparable in
|
||||
size to blocks - it would be if the noun were a block, but not otherwise.
|
||||
This generated a problem message. What now happens is that the above
|
||||
compiles to run-time checking, and a run-time problem is generated if
|
||||
the noun ever turns out not to be a block. (This is done because we
|
||||
often have a situation where the source text does guarantee things about
|
||||
the kinds of objects involved, but which Inform is unable to see.)
|
||||
Another one that is arguably a change of design rather than a bug fix:
|
||||
subject-verb inversion in assertions has been withdrawn for prepositions
|
||||
which are also participles. In previous builds, Inform would accept the
|
||||
somewhat Yoda-like sentence
|
||||
Holding the light sabre is the young Jedi.
|
||||
which is an inversion of
|
||||
The young Jedi is holding the light sabre.
|
||||
...yet has the same meaning. Inversions are often perfectly natural in
|
||||
English:
|
||||
On the table is a jar of marmalade.
|
||||
So we don't want to rule them out altogether. But we do want to prevent
|
||||
these sentences from being misread as inversions:
|
||||
Holding Area is a room.
|
||||
Wearing something is good manners.
|
||||
The order of testing the conditions on when a rule applies has been reversed.
|
||||
That sounds a more dramatic change than it really is; it means that a rule
|
||||
such as
|
||||
Instead of X when Y: ...
|
||||
will test to see if the action is X before testing whether condition Y is
|
||||
also true, rather than vice versa, as happened in previous builds. The
|
||||
main reason for this is so that a rule like
|
||||
Before printing the name of a vehicle (called the car) when the
|
||||
traffic warden cannot see the car: ...
|
||||
works properly, because the "car" variable is set during the test of X
|
||||
(that the "printing the name" activity is being applied to "a vehicle
|
||||
(called the car)"), and so is available for use in condition Y
|
||||
("the traffic warden cannot see the car").
|
||||
When one rule is "listed instead of" another one in the same rulebook,
|
||||
previous builds of Inform duplicated the first rule to provide the
|
||||
replacement; this had some advantages but broke the principle, implicit
|
||||
in the syntax and usually helpful (not to mention announced in the manual)
|
||||
that a rule can only occur once in the same rulebook. This build moves
|
||||
rather than duplicates the build. There was some debate about this on
|
||||
rec.arts.int-fiction in February 2009, and opinions were divided; we
|
||||
changed our own minds in the making of this new build; but in end, what
|
||||
lawyers call a bright-line test - a simple easily-stated principle - seemed
|
||||
for the best.
|
||||
When an actor other than the player tries an action which needs him to be able
|
||||
to touch one of the objects involved, Inform normally applies the basic
|
||||
accessibility rule (and thence the accessibility rulebook) to make the
|
||||
decision about whether this should be allowed, just as it would if the
|
||||
player tried the same thing. In previous builds, an exception was made
|
||||
for doors and backdrops, whose ability to be present in multiple rooms
|
||||
made it difficult to determine accessibility for third parties. Erring
|
||||
on the side of caution, the item would be assumed accessible. In this
|
||||
build, that leniency is narrowed so that it applies only in the case
|
||||
of third-party actors in a different location from the player.
|
||||
When Inform tests to see if an action applies, and it finds a region where it
|
||||
might have expected a room, it reads this as any room in that region.
|
||||
This is why:
|
||||
Instead of going from the Great Tundra, ...
|
||||
matches going from any room in the Great Tundra region, and since an
|
||||
action cannot apply to a region, there's no ambiguity here. But 5U92 also
|
||||
applied the same room to activities, which _can_ apply meaningfully to
|
||||
regions in their own right, and this was a bug. It has been fixed.
|
||||
In previous builds, it was legal but futile to try actions like this one:
|
||||
try asking Xerxes about "Athenians";
|
||||
- futile because command text is always reduced to lower case, so that
|
||||
the capital A in Athenians makes it guaranteed not to match anything
|
||||
Xerxes knows about. In this build, command snippets like this in a "try"
|
||||
are automatically reduced to lower case.
|
||||
Attempts to determine "the time since Alien Landing began" or "the time when
|
||||
World Obliteration ended" are not possible if these scenes have, in fact,
|
||||
never begun or ended. In previous builds, these questions would produce
|
||||
misleading answers. They now produce run-time problem messages.
|
||||
Problem message added to explain why doors cannot be "part of" other things,
|
||||
and how to achieve the same effect in other ways.
|
||||
Problem message added, in place of an internal error, if directions are created
|
||||
by complex rather than simple sentences (in defiance of the instruction
|
||||
in the documentation not to do this).
|
||||
Problem message added, in place of an internal error, if the source tries to
|
||||
assign properties to all kinds (e.g. by "A kind can be cool or lame.").
|
||||
Problem message clarified when the source tries to use the name of a kind
|
||||
of value as a 'let' variable name (e.g., "let the number be 10").
|
||||
Problem messages improved when lists are rejected because the spacing before
|
||||
commas is missing.
|
||||
Problem message added to be more helpful if "out of play" is used instead of
|
||||
"off-stage".
|
||||
Problem messages added when Inform 6 code is Included in place of template
|
||||
files which don't exist, or parts of them which don't exist.
|
||||
Problem message added, in place of an internal error, for attempts to
|
||||
construct a phrase in a vague way, like so:
|
||||
The factorial of a number is a phrase.
|
||||
Problem message added, in place of an I6 error, when a property name containing
|
||||
bizarre textual matter is created, usually as a result of missed punctuation:
|
||||
for instance, because of the missing full stop after "climbed" in:
|
||||
The Tree can be climbed "There is a tree in the middle of the lawn."
|
||||
Problem message added, in place of an internal error, for attempts to give
|
||||
definitions to phrases like "To try (the feat - an action): ..." which
|
||||
treat "feat" as if it were a value. (Inline definitions can use this,
|
||||
but not as a value, and nobody else can use it all. "Stored action" would
|
||||
be fine, as the problem message explains.)
|
||||
Problem message added to catch attempts to say that whole kinds of backdrop
|
||||
are "everywhere". (You can say a backdrop is everywhere, but only one
|
||||
backdrop at a time.)
|
||||
Problem message added to catch certain name-clashes between new values
|
||||
created as table entries, and other values already existing.
|
||||
Problem message added to catch "a random X" where X describes something with
|
||||
a domain which can't sensibly be searched - "a random text", for instance.
|
||||
Problem message added to prevent defining a rulebook, activity or action
|
||||
variable with a name which already has a meaning as something else.
|
||||
Bug fixed whereby a hidden limit of 255 grammatically different command verbs
|
||||
was being applied. Exceedingly this limit (which is quite hard, in fact)
|
||||
resulted previously in inexplicable mix-ups between the command verbs at
|
||||
run-time, clearly a very bad thing. Inform now enforces the limit on the
|
||||
Z-machine, where it's inherent, and lifts it on Glulx, where there can
|
||||
now be 65535 grammatically different command verbs. (Applying this fix
|
||||
required changes to the I6 compiler; we'd like to thank Brian Rapp, who
|
||||
posted issue C63010 to the I6 support pages, for putting us on the right
|
||||
track.)
|
||||
Bug fixed whereby releasing an existing story file (for instance to publish
|
||||
an old I6 project with new cover art and bibliographic data) would
|
||||
generate a spurious I6 error.
|
||||
Bug fixed whereby a bogus "too many activities" run-time problem message would
|
||||
appear once an "[any ...]" token in parsing produced a particular kind of
|
||||
parser error message on more than 20 different turns during play.
|
||||
Bug fixed whereby a condition property with three or more names, which was
|
||||
also given an explicit property name, would have the last name wrongly
|
||||
taken down: thus
|
||||
A fruit can be unripened, ripe, overripe, or mushy (this is its
|
||||
squishiness property).
|
||||
would lead to "mushy" not properly being defined.
|
||||
Bug fixed whereby lengths of time (though not times of day) mixed up hours
|
||||
and minutes, so that
|
||||
let T be 8 hours 3 minutes;
|
||||
would in fact set T to 3 hours 8 minutes. (Blushes all round.)
|
||||
Bug fixed whereby route-finding wasn't working through one-to-one relations.
|
||||
(It seems we just forgot this case: one-to-various, various-to-one, and
|
||||
various-to-various all worked.)
|
||||
Bug fixed whereby, if two actions look the same except that one takes two
|
||||
objects rather than one, then check/carry out/report rules can sometimes
|
||||
apply to the wrong one. For instance, given actions "tying" and "tying it
|
||||
to", a rule such as "Check tying something to: ..." could wrongly apply
|
||||
to the one-object form "tying" rather than to the two-object form.
|
||||
Bug fixed whereby a stored action property attached to a kind of object will
|
||||
be such that all instances of that kind which do not define their own
|
||||
value for this property will forever after share the default value, even
|
||||
if it is changed for some instances and not others.
|
||||
Bug fixed whereby mysterious run-time problems to do with your former self
|
||||
not having properties would appear in situations where the player is named
|
||||
as a character, and a property has been given to all people.
|
||||
Bug fixed whereby a list of ordinary texts being copied into a list of indexed
|
||||
texts would lose their contents, or be corrupted.
|
||||
Bug fixed whereby it would sometimes be possible to reach inside a closed
|
||||
container, if that container were part of something else which could be
|
||||
touched by the person concerned.
|
||||
Bug fixed whereby a person asked to perform an out of world action will
|
||||
silently do nothing. The reply is now something like this:
|
||||
> CLARK, SAVE
|
||||
[That command asks to do something outside of play, so it can only
|
||||
make sense from you to me. Clark cannot be asked to do this.]
|
||||
(This is a new library message - Miscellany number 74.)
|
||||
Bug fixed whereby "does the player mean" rules would sometimes not apply in
|
||||
several cases where the grammar in question involves two nouns, and the
|
||||
second noun either follows immediately on the first or has some stipulation
|
||||
applied to it (such as that it be "[someone]"), or where the first noun
|
||||
has some stipulation applied but which the second noun does not share.
|
||||
Bug fixed whereby, relatedly, the definition of the "block tying rule" in the
|
||||
Standard Rules was loosely worded and could catch one-object forms of
|
||||
tying, as well as the two-object form in the Standard Rules for which it
|
||||
was intended.
|
||||
Bug fixed whereby Glulx programmers creating additional Glk windows would find
|
||||
that sound channels were improperly created, and that random-number
|
||||
generation would not necessarily be "fixed" on debugging runs. (Many
|
||||
thanks to Eliuk Blau, for both finding and correcting this.)
|
||||
Bug fixed whereby units set up to imitate decimal places would print values
|
||||
wrongly if in between 0 and -1; e.g., given "A weight is a kind of value.
|
||||
-99.999 specifies a weight.", the value "-0.123" would print as "0.123".
|
||||
Bug fixed whereby table entries initially set to unspecified lists, with a
|
||||
column entry described only as (say) "a list of times", would then during
|
||||
run-time appear sometimes to be lists of numbers regardless of what they
|
||||
had been intended to contain.
|
||||
Bug fixed whereby optional clauses in descriptions of actions would not always
|
||||
be checked for sense - or rather, they would, but would fail with an
|
||||
internal error instead of a helpful problem message.
|
||||
Bug fixed whereby setting or testing the "to be through" relation, for talking
|
||||
about the far side of one-sided doors, silently failed during play.
|
||||
Bug fixed whereby a various-to-various relation where one of the two domains
|
||||
was a kind with no instances would sometimes produce I6 errors in
|
||||
translation.
|
||||
Bug fixed whereby, if the player gets into an enterable container on top of
|
||||
a pushable between rooms enterable supporter, and then tries to push that
|
||||
supporter to another room, a spurious programming error is displayed as
|
||||
well as the (thoroughly merited) reproof.
|
||||
Bug fixed whereby a supporter which held only an undescribed item would
|
||||
sometimes be mentioned in a broken-off sentence in a room description; e.g.
|
||||
An easel is a supporter in the studio. "An old fashioned easel is
|
||||
here." A painting is on the easel. It is undescribed.
|
||||
would produce
|
||||
An old fashioned easel is here.
|
||||
On the easel .
|
||||
Bug fixed whereby confusion could occur between actions which have similar
|
||||
names except that one takes two nouns and the other only one, e.g., as
|
||||
between "pointing at" and "pointing it at".
|
||||
Bug fixed whereby the use of brackets in heading names - e.g. "Section 2(c)1" -
|
||||
could cause bracketed stipulations like "(for use with...)" to be
|
||||
unrecognised.
|
||||
Bug fixed whereby matching the names of extensions in headings (those "for
|
||||
use with E by A", for instance) was performed case-sensitively - so that
|
||||
unless the exactly correct casing was used, the heading would behave
|
||||
unexpectedly. (Sorry: some people thought this was us being pedantic,
|
||||
but in fact it was an accident.)
|
||||
Bug fixed whereby the SHOWME testing command would incorrectly claim that
|
||||
some items were "initially carried".
|
||||
Bug fixed whereby the serial comma would be missed out of some lists produced
|
||||
by "say", even when "Use serial comma" was in force.
|
||||
Bug fixed whereby mapping tips given to improve the World index map would not
|
||||
always work where room names included the words "of" or "from".
|
||||
Bug fixed whereby the Kinds index would sometimes doubly list an either/or
|
||||
property ("Usually... drab not colorful, colorful not drab").
|
||||
|
||||
EXAMPLES
|
||||
|
||||
Added "The Speed of Thought" to demonstrate unit conversions.
|
||||
Added "Hatless" to spell out some details of how "now" works with randomness.
|
||||
Added "Slogar's Revenge" to demonstrate unlocking a door with a key can be
|
||||
worn instead of carried (and thus how to manipulate the carrying
|
||||
requirements rules)
|
||||
Added "The Facts Were These" to demonstrate giving multiple objects at once,
|
||||
with different results than if the player offered them separately
|
||||
Added "Oyster Wide Shut" to offer an alternate (and more flexible) way to
|
||||
handle the inventory listing of properties such as "(closed)"; it also
|
||||
allows the author to add his own properties to the standard list.
|
||||
Added "Whither?" to illustrate letting the player refer to a door as "the
|
||||
west door" or "the east door" under the appropriate circumstances.
|
||||
Added "Widget Enterprises" to demonstrate equations.
|
||||
"The Abolition of Love" and "What Not To Wear" changed to reflect the new
|
||||
flexibility of "now".
|
||||
"Zorb" updated to deal with a sentence of explanation that stopped without
|
||||
ending, and also to make it possible for the player to ride in the Zorb.
|
||||
"Identity Theft" given extra commentary to explain the different effects of
|
||||
compiling under Z- or Glulx.
|
||||
"Four Cheeses" improved with more refinement of scope-handling for interacting
|
||||
with a distant person who should not be visible.
|
||||
"Verbosity" slightly tweaked to give more information about how defaults work.
|
||||
"Verbosity 2" added to demonstrate how to *force* the player always to use
|
||||
full-length room descriptions (rather than merely setting the default and
|
||||
allowing him to modify it).
|
||||
"Only You" simplified and moved to an earlier section because Inform now
|
||||
pre-defines the adjective "even".
|
||||
"Channel 2" typo fixed.
|
||||
"Peeled 2" error fixed, and the documentation slightly expanded.
|
||||
"Dinner is Served" revised to make the sample code more safely portable into
|
||||
a larger game, and to remove a procedural rule that is no longer necessary.
|
||||
"Puncak Jaya" edited to improve behavior with revised accessibility rules,
|
||||
and to deal with the case where a ghost is the second noun rather than
|
||||
the noun.
|
||||
|
||||
BUILT-IN EXTENSIONS
|
||||
|
||||
New built in extension, "Metric Units": see above.
|
||||
Documentation for "Menus" substantially rewritten and the version number
|
||||
advanced to 3.
|
||||
"Basic Screen Effects" and "Complex Listing" adjusted to be more safely
|
||||
compatible with "Case Management": all three were defining a printed_text
|
||||
array but not consistently, with the result that some compilation effects
|
||||
varied depending on which extension was included first.
|
||||
"Rideable Vehicles" tidied up to be more consistent in handling how actors
|
||||
other than the player are treated; version number advanced to 3. The rules
|
||||
here have been more cleanly arranged, but with some renamings as a result -
|
||||
for instance, the "no person mounting a mounted animal rule" used to
|
||||
apply only to non-player actors, while the corresponding rule for the
|
||||
player was anonymous. There is now a single "can't mount when mounted on
|
||||
an animal rule". So any source text making use of the old rule names in this
|
||||
extension will need tidying up, or will need to use version 2. The actual
|
||||
functionality of the extension has not changed except that commands like
|
||||
"tanya, get on mystery" are now correctly understood; a cosmetic blemish in
|
||||
descriptions when multiple people are riding the same animal has been fixed.
|
||||
|
||||
RECIPE BOOK
|
||||
|
||||
Slightly expanded the section on start up features in order to include the
|
||||
idea of doing some game initialization, as necessary.
|
||||
Added a section "Other Built-in Actions" to the Commands section, which
|
||||
provides some explanation and cross-referencing for a number of types
|
||||
of action.
|
||||
Extensively rewrote the "Actions on Multiple Objects" section to provide a
|
||||
clearer explanation of how the multiple objects list works.
|
||||
Expanded the "Modifying Existing Commands" section to explain more clearly
|
||||
how to change the carrying requirements and related rules, and
|
||||
cross-referenced this segment from "Barter and Exchange", "Taking,
|
||||
Dropping, Inserting and Putting", and several sections that pertain to
|
||||
locking or placement.
|
||||
"Room Descriptions" section added to the "Place" chapter, which mostly
|
||||
contains material formerly under "Commands > Looking". Looking now points
|
||||
to this section; this organization change is due to assorted user
|
||||
feedback about where people were looking for material most often (and
|
||||
not finding it).
|
||||
"Going, Pushing things between rooms" expanded to explain the behavior of
|
||||
pushing more clearly; to offer more examples of how to write conditional
|
||||
rules governing pushing; and to lay out the details of meddling on room
|
||||
descriptions produced specifically in the context of going actions (as
|
||||
opposed to in response to LOOK). The previously under-documented "the
|
||||
room-describing action" variable used by the looking rulebooks is also
|
||||
explained in this section.
|
||||
"Scoring" expanded to explain the NOTIFY ON and NOTIFY OFF commands, to
|
||||
exemplify how to modify their behavior, and to refer the player to
|
||||
default message extensions in order to change the wording of such
|
||||
messages as "[Your score has just gone up by two points.]"
|
||||
"Saving and Undoing" expanded to mention undo prevention and warn against
|
||||
some of the dangers of using it.
|
||||
"Glulx Multimedia Effects" expanded to discuss in more detail what is and
|
||||
isn't at least theoretically possible under Glulx, in terms of sounds
|
||||
and images. (Several people on the newsgroup have asked recently whether
|
||||
it is possible to have multi-channel sounds or fade-ins and fade-outs
|
||||
under Glulx. The answer is yes, but it is not easy. The section suggests
|
||||
the prospective author check out the latest tools from the Inform
|
||||
extensions site.)
|
||||
"Settings and Status Checks During Play" section added to the Out of World
|
||||
chapter; this is largely a pointer to other sections of the manual
|
||||
(verbosity under Looking, notification under Scoring), but it also
|
||||
explains the other more obscure out of world actions. This is in response
|
||||
to an outstanding request that the unusual out of world actions be
|
||||
better documented.
|
||||
"Background, Memory and Knowledge" divided into two, considerably expanding
|
||||
the discussion of ways to track player character knowledge and use that
|
||||
tracking to affect descriptions, object names, and scope.
|
2363
Changes/Change Logs/6E36.txt
Normal file
2363
Changes/Change Logs/6E36.txt
Normal file
File diff suppressed because it is too large
Load diff
3057
Changes/Change Logs/6E59.txt
Normal file
3057
Changes/Change Logs/6E59.txt
Normal file
File diff suppressed because it is too large
Load diff
303
Changes/Change Logs/6E72.txt
Normal file
303
Changes/Change Logs/6E72.txt
Normal file
|
@ -0,0 +1,303 @@
|
|||
6E72 (1 Jul 2010)
|
||||
|
||||
This minor release of Inform contains no new features, and simply corrects a
|
||||
number of bugs reported in build 6E59. We would like to thank Jesse McGrew,
|
||||
especially, for setting up the Mantis-powered bug tracker on the Inform
|
||||
website; but also, of course, all of the people who registered to use the
|
||||
tracker, and who filed reports. The case numbers below, alarmingly in seven
|
||||
digits, are references to this database at www.inform7.com/bugs.
|
||||
|
||||
Contents:
|
||||
1. INFORM FOR OS X
|
||||
2. INFORM FOR WINDOWS
|
||||
3. INFORM FOR GNOME ON LINUX
|
||||
4. CORE INFORM MAINTENANCE
|
||||
5. EXAMPLES
|
||||
6. BUILT-IN EXTENSIONS
|
||||
|
||||
|
||||
1. INFORM FOR OS X
|
||||
|
||||
The issue in which the Index became inaccessible after a run producing
|
||||
Problem messages has been fixed.
|
||||
|
||||
2. INFORM FOR WINDOWS
|
||||
|
||||
----
|
||||
|
||||
3. INFORM FOR GNOME ON LINUX
|
||||
|
||||
Bug fixed (0000127) whereby the documentation for installed extensions
|
||||
didn't work.
|
||||
|
||||
Bug fixed (0000144) whereby the main window couldn't be resized
|
||||
smaller than a certain size.
|
||||
|
||||
Bug fixed (0000145) whereby installing the program for the first time
|
||||
on a fresh Ubuntu system caused all sorts of problems.
|
||||
|
||||
4. CORE INFORM MAINTENANCE
|
||||
|
||||
4.1. Source text and punctuation
|
||||
|
||||
Bug fixed (0000045) whereby phrases defined in the form "(list) ... words ...
|
||||
(list)" couldn't then be used with constant lists.
|
||||
|
||||
Bug fixed (0000064) whereby hard line breaks typed in the middle of text
|
||||
with substitutions would cause problems.
|
||||
|
||||
Bug fixed (0000110) whereby Inform would sometimes not allow "otherwise"
|
||||
clauses in "if" phrases whose condition ended with a digit, and whose first
|
||||
character of the succeeding phrase began with one.
|
||||
|
||||
4.2. Headings
|
||||
|
||||
Bug fixed (0000051) whereby heading cues for problem messages weren't very
|
||||
nicely spaced, vertically.
|
||||
|
||||
4.3. Extensions
|
||||
|
||||
Bug fixed (0000063) whereby installing an extension whose name contains a
|
||||
full stop would cause all kinds of unfortunate results, such as Inform refusing
|
||||
to compile projects altogether. (Full stops aren't allowed in extension names.)
|
||||
|
||||
Bug fixed (0000098) whereby the use of sections replacing sections found in
|
||||
extensions would mask any problem messages about those extensions having the
|
||||
wrong version.
|
||||
|
||||
Bug fixed (0000116) whereby variables in "unindexed" sections of extensions
|
||||
would nevertheless be included in extension documentation (not technically
|
||||
speaking the index; still, it must be right to exclude them).
|
||||
|
||||
4.4. Assertions and creations
|
||||
|
||||
Bug fixed (0000130) whereby confusions of the start location with a direction
|
||||
were reported with a cryptic problem message.
|
||||
|
||||
Bug fixed (0000112) whereby Inform could crash if asked to define objects using
|
||||
a table, and one of the objects exists already with a different meaning.
|
||||
|
||||
Bug fixed (0000046) whereby the compiler might go into an endless loop issuing
|
||||
problem messages in response to lines such as
|
||||
|
||||
There are 5 numbers in Home.
|
||||
|
||||
Problem message reporting such errors improved.
|
||||
|
||||
4.5. Model world
|
||||
|
||||
Bug fixed (0000038) whereby examining enterable supporters sometimes
|
||||
produced odd text.
|
||||
|
||||
Bug fixed (0000039) whereby a room whose name included the word "scene"
|
||||
provoked spurious problem messages.
|
||||
|
||||
4.6. Properties
|
||||
|
||||
Bug fixed (0000035) whereby assertions like "A tennis court has numbers called
|
||||
length and width." would make one property, called "length and width", not
|
||||
two, "length" and "width".
|
||||
|
||||
Bug fixed (0000037) whereby "X provides the property P" wouldn't always work
|
||||
if P were a property whose name coincides with that of a kind of value.
|
||||
|
||||
Bug fixed (0000082) whereby adjective definitions based on the value of a
|
||||
property would produce spurious problem messages if that property were
|
||||
non-arithmetic, e.g., a truth state.
|
||||
|
||||
Bug fixed (0000117) whereby rooms not explicitly declared as such could not
|
||||
be used as values of a property required to hold only rooms.
|
||||
|
||||
4.7. Relations
|
||||
|
||||
Bug fixed (0000104) whereby one-to-one relations of values couldn't always
|
||||
be tested directly.
|
||||
|
||||
Bug fixed (0000141) whereby conditions implicitly involving searches could
|
||||
not be used in definitions of relations, and produced a spurious internal
|
||||
error if they were.
|
||||
|
||||
Bug fixed (0000043) whereby Inform was not making sensible assumptions about
|
||||
the valencies of relations when these weren't explicitly given; e.g. in
|
||||
|
||||
Pet ownership relates various animals to a person (called the owner).
|
||||
|
||||
it's clear that this is various-to-one, but Inform was assuming v-to-v.
|
||||
|
||||
Bug fixed (0000041) whereby relations defined using a named property, but
|
||||
for values not able to take properties, resulted in obscure run-time problem
|
||||
messages rather than a helpful compile-time one.
|
||||
|
||||
Bug fixed (0000042) whereby equivalence relations of unbounded kinds, such
|
||||
as numbers, weren't working properly.
|
||||
|
||||
Bug fixed (0000049) whereby constant names of relations couldn't be used as
|
||||
values of variables or table entries, etc., if those relations were over
|
||||
unbounded kinds.
|
||||
|
||||
Relation memory usage slightly reduced in a few cases (see 0000059).
|
||||
|
||||
4.8. Actions
|
||||
|
||||
Bug fixed (0000057) whereby requesting an actor to end the story resulted in
|
||||
an "unable to do that" message.
|
||||
|
||||
4.9. Activities
|
||||
|
||||
4.10. Rules and rulebooks
|
||||
|
||||
Bug fixed (0000143) whereby Inform could crash on the name of a rule which
|
||||
contained parentheses.
|
||||
|
||||
Bug fixed (0000071) whereby phrases to invoke value-producing rulebooks didn't
|
||||
work with lists or some other complicated values.
|
||||
|
||||
Bug fixed (0000072) whereby phrases which produce values didn't always work if
|
||||
those values were to be lists or some other complicated values.
|
||||
|
||||
Bug fixed (0000070) whereby spurious programming errors about the "MStack"
|
||||
would appear during start-up in some cases if rulebooks had variables which
|
||||
contained lists.
|
||||
|
||||
4.11. Lists
|
||||
|
||||
Bug fixed (0000074) whereby constant lists were constrained to no more than
|
||||
127 entries. (The most serious bug in 6E59, and the main reason for this early
|
||||
bug-fixing re-release.)
|
||||
|
||||
4.12. Tables
|
||||
|
||||
Bug fixed (0000076) whereby self-referential constant lists didn't work in
|
||||
tables defining a kind of value.
|
||||
|
||||
4.13. Scenes
|
||||
|
||||
Bug fixed (0000075, 0000077) whereby the scene change machinery rule would
|
||||
always succeed, rather than end without result, which made it impossible to
|
||||
have rules working after it in the scene changing rulebook.
|
||||
|
||||
4.14. Kinds and typechecking
|
||||
|
||||
----
|
||||
|
||||
4.15. Phrases and functional programming
|
||||
|
||||
Bug fixed (0000033) whereby definitions such as
|
||||
|
||||
To say foo (X - text): ...
|
||||
|
||||
could not then be used.
|
||||
|
||||
Bug fixed (0000079) whereby the text substitution "[a list of ...]" would
|
||||
sometimes list the wrong things if the description included a negated relative
|
||||
clause, e.g., "a list of things in the cupboard which are not dishes".
|
||||
|
||||
Bug fixed (0000102) whereby "Definition:"s of adjectives given in the longer,
|
||||
phrasal form would always be compiled as if they applied to objects, whatever
|
||||
the specified domain of the adjective, with usually unfortunate results.
|
||||
|
||||
Bug fixed (0000050) whereby descriptions used as phrase tokens would sometimes
|
||||
be disallowed on grounds of their specificity, but wrongly - e.g., "all open
|
||||
doors" wouldn't be allowed as a description of things, when in fact it's fine
|
||||
as such because doors are things.
|
||||
|
||||
Bug fixed (0000105) whereby phrase tokens which had to match specific list
|
||||
values, and possibly other complicated values, didn't work.
|
||||
|
||||
Bug fixed (0000111) whereby phrase tokens involving relative clauses, such
|
||||
as "(X - a number that is four)", would fail.
|
||||
|
||||
Bug fixed (0000107) whereby "if" phrases using cases would sometimes reject
|
||||
constant names of other phrases on spurious type-checking grounds, if a
|
||||
specific kind of phrase was required.
|
||||
|
||||
Bug fixed (0000087) whereby the problem message would be rather unhelpful
|
||||
if a phrase were used to decide a value of a kind whose domain of values
|
||||
was in fact empty.
|
||||
|
||||
Bug fixed (0000085) whereby invoking a phrase that cannot be applied
|
||||
unambiguously produced unhelpful problem messages in some cases.
|
||||
|
||||
Bug fixed (0000099) whereby "now" could not be used to move backdrops.
|
||||
|
||||
Bug fixed (0000083) whereby using "decide on nothing" outside of a phrase -
|
||||
clearly a mistake - produced an internal error instead of a helpful problem
|
||||
message.
|
||||
|
||||
Bug fixed (0000032) whereby testing "if the player was on the holder of the
|
||||
player" always came true during the first turn.
|
||||
|
||||
Bug fixed (0000033) whereby "say" phrases whose tokens included text could
|
||||
not always be used. (An unusual thing to want to do, but legal.)
|
||||
|
||||
4.16. Equations, units and arithmetic
|
||||
|
||||
Bug fixed (0000044) whereby Inform could sometimes crash while trying to
|
||||
produce problem messages in reply to things like
|
||||
|
||||
showme the square root of "hello"
|
||||
|
||||
4.17. Understanding
|
||||
|
||||
----
|
||||
|
||||
4.18. Glulx issues, file I/O, figures, sounds
|
||||
|
||||
----
|
||||
|
||||
4.4. Spacing and printing
|
||||
|
||||
----
|
||||
|
||||
4.20. Indexing
|
||||
|
||||
Bug fixed (0000054) whereby the Scenes index had various arguable deficiencies,
|
||||
and could have been laid out better; this was really a suggestion, but was
|
||||
acted on anyway.
|
||||
|
||||
Bug fixed (0000061) whereby the Kinds index incorrectly listed which properties
|
||||
a kind typically held; and generally improved the coverage of properties on
|
||||
the Kinds index page.
|
||||
|
||||
Bug fixed (0000068) whereby phrases with kinds including arrows would have
|
||||
boldface misused.
|
||||
|
||||
Bug fixed (0000142) whereby the Phrasebook index subheadings would be wrong
|
||||
if indexing phrases defined in an extension, under headings in that extension
|
||||
which contained two hyphens.
|
||||
|
||||
4.21. Testing commands
|
||||
|
||||
----
|
||||
|
||||
4.22. Releasing, bibliographic data, and cBlorb
|
||||
|
||||
Bug fixed (0000040) whereby play-in-browser pages using Parchment would
|
||||
sometimes hang in Google's "Chrome" browser.
|
||||
|
||||
Bug fixed (0000058) whereby apostrophes couldn't be used edges of words in
|
||||
the story title.
|
||||
|
||||
Bug fixed (0000146) whereby one-page source web pages would be "page 1 of 0"
|
||||
rather than "page 1 of 1".
|
||||
|
||||
|
||||
5. EXAMPLES
|
||||
|
||||
"WXPQ": Corrected the commentary portion of the example, which continued to
|
||||
refer to outdated (as of 6E59) syntax for detecting parser errors.
|
||||
|
||||
"North by Northwest": updated to mention "Use DICT_WORD_SIZE of..." as an
|
||||
option to raise the nine-letter dictionary limit when compiling to Glulx.
|
||||
|
||||
|
||||
6. BUILT-IN EXTENSIONS
|
||||
|
||||
"Plurality": updated to remove deprecated "using... option" phrases; see
|
||||
report 0000073.
|
||||
|
||||
"Locksmith": updated to version 10 to remove deprecated "using... option"
|
||||
phrases.
|
||||
|
||||
"Complex Listing": updated to version 7 to remove deprecated "using... option"
|
||||
phrases.
|
996
Changes/Change Logs/6F92.txt
Normal file
996
Changes/Change Logs/6F92.txt
Normal file
|
@ -0,0 +1,996 @@
|
|||
6F92 (17 October 2010)
|
||||
|
||||
This is a private test build in advance of a maintenance release on Monday
|
||||
25 October. The build fixes every core Inform issue logged on the Inform bug
|
||||
tracker up to today, which means it resolves more than 160 issues arising
|
||||
since 6E72 (1 July); this change log lists almost all of the issues fixed,
|
||||
but omits a few which amount to simply corrections of typos. Except for the
|
||||
addition of the Quixe interpreter, allowing Glulx story files to be released
|
||||
with interpreters, there are no significant new features.
|
||||
|
||||
|
||||
Contents:
|
||||
1. INFORM FOR OS X
|
||||
2. INFORM FOR WINDOWS
|
||||
3. INFORM FOR GNOME ON LINUX
|
||||
4. MINOR NEW FEATURES
|
||||
5. CORE INFORM MAINTENANCE
|
||||
6. EXAMPLES
|
||||
7. BUILT-IN EXTENSIONS
|
||||
|
||||
|
||||
1. INFORM FOR OS X
|
||||
|
||||
(To follow.)
|
||||
|
||||
|
||||
2. INFORM FOR WINDOWS
|
||||
|
||||
When a project is saved, in order to keep the size of the skein under
|
||||
control, only a limited number of unlocked skein nodes are written out
|
||||
(currently 100). The user is warned of this the first time they open a
|
||||
project with more unlocked skein nodes in it than this. The user should lock
|
||||
any skein threads they want to keep.
|
||||
|
||||
The "Open Extensions" item in the File menu is now a sub-menu of the
|
||||
available extensions, matching the OS X front end. Extensions built into
|
||||
Inform 7 are shown in smaller text.
|
||||
|
||||
The old behaviour of the Home and End keys has been restored: they move to
|
||||
the start and end of the line on display, rather than the start and end of
|
||||
the current paragraph.
|
||||
|
||||
The items on the Format menu now all have keyboard shortcuts.
|
||||
|
||||
To match the OS X front end, the Transcript pane now has further buttons:
|
||||
"Next in Skein", "Next diff" and "Prev diff". These duplicate functionality
|
||||
from the Replay menu.
|
||||
|
||||
The Glulx interpreters for the Game pane have been updated to the latest
|
||||
versions: Glulxe 0.4.6 and Git 1.2.8.
|
||||
|
||||
|
||||
3. INFORM FOR GNOME ON LINUX
|
||||
|
||||
(To follow.)
|
||||
|
||||
|
||||
4. MINOR NEW FEATURES
|
||||
|
||||
The last major release of Inform (6E59) led with an important new feature: an
|
||||
integrated way to publish IF to a website allowing the story file to be
|
||||
played in-browser. This was done by constructing the site to use the Parchment
|
||||
interpreter, which ships as part of the Inform distribution. However, since
|
||||
Parchment is an interpreter for the Z-machine VM, this meant that only projects
|
||||
with the format setting set to "Z-code" could be released in this way. The new
|
||||
release comes with not only Parchment but also Quixe, Andrew Plotkin's
|
||||
in-browser interpreter for the Glulx VM. In response to the instruction:
|
||||
|
||||
Release along with an interpreter.
|
||||
|
||||
Inform will automatically choose Parchment for a Z-machine project, or
|
||||
Quixe for a Glulx one.
|
||||
|
||||
|
||||
Temporary "let" variables are now allowed to have names clashing with non-local
|
||||
ones; as in languages like C, these temporary definitions override the existing
|
||||
ones, but last only while the variable lasts. Thus:
|
||||
|
||||
The target is 17.
|
||||
When play begins:
|
||||
say "The target is [target]."
|
||||
When play begins:
|
||||
let the target be "brainz";
|
||||
say "This target is [target]."
|
||||
|
||||
prints up "The target is 17.", and then "This target is brainz." This should
|
||||
reduce name-clash problems where it's tricky to define global variables with
|
||||
the same name as any local ones existing in the Standard Rules (such as, in
|
||||
fact, the name "target").
|
||||
|
||||
|
||||
The rules on how temporary "let" variables are have been enforced better in this
|
||||
new build. This does cause some existing source text to fail. For example, in
|
||||
the example "Nickel and Dimed", previous builds included this:
|
||||
|
||||
if the total price of underpayment money is less than the cost:
|
||||
let the desired bill be the cheapest money which is overpayment;
|
||||
otherwise:
|
||||
let the desired bill be the costliest money which is underpayment;
|
||||
decide on the desired bill.
|
||||
|
||||
This is now rejected because "desired bill" is a name given to two different
|
||||
temporary values, each of which expires at the end of a branch of the "if";
|
||||
so that nothing called "desired bill" still exists at the "decide on..." line.
|
||||
While the above source looks (and is) harmless enough, consider this:
|
||||
|
||||
if the total price of underpayment money is less than the cost:
|
||||
let the desired bill be the cheapest money which is overpayment;
|
||||
decide on the desired bill.
|
||||
|
||||
This is clearly unfortunate if the condition fails, as then "desired bill" is
|
||||
a temporary value never brought into existence at all. Past builds of Inform
|
||||
would have allowed the usage, giving "desired bill" its default value in that
|
||||
case (albeit failing badly if the kind was such that no default value existed),
|
||||
but this was not a good idea. So we are now enforcing the rules more strictly.
|
||||
The same applies to the branches of an "if X is: ...", too. The relevant
|
||||
passage in "Nickel and Dimed" now reads:
|
||||
|
||||
if the total price of underpayment money is less than the cost:
|
||||
decide on the cheapest money which is overpayment;
|
||||
otherwise:
|
||||
decide on the costliest money which is underpayment.
|
||||
|
||||
|
||||
The handling of the "described/undescribed" either/or property has been
|
||||
made more consistent, and the documentation now says this:
|
||||
|
||||
There is also an either/or property called "described"/"undescribed",
|
||||
intended to be used only as a last resort, but which has the ability
|
||||
to hide something from room descriptions. This not really hiding: the
|
||||
idea is that "undescribed" should be used only for cases where some
|
||||
other text already reveals the item, or where its presence is
|
||||
implicit. Even then, it should only be used when the item is intended
|
||||
to be taken or moved by the player at some point - if the item isn't
|
||||
intended to move, it's much better to make it "scenery". (There's only
|
||||
one commonly-found example - the player's own body, the "yourself", is
|
||||
undescribed.)
|
||||
|
||||
Note that the "undescribed" property is automatically removed from
|
||||
anything carried by, worn by or part of the player, even indirectly;
|
||||
and that nothing on top of an "undescribed" supporter will be visible
|
||||
in a room description, even if it itself is "described". (Scenery
|
||||
supporters don't suffer from that restriction, which is one reason
|
||||
scenery is a better option when possible.)
|
||||
|
||||
|
||||
The rule on when punctuation in the source text divides up sentences has been
|
||||
slightly refined.
|
||||
|
||||
(a) Where a single punctuation mark other than "[" or "]" occurs in between
|
||||
two digits, or between a digit and a minus sign, or (in the case of full
|
||||
stops) between two lower-case alphanumeric characters, no division is made.
|
||||
This is done so that, for instance, "0.91" does not split into three words.
|
||||
|
||||
(b) Where the character following the punctuation mark is a slash, no
|
||||
division is made. This is done essentially to make most common URLs glue up
|
||||
as single words; otherwise "http://" would be broken up.
|
||||
|
||||
|
||||
The clauses in an action definition ("requiring light", "applying to...", and
|
||||
so on) previously had to appear in a specific order; now they can appear in
|
||||
any order.
|
||||
|
||||
|
||||
Implementing suggestion 1015949: RULES ON and SCENES ON are now synonymous
|
||||
with RULES and SCENES. (Previously OFF worked, but ON didn't, which was
|
||||
inconsistent with the behaviour of the ACTIONS command. This is all now
|
||||
consistent.)
|
||||
|
||||
|
||||
5. CORE INFORM MAINTENANCE
|
||||
|
||||
5.1. Source text and punctuation
|
||||
|
||||
---- (but see "Spacing and Printing" below, and see the notes above about
|
||||
word-breaking conventions)
|
||||
|
||||
5.2. Headings
|
||||
|
||||
Bug fixed (0000231) whereby a title which contains a paragraph break (why,
|
||||
why, would anyone do this?) would have it appearing with HTML tags printed
|
||||
up as part of the title when the story file begins play.
|
||||
|
||||
Bug fixed (0000161) whereby sections with quotation marks in their headings
|
||||
can't be replaced by "in place of" headings.
|
||||
|
||||
5.3. Extensions
|
||||
|
||||
Bug fixed (0000225) whereby spacing around punctuation, when extension
|
||||
documentation is being pretty-printed, would sometimes be excessive.
|
||||
|
||||
Bug fixed (0000132) whereby extension documentation containing examples with
|
||||
text containing literal paragraph breaks would fail to set up the "paste
|
||||
source" button correctly.
|
||||
|
||||
Bug fixed (0000205) whereby extension documentation containing examples with
|
||||
text containing a (- ... -) I6 escape sequence would fail to set up the "paste
|
||||
source" button correctly.
|
||||
|
||||
Bug fixed (0000167) whereby tooltips (i.e. explanation text appearing above the
|
||||
mouse arrow when it hovers) over a link icon to extension documentation would
|
||||
name the extension and author with Each Word Capitalisation, instead of
|
||||
respecting the capitalisation actually used by the extension, e.g., "CrAzYcApS
|
||||
by UNUSUALLY caPitAlized namE" as "Crazycaps By Unusually Capitalized Name".
|
||||
|
||||
Bug fixed (0000230) whereby the wording used on the warning for an incorrectly
|
||||
installed extension implied that extensions aren't allowed to have filename
|
||||
extensions - whereas they now can, and indeed should, end in ".i7x".
|
||||
|
||||
Bug fixed (0000217) whereby extensions with prodigiously large quantities of
|
||||
documentation (say 500,000 words or more) would, in some circumstances, crash
|
||||
Inform when used.
|
||||
|
||||
5.4. Assertions and creations
|
||||
|
||||
Bug fixed (0000254) whereby creations of rulebooks no longer lead to
|
||||
misreadings of "it". For example,
|
||||
|
||||
The Test rules is a rulebook.
|
||||
It has a number called the test number.
|
||||
|
||||
now produces a problem message; previously, "it" would have been taken to
|
||||
refer to something prior to the first sentence here, with disastrous
|
||||
consequences.
|
||||
|
||||
Bug fixed (0000109) whereby no problem message is issued if the source tries
|
||||
to create an object using an adjective which is an antonym; e.g.,
|
||||
|
||||
Definition: A device is complex rather than simple if its CPU power is
|
||||
50 or more.
|
||||
A simple device called a netbook is in the lab.
|
||||
|
||||
was previously accepted but created the netbook as a complex device; it now
|
||||
produces a problem message, since Inform doesn't know what CPU power to
|
||||
assign to the netbook.
|
||||
|
||||
Bug fixed (0000138) whereby an unhelpful problem message was produced in
|
||||
reply to ambiguities such as this one:
|
||||
|
||||
The kitchen is a room. The player carries no tea.
|
||||
Every turn: if the player carries no tea, say "Still no tea."
|
||||
|
||||
where an object called "no tea" is created, but this clashes against "no" as
|
||||
a determiner. A somewhat better problem message is now produced.
|
||||
|
||||
Bug fixed (0000195) whereby a nameless room passively created could not always
|
||||
be referred to implicitly by "here", as in this example:
|
||||
|
||||
There is a dark room. The player is here.
|
||||
|
||||
Bug fixed (0000139) whereby Inform silently ignored assertions about the value
|
||||
of a variable which aliases an I6 variable, as here:
|
||||
|
||||
Foo is a number that varies. The foo variable translates into I6 as "foobar".
|
||||
Foo is usually 5.
|
||||
|
||||
Inform now issues a problem message. (It's impossible because Inform 7 doesn't
|
||||
control this variable, and can't create or initialise it.)
|
||||
|
||||
Bug fixed (0000276) whereby names could clash against local variable names;
|
||||
see "minor new features" above.
|
||||
|
||||
Bug fixed (0000174) whereby sounds, figures and external files could be
|
||||
created implicitly without using the special syntax provided for this (but
|
||||
the results wouldn't always work); for example
|
||||
|
||||
A tag is a kind of value.
|
||||
Tagging relates various tags to various figure names. The verb to tag
|
||||
(he tags, they tag) implies the tagging relation.
|
||||
Outdoors is a tag. Outdoors tags Figure of Forest.
|
||||
|
||||
would cause Inform to create the figure, since it knows from the relation that
|
||||
this is what "Figure of Forest" must be, but the result is unhappy because
|
||||
there's no way to know the filename for the image. Inform now issues an
|
||||
explanatory problem message for cases like this.
|
||||
|
||||
Bug fixed (0000218) whereby contradiction problems arising from assemblies
|
||||
were not being reported very clearly. It takes quite a while to realise what
|
||||
is wrong with the following, for instance:
|
||||
|
||||
There is a room.
|
||||
A hairstyle is a kind of thing.
|
||||
A hairspray is a kind of thing.
|
||||
Every hairstyle incorporates a hairspray.
|
||||
Every hairspray incorporates a propellant.
|
||||
There is a hairstyle.
|
||||
There is a hairstyle.
|
||||
|
||||
The problem here is that there is only a single "propellant" object, yet
|
||||
Inform tries to incorporate it in both of the hairsprays created by the
|
||||
hairstyles; a contradiction since it can't be in two places at once. What has
|
||||
really happened, of course, is that the source forgot to say "A propellant
|
||||
is a kind of thing". Inform previously reported this, correctly but rather
|
||||
unhelpfully, as a contradiction between "There is a hairstyle" and "There is
|
||||
a hairstyle"; it now diagnoses the fault much better.
|
||||
|
||||
Bug fixed (0000209) whereby an unhelpful problem message was produced in
|
||||
response to:
|
||||
|
||||
A hairstyle is a kind of thing. A hairspray is part of every hairstyle.
|
||||
|
||||
where the use of "every" on this side of the relationship implicitly puts
|
||||
the same item in an unlimited number of places; a better objection is now
|
||||
made to this. (Compare the related 0000218.)
|
||||
|
||||
Bug fixed (0000134) whereby an unhelpful problem message would result from:
|
||||
|
||||
Instead of exiting when the location is lounge and when Rob is in location
|
||||
|
||||
where the actual problem is the spurious second usage of "when", which is
|
||||
now explained.
|
||||
|
||||
Bug fixed (0000333) whereby assertions such as
|
||||
|
||||
Foo is a number that varies. Foo is never 5.
|
||||
|
||||
would apparently be allowed, but have no practical effect except to prevent
|
||||
"foo" from being properly created. "Always", "seldom" and "never" are now
|
||||
prohibited in such sentences. ("Usually" remains allowed, so that extensions
|
||||
can set default values for variables which can be overridden by the main
|
||||
source text.)
|
||||
|
||||
Bug fixed (0000332) whereby contradictory assertions about the initial value
|
||||
of a variable produce a problem message about contradictory values of a
|
||||
property, confusingly. (Internally, initial values of variables are stored
|
||||
as the values of a property called "initial value" which belongs to
|
||||
variables, y'see. But this is purely an implementation convenience.) The
|
||||
problem message has been clarified.
|
||||
|
||||
|
||||
5.5. Model world
|
||||
|
||||
Bug fixed (0000202) whereby inventory listings could under rare circumstances
|
||||
print incorrectly with translation extensions such as Spanish by Sebastian Arg.
|
||||
|
||||
Bug fixed (0000278) whereby the player's holdall, if in use, would sometimes
|
||||
be called "nothing" if it was being used in a turn when it hadn't been held
|
||||
at the start of the turn.
|
||||
|
||||
5.6. Properties
|
||||
|
||||
Bug fixed (0000329) whereby a property created both explicitly and as a column
|
||||
in a table used to create objects would have the kind implied by the table
|
||||
column, even if that contradicted what the explicit declaration said; e.g.,
|
||||
|
||||
A foo is a kind of thing. A foo has a number called the fooness.
|
||||
Some foos are defined by the Table of Goodies.
|
||||
|
||||
Table of Goodies
|
||||
foo fooness
|
||||
Foo 1 "very foo indeed"
|
||||
|
||||
would not detect that "fooness" seems to be a number and a text at the same
|
||||
time. Inform now reports this with a problem message.
|
||||
|
||||
Bug fixed (0000287) whereby attempts to use properties which don't exist were
|
||||
not always picked up run-time problem messages. For instance, this passed
|
||||
without problems:
|
||||
|
||||
Home is a room. A direction has a number called the compass heading.
|
||||
When play begins: say the compass heading of Home.
|
||||
|
||||
Bug fixed (0000124) whereby defining a property of an individual non-object
|
||||
value did not always work; for example,
|
||||
|
||||
Pool Game is a scene. Pool Game has a number called target score.
|
||||
|
||||
would leave a "target score" property which produced spurious run-time problem
|
||||
messages when used.
|
||||
|
||||
5.7. Relations
|
||||
|
||||
Bug fixed (0000160) whereby phrases like "list of K that R relates", where
|
||||
K is a kind and R a relation, did not work with statically defined relations.
|
||||
|
||||
Bug fixed (0000169) whereby dynamic relations would be corrupted in some
|
||||
circumstances if they grew beyond a certain (actually quite small) size.
|
||||
|
||||
Bug fixed (0000247) whereby testing some asymmetric relations with verbs
|
||||
would produce spurious I6 errors; for example,
|
||||
|
||||
A language is a kind of value. The languages are English and Perplexish.
|
||||
Speaking relates one person to various languages. The verb to speak (he
|
||||
speaks, they speak, he spoke, it is spoken, he is speaking) implies the
|
||||
speaking relation.
|
||||
When play begins: if Zora speaks English, say "Huzzah!"
|
||||
|
||||
is clearly correct source text, but would compile incorrect code to test
|
||||
"Zora speaks English".
|
||||
|
||||
Bug fixed (0000103) whereby lists created by relationships would sometimes
|
||||
have the wrong kinds, resulting in odd failures at run-time. For example:
|
||||
|
||||
Partnership relates various lists of numbers to various lists of numbers.
|
||||
The verb to belong with (he belongs with, they belong with) implies the
|
||||
partnership relation.
|
||||
{3} belongs with {7}.
|
||||
|
||||
would not correctly initialise the relationship, so that "if {3} belongs with
|
||||
{7}" would then fail at run-time.
|
||||
|
||||
Bug fixed (0000080) whereby properties and variables with unsafe kinds could
|
||||
be created when their values were relations; for example,
|
||||
|
||||
Foo is a relation that varies.
|
||||
A thing has a relation of values to values called bar.
|
||||
|
||||
are both unsafe because the relationships are too vaguely defined to be safe
|
||||
in usage. ("Foo is a relation of numbers that varies" would be fine.) This
|
||||
now results in a problem message.
|
||||
|
||||
Bug fixed (0000096) whereby dynamic relations of block values would be
|
||||
incorrectly tested at run-time, with e.g.
|
||||
|
||||
Partnership relates various indexed texts to various indexed texts.
|
||||
When play begins: now the partnership relation relates "apples" to "bananas".
|
||||
|
||||
producing spurious "deep copy failed" messages.
|
||||
|
||||
Bug fixed (0000095) whereby valency changes to newly created relations were
|
||||
not taking effect for one-to-one relations (or equivalence relations), so
|
||||
that they sometimes came out as asymmetric when they should have been
|
||||
symmetric.
|
||||
|
||||
Bug fixed (0000185) whereby multiple-word verbs wouldn't always be conjugated
|
||||
correctly; for example,
|
||||
|
||||
Liking relates various people to various things.
|
||||
The verb to really like (he really likes, they really like, he really
|
||||
liked, it is really liked, he is really liking) implies the liking relation.
|
||||
Definition: a thing is popular if it is really liked by all people.
|
||||
|
||||
was rejected because Inform didn't recognise "it is really liked" in the
|
||||
definition. This now works as intended.
|
||||
|
||||
Bug fixed (0000241) whereby relationships to "nothing" produced crashes in
|
||||
some cases instead of problem messages; for example,
|
||||
|
||||
Requirement relates various things to various things. The verb to require
|
||||
(he requires, they require, he required, it is required, he is requiring)
|
||||
implies the requirement relation.
|
||||
The sufficiency is a thing. It requires nothing.
|
||||
|
||||
5.8. Actions
|
||||
|
||||
Bug fixed (0000303) whereby "undescribed" caused various infelicities: see
|
||||
"minor new features" above.
|
||||
|
||||
Bug fixed (0000321) whereby describing an action could fail if it included
|
||||
"that", since there would then be an ambiguity with a relative clause:
|
||||
|
||||
Answering someone that is unmaidenly behavior.
|
||||
|
||||
This used to cause a problem message, but is now accepted.
|
||||
|
||||
Bug fixed (0000177) whereby the use of action variables in the past tense
|
||||
caused "unavailable" run-time errors. This now causes a compile-time problem
|
||||
message. (It's wrong because action variables have only temporary existence;
|
||||
in the past, they were not alive to have a value.)
|
||||
|
||||
Bug fixed (0000193) whereby actions applying to lists (or other pointer values)
|
||||
could not have constant stored actions created; for example,
|
||||
|
||||
Extrapolating is an action applying to one list of numbers.
|
||||
The best idea yet is a stored action which varies. The best idea yet is
|
||||
the action of extrapolating {1, 2, 3}.
|
||||
|
||||
(This is highly dubious since such an action can never arise from a typed
|
||||
command, but we haven't actually prohibited it. If such actions cause further
|
||||
trouble, we may simply ban them.)
|
||||
|
||||
Bug fixed (0000216) whereby use of UNDO on the opening turn produced the
|
||||
wrong complaint.
|
||||
|
||||
Bug report (0000286) wasn't strictly a bug, but led to the syntax for creating
|
||||
actions being improved: see "minor new features" above.
|
||||
|
||||
5.9. Activities
|
||||
|
||||
Bug fixed (0000289) whereby an unhelpful problem message was given in reply to
|
||||
|
||||
A colour is a kind of value. The colours are red, green, blue.
|
||||
Painting is an activity on colours.
|
||||
|
||||
when the only actual problem is that it should have been "painting something".
|
||||
|
||||
5.10. Rules and rulebooks
|
||||
|
||||
Bug fixed (0000157) whereby use of constant values of certain kinds would not
|
||||
work if they were needed to determine a condition which involves an implicit
|
||||
search, for example, in the following search through all people implied by
|
||||
the word "someone":
|
||||
|
||||
Gambling relates various people to various lists of numbers. The verb to
|
||||
bet on (he bets on, they bet on) implies the gambling relation.
|
||||
Every turn when someone bets on {1, 2, 3, 4, 5}: say "Just checking."
|
||||
|
||||
Bug fixed (0000306) whereby rules such as this one, explicitly mentioning
|
||||
"an actor":
|
||||
|
||||
Report an actor painting when tint is red:
|
||||
|
||||
would fail because Inform wasn't reading "when" correctly.
|
||||
|
||||
Bug fixed (0000322) whereby rule-sorting did not detect that a "when" condition
|
||||
with two or more clauses divided by "and" was more specific than one with
|
||||
fewer clauses.
|
||||
|
||||
Bug fixed (0000125) whereby rule-sorting did not detect that a specific action
|
||||
like "examining the apple tree" was more specific than "doing something to the
|
||||
apple tree".
|
||||
|
||||
Bug fixed (0000176) whereby rule preambles naming bare kinds (rather than
|
||||
qualifying them with adjectives) would fail with spurious problems. For
|
||||
example,
|
||||
|
||||
Dialing is an action applying to one number.
|
||||
Carry out dialing a number: say "There's no answer."
|
||||
|
||||
Bug fixed (0000072) whereby rulebooks producing pointer values (indexed texts,
|
||||
say, or lists) would not work. For example:
|
||||
|
||||
Scribbling is a rulebook producing an indexed text.
|
||||
When play begins: let T be the indexed text produced by the scribbling
|
||||
rulebook.
|
||||
|
||||
would produce a spurious "deep copy failed" error at run-time.
|
||||
|
||||
Bug fixed (0000264) whereby the use of the word "rulebook" wasn't always
|
||||
consistent with "rules", e.g., creating
|
||||
|
||||
The alpha rules is a rulebook.
|
||||
The beta rulebook is a rulebook.
|
||||
|
||||
would allow rules to begin "Alpha:" but not "Beta:"; this contradicted the
|
||||
documentation, and has been put right.
|
||||
|
||||
Bug fixed (0000248) whereby callings in rules for object based rulebooks
|
||||
did not always work.
|
||||
|
||||
Bug fixed (0000179) whereby "anonymously abide by R", for some rule R, would
|
||||
sometimes abide by it but not anonymously - the circumstances are a little
|
||||
complicated to go into here, so see the tracker.
|
||||
|
||||
5.11. Lists
|
||||
|
||||
Bug fixed (0000137) whereby nested list variables were not always correctly
|
||||
initialised; for example,
|
||||
|
||||
The grid is a list of lists of indexed texts which varies. The grid is
|
||||
{{"foo", "bar"}}.
|
||||
|
||||
Bug fixed (0000293) whereby constant lists containing indexed texts which
|
||||
themselves were initialised with text substitutions would not work, under
|
||||
some eldritch circumstances: see the tracker.
|
||||
|
||||
Bug fixed (0000108) whereby comparing a newly-created empty list against
|
||||
a constant empty list would fail:
|
||||
|
||||
let L be a list of numbers;
|
||||
if L is {}, say "Test succeeded.";
|
||||
|
||||
(because Inform wrongly considered these lists to have different kinds of
|
||||
entries).
|
||||
|
||||
Bug fixed (0000224) whereby constant lists including as entries constants
|
||||
which themselves had names including the word "with" would be misunderstood.
|
||||
For example,
|
||||
|
||||
Ducks-in-a-row is a list of figure names that varies. Ducks-in-a-row is
|
||||
{Figure of Duck with Hat, Figure of Duck with Hat}.
|
||||
|
||||
5.12. Tables
|
||||
|
||||
Bug fixed (0000304) whereby nested "repeat through the table..." loops would
|
||||
sometimes fail, iterating incorrectly.
|
||||
|
||||
Bug fixed (0000188) whereby tables which begin entirely empty of rows, and
|
||||
where the kinds of the columns are therefore given in brackets after the
|
||||
column names, could not be created.
|
||||
|
||||
Bug fixed (0000228) whereby testing for the existence of an entry in a blank
|
||||
table would result in spurious "programming error" messages at run-time.
|
||||
|
||||
Bug fixed (0000189) whereby excessively large numbers of table entries would
|
||||
cause I6 errors on the Z-machine setting, rather than a problem message.
|
||||
(Memory is very limited in the Z-machine.)
|
||||
|
||||
5.13. Scenes
|
||||
|
||||
Bug fixed (0000294) whereby scenes were not allowed to be joined circularly
|
||||
end-to-end like so:
|
||||
|
||||
Repetition begins when Repetition ends.
|
||||
|
||||
Bug fixed (0000187) whereby scenes beginning based on what encloses the player
|
||||
would sometimes hang at run-time on the opening turn:
|
||||
|
||||
Importance is a scene. Importance begins when Current Place encloses the
|
||||
player for the first turn.
|
||||
|
||||
5.14. Kinds and typechecking
|
||||
|
||||
Bug fixed (0000221) whereby attempts to create an unsafe variable which
|
||||
contains a list of table columns would be rejected with an unhelpful problem
|
||||
message.
|
||||
|
||||
Bug fixed (0000222) whereby the wrong problem message would arise from a
|
||||
let variable being created like so:
|
||||
|
||||
let C be a table column;
|
||||
|
||||
(This is incorrect because unsafe; C can't be used unless we know the kind
|
||||
of the entries in the column.)
|
||||
|
||||
Bug fixed (0000129) whereby assignments to variables were not always checked
|
||||
properly at run-time for the correct kind of object, e.g.:
|
||||
|
||||
The place of origin is a room that varies.
|
||||
The shadows are scenery.
|
||||
When play begins:
|
||||
let a dim spot be the shadows;
|
||||
now the place of origin is a dim spot.
|
||||
|
||||
is unsafe because it assigns "shadows", a thing, to "place of origin", which
|
||||
is supposed to contain a room. This is now caught.
|
||||
|
||||
Bug fixed (0000302) whereby changing a text property to an indexed text value,
|
||||
for example, with
|
||||
|
||||
To rename to (Y - some indexed text):
|
||||
now the printed name of location is Y.
|
||||
|
||||
would be allowed but then crash at run-time. There's now a problem message at
|
||||
compile time.
|
||||
|
||||
Bug fixed (0000327) whereby assigning a value of the wrong kind to a property
|
||||
belonging to a constant value (which is not an object) would throw an internal
|
||||
error instead of a problem message.
|
||||
|
||||
Bug fixed (0000173) whereby spurious problem messages would be produced by
|
||||
a description used as a value which was written with a relative clause, for
|
||||
example,
|
||||
|
||||
To disregard (D - a description of numbers): do nothing.
|
||||
When play begins: disregard numbers which are even.
|
||||
|
||||
where "numbers which are even" would be rejected as a description of numbers,
|
||||
even though that's what it is.
|
||||
|
||||
Bug fixed (0000184a) whereby definitions about "actions", like this one:
|
||||
|
||||
Definition: an action is gluttonous if it is eating.
|
||||
|
||||
were rejected with an unhelpful problem message - the problem is that "action
|
||||
name" and "stored action" are kinds but "action" is not. This is now better
|
||||
explained.
|
||||
|
||||
Bug fixed (0000184b) whereby attempts to use "action" as a token in a phrase
|
||||
definition were not being rejected:
|
||||
|
||||
To disregard (act - an action): ...
|
||||
|
||||
(This is legal if the phrase has an I6 inline definition, and the Standard
|
||||
Rules uses this to define "try", for instance, but it's otherwise illegal
|
||||
because "action" is not a kind of value.)
|
||||
|
||||
Bug fixed (0000181) whereby in some circumstances "now P is V", changing the
|
||||
property P of some implied property-holder to a given value V, would be
|
||||
rejected as if it were an attempt to compare a property (as a value in its
|
||||
own right) with V.
|
||||
|
||||
Bug fixed (0000186) whereby indexed text would not work when accessed only
|
||||
indirectly and with a value which was originally text; for example:
|
||||
|
||||
To decide which number is the length of (T - an indexed text) (this is
|
||||
length extraction): decide on the number of characters in T.
|
||||
When play begins: showme length extraction applied to "Hello world!"
|
||||
|
||||
would fail with various different symptoms depending on other source text.
|
||||
|
||||
Bug fixed (0000331) whereby "provides" used with implicit searches would
|
||||
behave incorrectly for kinds of value other than kinds of object.
|
||||
|
||||
5.15. Phrases and functional programming
|
||||
|
||||
Bug fixed (0000324) whereby temporary "let" variables remained in scope after
|
||||
the end of an "if" branch in which they were created; see "minor new features"
|
||||
above.
|
||||
|
||||
Bug fixed (0000220) whereby spurious problem messages appeared after an "if"
|
||||
which was malformed, complaining about the lack of an "end if".
|
||||
|
||||
Bug fixed (0000311) whereby a phrase definition which used too many "let"
|
||||
and "repeat" variables on the Z-machine setting would not always produce
|
||||
a helpful problem message if it also repeated through tables.
|
||||
|
||||
Bug fixed (0000314) whereby "repeat" variables were allowed to be changed
|
||||
by "let", which is unsafe. For example,
|
||||
|
||||
repeat with x running from 1 to 10:
|
||||
let x be 1000;
|
||||
say "[x]."
|
||||
|
||||
used to produce the output "1000.", but now produces a problem message instead;
|
||||
the "x" value is protected from changes inside the body of the "repeat".
|
||||
|
||||
Bug fixed (0000105b) whereby phrases defined to apply to specific values
|
||||
which are themselves constant phrase names do not work; for example,
|
||||
|
||||
To waste time (this is wasting time): do nothing.
|
||||
To disregard (P - wasting time): do nothing.
|
||||
|
||||
caused "disregard wasting time" to fail to work.
|
||||
|
||||
Bug fixed (0000229) whereby phrases were forbidden to have two-word names
|
||||
with first word "end", like so:
|
||||
|
||||
To end all: end the story saying "It is all over!"
|
||||
|
||||
(A hangover to the pre-Pythonesque days when "end ..." phrases were reserved
|
||||
for closing blocks of code; there's no longer any need to reserve these.)
|
||||
|
||||
Bug fixed (0000119) whereby descriptions wouldn't work when applied to
|
||||
values stored in the Z-machine as negative numbers between -6 and -1
|
||||
inclusive. So, for example,
|
||||
|
||||
filter to negative numbers of {-2, -1, 0, 1, 2};
|
||||
|
||||
would produce a spurious run-time problem instead of {-2, -1}.
|
||||
|
||||
Bug fixed (not registered on tracker) whereby definitions like this one:
|
||||
|
||||
Definition: a weight (called S) is possible: ...
|
||||
|
||||
would result in the temporary value "S" having the kind "object" rather than
|
||||
"weight", making the definition very unlikely to translate properly.
|
||||
|
||||
Bug fixed (0000183) whereby use of an undeclared object in a (+ ... +) I6
|
||||
escape could report a problem at the wrong place, or in some cases crash.
|
||||
|
||||
Bug fixed (0000158) whereby references to indexed text values in the past
|
||||
tense, compared against literal ones, would sometimes produce I6 errors. For
|
||||
example,
|
||||
|
||||
The message is an indexed text which varies.
|
||||
Every turn when the message was "send more money": say "Just checking."
|
||||
|
||||
Bug fixed (0000219) whereby definitions referring to temporary values in the
|
||||
past tense would result in multiple reports of the same problem message.
|
||||
|
||||
5.16. Equations, units and arithmetic
|
||||
|
||||
Bug fixed (0000328) whereby a value of 0 is printed using the "natural" unit
|
||||
for a given kind even when that natural unit is for use in the singular only.
|
||||
For example,
|
||||
|
||||
Population is a kind of value. 1 person (singular) specifies a population.
|
||||
3 people (plural) specifies a population.
|
||||
|
||||
resulted in "0 person", not "0 people".
|
||||
|
||||
Bug fixed (0000319) whereby comparisons of truth states with the value "true"
|
||||
would sometimes result in false negatives.
|
||||
|
||||
5.17. Understanding
|
||||
|
||||
Bug fixed (0000208) whereby DROP ... ON ... would be understood as a throwing
|
||||
action rather than a putting action. The Standard Rules now have
|
||||
|
||||
Understand "drop [something preferably held] at/against [something]" as
|
||||
throwing it at.
|
||||
|
||||
rather than
|
||||
|
||||
Understand "drop [something preferably held] at/against/on/onto [something]"
|
||||
as throwing it at.
|
||||
|
||||
Bug fixed (0000168) whereby problem messages arising from "Understand ... when
|
||||
C" for some invalid condition C would be reported at the wrong sentence, often
|
||||
somewhere in the Standard Rules.
|
||||
|
||||
Bug fixed (0000280) whereby multiple Understand lines giving one-word names
|
||||
to things would sometimes allow these words to be combined, and sometimes
|
||||
not, depending on what order they were given in in the source text. For
|
||||
example,
|
||||
|
||||
Understand "brass" as the key.
|
||||
Understand "fob" as the key.
|
||||
|
||||
would permit BRASS FOB, BRASS and FOB but not FOB BRASS. This is contrary to
|
||||
a strict reading of the documentation, and (which is more serious) introduces
|
||||
an unnecessary dependency on the order of writing sentences. All four forms of
|
||||
the name now work.
|
||||
|
||||
Bug fixed (0000162) whereby, because of names being parsed overly fussily (see
|
||||
0000280), disambiguation questions would sometimes have the answer refused.
|
||||
An example would be lengthy; see the tracker.
|
||||
|
||||
Bug fixed (0000325) whereby spurious problems were generated by attempts to
|
||||
use tokens which gave qualified descriptions of non-object values, e.g.,
|
||||
|
||||
A spell is a kind of value. Xyzzy is a spell.
|
||||
Casting is an action applying to one spell. Understand "cast [possible spell]"
|
||||
as casting.
|
||||
Definition: a spell is possible: yes.
|
||||
|
||||
Bug fixed (0000292) whereby a test like:
|
||||
|
||||
if the player's command matches "[something visible]"...
|
||||
|
||||
did not work. (This is a very dubious practice: visibility depends on who is
|
||||
looking, which is not certainly known at this stage in parsing. So it is
|
||||
really best to be more explicit, e.g., "[something which the player can see]".)
|
||||
|
||||
Bug fixed (0000192) whereby the parser's response to an odd use of pronouns
|
||||
like this:
|
||||
|
||||
Locating is an action applying to one thing.
|
||||
Understand "locate [a device]" as locating.
|
||||
Test me with "locate me."
|
||||
|
||||
...has been improved.
|
||||
|
||||
Bug fixed (0000207) whereby the parser's response to HER, when it can't see
|
||||
the last known female in scope, is improved in cases where the source text
|
||||
also loads the word "HER" with an adjectival meaning, e.g.,
|
||||
|
||||
Understand "her" as a thing when the item described is enclosed by a woman.
|
||||
|
||||
Bug fixed (0000282) whereby an answer to a disambiguation question which is
|
||||
a fresh request made to somebody else (i.e. ignoring the question) is instead
|
||||
misread as an attempt to disambiguate, with odd consequences, e.g.,
|
||||
|
||||
>BOB, GIVE ME THE HAT
|
||||
Which do you mean, the small red hat or the large yellow hat?
|
||||
|
||||
>CAITLIN, GIVE ME THE BOX
|
||||
There is no reply.
|
||||
|
||||
actually not resulting in Caitlin having been asked anything, but from a
|
||||
command BOB, GIVE ME THE CAITLIN, GIVE ME THE BOX HAT - to which, not
|
||||
unreasonably, Bob doesn't know what to say.
|
||||
|
||||
Bug fixed (0000191) whereby unnecessary clarification messages would be printed
|
||||
by the parser in certain cases when the choice was made between
|
||||
indistinguishable alternatives. (There's no perfect way to do this, but we
|
||||
found that the new method produced fewer false positives, so to speak, on the
|
||||
corpus of Inform test cases; it usually, but not quite always, reads more
|
||||
naturally than the old way.)
|
||||
|
||||
Bug fixed (0000236) whereby the following:
|
||||
|
||||
Understand "nothing" as nothing.
|
||||
|
||||
produced an internal error instead of a problem message.
|
||||
|
||||
5.18. Glulx issues, file I/O, figures, sounds
|
||||
|
||||
----
|
||||
|
||||
5.19. Spacing and printing
|
||||
|
||||
Bug fixed (0000305) whereby text with nested, or mismatched, "[" and "]"
|
||||
was allowed, and treated these (usually) as literals; this was bad because
|
||||
it caused syntax-colouring hassles for the user interface applications,
|
||||
made source text more difficult to release to websites, and so on. There
|
||||
are now explanatory problem messages for misuse of "[" and "]".
|
||||
|
||||
Bug fixed (0000308) whereby the problem message for an empty text substitution
|
||||
"... [] ..." misleading mentioned use of a comma.
|
||||
|
||||
Bug fixed (0000196) whereby lists of objects including closed, empty,
|
||||
light-providing containers did not respect the "Use the serial comma." option.
|
||||
|
||||
Bug fixed (0000194) whereby the "[is-are a list...]" and similar text
|
||||
substitutions would wrongly omit "is" when forced to print "nothing" because
|
||||
no objects made the list. This resulted in text like "On the table nothing"
|
||||
instead of "On the table is nothing".
|
||||
|
||||
Bug fixed (0000277) whereby the phrase "replace the text X in Y with Z" would
|
||||
always replace using regular-expression matching, rather than literal matching,
|
||||
so that something like this:
|
||||
|
||||
replace the text "a" in t with "\(";
|
||||
|
||||
would behave unexpectedly because the "\" in the replacement text would be
|
||||
read as a literal marker, and so "banana" would become "b(n(n(" not "b\(n\(n\(".
|
||||
|
||||
Bug fixed (0000114) whereby the "[one of]...[or]..." text substitution would
|
||||
fail on some cycles if there were large numbers of alternatives present.
|
||||
|
||||
5.20. Indexing
|
||||
|
||||
Bug fixed (0000309) whereby the Actions index omitted "during" clauses.
|
||||
|
||||
Bug fixed (0000279) whereby the Actions index omitted commands from the
|
||||
list of "Typed commands leading to this action" when they were verbless
|
||||
commands of the form
|
||||
|
||||
Understand "[any room]" as asking for navigation help.
|
||||
|
||||
Bug fixed (0000148) whereby, when an optional section is present in the source
|
||||
text, the Contents index displays the "for use with" line, but the Phrasebook
|
||||
index does not, when indexing the contents of the section.
|
||||
|
||||
Bug fixed (0000147) whereby the "X understood" variables were unhelpfully
|
||||
spread across the Contents index.
|
||||
|
||||
Bug fixed (0000149) whereby relations taking up memory would be incorrectly
|
||||
shown, with garbled names, in the memory usage table at the foot of the
|
||||
Contents index.
|
||||
|
||||
Bug fixed (0000255) whereby the Phrasebook index would show the kinds of
|
||||
the terms of relations unhelpfully in the case of some of the built-in ones.
|
||||
|
||||
5.21. Testing commands
|
||||
|
||||
----
|
||||
|
||||
5.22. Releasing, bibliographic data, and cBlorb
|
||||
|
||||
Bug fixed (not actually registered on bug tracker, though referred to in
|
||||
passing by other reports) whereby the page numbering on released source text
|
||||
websites would be off by one.
|
||||
|
||||
Bugs fixed (0000290 and 0000281) whereby projects whose titles include
|
||||
an apostrophe would be difficult to release in various ways. (It's
|
||||
worse if the filename of the Inform project also has an apostrophe in,
|
||||
but that too ought to work in most cases; it seems to be best avoided
|
||||
if releasing along with an interpreter, though. Since there's no
|
||||
requirement for the Inform project to have the same filename as its
|
||||
story title, it may be simplest just to remove any apostrophe used in
|
||||
the filename.)
|
||||
|
||||
Bug fixed (0000180) whereby tables in the source text which contained text
|
||||
which contained explicit line and paragraph breaks would be formatted
|
||||
incorrectly in a release of the source text as part of the website.
|
||||
|
||||
Bug fixed (0000100) whereby a funny thing happened with headings appearing
|
||||
in the wrong places in a release of the source text as a website, but only
|
||||
on Windows, and... oh, see the Tracker for more.
|
||||
|
||||
Bug fixed (0000258) whereby various minor snags with footnotes appeared
|
||||
when releasing the source text as a website.
|
||||
|
||||
Bug fixed (0000223) whereby the "Standard" release template resulted in
|
||||
an in-browser interpreter page "play.html" with links assuming that the
|
||||
cover art was in JPEG format, when in fact it might be PNG.
|
||||
|
||||
|
||||
6. EXAMPLES
|
||||
|
||||
Several typos have been removed from both manuals. In "Writing with Inform",
|
||||
description of "handling an activity" tweaked to be clearer, since explanations
|
||||
added during the creation of the phrase book misleadingly suggested this phrase
|
||||
was equivalent to checking whether the activity was happening.
|
||||
|
||||
In the "Recipe Book", a new section on "Timed Input" has been added, pointing
|
||||
users to the extensions capable of handling realtime.
|
||||
|
||||
"Ant-Sensitive Sunglasses" added to help explain the function of activities,
|
||||
and demonstrate how to hook activities into room and object descriptions.
|
||||
|
||||
"Unexamined Life" updated to include the different Test me required when
|
||||
running the example under Glulx.
|
||||
|
||||
"Blankness", "Walls and Noses", "Paddington", "Facts Were These", "A Day for
|
||||
Fresh Sushi", "Control Center": typos removed.
|
||||
|
||||
"Newbie": bug in the newbie triggering removed; example simplified, since it
|
||||
is no longer trying to demonstrate procedural rules.
|
||||
|
||||
"GET AXE", "Gelato", "Muppets": procedural rules stripped out of examples.
|
||||
|
||||
"IQ Test": removed explanation text that no longer applies now that procedural
|
||||
rules have been removed from the example.
|
||||
|
||||
"Timeless", "We": removed explanation about not using procedural rules, since
|
||||
these are now deprecated anyway.
|
||||
|
||||
"A Day for Fresh Sushi": minor tweak to deal with the bug that >GIVE FOOD TO FISH
|
||||
was accepted as a winning move even though some code was included to encourage
|
||||
the player to FEED FISH instead.
|
||||
|
||||
|
||||
7. BUILT-IN EXTENSIONS
|
||||
|
||||
Locksmith: Version 11 removes a double-printing of the items on a keyring,
|
||||
arising because of changes to the Standard Rules for describing examined
|
||||
supporters.
|
||||
|
||||
Plurality: Version 9 re-includes some phrases that were introduced (including
|
||||
's/'re and more rational capitalization schemes); and also names several
|
||||
previously unnamed rules, and moves pronoun-noticing rules to a more
|
||||
appropriate place in the turn sequence.
|
1099
Changes/Change Logs/6F95.txt
Normal file
1099
Changes/Change Logs/6F95.txt
Normal file
File diff suppressed because it is too large
Load diff
274
Changes/Change Logs/6G60.txt
Normal file
274
Changes/Change Logs/6G60.txt
Normal file
|
@ -0,0 +1,274 @@
|
|||
6G60 (23 December 2010)
|
||||
|
||||
This release of Inform leaves the core language unchanged, except for the
|
||||
correction of a small number of bugs, and its main purpose is to provide
|
||||
an improved Index. Better maps are drawn on the World Index, and there's
|
||||
more detail across several other pages.
|
||||
|
||||
Contents:
|
||||
1. INFORM FOR OS X
|
||||
2. INFORM FOR WINDOWS
|
||||
3. INFORM FOR GNOME ON LINUX
|
||||
4. INDEX CHANGES
|
||||
5. CORE INFORM MAINTENANCE
|
||||
|
||||
|
||||
1. INFORM FOR OS X
|
||||
|
||||
The OS X application is unchanged.
|
||||
|
||||
|
||||
2. INFORM FOR WINDOWS
|
||||
|
||||
The preferences dialog now allows the font and font size to be changed.
|
||||
|
||||
If a window is brought to the front, and its underlying source file has
|
||||
been changed by another program, then the source file is re-loaded. The
|
||||
only exception to this is if the source has been changed in Inform 7
|
||||
but not saved, in which case there is no re-load.
|
||||
|
||||
The settings file is only now updated if the user changes any of the
|
||||
project's settings, and the settings file format has been adjusted to
|
||||
be closer to the latest version of the OS X Inform front-end.
|
||||
|
||||
|
||||
3. INFORM FOR GNOME ON LINUX
|
||||
|
||||
Fixed the same bug as on the other platforms (0000394) which caused
|
||||
incorrect highlighting of Unicode quotation marks.
|
||||
|
||||
Made some other minor improvements to syntax highlighting.
|
||||
|
||||
|
||||
4. INDEX CHANGES
|
||||
|
||||
Although we have given the Index a comprehensive revision, the effect is more
|
||||
evolutionary than revolutionary. Most of the changes are refinements aimed at
|
||||
people with larger source texts. We'd like to thank everyone who made
|
||||
suggestions on the forum at inform7.uservoice.com, whether we accepted these
|
||||
or not.
|
||||
|
||||
The major change in this build is to the World Index page, where the method
|
||||
used to deduce the positions of rooms has been replaced by a more sophisticated
|
||||
algorithm, producing better-laid-out rooms for a variety of source texts;
|
||||
and where maps are also better rendered. A text-only change log is not the
|
||||
best place to explain what has been done, so we have prepared a PDF file to
|
||||
accompany the new build, illustrating what's new.
|
||||
|
||||
Otherwise, there are changes as follows:
|
||||
|
||||
4.1. Actions Index
|
||||
|
||||
Acting on suggestion 1163485, we have provided a new index of the Understand
|
||||
tokens which are built-in (like "[things]") or defined in the source, or in
|
||||
extensions. Definitions are shown, with source links, and there are
|
||||
documentation links.
|
||||
|
||||
The general actions rulebooks - before, after, instead, and so on - used to
|
||||
be indexed at the foot of this page. They have moved, and are now at the top
|
||||
of the Rules Index page.
|
||||
|
||||
4.2. Contents Index
|
||||
|
||||
The contents listing by heading now opens with the title and author rather
|
||||
than the word "Contents".
|
||||
|
||||
The memory usage estimates are now shown only for projects with the Z-machine
|
||||
setting, since they're irrelevant for Glulx, and are hidden behind a (+) icon.
|
||||
|
||||
Acting on suggestion 1238573, there's now an index of the use options which
|
||||
are currently set for a project; there are source links as usual, and also
|
||||
paste icons for setting currently unset options.
|
||||
|
||||
4.3. Kinds Index
|
||||
|
||||
This was overhauled back in the summer, so not much has changed in this
|
||||
one. However, the sometimes distractingly long lists of objects belonging
|
||||
to each kind have been shaded in grey or (in cases where they become long
|
||||
enough to make it worthwhile) hidden behind a (+) icon. On very large
|
||||
projects, this makes a big difference to legibility.
|
||||
|
||||
4.4. Phrasebook Index
|
||||
|
||||
The table of "Relations" now has column headings.
|
||||
|
||||
The table of "Verbs used in descriptions" now includes the meanings of
|
||||
verbs (i.e., which relations they correspond to), and links to the source text
|
||||
definitions of any new verbs. Prepositional usages such as "To be adjacent to"
|
||||
are also listed for the first time (see bug report 0000395, though this wasn't
|
||||
really a bug as such).
|
||||
|
||||
4.5. Rules Index
|
||||
|
||||
Acting on suggestion 1099933, the rules index is consolidated onto a single
|
||||
page which shows the names of all of the rulebooks; actual contents of each
|
||||
rulebook are hidden behind a (+), but the number of rules in the book can be
|
||||
seen without opening it, and in particular empty rulebooks or activities are
|
||||
shaded grey. The "Detail view" sub-pages of the Rules Index are therefore
|
||||
no longer needed.
|
||||
|
||||
Also following 1099933, there are now source links to the creations of rulebooks
|
||||
and activities in the source text.
|
||||
|
||||
The groups of rulebooks have been reordered to put the ones most useful to
|
||||
working Inform authors at the top, and the technicalities down at the bottom.
|
||||
In particular, the action rulebooks have moved here from the Actions Index.
|
||||
|
||||
4.6. Scenes Index
|
||||
|
||||
This is unchanged. It was perfect already.
|
||||
|
||||
4.7. World Index
|
||||
|
||||
As noted above, the map-making algorithm is entirely overhauled, but in ways
|
||||
we won't detail here. In addition, each room and thing has a (+) icon hiding
|
||||
a new panel of details, including the properties and where they are set;
|
||||
the kind, and where it is set; map connections and region (for rooms), and
|
||||
where they are set; and a list of rules in the source text which make
|
||||
specific reference to the room or thing in question.
|
||||
|
||||
Following suggestion 1109933, the World Index map now follows the same room
|
||||
colouring as the EPS map, where this has been specified. So, for example:
|
||||
|
||||
Index map with room-colour of Zoo set to "Navy" and room-name-colour of
|
||||
Zoo set to "White".
|
||||
|
||||
will now affect both maps. (The only settings recognised by the World Index
|
||||
map are "room-colour" and "room-name-colour", and only for named individual
|
||||
rooms and for regions.)
|
||||
|
||||
|
||||
5. CORE INFORM MAINTENANCE
|
||||
|
||||
5.1. Source text and punctuation
|
||||
|
||||
Bug fixed (0000381) to improve problem messages for doubtful phrase punctuation.
|
||||
|
||||
Bug fixed (0000400) to improve problem message for text substitutions using
|
||||
exotic Unicode characters as part of their names.
|
||||
|
||||
Bug fixed (0000373) whereby improperly using brackets to define an antonym,
|
||||
like so:
|
||||
|
||||
Definition: a room is home (rather than house) if ...
|
||||
|
||||
would cause an internal error rather than a problem message. (Removing the
|
||||
brackets makes this work as intended.)
|
||||
|
||||
5.2. Headings
|
||||
|
||||
----
|
||||
|
||||
5.3. Extensions
|
||||
|
||||
----
|
||||
|
||||
5.4. Assertions and creations
|
||||
|
||||
Bug fixed (0000370) whereby Inform wasn't allowing words long enough to hold
|
||||
enormous URLs, or the longest word in James Joyce's Finnegans Wake.
|
||||
|
||||
Bug fixed (0000375) whereby very deeply recursive assemblies would spuriously
|
||||
produce problem messages for composite names which were too long.
|
||||
|
||||
5.5. Model world
|
||||
|
||||
Bug fixed (0000432) whereby the problem message for a three-sided door wasn't
|
||||
giving source text links.
|
||||
|
||||
Bug fixed (0000372) whereby the BRIEF printing mode was still being described
|
||||
as "normal", when in fact it's no longer the default.
|
||||
|
||||
5.6. Properties
|
||||
|
||||
Bug fixed (0000390) whereby misleading problem messages were issued for
|
||||
attempts to create properties of actions, activities or rulebooks.
|
||||
|
||||
Bug fixed (0000397) whereby Inform produced an internal error rather than a
|
||||
problem message for attempts to use "player" as a constant property value.
|
||||
(The "player" is not constant, because point of view can switch during play.)
|
||||
|
||||
5.7. Relations
|
||||
|
||||
----
|
||||
|
||||
5.8. Actions
|
||||
|
||||
----
|
||||
|
||||
5.9. Activities
|
||||
|
||||
----
|
||||
|
||||
5.10. Rules and rulebooks
|
||||
|
||||
Bug fixed (0000405) whereby rules written like so:
|
||||
|
||||
Carry out an actor dead end reaching: ...
|
||||
|
||||
would cause spurious problem messages if (a) the action had its participle,
|
||||
in this case "reaching", as other than the first word; and (b) the text "an
|
||||
actor" was given to specify who would be doing it.
|
||||
|
||||
5.11. Lists
|
||||
|
||||
----
|
||||
|
||||
5.12. Tables
|
||||
|
||||
----
|
||||
|
||||
5.13. Scenes
|
||||
|
||||
Bug fixed (0000415) whereby Inform could hang if told that scene S begins
|
||||
when scene T ends and also vice versa.
|
||||
|
||||
5.14. Kinds and typechecking
|
||||
|
||||
----
|
||||
|
||||
5.15. Phrases and functional programming
|
||||
|
||||
Bug fixed (0000398) whereby Inform produced an internal error instead of a
|
||||
problem message for an attempt to use "otherwise if" incorrectly.
|
||||
|
||||
Bug fixed (0000404) whereby attempts to use descriptions rather than explicit
|
||||
values in the phrase "place ... in scope" would cause an internal error rather
|
||||
than a problem message.
|
||||
|
||||
5.16. Equations, units and arithmetic
|
||||
|
||||
An embarrassing one, this: bug fixed (0000370) whereby, when printing numbers
|
||||
in words, Inform printed billions as "millions".
|
||||
|
||||
5.17. Understanding
|
||||
|
||||
----
|
||||
|
||||
5.18. Glulx issues, file I/O, figures, sounds
|
||||
|
||||
----
|
||||
|
||||
5.19. Spacing and printing
|
||||
|
||||
----
|
||||
|
||||
5.20. Indexing
|
||||
|
||||
Bug fixed (0000363) whereby kinds were listed as kinds of themselves in the
|
||||
Lexicon (as for instance "animal... noun, a kind of animal").
|
||||
|
||||
Bug fixed (0000351) whereby an EPS map, if output, didn't respect instructions
|
||||
to map non-standard directions like "starboard".
|
||||
|
||||
Bug fixed (0000371) whereby regions on the World Index weren't being
|
||||
coloured as they should have been, and whereby disconnected components
|
||||
were being superimposed in some cases.
|
||||
|
||||
5.21. Testing commands
|
||||
|
||||
----
|
||||
|
||||
5.22. Releasing, bibliographic data, and cBlorb
|
||||
|
||||
----
|
4012
Changes/Change Logs/6L02.txt
Normal file
4012
Changes/Change Logs/6L02.txt
Normal file
File diff suppressed because it is too large
Load diff
564
Changes/Change Logs/6L38.txt
Normal file
564
Changes/Change Logs/6L38.txt
Normal file
|
@ -0,0 +1,564 @@
|
|||
Inform build 6L38 (30 August 2014)
|
||||
|
||||
Contents:
|
||||
1. Introduction
|
||||
2. Minor new features in the language
|
||||
3. The Inform application
|
||||
3 (a). Inform for Mac OS X
|
||||
3 (b). Inform for Windows
|
||||
3 (c). Inform for Linux
|
||||
3 (d). Inform for Command-Line Linux
|
||||
3 (e). Inform for Android
|
||||
4. Maintenance
|
||||
4 (a). Core Inform maintenance
|
||||
4 (b). Extension maintenance
|
||||
4 (c). Examples maintenance
|
||||
4 (d). Interpreter maintenance
|
||||
|
||||
Note: Throughout this document, bug numbers in the seven-digit form "0000123"
|
||||
refer to tickets at the Inform bug tracker: http://inform7.com/mantis/.
|
||||
Suggestion numbers, also large but not starting with a 0, refer to tickets at
|
||||
Inform's Uservoice forum, a public venue for suggestions to be made about
|
||||
future features: http://inform7.uservoice.com/.
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
Unlike its predecessor, build 6L02, this release of Inform is aimed almost
|
||||
entirely at maintenance: it fixes around 150 bugs, most of them minor and
|
||||
related to recent changes. Users of 6L02 should be able to upgrade with
|
||||
no preparation needed; users of earlier builds, though, would be well
|
||||
advised to read the notes on the big changes in 6L02 before proceeding.
|
||||
|
||||
But there is one major development, all the same: for the first time
|
||||
Inform is released for a mass-market mobile operating system - Android.
|
||||
|
||||
|
||||
2. Minor new features in the language
|
||||
|
||||
* It was realised soon after the release of 6L02 that the text substitutions
|
||||
"[those]" and "[Those]" were ambiguous, since if they're applied to an
|
||||
object which is a man or woman then they would have to be different in the
|
||||
accusative and nominative cases. Consider the two texts:
|
||||
|
||||
"But [we] [aren't] holding [regarding the noun][those]."
|
||||
"But [regarding the noun][those] [aren't] available."
|
||||
|
||||
and suppose the noun is Andrew. Then "[those]" needs to expand as "him" in the
|
||||
first case but as "he" in the second. To distinguish these,
|
||||
|
||||
"[those in the nominative]"
|
||||
"[those in the accusative]"
|
||||
|
||||
and similarly for Those. But what should plain "[those]" and "[Those]" do?
|
||||
We note that the Standard Rules used "[those]" in 7 responses, all accusative,
|
||||
and "[Those]" in a further 12, all nominative. Accordingly, Inform now defines
|
||||
"[those]" as equivalent to "[those in the accusative]" and "[Those]" as
|
||||
"[Those in the nominative]". This fixes bug 0001232, and though it's not a
|
||||
perfect solution, it's intended to be something we might revisit when Inform
|
||||
has a better idea of noun cases (as it will need for, say, adaptive German).
|
||||
Note that "nominative" and "accusative" are the two values of the kind
|
||||
"grammatical case"; "nominative" existed in 6L02, but "accusative" is new in
|
||||
this build.
|
||||
|
||||
* The real square root function can now be applied to any numerical quantity
|
||||
for which the dimensions (in physics terms) are a perfect square. Thus, if
|
||||
we're using the Metric Units extension,
|
||||
|
||||
the real square root of 4 sq m
|
||||
|
||||
produces the length "2.0m". This also means that equations such as:
|
||||
|
||||
Equation - Pythagoras's Theorem
|
||||
a = root (b^2+c^2)
|
||||
where a is a length, b is a length, c is a length.
|
||||
|
||||
can be solved for "a"; this previously failed because "root" could be applied
|
||||
only to dimensionless numbers. (See also bug report 0001264.)
|
||||
|
||||
* The following are now equivalent:
|
||||
|
||||
[1] A food is a kind of thing which is edible. [2] A food is a kind of edible thing.
|
||||
|
||||
(Previously [1] was allowed, but [2] was disallowed.)
|
||||
|
||||
* Action descriptions like the following are now rejected:
|
||||
|
||||
Instead of taking seven things: ...
|
||||
Instead of taking the teddy bear on the dresser: ...
|
||||
|
||||
The first case is rejected because a single noun can't be "seven things", and
|
||||
the second because "the teddy bear", a proper noun, is being used as if it
|
||||
were a common noun. ("a thing on the dresser" would be fine.) Previous builds
|
||||
of Inform allowed these, but compiled misleading tests: e.g. the latter
|
||||
would simply test whether the teddy bear was on the dresser, regardless
|
||||
of whether or not it was the thing taken.
|
||||
|
||||
* It is now officially illegal to create something new with one of the
|
||||
following reserved names:
|
||||
|
||||
action, condition, list-entry, now-condition, phrase, property-value,
|
||||
storage, table-reference, variable
|
||||
|
||||
These all have internal meanings and it's unlikely to be safe to create
|
||||
anything with these names, though in some cases one might be lucky. (The
|
||||
example "Greater Variety", for instance, created a table column named
|
||||
"action" in 6L02 and got away with it; this column has been renamed.
|
||||
See bug report 0001347.)
|
||||
|
||||
* It is now officially illegal to define a phrase which looks like "X is
|
||||
(a relationship) Y". For example,
|
||||
|
||||
To decide whether (X - testval) is less than (Y - testval):
|
||||
|
||||
is now disallowed, because there's already a meaning of "To be less than".
|
||||
(See bug report 0001230.)
|
||||
|
||||
* When replacing a heading from an extension, it is now possible to put the
|
||||
heading name in quotation marks for clarity. For example:
|
||||
|
||||
Section - Another Questions fix (in place of "Section 4 - Phrase used to
|
||||
ask questions in closed mode" in Questions by Michael Callaghan)
|
||||
|
||||
(Without quotation marks, the grammar is ambiguous, because of the "in" in
|
||||
the name of the heading. See bug report 0001239.)
|
||||
|
||||
* It's now legal to test actions against kinds of actions in a more flexible
|
||||
way. For example:
|
||||
|
||||
Attacking is aggressive behaviour.
|
||||
Examining is inquisitive behaviour.
|
||||
[1] Before aggressive behaviour: ...
|
||||
[2] Before doing something other than aggressive behaviour: ...
|
||||
[3] Before aggressive behaviour or inquisitive behaviour: ...
|
||||
[4] Before aggressive behaviour or jumping: ...
|
||||
|
||||
Previously only rule [1] would have been allowed. (This was prompted by
|
||||
bug report 0001244, though that was arguably a suggestion in disguise.)
|
||||
|
||||
* The "backtrace" problem messages arising from ambiguous possible phrases,
|
||||
which list what Inform was trying to read, have been redesigned a little.
|
||||
|
||||
* The default contents of the following two responses have changed:
|
||||
|
||||
list writer internal rule response (R)
|
||||
list writer internal rule response (T)
|
||||
|
||||
in each case to remove an open bracket at the beginning; this open bracket
|
||||
is instead displayed using list writer internal rule response (A) first. The
|
||||
practical effect of this is that only two changes are needed to make the
|
||||
list writer always use, say, square brackets instead of round ones:
|
||||
|
||||
The list writer internal rule response (A) is " [bracket]".
|
||||
The list writer internal rule response (B) is "[close bracket]".
|
||||
|
||||
(See bug report 0001344, to which this is related.)
|
||||
|
||||
* I6 template files can now be installed in Inform's external resources
|
||||
folder, in a subfolder called "I6T". Inform first looks for these in
|
||||
Project.materials/I6T, then in (external)/I6T, and lastly in its own
|
||||
built-in reservoir. This is a change nobody actually asked for, but it makes
|
||||
everything consistent since the same convention is followed for Language
|
||||
bundles, website Templates and Extensions.
|
||||
|
||||
|
||||
3. The Inform application
|
||||
|
||||
3 (a). Inform for Mac OS X
|
||||
|
||||
6L02 introduced an almost entirely rewritten user interface, and inevitably
|
||||
there were a few bugs: the Installed Extensions list redrew awkwardly,
|
||||
flashing content (0001238); entering full screen mode could leave the Find
|
||||
dialog stranded behind (0001252); save panels from the Welcome window were
|
||||
not sufficiently explanatory (0001273); clicking on extension names to
|
||||
bring up their documentation worked badly (0001237); unchecking the "bind up
|
||||
into a Blorb file on release" option on the Settings pane had no effect
|
||||
(0001306); Inform crashed on launch under Snow Leopard (0001271); IFIDs
|
||||
were not persistent, defeating their purpose (0001278); headings at the
|
||||
top of the source text were not correctly rendered on screen (0001331).
|
||||
These are all fixed.
|
||||
|
||||
3 (b). Inform for Windows
|
||||
|
||||
A new option, "Generate Inform 6 debugging information", has been added to the
|
||||
preferences dialog. This option controls whether the command line used to run
|
||||
Inform 6 specifies that the debugging output file should be created, and
|
||||
defaults to "off".
|
||||
|
||||
The Extensions tab is now implemented, providing access to the Public Library.
|
||||
|
||||
"Create new project" buttons are present in the documentation, next to example
|
||||
projects.
|
||||
|
||||
The elastic tab-stops option is now "Auto-space table columns" in the
|
||||
preferences dialog, to match better how things work on OS X.
|
||||
|
||||
Bugs 0000210 and 0001362 have been fixed.
|
||||
|
||||
3 (c). Inform for Linux
|
||||
|
||||
We would like to thank Vincent Petry, who has helpfully contributed packages
|
||||
for OpenSUSE Linux.
|
||||
|
||||
3 (d). Inform for Command-Line Linux
|
||||
|
||||
TO FOLLOW
|
||||
|
||||
3 (e). Inform for Android
|
||||
|
||||
For the first time, this build of Inform is available for Android:
|
||||
specifically, for Android 2.1 (Eclair) or later.
|
||||
|
||||
|
||||
4. Maintenance
|
||||
|
||||
4 (a). Core Inform maintenance
|
||||
|
||||
Around 100 bug fixes are made in this build, and once again all known issues
|
||||
have been resolved.
|
||||
|
||||
The following lists only the more significant bug fixes: it excludes those
|
||||
categorised by the bug tracker as "cosmetic", mostly small improvements to
|
||||
problem messages, or which affect only the documentation. I'm nevertheless
|
||||
grateful to all those who submitted these bugs, and in particular this build
|
||||
benefits from reports 0001229, 0001234, 0001246, 0001251, 0001259, 0001262,
|
||||
0001263, 0001281, 0001289, 0001295, 0001299, 0001303, 0001308, 0001311,
|
||||
0001316, 0001318, 0001321, 0001324, 0001327, 0001333, 0001334, 0001341,
|
||||
0001342, 0001345, 0001352, 0001388.
|
||||
|
||||
(A special mention to 0001336 and 0001337 for some close proof-reading of the
|
||||
manuals, and another to 0001275 for pointing out that we confused the Swedish
|
||||
country code (SE) with its language code (SV) when putting together icons to
|
||||
indicate the language of play, which resulted in the flag of San Salvador
|
||||
making an appearance.)
|
||||
|
||||
4 (a) 0. Uncategorisable
|
||||
|
||||
Bug fixed (0001339) whereby a really large source text might compile to I6
|
||||
code containing spurious space characters which, with bad luck, might
|
||||
fall in the middle of a keyword and thus cause I6 errors. (This is only
|
||||
ever known to have occurred on a 3.6 million word source.)
|
||||
|
||||
4 (a) 1. Source text and punctuation
|
||||
|
||||
--
|
||||
|
||||
4 (a) 2. Headings
|
||||
|
||||
Bug fixed (0001249) whereby headings with multiple bracketed stipulations
|
||||
|
||||
Section - Fruit (for use with Locksmith by Emily Short) (not for release) (for Glulx only)
|
||||
|
||||
would produce spurious problem messages.
|
||||
|
||||
4 (a) 3. Extensions
|
||||
|
||||
--
|
||||
|
||||
4 (a) 4. Assertions and creations
|
||||
|
||||
Bug fixed (0001309) whereby assertions to set rule responses would be
|
||||
misread if the rule names included the word "with" or "having".
|
||||
|
||||
Bug fixed (0001247) whereby assertions moving rules in rulebooks would
|
||||
sometimes be misread if the rule or rulebook names included the word "in".
|
||||
|
||||
Bug fixed (0001373) whereby "The Attic is above the Parlor" would work,
|
||||
but "The Attic is a room above the Parlor" would make a connection
|
||||
the wrong way (up from the Attic to the Parlor rather than vice versa).
|
||||
|
||||
Bug fixed (0001290) whereby some attempts to make map connections to
|
||||
constant values which aren't objects would be ignored (which is fair
|
||||
enough) but with no problem message (which isn't).
|
||||
|
||||
Bug fixed (0001260) whereby an oddly-phrased sentence such as
|
||||
|
||||
X with the printed name "Cross" is a thing.
|
||||
|
||||
would be read even more oddly as a declaration that all things have
|
||||
this printed name.
|
||||
|
||||
Bug fixed (0001361) whereby the assertion "X is on top of Y" would sometimes
|
||||
be read as "X is on (top of Y)".
|
||||
|
||||
4 (a) 5. Model world
|
||||
|
||||
Bug fixed (0001292) whereby the reaching inside/outside rules would not
|
||||
properly set the "person reaching" variable if the test were run
|
||||
other than via an action.
|
||||
|
||||
Bug fixed (0001363) whereby "the direction of D from R" would produce
|
||||
a bogus result for a one-sided door.
|
||||
|
||||
Bug fixed (0001243) whereby making scenery parts of a person would lead to
|
||||
a strangely worded problem message.
|
||||
|
||||
Bug fixed (0001359) whereby the text substitution "[the player's surroundings]"
|
||||
would produce empty text before play begins.
|
||||
|
||||
4 (a) 6. Properties
|
||||
|
||||
Bug fixed (0001228) whereby attempts to refer to an impossible property
|
||||
of an object (a property, that is, which can only belong to an object
|
||||
of a different kind) would not always be caught at compile time.
|
||||
|
||||
4 (a) 7. Relations
|
||||
|
||||
Bug fixed (0001364) whereby a relation defined by a condition involving a test which,
|
||||
to resolve, would require the expansion of a text substitution, would
|
||||
fail with an internal error. (Such a relation is quite legal and now
|
||||
compiles properly.)
|
||||
|
||||
Bug fixed (0001285) whereby route-finding through a various-to-one relation
|
||||
would fail to work in some configurations of the relationship. (That's
|
||||
probably being generous - when it did work, that was mostly luck.)
|
||||
|
||||
4 (a) 8. Actions
|
||||
|
||||
--
|
||||
|
||||
4 (a) 9. Activities
|
||||
|
||||
--
|
||||
|
||||
4 (a) 10. Rules and rulebooks
|
||||
|
||||
Bug fixed (0001329) whereby a condition limiting the applicability of a rule
|
||||
might not be properly type-checked, causing internal errors in some cases.
|
||||
|
||||
Bug fixed (0001280) whereby an attempt to put just a "value" into a rule's
|
||||
preamble would cause an unclear problem message.
|
||||
|
||||
Bug fixed (0001323) whereby rules such as...
|
||||
|
||||
Before doing something other than listening to or examining the creature:
|
||||
|
||||
...would be misunderstood as (listening) to (or examining the creature)
|
||||
rather than (listening to or examining) (the creature).
|
||||
|
||||
Bug fixed (0001296) whereby
|
||||
|
||||
[1] Instead of taking the rock or looking: ...
|
||||
[2] Instead of looking or taking the rock: ...
|
||||
|
||||
[1] was reported as a problem (the actions can't mix because "looking"
|
||||
can't apply to the rock), but [2] wasn't. To avoid ambiguities, both
|
||||
forms are illegal.
|
||||
|
||||
Problem message improved (0001389) for getting the 'for...' and 'when...'
|
||||
clauses attached to a rule about actions in the wrong order.
|
||||
|
||||
Bug fixed (0001328) whereby rules based on a parameter which happens to
|
||||
end with the word "rule" would sometimes have the parameter ignored,
|
||||
making them more widely applicable than intended.
|
||||
|
||||
4 (a) 11. Lists
|
||||
|
||||
Bug fixed (0001387) whereby Inform wasn't preventing constant lists or
|
||||
texts from being modified using text replacement, list sorting and
|
||||
so forth. All such attempts now result in problem messages.
|
||||
|
||||
4 (a) 12. Tables
|
||||
|
||||
Bug fixed (0001322, 0001338) whereby creating objects via a table which contained
|
||||
additional blank rows would generate spurious I6 errors.
|
||||
|
||||
Bug fixed (0001360) whereby attempting to access a table row, where no row
|
||||
was selected, could cause TableLookUpEntry() to crash at run time. There's
|
||||
now a run-time problem message instead.
|
||||
|
||||
Bug fixed (0001255) whereby looking up texts, lists, etc., in a table which
|
||||
contained a blank row before the match would sometimes cause memory
|
||||
out of range crashes at run time.
|
||||
|
||||
Bug fixed (0001250) whereby it was possible to create the same column in
|
||||
two different tables with different kinds, provided that both columns
|
||||
started out empty; this resulted in mysterious type-checking problem
|
||||
messages.
|
||||
|
||||
Bug fixed (0001390) whereby attempting to read a blank entry of a table as
|
||||
if it held a value would throw a run-time problem (as it should) but
|
||||
then also in some circumstances crash the virtual machine.
|
||||
|
||||
4 (a) 13. Scenes
|
||||
|
||||
--
|
||||
|
||||
4 (a) 14. Kinds and typechecking
|
||||
|
||||
--
|
||||
|
||||
4 (a) 15. Phrases and functional programming
|
||||
|
||||
--
|
||||
|
||||
4 (a) 16. Equations, units and arithmetic
|
||||
|
||||
Bug fixed (0001302) whereby real-valued constants of some kinds, notably
|
||||
those defined by the Metric Units extension, couldn't be written with
|
||||
a minus sign.
|
||||
|
||||
Bug fixed (0001268) whereby local variables were not being promoted implicitly
|
||||
from "number" to "real number" when used in an equation. (The documentation
|
||||
half-promised that this would happen; well, now it does.)
|
||||
|
||||
Bug fixed (0001310) whereby comparisons between values of a kind other than
|
||||
"real number", but nevertheless stored as floating-point quantities,
|
||||
would wrongly be made using integer comparisons.
|
||||
|
||||
Bug fixed (0001257) whereby comparisons between real numbers and numbers
|
||||
would not always implicitly promote the numbers to reals before making
|
||||
the comparison.
|
||||
|
||||
4 (a) 17. Understanding
|
||||
|
||||
Bug fixed (0001369) whereby a declaration of "Understand... as a mistake",
|
||||
with no error message text supplied, would sometimes crash Inform.
|
||||
|
||||
Bug fixed (0001265) whereby an "Understand... when..." condition would
|
||||
throw a problem about referring to the current action even when it
|
||||
in fact tested whether actions had taken place in the past.
|
||||
|
||||
Bug fixed (0001313) whereby a runtime error is thrown when the player's
|
||||
command is matched against the text "me", which doesn't qualify,
|
||||
on early turns only.
|
||||
|
||||
Bug fixed (0001325) whereby the Understand token "[any K]", where K is
|
||||
a kind of value but not a kind of object, could sometimes produce
|
||||
an internal error.
|
||||
|
||||
Bug fixed (0001301) whereby single-letter elements of literal patterns
|
||||
would fail to parse at the command line under Glulx if written in
|
||||
upper case. (Thus a command such as "heat the water by 5c" would work,
|
||||
but not "heat the water by 5C".) Note that this only affected commands
|
||||
typed by hand, because the TEST command flattens to lower case
|
||||
automatically.
|
||||
|
||||
4 (a) 18. Glulx issues, file I/O, figures, sounds
|
||||
|
||||
--
|
||||
|
||||
4 (a) 19. I6 template layer and inclusions
|
||||
|
||||
--
|
||||
|
||||
4 (a) 20. Text, spacing and printing
|
||||
|
||||
Bug fixed (0001242) whereby "blouse" and its derivations pluralized as
|
||||
"blmice", not "blouses".
|
||||
|
||||
Bug fixed (0001231, but see also 0001396) whereby the text substitution "[A
|
||||
list of...]" would only capitalise the first word of the output if it were an
|
||||
article, so for example it could produce "four gold coins" rather than "Four
|
||||
gold coins". And similarly for "[The list of...]", which could be fooled by
|
||||
proper nouns in lower case.
|
||||
|
||||
Bug fixed (0001258) whereby printing unusual indefinite articles using the
|
||||
"[A ...]" text substitution would produce a "library error 2" at
|
||||
run-time.
|
||||
|
||||
Bug fixed (0001319) whereby a text substitution defined with a slash to
|
||||
indicate alternate phrasings on the opening word would lose its case
|
||||
sensitivity.
|
||||
|
||||
Bug fixed (0001291) whereby string comparisons in the background would cause
|
||||
"[first time]..." text substitutions to behave unexpectedly when used
|
||||
in certain properties of rooms or things.
|
||||
|
||||
Bug fixed (0001370) whereby the string "[one of]..." compares as equal to the
|
||||
empty text "" before being first printed, even if it's never possible for
|
||||
it to be empty. For comparison purposes, it now is equal to the text
|
||||
value it will have when next printed.
|
||||
|
||||
Bug fixed (0001368) whereby spurious line breaks would sometimes appear in
|
||||
room descriptions including paragraphs arising from "writing a paragraph
|
||||
about" rules.
|
||||
|
||||
Bug fixed (0001365) whereby grouping items under a given text would not
|
||||
always work if that text included substitutions. It now does, and
|
||||
automatically performs the substitution at grouping time.
|
||||
|
||||
Bug fixed (0001344) whereby two oddball cases in the list-writer printed
|
||||
a close round bracket ")" directly, rather than printing it with the
|
||||
list writer internal rule response (B).
|
||||
|
||||
Bug fixed (0001283) whereby the past tenses of regular English verbs ending
|
||||
-ay, -ey or -oy were incorrect: thus play was plaied, annoy was annoied,
|
||||
and so forth.
|
||||
|
||||
Bug fixed (0001396) to do with capitalising "ÿ" in the Z-machine (Queensrÿche
|
||||
fans, beware).
|
||||
|
||||
4 (a) 21. Indexing
|
||||
|
||||
Bug fixed (0001300) whereby the text "This text is not actually used" is
|
||||
actually used in the Actions detail view.
|
||||
|
||||
Bug fixed (0001335) whereby the adjective "substituted" was wrongly defined
|
||||
in the Lexicon index.
|
||||
|
||||
Bug fixed (0001332) whereby the Contents index was miscounting the number of
|
||||
words under some headings.
|
||||
|
||||
4 (a) 22. Testing commands
|
||||
|
||||
Bug fixed (0001256) whereby the RESPONSES testing command would list responses
|
||||
from some extensions in more than one numbered chunk.
|
||||
|
||||
Bug fixed (0001236) whereby run-time problem messages would sometimes be
|
||||
hidden on screen if they occurred during the expansion of a text
|
||||
substitution.
|
||||
|
||||
4 (a) 23. Releasing, bibliographic data, and cBlorb
|
||||
|
||||
Bug fixed (0001293) to make HTML generated by cBlorb slightly better
|
||||
at passing validators.
|
||||
|
||||
Bug fixed (0001253) whereby releasing along with the "introductory booklet"
|
||||
or "introductory postcard" had stopped working.
|
||||
|
||||
4 (b). Extension maintenance
|
||||
|
||||
Glulx Text Effects by Emily Short (now maintained by Dannii Willis) has been
|
||||
updated to give comprehensive support for all Glk text features, and to
|
||||
simplify how colours are set, by using web (CSS) colours like #8800FF.
|
||||
See the extension documentation for more details. An issue to do with
|
||||
deprecated phrases in the examples has been resolved (see 0001367).
|
||||
This update is not fully backwards compatible, but any changes will be
|
||||
easy to make.
|
||||
|
||||
Metric Units: removed documentation references to the limitations which
|
||||
existed before we switched to floating-point arithmetic in 6L02.
|
||||
|
||||
Epistemology by Eric Eve: Updated to version 8. This fixes a bug (which has
|
||||
oddly only just come to light after all this time, unless it’s a by-product of
|
||||
6L02) by which backdrops weren’t being marked as seen. It also adds an (A) to
|
||||
label the response of the report epistemic status rule.
|
||||
|
||||
4 (c). Examples maintenance
|
||||
|
||||
Examples in the documentation which contained ampersands now paste correctly
|
||||
into the source panel (see 0001312).
|
||||
|
||||
Small revisions have been made to the examples Lethal Concentration 1 and 2
|
||||
(see 0001341), Persephone (see 0001346), Terror of the Sierra Madre (0001340),
|
||||
Olfactory Settings (see 0001305).
|
||||
|
||||
The example "Lollipop Guild" has been rewritten to demonstrate removing
|
||||
implicit takes from a different action (since eating no longer mandates
|
||||
these); and it is more dentist-friendly into the bargain.
|
||||
|
||||
The tiny example "We" has been removed: responses and adaptive text have
|
||||
overtaken it (see 0001245).
|
||||
|
||||
The example "Greater Variety" has been renamed "Variety 2" to emphasise its
|
||||
sequelness (see 0001284).
|
||||
|
||||
4 (d). Interpreter maintenance
|
||||
|
||||
Inform comes with browser interpreters built in, so that it can act on release
|
||||
instructions such as "Release along with an interpreter.", which tell Inform
|
||||
to make a website in which the current story is immediately playable.
|
||||
|
||||
Parchment, Quixe and Vorple, all included by default, are unchanged from
|
||||
their 6L02 versions.
|
1067
Changes/Change Logs/6M62.txt
Normal file
1067
Changes/Change Logs/6M62.txt
Normal file
File diff suppressed because it is too large
Load diff
16
Changes/Change Logs/NEXT.txt
Normal file
16
Changes/Change Logs/NEXT.txt
Normal file
|
@ -0,0 +1,16 @@
|
|||
Inform build 6M62 (14 December 2015)
|
||||
|
||||
Command line: -log=X is now -log X
|
||||
|
||||
Limit on quoted text length raised to 8K
|
||||
|
||||
Limit on object name length removed
|
||||
|
||||
Options.txt now encoded as UTF-8, not ISO Latin-1
|
||||
|
||||
Adjective grading improved:
|
||||
big -> bigger, biggest
|
||||
And "long" to "length"
|
||||
|
||||
In text substitutions, a local variable name is preferred over an adaptive
|
||||
verb; e.g. if "index" is both.
|
BIN
Changes/Changes to Inform.epub
Normal file
BIN
Changes/Changes to Inform.epub
Normal file
Binary file not shown.
3563
Changes/Changes to Inform.txt
Normal file
3563
Changes/Changes to Inform.txt
Normal file
File diff suppressed because it is too large
Load diff
65
Changes/indoc-instructions.txt
Normal file
65
Changes/indoc-instructions.txt
Normal file
|
@ -0,0 +1,65 @@
|
|||
volume: Changes to Inform
|
||||
images: Imagery/doc_images/
|
||||
cover: changes_cover.png
|
||||
|
||||
dc:title: Changes to Inform
|
||||
dc:creator: Graham Nelson and Emily Short
|
||||
dc:subject: Interactive Fiction
|
||||
dc:identifier: inform-changes
|
||||
|
||||
contents_expandable = yes
|
||||
treat_code_as_verbatim = no
|
||||
inform_definitions_mode = yes
|
||||
alphabetization = word-by-word
|
||||
|
||||
css: p.quoted + {
|
||||
font-family: "Lucida Grande", Geneva, Arial, Tahoma, Verdana, Helvetica, Helv;
|
||||
}
|
||||
|
||||
css: td.midnightrighthalfpage ++ {
|
||||
background-color: #ffffe5;
|
||||
}
|
||||
|
||||
css: <i>text</i> = italic
|
||||
css: <b>text</b> = boldface
|
||||
|
||||
css: body.paper ++ {
|
||||
overflow-y: visible;
|
||||
}
|
||||
|
||||
ebook {
|
||||
granularity = 2
|
||||
examples_mode = open
|
||||
navigation = unsigned
|
||||
}
|
||||
|
||||
test {
|
||||
# test HTML for the I7 website
|
||||
format = HTML
|
||||
navigation = midnight
|
||||
examples_mode = openable
|
||||
images_copy = yes
|
||||
}
|
||||
|
||||
website {
|
||||
# HTML for the I7 website
|
||||
destination = Website/content/learn/man/
|
||||
images_copy = no
|
||||
examples_mode = openable
|
||||
# examples_mode = external
|
||||
# top_and_tail = Website/models/www-inform7-com-model.html
|
||||
# top_and_tail_sections = Website/models/www-inform7-com-model.html
|
||||
}
|
||||
|
||||
html_for_chm {
|
||||
# Minimally tagged HTML for CHM
|
||||
html_light = yes
|
||||
destination = Website/content/learn/man/Inform-manuals/
|
||||
top_and_tail = Website/models/HTMLModel.html
|
||||
top_and_tail_sections = Website/models/HTMLModel.html
|
||||
}
|
||||
|
||||
plain {
|
||||
# Plain text for screenreaders
|
||||
destination = Website/content/learn/man/ChangesToInform.txt
|
||||
}
|
25
Documentation/Advice/AdviceCredits.html
Normal file
25
Documentation/Advice/AdviceCredits.html
Normal file
|
@ -0,0 +1,25 @@
|
|||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
|
||||
<link href="indoc_WI.css" rel="stylesheet" type="text/css" />
|
||||
<title>Credits</title>
|
||||
</head>
|
||||
<body class="paper papertint">
|
||||
<!-- START IGNORE -->
|
||||
<p class="sectionheading">Credits</p>
|
||||
<p>Inform is a team effort kept alive by the enthusiasm of a community of writers.<br><br>
|
||||
|
||||
The core software is by Graham Nelson, and the Examples and much of the design by Emily Short, with advice from Andrew Plotkin and others.<br><br>
|
||||
|
||||
The Mac OS X application was originally written by Andrew Hunter, and was rewritten in 2014 by Toby Nelson, building on Andrew's foundations. Corresponding apps for Windows and Linux are by David Kinder and Philip Chimento, and command-line tools for Linux, on a variety of processors, are maintained by Adam Thornton. David also maintains the Inform 6 code base, now used as a code-generator within Inform 7.<br><br>
|
||||
|
||||
The two virtual machines underlying Inform are the Z-machine, designed by Joel Berez, Marc Blank, Dave Lebling and others (and originally called the ZIP), and Glulx, a successor in the same general spirit, which was designed by Andrew Plotkin.<br><br>
|
||||
|
||||
Many people have generously shared their Extensions to Inform, and they're credited individually. But special thanks are due to Erik Temple, Dannii Willis, Aaron Reed, Ron Newcomb, Eric Eve and Juhana Leinonen for putting together the core of the Public Library. Mark Musante has been a tireless librarian of the extensions, and Justin de Vesine a great help in organising our forum.<br><br>
|
||||
|
||||
Literally thousands of people have filed bug reports or suggestions over the years. If you're one of them, sincere thanks to YOUR NAME HERE. Inform would never have got this far without you.
|
||||
</p>
|
||||
<!-- END IGNORE -->
|
||||
</body>
|
||||
</html>
|
129
Documentation/Advice/AdviceKeyboardShortcuts.html
Normal file
129
Documentation/Advice/AdviceKeyboardShortcuts.html
Normal file
|
@ -0,0 +1,129 @@
|
|||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
|
||||
<link href="indoc_WI.css" rel="stylesheet" type="text/css" />
|
||||
<style type="text/css">
|
||||
th,td
|
||||
{
|
||||
text-align: left;
|
||||
font-size: 80%;
|
||||
padding: 0px;
|
||||
}
|
||||
table
|
||||
{
|
||||
border-spacing:16px 0px;
|
||||
}
|
||||
</style>
|
||||
<title>Keyboard Shortcuts</title>
|
||||
</head>
|
||||
<body class="paper papertint">
|
||||
|
||||
<!-- START IGNORE -->
|
||||
<p class="sectionheading">Keyboard Shortcuts</p>
|
||||
|
||||
<table>
|
||||
<tr><td>⌘L</td><td>Summon/Dismiss Launcher</td></tr>
|
||||
|
||||
<tr><td colspan=2> </td></tr>
|
||||
<tr><th colspan=2>Projects</th></tr>
|
||||
<tr><td>⌘O</td><td>Open...</td></tr>
|
||||
<tr><td>⌘N</td><td>New Project</td></tr>
|
||||
<tr><td>⌘W</td><td>Close Project</td></tr>
|
||||
<tr><td>⌘R</td><td>Go</td></tr>
|
||||
<tr><td>⌥⌘R</td><td>Replay</td></tr>
|
||||
<tr><td>⇧⌘R</td><td>Release</td></tr>
|
||||
<tr><td>⌃⌥⌘T</td><td>Go and then type "Test Me"</td></tr>
|
||||
<tr><td>⌘I</td><td>Refresh Index</td></tr>
|
||||
<tr><td>⌘M</td><td>Open Materials Folder in Finder</td></tr>
|
||||
|
||||
<tr><td colspan=2> </td></tr>
|
||||
<tr><th colspan=2>Switching Panes</th></tr>
|
||||
<tr><td>⌘1</td><td>Go to Left Pane</td></tr>
|
||||
<tr><td>⌘2</td><td>Go to Right Pane</td></tr>
|
||||
<tr><td>⌥⌘⇥</td><td>Switch Panes</td></tr>
|
||||
<tr><td>F1</td><td>Source</td></tr>
|
||||
<tr><td>F2</td><td>Results</td></tr>
|
||||
<tr><td>F3</td><td>Index</td></tr>
|
||||
<tr><td>⌘3</td><td>Index: Welcome Page</td></tr>
|
||||
<tr><td>⌘4</td><td>Index: Contents Page</td></tr>
|
||||
<tr><td>⌘5</td><td>Index: Actions Page</td></tr>
|
||||
<tr><td>⌘6</td><td>Index: Kinds Page</td></tr>
|
||||
<tr><td>⌘7</td><td>Index: Phrasebook Page</td></tr>
|
||||
<tr><td>⌘8</td><td>Index: Rules Page</td></tr>
|
||||
<tr><td>⌘9</td><td>Index: Scenes Page</td></tr>
|
||||
<tr><td>⌘0</td><td>Index: World Page</td></tr>
|
||||
<tr><td>F4</td><td>Skein</td></tr>
|
||||
<tr><td>F5</td><td>Transcript</td></tr>
|
||||
<tr><td>F6</td><td>Story</td></tr>
|
||||
<tr><td>F7</td><td>Documentation</td></tr>
|
||||
<tr><td>F8</td><td>Extensions</td></tr>
|
||||
<tr><td>F13</td><td>Settings</td></tr>
|
||||
|
||||
<tr><td colspan=2> </td></tr>
|
||||
<tr><th colspan=2>Within the Source Pane</th></tr>
|
||||
<tr><td>⇧⌘H</td><td>Show Headings</td></tr>
|
||||
<tr><td>⌥⌘.</td><td>Show Only This Section in Source</td></tr>
|
||||
<tr><td>⌘></td><td>Show More Sections in Source</td></tr>
|
||||
<tr><td>⌘<</td><td>Show Fewer Sections in Source</td></tr>
|
||||
<tr><td>⌥⌘,</td><td>Show Entire Source</td></tr>
|
||||
<tr><td>⌘⇞</td><td>Shift View to Previous Section</td></tr>
|
||||
<tr><td>⌘⇟</td><td>Shift View to Next Section</td></tr>
|
||||
<tr><td>⌥⌘N</td><td>Renumber All Sections</td></tr>
|
||||
|
||||
<tr><td colspan=2> </td></tr>
|
||||
<tr><th colspan=2>Editing the Source</th></tr>
|
||||
<tr><td>⌘C</td><td>Copy</td></tr>
|
||||
<tr><td>⌘V</td><td>Paste</td></tr>
|
||||
<tr><td>⌘X</td><td>Cut</td></tr>
|
||||
<tr><td>⌘Z</td><td>Undo</td></tr>
|
||||
<tr><td>⇧⌘Z</td><td>Redo</td></tr>
|
||||
<tr><td colspan=2> </td></tr>
|
||||
<tr><td>⌘A</td><td>Select All</td></tr>
|
||||
<tr><td>⌘]</td><td>Shift Selection Right</td></tr>
|
||||
<tr><td>⌘[</td><td>Shift Selection Left</td></tr>
|
||||
<tr><td>⌘/</td><td>Comment Out Selection</td></tr>
|
||||
<tr><td>⌥⌘/</td><td>Uncomment Selection</td></tr>
|
||||
<tr><td colspan=2> </td></tr>
|
||||
<tr><td>⌘:</td><td>Show Spelling and Grammar</td></tr>
|
||||
<tr><td>⌘;</td><td>Check Spelling</td></tr>
|
||||
|
||||
<tr><td colspan=2> </td></tr>
|
||||
<tr><th colspan=2>Find</th></tr>
|
||||
<tr><td>⌘E</td><td>Find Selected Text</td></tr>
|
||||
<tr><td>⌘F</td><td>Find...</td></tr>
|
||||
<tr><td>⇧⌘F</td><td>Find In Files...</td></tr>
|
||||
<tr><td>⌘G</td><td>Find Next</td></tr>
|
||||
<tr><td>⇧⌘G</td><td>Find Previous</td></tr>
|
||||
<tr><td>⌘J</td><td>Scroll To Selection</td></tr>
|
||||
|
||||
<tr><td colspan=2> </td></tr>
|
||||
<tr><th colspan=2>Skein and Transcript</th></tr>
|
||||
<tr><td>⌃⌥⌘R</td><td>Replay Commands Blessed In Transcript</td></tr>
|
||||
<tr><td>⌥⌘L</td><td>Show Last Command In Transcript</td></tr>
|
||||
<tr><td>⇧⌘L</td><td>Show Last Command In Skein</td></tr>
|
||||
<tr><td>⌥⌘↑</td><td>Find Previous Changed Command</td></tr>
|
||||
<tr><td>⌥⌘↓</td><td>Find Next Changed Command</td></tr>
|
||||
<tr><td>⌃⌘↑</td><td>Find Previous Difference</td></tr>
|
||||
<tr><td>⌃⌘↓</td><td>Find Next Difference</td></tr>
|
||||
<tr><td>⌃⌥⌘↓</td><td>Show Next Difference</td></tr>
|
||||
|
||||
<tr><td colspan=2> </td></tr>
|
||||
<tr><th colspan=2>Application Control</th></tr>
|
||||
|
||||
<tr><td>⌘,</td><td>(Inform) Preferences</td></tr>
|
||||
<tr><td>⌘H</td><td>Hide Inform</td></tr>
|
||||
<tr><td>⌥⌘H</td><td>Hide Others</td></tr>
|
||||
<tr><td>⌥⌘M</td><td>Minimize Window</td></tr>
|
||||
<tr><td>⌘S</td><td>Save</td></tr>
|
||||
<tr><td>⇧⌘S</td><td>Save As...</td></tr>
|
||||
<tr><td>⌘P</td><td>Print</td></tr>
|
||||
<tr><td>⇧⌘P</td><td>Page Setup</td></tr>
|
||||
<tr><td>⌘Q</td><td>Quit</td></tr>
|
||||
|
||||
</td></tr>
|
||||
</table>
|
||||
|
||||
<!-- END IGNORE -->
|
||||
</body>
|
||||
</html>
|
60
Documentation/Advice/AdviceMaterialsFolder.html
Normal file
60
Documentation/Advice/AdviceMaterialsFolder.html
Normal file
|
@ -0,0 +1,60 @@
|
|||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
|
||||
<link href="indoc_WI.css" rel="stylesheet" type="text/css" />
|
||||
<style type="text/css">
|
||||
.red
|
||||
{
|
||||
color:rgb(255,0,0);
|
||||
}
|
||||
</style>
|
||||
<title>Materials Folder</title>
|
||||
</head>
|
||||
<body class="paper papertint">
|
||||
<!-- START IGNORE -->
|
||||
<p class="sectionheading">Materials Folder</p>
|
||||
<p>Every project has a ".materials" folder, which is always stored next to it on disc. (Use ⌘M to show the current project's .materials in the Finder.) This screenshot shows how the .materials folder would look for a project which used it in every possible way. In practice, this is very unlikely.</p>
|
||||
|
||||
<img src="MaterialsDiagram.png" width="275" height="403"/>
|
||||
|
||||
<p>Project (<span class="red">1</span>) and .materials folder (<span class="red">2</span>) live side by side in the Finder: everything else here is inside .materials (<span class="red">2</span>). The author of this story decided that it should be given to players along with a PDF booklet (<span class="red">3</span>), by including this Release instruction in the source text:
|
||||
|
||||
<blockquote class="code"><p class="quoted">
|
||||
Release along with a file of "A Guide to Arboreal Fauna" called "A Guide to Arboreal Fauna.pdf".
|
||||
</p></blockquote>
|
||||
|
||||
<p>Every released project needs cover art. Authors have to provide two files, full-sized at 960 by 960 (<span class="red">4</span>) and reduced at 120 by 120 (<span class="red">18</span>): they can either be "Cover.jpg" and "Small Cover.jpg" or "Cover.png" and "Small Cover.png".</p>
|
||||
|
||||
<p>Extensions to Inform are usually centrally installed, and available to all projects. But this project has its own private copy of "Feeding Squirrels by Emily Short" (<span class="red">7</span>), in its own private Extensions folder (<span class="red">5</span>). This would override any installed copy of the same extension. It has to have the correct name and .i7x ending, and it has to live inside a folder with its author's name (<span class="red">6</span>).</p>
|
||||
|
||||
<p>Projects which include pictures as well as text need to store the necessary images, in JPEG or PNG format, in the Figures folder (<span class="red">8</span>). This one was declared in the source text like so:</p>
|
||||
|
||||
<blockquote class="code"><p class="quoted">
|
||||
Figure of Red Admiral Butterfly is the file "butterfly.jpg".
|
||||
</p></blockquote>
|
||||
|
||||
<p>Sound effects are similar, use AIFF or OGG format, and live in Sounds (<span class="red">19</span>). There's one here (<span class="red">20</span>), declared by:</p>
|
||||
|
||||
<blockquote class="code"><p class="quoted">
|
||||
Sound of Rustling Leaves is the file "Rustling Leaves.aiff".
|
||||
</p></blockquote>
|
||||
|
||||
<p>Projects which read or write files of data as they play should have a Files folder (<span class="red">10</span>) to hold these. This one (<span class="red">11</span>) was declared by:
|
||||
|
||||
<blockquote class="code"><p class="quoted">
|
||||
The File of Nut Storage Locations is called "nutstorage".
|
||||
</p></blockquote>
|
||||
|
||||
<p>Now for some expert-only features which hardly anybody needs in practice. The I6T folder (<span class="red">12</span>) provides extra template files (<span class="red">13</span>), or indeed replacement ones (<span class="red">14</span>), and allows a project to include substantial portions of raw Inform 6 code. The Languages folder (<span class="red">16</span>) is for experimenting with new language bundles, a 2014 feature still in its early stages. The Templates folder (<span class="red">21</span>) is for providing the project with a non-standard Javascript engine, called an "interpreter", when it's released as a website. Here there's an intepreter called "Experimental" (<span class="red">22</span>) which can be selected by putting this into the source:</p>
|
||||
|
||||
<blockquote class="code"><p class="quoted">
|
||||
Release along with the "Experimental" interpreter.
|
||||
</p></blockquote>
|
||||
|
||||
<p>And that just leaves the Release folder (<span class="red">17</span>). Inform creates this automatically if the project's Release button is clicked, and then writes into it whatever will eventually go out to players. So never store anything permanent here: it's intended to be just a holding area.
|
||||
</p>
|
||||
|
||||
<!-- END IGNORE -->
|
||||
</body>
|
||||
</html>
|
30
Documentation/Advice/AdviceNewToInform.html
Normal file
30
Documentation/Advice/AdviceNewToInform.html
Normal file
|
@ -0,0 +1,30 @@
|
|||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
|
||||
<link href="indoc_WI.css" rel="stylesheet" type="text/css" />
|
||||
<title>New To Inform?</title>
|
||||
</head>
|
||||
<body class="paper papertint">
|
||||
<!-- START IGNORE -->
|
||||
<p class="sectionheading">New To Inform?</p>
|
||||
<p>Inform is both an application and a language for creating text-based interactive stories. Interactive fiction is an art form which evolved out of the adventure games of the 1970s, in the same way that today's graphic novels evolved out of the newspaper cartoons of the 1930s. Inform has been the design tool of choice for many, indeed most, of the world's leading writers in this genre since 1993, and is also widely used in education at a variety of levels. It's completely free, even when used to create commercial works. Thanks for downloading this copy, and we hope you'll enjoy it.</p>
|
||||
|
||||
<p>As you've seen, the app begins with a launcher panel. (Bring it back or remove it by typing ⌘L.) You might like to try clicking Onyx, the smallest of the samples, under the "Open a Sample Project" list: it's a very short Russian folk-tale. Inform will ask you to choose somewhere on disc to store it, and then make a copy there. You can play with this and alter it freely, then throw it away when you're done: it's just a copy.</p>
|
||||
|
||||
<p>You can have several Inform projects open at once, but each one lives in a single window which is divided in half. The left and right sides are called "panes" and you can choose what's shown in them with the side tabs: it starts out as Source on the left, Documentation on the right. (From the Launcher, you can also save out a copy of the documentation as an EPUB file to read in iBooks on Mac OS 10.9 or later, or on an iPad.)</p>
|
||||
|
||||
<p>Inform "translates" the instructions in the Source into a playable story. To see that in action, click the Go button for the Onyx project. You'll have to wait just a moment - an Inform project is a surprisingly complicated thing to make, even when the instructions look short - but then the Story pane will open, and you can type in commands as if you were the player. If you're not sure what to type, try </p>
|
||||
|
||||
<blockquote class="code"><p class="quoted">
|
||||
TEST ME
|
||||
</p></blockquote>
|
||||
|
||||
<p>which makes it show what it can do.</p>
|
||||
|
||||
<p>The Launcher also offers a larger sample project called "Disenchantment Bay", a story about a boat trip in Alaska. Beyond that, there are around 450 Examples in the Documentation, and by clicking on the "save as project" icon you can get playable versions of all of those, too.</p>
|
||||
|
||||
</p>
|
||||
<!-- END IGNORE -->
|
||||
</body>
|
||||
</html>
|
23
Documentation/Advice/AdviceUpgrading.html
Normal file
23
Documentation/Advice/AdviceUpgrading.html
Normal file
|
@ -0,0 +1,23 @@
|
|||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
|
||||
<link href="indoc_WI.css" rel="stylesheet" type="text/css" />
|
||||
<title>Upgrading?</title>
|
||||
</head>
|
||||
<body class="paper papertint">
|
||||
<!-- START IGNORE -->
|
||||
<p class="sectionheading">Upgrading?</p>
|
||||
<p>If you haven't used the spring 2014 builds of Inform before, much has changed. The Mac OS X application had been considerably enhanced, for one thing, but the changes go deeper than that. Here are just the headlines: for the full story, see the ebook "Changes to Inform", which you can access from the Launcher.</p>
|
||||
|
||||
<p>Firstly: the old "Materials" folder has been renamed ".materials". So if your project is called "Dream.inform" then it's accompanied by "Dream.materials", not "Dream Materials" as before.</p>
|
||||
|
||||
<p>Secondly: the language has much better handling of text, getting rid of "indexed" text entirely, and providing grammatical adaptation - the ability to turn "You go out" automatically into "They went out", for example. There's also real number support with scientific functions (so you can perform physical calculations and have Inform check the dimensions, for example); there are named constants; there's a new ability for projects to have their own private Extensions; and so on.</p>
|
||||
|
||||
<p>Thirdly: a whole pile of phrases which have been deprecated since before 2010 have finally been removed from the language. If you're still using any of those, you'll need to reword - there's advice on this in the Changes book.</p>
|
||||
|
||||
<p>Finally, more than 400 bugs have been fixed, which resolves over 95% of all known issues with Inform.</p>
|
||||
|
||||
<!-- END IGNORE -->
|
||||
</body>
|
||||
</html>
|
707
Documentation/Examples/(Recipes).txt
Normal file
707
Documentation/Examples/(Recipes).txt
Normal file
|
@ -0,0 +1,707 @@
|
|||
Going Going == OMIT
|
||||
Streaming == OMIT
|
||||
Sackcloth == OMIT
|
||||
Polygons == OMIT
|
||||
Winds of Change == OMIT
|
||||
America Stands Tall == OMIT
|
||||
Studious == OMIT
|
||||
Buttons == OMIT
|
||||
Waiting Room == OMIT
|
||||
Tour des Maillots == OMIT
|
||||
Terracotta == OMIT
|
||||
Appraisal == OMIT
|
||||
|
||||
>INTRODUCTION
|
||||
*PREFACE
|
||||
About the examples
|
||||
Basic room, container, and supporter descriptions
|
||||
|
||||
*DISENCHANTMENT BAY
|
||||
1. The charter boat
|
||||
Basic scenery
|
||||
Basic backdrop
|
||||
Basic descriptions
|
||||
Basic door
|
||||
Basic locked container
|
||||
Radar aboard ship
|
||||
Basic pushable object
|
||||
Basic character
|
||||
Basic clothing
|
||||
Basic holdall
|
||||
12. Complete playable scenario
|
||||
|
||||
*INFORMATION ONLY
|
||||
Backus-Naur form for rules
|
||||
Formal syntax of sentences
|
||||
Mathematical view of relations
|
||||
Graph-theory view of relations
|
||||
About Inform's regular expression support
|
||||
|
||||
>ADAPTIVE PROSE
|
||||
*VARYING WHAT IS WRITTEN
|
||||
Random variations within text
|
||||
Phrase to let us say things some number of times
|
||||
Substituting insults and boasts
|
||||
To say rules for insults and boasts
|
||||
Cyclical randomization of named objects
|
||||
Names of objects change with player's diction
|
||||
Say rules for is-are and it/them
|
||||
Saying a number in round numbers
|
||||
Otherwise if demonstrated
|
||||
Exact numbers replaced with vague quantifiers
|
||||
Creating our own text variations rules
|
||||
Filtering text output in room names
|
||||
Paragraphs of flexible descriptions
|
||||
Case change for text produced by to say phrases
|
||||
An example bouquet of flowers
|
||||
Describing ongoing character behavior with participles
|
||||
Describing relations using a random choice of verb
|
||||
Describing action outcomes using a random choice of verb or describing the world state that results
|
||||
Identifying nouns by the last thing done to them
|
||||
Describing action outcomes using a random choice of verb
|
||||
Inventory standard response changed
|
||||
Describing action outcomes using an adaptive random choice of verb
|
||||
Altering response text programmatically
|
||||
|
||||
*VARYING WHAT IS READ
|
||||
Printed names for complex-named objects
|
||||
Kinds given new singular and plural synonyms
|
||||
Understanding names of things, basic
|
||||
Questions asked of the player
|
||||
Handling the nine-character limit
|
||||
Setting pronouns to respond to sudden changes
|
||||
|
||||
*USING THE PLAYER'S INPUT
|
||||
Understanding text
|
||||
Fish of ambiguous species
|
||||
Player's erroneous command recorded for later
|
||||
Pig Latin for the player's commands
|
||||
|
||||
>PLACE
|
||||
*ROOM DESCRIPTIONS
|
||||
Varying room description text
|
||||
Testing the locale description order
|
||||
Levels of lighting
|
||||
Supporters that don't list contents in room descriptions
|
||||
Incorporating changeable objects into the body of the room description
|
||||
LOOK mentions only currently useful objects
|
||||
Room description changes after first visit
|
||||
Room description changes at each of several visits
|
||||
Room description changes after note is read
|
||||
|
||||
*MAP
|
||||
1. A landscape from Jamaica, 1691
|
||||
2. With one-way connections added
|
||||
3. Divided into regions
|
||||
Region off-limits to a player without VIP pass
|
||||
Maze with randomized room links
|
||||
Carousel Room from which exits lead to random locations
|
||||
Exits added to a room
|
||||
Map rearranged as player wanders so he finds rooms in order
|
||||
Compass directions renamed
|
||||
A hexagonal map grid for movement
|
||||
|
||||
*DOORS, STAIRCASES, AND BRIDGES
|
||||
Door described differently depending on where it is
|
||||
Door kind that describes the destination
|
||||
Door described and parsed differently depending on where it is
|
||||
Doors that open automatically
|
||||
An automatically closing door
|
||||
Deadbolted door unlockable without a key on one side
|
||||
Readout showing status of all doors
|
||||
Doors as seen by NPCs
|
||||
Staircase kind of door, always open and unopenable
|
||||
Staircase kind of door which diverts the CLIMB command
|
||||
Plank bridge breaks on being crossed when the player is carrying something
|
||||
|
||||
*POSITION WITHIN ROOMS
|
||||
Rooms with visible exteriors
|
||||
Pushing a box between named internal positions in a room
|
||||
|
||||
*CONTINUOUS SPACES AND THE OUTDOORS
|
||||
Large objects visible from distant rooms
|
||||
Lighthouse whose light can shine in different directions
|
||||
Backdrops which can only be examined
|
||||
LOOK [direction] command
|
||||
Continuous space, simple
|
||||
Continuous space with distant objects visible
|
||||
Continuous space with distant objects visible and automatic room description
|
||||
Signposts to distant rooms
|
||||
|
||||
*WINDOWS
|
||||
Basic window similar to a door
|
||||
Window that can be opaque or transparent
|
||||
Random characters seen through a window
|
||||
Window connecting two rooms
|
||||
Windows in high places
|
||||
|
||||
*LIGHTING
|
||||
Rooms with light effects
|
||||
Light levels variable depending on the number of candles the player has lit
|
||||
Torch understood as flaming or extinguished
|
||||
Basic switchable light for a room
|
||||
Electric light kind of device
|
||||
Shiny items are described as reflecting torchlight
|
||||
Dark rooms given non-standard description
|
||||
Dark room which relies on other senses when light is off
|
||||
Scope approaches compared
|
||||
Light-filled rooms as a route through a space
|
||||
Cloak that makes a room dark
|
||||
|
||||
*SOUNDS
|
||||
Rooms with sounds of nearby water
|
||||
Noisemaking gadgets which can be heard with LISTEN
|
||||
Scope for listening different from scope for seeing
|
||||
|
||||
*PASSERS-BY, WEATHER AND ASTRONOMICAL EVENTS
|
||||
Clouds with random descriptions
|
||||
Randomized pedestrian passer-by
|
||||
Atmospheric background events that occur randomly during a scene
|
||||
Backdrops that move conditionally
|
||||
Cycle of day and night scenes
|
||||
Scheduling an eclipse
|
||||
|
||||
>TIME AND PLOT
|
||||
*THE PASSAGE OF TIME
|
||||
Time told in 24-hour military style
|
||||
Time expressed in units other than minutes
|
||||
Turns take 15 minutes each
|
||||
Turns take a quarter day each
|
||||
Instant EXAMINE and LOOK
|
||||
All actions given different durations
|
||||
Implicit takes require time
|
||||
|
||||
*SCRIPTED SCENES
|
||||
Sequence of background events that plays out in order
|
||||
Triggering a new scene when the player does any of several things
|
||||
Hurrying the player on a specific task
|
||||
Scenes which restrict movement
|
||||
|
||||
*EVENT SCHEDULING
|
||||
Shops open and close at specific hours
|
||||
People who follow a schedule of activities
|
||||
Appointments at future times
|
||||
|
||||
*SCENE CHANGES
|
||||
Moving props on and off-stage as scenes start and end
|
||||
Moving a backdrop during play
|
||||
Scenes with props lists and location properties
|
||||
Commercial break
|
||||
|
||||
*FLASHBACKS
|
||||
Flashback scenes, simple
|
||||
Flashbacks with multiple outcomes
|
||||
|
||||
*PLOT MANAGEMENT
|
||||
Goal-seeking plot manager, simple
|
||||
|
||||
>THE VIEWPOINT CHARACTER
|
||||
*THE HUMAN BODY
|
||||
Disambiguating body parts
|
||||
Height of player affects descriptions
|
||||
Postures for sitting, standing, and lying down
|
||||
|
||||
*TRAITS DETERMINED BY THE PLAYER
|
||||
Name of player character selected at start of play
|
||||
Asking the player to choose a gender
|
||||
Allowing the player to describe his character before starting play
|
||||
|
||||
*CHARACTERIZATION
|
||||
Another, distinct from the player
|
||||
Restrictions preventing inappropriate behavior
|
||||
Examining the player
|
||||
|
||||
*BACKGROUND
|
||||
REMEMBER command keyed to topics
|
||||
FIND command
|
||||
|
||||
*MEMORY AND KNOWLEDGE
|
||||
Characters referred to when absent
|
||||
Box reports whether it has been open
|
||||
Horribly heavy box described differently after being taken
|
||||
Narration which changes as the player learns new facts
|
||||
|
||||
*VIEWPOINT
|
||||
Player controls multiple player-characters in turn
|
||||
Different player characters that see different things
|
||||
Description related to player preconceptions
|
||||
Description varying depending on which avatar the player uses
|
||||
|
||||
>COMMANDS
|
||||
*DESIGNING NEW COMMANDS
|
||||
|
||||
*WRITING NEW COMMANDS
|
||||
|
||||
*MODIFYING EXISTING COMMANDS
|
||||
LOCK and UNLOCK with altered carrying requirements
|
||||
|
||||
*LOOKING
|
||||
Brief descriptions by default
|
||||
Full-length descriptions mandatory
|
||||
|
||||
*EXAMINING
|
||||
EXAMINE always lists contents of containers and supporters
|
||||
Adding to descriptions without using "after examining"
|
||||
You see nothing special... message replaced
|
||||
EXAMINE produces special results for a group of objects
|
||||
Examining everything at once
|
||||
|
||||
*LOOKING UNDER AND HIDING
|
||||
Evidence hidden until item is searched
|
||||
Hiding things under other things
|
||||
LOOK UNDER shows nothing unless the player has a light
|
||||
SEARCH [room] action that opens every visible unlocked container
|
||||
|
||||
*INVENTORY
|
||||
Wide and divided variations on inventory
|
||||
INVENTORY listing with separate carried and worn items
|
||||
INVENTORY handling of properties made more flexible
|
||||
INVENTORY revised for other characters
|
||||
|
||||
*TAKING, DROPPING, INSERTING AND PUTTING
|
||||
Scenery taking with a new message
|
||||
TAKE action reports where the noun came from
|
||||
DROPPING into and onto things
|
||||
DROP applies even to objects the player carries indirectly
|
||||
TAKE prints a description
|
||||
PUT and INSERT automatically TAKE first
|
||||
PUT and INSERT automatically TAKE first even with multiples
|
||||
Object the player can show off without taking it first
|
||||
|
||||
*GOING, PUSHING THINGS IN DIRECTIONS
|
||||
Pushable ball that rolls on its own
|
||||
Exits listed when the player tries a wrong direction
|
||||
Travel to a room described
|
||||
Message on leaving a region
|
||||
Falling into a pit when going from darkness to darkness
|
||||
Travel with a pushed object given a new description
|
||||
First look text added for a newly entered room
|
||||
Traveling by room name rather than compass direction
|
||||
Traveling by room name, opening doors on the way
|
||||
PUSH something A DIRECTION modified
|
||||
GO BACK command
|
||||
GO equivalent to GO OUT
|
||||
GO OUT and GO IN determine most appropriate direction if none is defined
|
||||
GO UP and GO DOWN determined by room altitude
|
||||
|
||||
*ENTERING AND EXITING, SITTING AND STANDING
|
||||
Variety of postures
|
||||
GET DOWN and DOWN understood as EXIT
|
||||
Automatically leaving an object before trying to travel
|
||||
Automatically leaving an object before trying to take it
|
||||
|
||||
*OPENING, CLOSING, LOCKING AND UNLOCKING
|
||||
|
||||
*WAITING, SLEEPING
|
||||
WAIT [number] MINUTES command
|
||||
WAIT UNTIL [time] command
|
||||
Sleep and waking
|
||||
|
||||
*MAGIC WORDS
|
||||
Joke command added
|
||||
|
||||
*ADDITIONAL COMMAND SETS
|
||||
|
||||
*REMEMBERING, CONVERTING AND COMBINING ACTIONS
|
||||
Redirecting actions to new objects
|
||||
ASKing about a conversation topic other than the one the player typed
|
||||
Characters killed off by trigger actions
|
||||
Using lists as sets
|
||||
Maze escaped by performing an exact sequence of actions
|
||||
Device to remember and play back actions
|
||||
|
||||
*ACTIONS ON MULTIPLE OBJECTS
|
||||
EXAMINE multiple things at once
|
||||
Multiple-object actions given modified descriptions
|
||||
Controlling the order in which multiple-object actions occur
|
||||
GIVE extended to multiple objects at once
|
||||
Allowing EXAMINE to see multiple objects with a single command
|
||||
Reordering multiple objects for dramatic effect
|
||||
|
||||
*ALTERNATE DEFAULT MESSAGES
|
||||
|
||||
*CLARIFICATION AND CORRECTION
|
||||
USE action which divines rational behavior for a wide range of possible nouns
|
||||
Disambiguation question giving items more explicit names
|
||||
Disambiguation question worded in a new way entirely
|
||||
Modifying and re-parsing an entered command
|
||||
Parser errors involving the any token
|
||||
|
||||
*ALTERNATIVES TO STANDARD PARSING
|
||||
Adverbs used in commands
|
||||
Keywords in place of ordinary commands
|
||||
Menu of numerical options
|
||||
|
||||
>OTHER CHARACTERS
|
||||
*GETTING ACQUAINTED
|
||||
Characters and objects with titles and special articles
|
||||
Characters renamed in play
|
||||
People changing their titles during play
|
||||
People introduced by relative
|
||||
Relations applying to multiple values of the same kind
|
||||
Murderer chosen randomly at start of play
|
||||
|
||||
*LIVELINESS
|
||||
People who do new things each time the player looks
|
||||
Child who asks if we're there yet
|
||||
Person who picks up treasures
|
||||
Every turn an opponent plays
|
||||
|
||||
*REACTIVE CHARACTERS
|
||||
Actions prohibited in the presence of a dangerous character
|
||||
Disorderly conduct
|
||||
Observation stage after report
|
||||
Smuggler carrying hidden items
|
||||
Sleeping person who can be woken in various ways
|
||||
Person who comments on the player's every action
|
||||
Furniture, resentment of
|
||||
|
||||
*BARTER AND EXCHANGE
|
||||
GIVE command extended
|
||||
GIVE action for other characters
|
||||
|
||||
*COMBAT AND DEATH
|
||||
DIAGNOSE command
|
||||
Simple Randomized Combat
|
||||
Randomized Combat with Weapons
|
||||
Corpses left behind when a character dies
|
||||
Multipart objects broken into components by gun blast
|
||||
Command prompt changing to reflect state of combat
|
||||
|
||||
*GETTING STARTED WITH CONVERSATION
|
||||
People who must be greeted before conversation
|
||||
TALK TO usage corrected
|
||||
|
||||
*SAYING SIMPLE THINGS
|
||||
ASK, TELL, and ANSWER commands rolled into one
|
||||
YES and NO handled as conversation
|
||||
Asking the player a Yes/No question
|
||||
ASK made like SHOW when applied to objects
|
||||
|
||||
*SAYING COMPLICATED THINGS
|
||||
Conversation system with recap of past exchanges
|
||||
Conversation with multiple options for each conversation topic
|
||||
TALK TO command used with scenes
|
||||
Conversation based on keyword recognition
|
||||
|
||||
*CHARACTER EMOTION
|
||||
Gestures for different characters to make during speech
|
||||
Person with emotions about what is said
|
||||
|
||||
*CHARACTER KNOWLEDGE AND REASONING
|
||||
People attempting to detect the murderer
|
||||
Person who answers questions based on a common pool of knowledge
|
||||
Person who answers what, where, and when questions differently
|
||||
Conversation where characters seek logical connection to foregoing topics
|
||||
Hints leading the player through conversation
|
||||
|
||||
*CHARACTERS FOLLOWING A SCRIPT
|
||||
Princess who makes various remarks
|
||||
Robot who records, then replays, the player's actions
|
||||
Robot who tracks up to fifteen separate command scripts
|
||||
Using lists as stacks
|
||||
|
||||
*TRAVELING CHARACTERS
|
||||
Person who moves randomly
|
||||
Person who moves on a pre-determined path
|
||||
Person who finds a path to a destination specified by player
|
||||
FOLLOW command
|
||||
Person who follows the player
|
||||
Multiple people's movements are collated into paragraphs
|
||||
|
||||
*OBEDIENT CHARACTERS
|
||||
People commanded to obey
|
||||
Character who learns new actions by watching the player
|
||||
Person who gets fed up after being asked to do many implausible things
|
||||
People who reject categories of instruction
|
||||
Person who obeys almost all instructions
|
||||
Issuing vague commands to characters
|
||||
ASK person TO do something, understood
|
||||
|
||||
*GOAL-SEEKING CHARACTERS
|
||||
Escape action for non-player characters only
|
||||
Reporting rules for other characters' behavior
|
||||
Person who opens a container before trying to get something from it
|
||||
Person who pursues his own goals each turn
|
||||
|
||||
*SOCIAL GROUPS
|
||||
People who interact with each other each turn
|
||||
People listed as a group, with their possessions afterward
|
||||
Shifting alliances among people
|
||||
Shifting alliances demonstrating all relation types
|
||||
People who move around a party on their own
|
||||
Using lists as queues
|
||||
|
||||
>VEHICLES, ANIMALS AND FURNITURE
|
||||
*BICYCLES, CARS AND BOATS
|
||||
Vehicles that make noise
|
||||
Car which can only be driven on roads
|
||||
Travel requiring a vehicle
|
||||
Description from inside a vehicle
|
||||
|
||||
*SHIPS, TRAINS AND ELEVATORS
|
||||
An elevator operated simply by walking in and out
|
||||
An elevator which takes the player to alternate floors
|
||||
Shipboard directions
|
||||
Train that makes station stops
|
||||
|
||||
*ANIMALS
|
||||
Cat interacting with toys
|
||||
Concealed pet who would yip at you if it could see you
|
||||
Name of a dog set by the player
|
||||
|
||||
*FURNITURE
|
||||
Drawers where thing is always in the last opened
|
||||
Finding the bottom of a pile
|
||||
Chest with a supporting lid
|
||||
Stool, from which dropped objects fall to the floor
|
||||
Raised supporter kind that conceals its contents
|
||||
Basic enterable containers and supporters
|
||||
Using lists as rings
|
||||
|
||||
*KITCHEN AND BATHROOM
|
||||
Kitchen appliances
|
||||
Mirror into which the player can look
|
||||
|
||||
>PROPS: FOOD, CLOTHING, MONEY, TOYS, BOOKS, ELECTRONICS
|
||||
*FOOD
|
||||
Food the player can eat without taking it first
|
||||
Sanity-check stage before the Before rules
|
||||
Foods with flavor
|
||||
Food with ingredients affecting the player
|
||||
Poisoned candy chosen randomly
|
||||
Hunger eventually killing the player
|
||||
|
||||
*BAGS, BOTTLES, BOXES AND SAFES
|
||||
Safe that can be opened with a combination
|
||||
Safe with a multi-number combination
|
||||
Bottles with removable stoppers
|
||||
Containers referred to by contents
|
||||
Object named differently if next to specific things
|
||||
Object named differently if alone in its container
|
||||
Letters described as a group
|
||||
Containers and supporters given a common kind
|
||||
|
||||
*CLOTHING
|
||||
Clothing kinds
|
||||
Clothing that layers
|
||||
Clothing with layering and regions of the body
|
||||
Concealing clothing for other characters
|
||||
Pocket added to every jacket
|
||||
Shirts constructed from component parts
|
||||
|
||||
*MONEY
|
||||
Money system with simple tracking of player wealth
|
||||
Catalog of juggling equipment with prices
|
||||
OFFER price FOR command allowing player to bargain
|
||||
Money system including denominations of bills and coins
|
||||
Clothes made of priced fabrics
|
||||
Equation used for price curves
|
||||
|
||||
*DICE AND PLAYING CARDS
|
||||
Deck of cards
|
||||
Deck of cards with individual card objects
|
||||
Deck of cards with identified poker hands
|
||||
Shuffling the arrangement of items in a container
|
||||
Pair of dice for rolling
|
||||
|
||||
*READING MATTER
|
||||
Book with various contents
|
||||
Book with numbered pages
|
||||
Bookshelf with numerous books
|
||||
Encyclopedia set
|
||||
READ command separate from EXAMINE
|
||||
Notebooks that can be written in
|
||||
Notebooks that can be written in as a separate command line
|
||||
|
||||
*PAINTING AND LABELING DEVICES
|
||||
Colour names for exotic pigments
|
||||
Paint that colours blocks
|
||||
Red sticky label
|
||||
|
||||
*SIMPLE MACHINES
|
||||
Computer with numerous components
|
||||
On/off button for devices
|
||||
Signpost that can be turned
|
||||
Fishing pole assembled from parts
|
||||
|
||||
*TELEVISIONS AND RADIOS
|
||||
Radios and other devices active when switched on
|
||||
Radio producing cycling programming
|
||||
Television with aspect ratio
|
||||
Television with channels, simple
|
||||
Television with channels, advanced
|
||||
|
||||
*TELEPHONES
|
||||
Telephones reaching distant parties
|
||||
Telephones with standard American-length phone numbers
|
||||
|
||||
*CLOCKS AND SCIENTIFIC INSTRUMENTS
|
||||
Clocks that can be SET TO any time
|
||||
Telescope allowing view of another room
|
||||
EMF Meter for ghost detection
|
||||
|
||||
*CAMERAS AND RECORDING DEVICES
|
||||
Recorder that records sounds made by player and non-player actions
|
||||
Camera producing instant photographs
|
||||
Model objects referred to by the thing modeled
|
||||
Mirror remembering a room description from the past
|
||||
Video camera that records all actions
|
||||
|
||||
>PHYSICS: SUBSTANCES, ROPES, ENERGY AND WEIGHT
|
||||
*GASES
|
||||
Smoke which spreads, not tracking concentration
|
||||
Diffusion of gas through the map, with concentrations
|
||||
Diffusion of gas through the map, where gas sinks
|
||||
|
||||
*LIQUIDS
|
||||
Liquid container removed when drunk
|
||||
SHAKE command
|
||||
Liquid which soaks into porous items
|
||||
Flotation of objects
|
||||
Command applying to an object added to the story
|
||||
Liquid container that can be full, depleted, or empty
|
||||
Liquid containers with measured contents
|
||||
Fire put out by liquid
|
||||
Liquids in mixtures, identified by recipe
|
||||
Liquid model with large bodies of liquid added
|
||||
|
||||
*DISPENSERS AND SUPPLIES OF SMALL OBJECTS
|
||||
Faux-infinite supply of red pens
|
||||
Near-infinite supply of pizza
|
||||
|
||||
*GLASS AND OTHER DAMAGE-PRONE SUBSTANCES
|
||||
Fragile things that break when attacked
|
||||
Fragile things, basic
|
||||
Fragile objects broken when things are thrown at them
|
||||
Broken and unbroken flowerpots
|
||||
Soft objects able to be cut open
|
||||
|
||||
*VOLUME, HEIGHT, WEIGHT
|
||||
Weighbridge
|
||||
Unit conversions
|
||||
Containers that calculate internal volume and available room
|
||||
Containers which have a breaking strain
|
||||
Sloping landscape on which round things roll away
|
||||
|
||||
*ROPES
|
||||
Strings referred to by their length
|
||||
String that can be divided and tied together again
|
||||
Rope, able to be tied to things and dragged betwixt rooms
|
||||
|
||||
*ELECTRICITY AND MAGNETISM
|
||||
Batteries that can power devices and eventually run down
|
||||
Electrified objects
|
||||
Magnet which picks up nearby metal objects
|
||||
|
||||
*FIRE
|
||||
Candle that changes as it burns down
|
||||
Camp fire which can be lit using tinder
|
||||
Matches that set fires
|
||||
Fire that spreads
|
||||
|
||||
*HEAT
|
||||
Supporter from which the player cannot take things
|
||||
Disambiguating based on properties
|
||||
Infrared goggles affect what player can see and refer to
|
||||
Hot and cold objects approach room temperature
|
||||
|
||||
*MAGIC (BREAKING THE LAWS OF PHYSICS)
|
||||
Machine that transmutes objects
|
||||
Person capable of reaching through solid objects
|
||||
The Pointy Hat of Liminal Transgression
|
||||
Wand which reveals a person's concealed possessions
|
||||
|
||||
*MATHEMATICS
|
||||
Using lists as arrays
|
||||
Using lists as sieves
|
||||
Numbers in relations
|
||||
|
||||
>PUZZLES
|
||||
*EXPLORATION
|
||||
|
||||
*RESTRICTED AREAS AND LOCKED CONTAINERS
|
||||
|
||||
*MAZES, CHANGING EXITS, AND RANDOM EXITS
|
||||
|
||||
*RESOURCE MANAGEMENT
|
||||
|
||||
*TIMED PUZZLES
|
||||
|
||||
*PEOPLE AS BARRIERS
|
||||
|
||||
*REPLAYABLE AND RANDOMIZING ELEMENTS
|
||||
|
||||
*COMMUNICATING GOALS AND DIRECTION
|
||||
|
||||
>OUT OF WORLD ACTIONS AND EFFECTS
|
||||
*START-UP FEATURES
|
||||
Banner printing at appropriate times
|
||||
Preferences file loaded on replaying
|
||||
Random distribution at the start of play
|
||||
|
||||
*SAVING AND UNDOING
|
||||
A point for never saving the game
|
||||
A room where the game cannot be saved
|
||||
|
||||
*HELPING AND HINTING
|
||||
HELP command is recommended if the player seems lost
|
||||
Novice mode offers suggestions before each prompt
|
||||
Responding to questions starting with WHO, WHAT, etc.
|
||||
Hint access able to be turned off for the duration of the game
|
||||
HELP menu from extension, with added content
|
||||
HELP with a simple menu
|
||||
HELP command with specific set of topics
|
||||
Hints leading the player through physical puzzles
|
||||
|
||||
*SCORING
|
||||
Scored items listed in a table
|
||||
FULL SCORE using a list of stored actions
|
||||
Awarding points for visiting a room
|
||||
FULL SCORE with achievements table and rankings
|
||||
Plot summary in place of a score
|
||||
Scoreboard preserved between games
|
||||
|
||||
*ENDING THE STORY
|
||||
Death message replaced
|
||||
UNDO not mentioned in the final question
|
||||
AMUSING menu shown at the endgame
|
||||
Changing the final question after victory
|
||||
Histories of previous games saved to external file
|
||||
Resuming play after an accidental death
|
||||
|
||||
>TYPOGRAPHY, LAYOUT, AND MULTIMEDIA EFFECTS
|
||||
*SCREEN EFFECTS (GENERAL)
|
||||
|
||||
*TYPOGRAPHY
|
||||
HTML-style italic and boldface tags
|
||||
Accented and exotic letters and symbols
|
||||
Coloured letters on screen
|
||||
Coloured lettering for both z-machine and Glulx
|
||||
|
||||
*THE STATUS LINE
|
||||
Blanking the status line before play
|
||||
Capitalised status line
|
||||
Status line with centered text, the easy way
|
||||
Status line with centered text, the hard way
|
||||
Exits only listed in the status line
|
||||
Exits and rooms listed in the status line
|
||||
Map region listed in status line
|
||||
|
||||
*MENUS
|
||||
|
||||
*FOOTNOTES
|
||||
Footnote system
|
||||
|
||||
*GLULX MULTIMEDIA EFFECTS
|
||||
An RSS reader connecting to the Internet
|
||||
|
||||
>TESTING AND PUBLISHING
|
||||
*TESTING
|
||||
Checking for missed properties
|
||||
Testing command
|
||||
|
||||
*PUBLISHING
|
||||
Producing an EPS floorplan
|
||||
Producing an EPS map of Greece
|
||||
Producing an EPS map of Port Royal
|
286
Documentation/Examples/Abolition.txt
Normal file
286
Documentation/Examples/Abolition.txt
Normal file
|
@ -0,0 +1,286 @@
|
|||
* Defining new prepositions
|
||||
(Relations syntax explored--Shifting alliances demonstrating all relation types; The Abolition of Love)
|
||||
A thorough exploration of all the kinds of relations established so far, with the syntax to set and unset them.
|
||||
|
||||
Suppose we are modeling a complex society seething with interpersonal relations of every kind.
|
||||
|
||||
{*}"The Abolition of Love"
|
||||
|
||||
Section 1 - Relation types
|
||||
|
||||
Loving relates one person to one person.
|
||||
|
||||
Noticing relates various people to one person.
|
||||
|
||||
Impressing relates one person to various people.
|
||||
|
||||
Fancying relates various people to various people.
|
||||
|
||||
Acquaintance relates people to each other.
|
||||
|
||||
Marriage relates one person to another.
|
||||
|
||||
Alliance relates people to each other in groups.
|
||||
|
||||
The Chapel is a room. Elizabeth, Wickham and Darcy are people in the Chapel. Mr Bennett and Mrs Bennett are people in the Chapel. Georgiana is a person in the Chapel.
|
||||
|
||||
The verb to love means the loving relation.
|
||||
|
||||
The verb to notice means the noticing relation.
|
||||
|
||||
The verb to impress means the impressing relation.
|
||||
|
||||
The verb to fancy means the fancying relation.
|
||||
|
||||
The verb to know means the acquaintance relation.
|
||||
|
||||
The verb to be married to means the marriage relation.
|
||||
|
||||
The verb to be related to means the alliance relation.
|
||||
|
||||
Elizabeth loves Darcy. Elizabeth fancies Darcy. Elizabeth notices Darcy. Elizabeth impresses Darcy.
|
||||
|
||||
Mr Bennett is related to Mrs Bennett and Elizabeth. Mr Bennett is married to Mrs Bennett.
|
||||
|
||||
Georgiana is related to Darcy.
|
||||
|
||||
Now we want ways to set and unset all of these relations. (In the interests of thoroughness, we may get a bit far-fetched here. It is not recommended in practice that we make the player guess the verb "traduce".)
|
||||
|
||||
{**}Section 2 - Setting and Unsetting Love (1-1)
|
||||
|
||||
Understand "infatuate [someone] with [someone]" as infatuating it with. Infatuating it with is an action applying to two visible things.
|
||||
|
||||
Carry out infatuating it with:
|
||||
now the noun loves the second noun.
|
||||
|
||||
Report infatuating it with:
|
||||
say "Now [the noun] loves [a random person loved by the noun][if the second noun loves someone], while [the second noun] loves [a random person loved by the second noun][end if]."
|
||||
|
||||
Understand "embitter [someone] toward [someone]" as embittering it toward. Embittering it toward is an action applying to two visible things.
|
||||
|
||||
Carry out embittering it toward:
|
||||
now the noun does not love the second noun.
|
||||
|
||||
Report embittering it toward:
|
||||
say "[The noun] sees [the second noun] in a different light and no longer feels any affection."
|
||||
|
||||
Because love is a 1-1 relation, a person cannot love more than one other character at a time. Whenever we set a character to love a new person, that person ceases to love the character loved before. It is a fickle world.
|
||||
|
||||
One to various relations are a bit more open: we can say someone impresses multiple other characters, and our additions to the list do not override the initial ones.
|
||||
|
||||
{**}Section 3 - Setting and Unsetting Impressed (1-V)
|
||||
|
||||
Understand "commend [someone] to [someone]" as commending it to. Commending it to is an action applying to two visible things.
|
||||
|
||||
Carry out commending it to:
|
||||
now the noun impresses the second noun.
|
||||
|
||||
Report commending it to:
|
||||
say "[The second noun] takes a very decided interest in [the noun]."
|
||||
|
||||
|
||||
Understand "traduce [someone] to [someone]" as traducing it to. Traducing it to is an action applying to two visible things.
|
||||
|
||||
Carry out traducing it to:
|
||||
now the noun does not impress the second noun.
|
||||
|
||||
Report traducing it to:
|
||||
say "[The second noun], hearing your story, decides not to be at all impressed with [the noun]."
|
||||
|
||||
And because this is a one-to-various relation, we can also make statements which set multiple relations at once, so:
|
||||
|
||||
{**}Understand "celebrate [someone]" as celebrating. Celebrating is an action applying to one visible thing.
|
||||
|
||||
Carry out celebrating:
|
||||
now the noun impresses every person.
|
||||
|
||||
Report celebrating:
|
||||
say "[The list of people who are impressed by the noun] take a very decided interest in [the noun]."
|
||||
|
||||
|
||||
Understand "slander [someone]" as slandering to. Slandering to is an action applying to one visible thing.
|
||||
|
||||
Carry out slandering to:
|
||||
now every person is not impressed by the noun.
|
||||
|
||||
Report slandering to:
|
||||
say "Now [the noun] impresses [the list of people who are impressed by the noun]."
|
||||
|
||||
Note that the above unsetting is not equivalent to "now the noun does not impress every person" -- which would be ambiguous in spoken English, as well. Various-to-one relations are similar:
|
||||
|
||||
{**}Section 4 - Setting and Unsetting Noticing (V-1)
|
||||
|
||||
Understand "draw the attention of [someone] to [someone]" as drawing the attention of it to. Drawing the attention of it to is an action applying to two visible things.
|
||||
|
||||
Carry out drawing the attention of it to:
|
||||
now the noun notices the second noun.
|
||||
|
||||
Report drawing the attention of it to:
|
||||
say "[The noun] glances thoughtfully in the direction of [the second noun]."
|
||||
|
||||
Understand "distract [someone] from [someone]" as distracting it from. Distracting it from is an action applying to two visible things.
|
||||
|
||||
Carry out distracting it from:
|
||||
now the noun does not notice the second noun.
|
||||
|
||||
Report distracting it from:
|
||||
say "You distract [the noun] from [the second noun]."
|
||||
|
||||
|
||||
Understand "draw attention to [someone]" as drawing attention to. Drawing attention to is an action applying to one visible thing.
|
||||
|
||||
Carry out drawing attention to:
|
||||
now every person notices the noun.
|
||||
|
||||
Report drawing attention to:
|
||||
say "You quickly cause everyone to attend to [the noun]."
|
||||
|
||||
|
||||
Understand "outshine [someone]" as outshining. Outshining is an action applying to one visible thing.
|
||||
|
||||
Carry out outshining:
|
||||
now every person does not notice the noun.
|
||||
|
||||
Report outshining:
|
||||
say "You quickly distract everyone from [the noun]."
|
||||
|
||||
|
||||
Section 5 - Setting and Unsetting Fancying (V-V)
|
||||
|
||||
Understand "flatter [someone]" as flattering. Flattering is an action applying to one thing.
|
||||
|
||||
Carry out flattering:
|
||||
now every person fancies the noun.
|
||||
|
||||
Report flattering:
|
||||
say "You draw down universal admiration for [the noun] by casting him or her in a flattering light."
|
||||
|
||||
|
||||
Understand "unflatter [someone]" as unflattering. [Okay, okay, but it's four am.] Unflattering is an action applying to one thing.
|
||||
|
||||
Carry out unflattering:
|
||||
now every person does not fancy the noun.
|
||||
|
||||
Report unflattering:
|
||||
say "[The noun] gives everyone a universal disgust."
|
||||
|
||||
|
||||
Understand "admire [someone]" as admiring. Admiring is an action applying to one thing.
|
||||
|
||||
Carry out admiring: now the player fancies the noun.
|
||||
|
||||
Report admiring: say "You find you rather fancy [the noun]."
|
||||
|
||||
Understand "loathe [someone]" as loathing. Loathing is an action applying to one thing.
|
||||
|
||||
Carry out loathing: now the player does not fancy the noun.
|
||||
|
||||
Report loathing: say "You take [the noun] in disgust."
|
||||
|
||||
Understand "cause chaos" as causing chaos. Causing chaos is an action applying to nothing.
|
||||
|
||||
Carry out causing chaos:
|
||||
now every person fancies every person.
|
||||
|
||||
Report causing chaos: say "Now everyone fancies everyone else, which is quite an inconvenient state of affairs."
|
||||
|
||||
Understand "relieve chaos" as relieving chaos. Relieving chaos is an action applying to nothing.
|
||||
|
||||
Carry out relieving chaos:
|
||||
now every person is fancied by no one.
|
||||
|
||||
Report relieving chaos: say "Now no one fancies anyone, which is safe but tedious."
|
||||
|
||||
Our options for setting and unsetting symmetrical relations are more limited again:
|
||||
|
||||
{**}Section 6 - Setting and Unsetting Marriage (1-1 Symmetrical)
|
||||
|
||||
Understand "marry [someone] to [someone]" as uniting it in matrimony with. Uniting it in matrimony with is an action applying to two visible things.
|
||||
|
||||
Carry out uniting it in matrimony with:
|
||||
now the noun is married to the second noun.
|
||||
|
||||
Report uniting it in matrimony with:
|
||||
say "You perform the marriage of [the noun] to [the second noun], joining them to the family of [a list of people related to the noun]."
|
||||
|
||||
Understand "divorce [someone] from [someone]" as divorcing it from. Divorcing it from is an action applying to two visible things.
|
||||
|
||||
Check divorcing it from:
|
||||
if the noun is not married to the second noun, say "[The noun] is not married to [the second noun] anyway." instead.
|
||||
|
||||
Carry out divorcing it from:
|
||||
now the noun is not married to the second noun.
|
||||
|
||||
Report divorcing it from:
|
||||
say "[The noun] is now not married to [the second noun]."
|
||||
|
||||
When we unset the symmetrical relation on one side, it is automatically set or unset on the other. It is not necessary to say "the second noun is married to the noun" or "the second noun is not married to the noun", even though that is the case.
|
||||
|
||||
{**}Section 7 - Setting and Unsetting Acquaintance (V-V Symmetrical)
|
||||
|
||||
Understand "introduce [someone] to [someone]" as introducing it to. Introducing it to is an action applying to two visible things.
|
||||
|
||||
Carry out introducing it to:
|
||||
now the noun knows the second noun.
|
||||
|
||||
Report introducing it to:
|
||||
say "You introduce [the noun] to [the second noun]. Now [the noun] is acquainted with [the list of people who are known by the noun], and [the second noun] is acquainted with [the list of people who are known by the second noun]."
|
||||
|
||||
|
||||
Understand "announce [someone]" as announcing. Announcing is an action applying to one visible thing.
|
||||
|
||||
Carry out announcing:
|
||||
now every person knows the noun.
|
||||
|
||||
Report announcing:
|
||||
say "You announce [the noun] to the whole assembled company."
|
||||
|
||||
|
||||
Understand "ostracise [someone]" as ostracising. Ostracising is an action applying to one visible thing.
|
||||
|
||||
Carry out ostracising:
|
||||
now every person does not know the noun.
|
||||
|
||||
Report ostracising:
|
||||
say "You cause everyone present to forget and pretend not to be acquainted at all with [the noun]."
|
||||
|
||||
And finally, setting groups:
|
||||
|
||||
{**}Section 8 - Setting and Unsetting Familial Relations (Groups)
|
||||
|
||||
Understand "make [someone] adopt [someone]" as forcing it to adopt. Forcing it to adopt is an action applying to two visible things.
|
||||
|
||||
Carry out forcing it to adopt:
|
||||
now the noun is related to the second noun.
|
||||
|
||||
Report forcing it to adopt:
|
||||
say "Now [the second noun] is related to [the list of people related to the second noun]."
|
||||
|
||||
Understand "make [someone] disown [someone]" as forcing it to disown. Forcing it to disown is an action applying to two visible things.
|
||||
|
||||
Carry out forcing it to disown:
|
||||
now the second noun is not related to the noun.
|
||||
|
||||
Report forcing it to disown:
|
||||
say "Now [the second noun] is related to [the list of people who are related to the second noun], and [the noun] is related to [the list of people who are related to the noun]."
|
||||
|
||||
Notice that when we say "the second noun is not related", we remove that person from the group: they are now in a separate group of their own, while the rest of the group's members remain related to one another.
|
||||
|
||||
And finally, a long litany of test cases, complete with the relations lists:
|
||||
|
||||
{**}Test acquaintance with "relations / introduce darcy to elizabeth / introduce darcy to wickham / announce mr bennett / relations / ostracise wickham / introduce georgiana to wickham / relations".
|
||||
|
||||
Test impression with "commend georgiana to elizabeth / relations / celebrate Mrs bennett / relations / traduce mrs bennett to darcy / relations / slander mrs bennett / relations".
|
||||
|
||||
Test notice with "draw the attention of darcy to elizabeth / relations / draw attention to mr bennett / relations / distract darcy from mr bennett / relations / outshine mr bennett / relations".
|
||||
|
||||
Test love with "embitter elizabeth toward darcy / relations / infatuate elizabeth with wickham / relations".
|
||||
|
||||
Test marriage with "marry elizabeth to darcy / relations / divorce elizabeth from darcy / relations".
|
||||
|
||||
Test alliance with "make mr bennett adopt georgiana / relations / make mrs bennett disown georgiana / relations".
|
||||
|
||||
Test fancying with "admire elizabeth / relations / loathe elizabeth / relations / flatter elizabeth / relations / unflatter elizabeth / relations / cause chaos / relations / relieve chaos / relations".
|
||||
|
||||
Test me with "test acquaintance / test impression / test notice / test love / test alliance / test fancying / test marriage".
|
||||
|
68
Documentation/Examples/ActorsStudio.txt
Normal file
68
Documentation/Examples/ActorsStudio.txt
Normal file
|
@ -0,0 +1,68 @@
|
|||
** Stored actions
|
||||
(Video camera that records all actions; Actor's Studio)
|
||||
A video camera that records actions performed in its presence, and plays them back with time-stamps.
|
||||
|
||||
Here we construct a video camera to track and play back actions:
|
||||
|
||||
{*}"The Actor's Studio"
|
||||
|
||||
Section 1 - The Video Camera
|
||||
|
||||
The video camera is a thing carried by the player.
|
||||
|
||||
Table of Videotape
|
||||
recorded action time stamp
|
||||
waiting 9:00 AM
|
||||
with 25 blank rows.
|
||||
|
||||
Mode is a kind of value. The modes are idle, recording, and playing back. The video camera has a mode. The video camera is idle.
|
||||
|
||||
Understand "play back" as playing back. Instead of switching on the camera, try tuning the camera to recording. Instead of switching off the camera, try tuning the camera to idle.
|
||||
|
||||
The description of the video camera is "It is currently [mode]; its available settings are idle, recording, and playing back."
|
||||
|
||||
Understand "set [camera] to [a mode]" as tuning it to. Tuning it to is an action applying to one thing and one mode.
|
||||
|
||||
Instead of setting the camera to something:
|
||||
say "The available settings are idle, recording, and playing back."
|
||||
|
||||
Check tuning it to:
|
||||
if the noun is not the camera, say "Only the video camera can be set to [the mode understood]." instead.
|
||||
|
||||
Carry out tuning it to:
|
||||
now the mode of the noun is the mode understood.
|
||||
|
||||
Report tuning it to:
|
||||
say "You set [the noun] to [mode understood]."
|
||||
|
||||
After an actor doing something when the video camera is recording:
|
||||
if the current action is tuning the video camera to recording, make no decision;
|
||||
if the number of blank rows in the Table of Videotape is greater than zero:
|
||||
choose a blank row in the Table of Videotape;
|
||||
now the recorded action entry is the current action;
|
||||
now the time stamp entry is the time of day;
|
||||
otherwise:
|
||||
now the video camera is idle;
|
||||
say "The video camera runs out of recording memory and switches off.";
|
||||
continue the action.
|
||||
|
||||
Every turn when the video camera is playing back:
|
||||
say "On the camera screen, you see [run paragraph on]";
|
||||
let starting playback be false;
|
||||
repeat through the Table of Videotape:
|
||||
if the recorded action entry is not waiting:
|
||||
now starting playback is true;
|
||||
say "[line break] -- [if the actor part of the recorded action entry is the player]you [end if][the recorded action entry], time stamped at [time stamp entry]";
|
||||
blank out the whole row;
|
||||
if starting playback is false, say "only static.";
|
||||
otherwise say paragraph break.
|
||||
|
||||
Section 2 - The Scenario
|
||||
|
||||
The Actor's Studio is a room. Lucas is a man in the Actor's Studio. Persuasion rule: persuasion succeeds.
|
||||
|
||||
The Studio contains an edible thing called a croissant.
|
||||
|
||||
Test me with "set camera to recording / x lucas / lucas, take inventory / lucas, eat croissant / set camera to playing back / z".
|
||||
|
||||
Notice that both Lucas' implied taking action (picking up the croissant) and his eating action are recorded on the same move.
|
75
Documentation/Examples/Aftershock.txt
Normal file
75
Documentation/Examples/Aftershock.txt
Normal file
|
@ -0,0 +1,75 @@
|
|||
*** New activities
|
||||
(Radios and other devices active when switched on; Aftershock)
|
||||
Modifying the rules for examining a device so that all devices have some specific behavior when switched on, which is described at various times.
|
||||
|
||||
The built-in behavior of Inform is to print a line after a device is examined, saying whether the item is on or off. This is often inappropriate, and we could simply turn off that behavior in general by instructing Inform to ignore the "examine described devices rule" (see the chapter on rulebooks).
|
||||
|
||||
Perhaps, though, we would like continue to have a short passage about the action of any switched on device; we'd just like a little more control over what it says from time to time. And in that case, we might change the rule to give a new activity control over that portion of the description:
|
||||
|
||||
{*}"Aftershock"
|
||||
|
||||
Section 1 - Showing actions
|
||||
|
||||
Showing action of something is an activity.
|
||||
|
||||
Rule for showing action of something (called item):
|
||||
if the item is switched on, say "[The item] is switched on.";
|
||||
otherwise say "[The item] is switched off."
|
||||
|
||||
Borrowing from the rulebooks chapter, we can replace the standard "examine described devices" rule with something that uses this activity.
|
||||
|
||||
{**}The new described devices rule is listed instead of the examine devices rule in the carry out examining rules.
|
||||
|
||||
This is the new described devices rule:
|
||||
if the noun is a device:
|
||||
carry out the showing action activity with the noun;
|
||||
now examine text printed is true.
|
||||
|
||||
Thus far we have essentially replicated the original behavior, but we've made it possible to write specialized behavior for devices, and to invoke that behavior in other places:
|
||||
|
||||
{**}Report switching on something:
|
||||
say "You flip a switch. ";
|
||||
carry out the showing action activity with the noun instead.
|
||||
|
||||
This might be useful for an electric lamp kind:
|
||||
|
||||
{**}Section 2 - Electric Lamps
|
||||
|
||||
An electric lamp is a kind of device.
|
||||
|
||||
Rule for showing action of an electric lamp (called item):
|
||||
if the item is switched on, say "[The item] is lit[if the number of visible lit things is greater than 1], competing with [the list of visible lit things which are not the item][end if].";
|
||||
otherwise say "[The item] is dark."
|
||||
|
||||
Carry out switching on an electric lamp: now the noun is lit. Carry out switching off an electric lamp: now the noun is unlit.
|
||||
|
||||
{**}Section 2 - The Scenario
|
||||
|
||||
The time of day is 3:47 AM. When play begins, now the right hand status line is "[time of day]".
|
||||
|
||||
The Downstairs Hallway is a dark room. "The only room in the house with no furniture and almost nothing on the walls. At times like this you always notice the crack in the plaster, originating near the light fixture and running almost all the way to the wall."
|
||||
|
||||
A plastic jug of filtered water is in the Downstairs Hallway. The description is "Five gallons, not that that will last you very long, hot as it has been lately."
|
||||
|
||||
The crack is scenery in the Hallway. The description is "No, the ceiling isn't going to fall on you today."
|
||||
|
||||
The light fixture is an electric lamp in the Hallway. It is switched on, lit, and scenery. The description is "A plain globe of frosted glass containing the light bulb. Nothing special, and you never think about it except when, as now, you are forced to spend hours in this room."
|
||||
|
||||
The flashlight is an electric lamp carried by the player. The description is "A shiny red flashlight." The portable radio is a device carried by the player. The description is "A small battery-operated radio which you received for free with your subscription to US News & World Report. It has served you well through many earthquakes past."
|
||||
|
||||
And with our activity, we can override the flashlight's electric lamp behavior with new behavior:
|
||||
|
||||
{**}Rule for showing action of the flashlight:
|
||||
if the flashlight is switched on, say "A strong, narrow beam of light shines from the flashlight.";
|
||||
otherwise say "It is currently switched off."
|
||||
|
||||
...or give special actions for the radio:
|
||||
|
||||
{**}Rule for showing action of the radio:
|
||||
if the radio is switched on, say "Through the static, you pick up pieces of discussion: a 6.7 on the Richter scale, epicenter... something about Topanga... but it crackles out again.";
|
||||
otherwise say "The radio is silent. You're saving the batteries."
|
||||
|
||||
Instead of listening in the presence of the switched on radio:
|
||||
carry out the showing action activity with the radio instead.
|
||||
|
||||
Test me with "examine light / switch light off / switch flashlight on / switch radio on / examine radio / examine flashlight".
|
36
Documentation/Examples/Ahem.txt
Normal file
36
Documentation/Examples/Ahem.txt
Normal file
|
@ -0,0 +1,36 @@
|
|||
* Pattern matching
|
||||
(Phrase to repeat a rule--Phrase to let us say things some number of times; Ahem)
|
||||
Writing a phrase, with several variant forms, whose function is to follow a rule several times.
|
||||
|
||||
As we see in the example here, it is possible to use slashed variations in more than one place in a phrase, and to offer a number of separate forms. The main rule of thumb to remember is that value inputs for the phrase should always be separated by some text; so
|
||||
|
||||
To do/follow (chosen rule - a rule) exactly/precisely/just/-- (N - a number) time/times:
|
||||
....
|
||||
|
||||
would cause a problem when we tried to call it with
|
||||
|
||||
follow the throat-clearing rule 2 times.
|
||||
|
||||
In general, we probably don't need to make our phrase definitions quite so flexible as this, but it's a good idea to account for "a" vs. "the", and for the possibility of using singular and plural forms, especially when writing extensions or other source to be shared.
|
||||
|
||||
{*} "Ahem"
|
||||
|
||||
To do/follow (chosen rule - a rule) exactly/precisely/just (N - a number) time/times:
|
||||
repeat with index running from 1 to N:
|
||||
follow chosen rule.
|
||||
|
||||
This is the throat-clearing rule:
|
||||
say "'Ahem,' says [a random visible person who is not the player]."
|
||||
|
||||
After waiting:
|
||||
do the throat-clearing rule just one time.
|
||||
|
||||
Instead of listening:
|
||||
follow the throat-clearing rule precisely three times.
|
||||
|
||||
Instead of smelling:
|
||||
follow the throat-clearing rule exactly 2 times.
|
||||
|
||||
Chateau Marmont is a room. Tom, Jack, Zsa-Zsa, and Wilma-Faye are people in the Chateau. Zsa-Zsa and Wilma-Faye are women.
|
||||
|
||||
Test me with "wait / smell / listen".
|
54
Documentation/Examples/Alias-G.txt
Normal file
54
Documentation/Examples/Alias-G.txt
Normal file
|
@ -0,0 +1,54 @@
|
|||
*** Numbers and real numbers
|
||||
(Telephones with standard American-length phone numbers; Alias)
|
||||
A telephone with phone numbers of the standard American seven-digit length.
|
||||
|
||||
Seven-digit telephone numbers are too long for Inform to handle when compiling to the Z-Machine, but they will work under Glulx. To have this example succeed, make sure that you have selected the Glulx option in your settings menu.
|
||||
|
||||
{*}"Alias"
|
||||
|
||||
A telephone is a kind of thing. Understand "phone" or "telephone" as a telephone.
|
||||
|
||||
A phone number is a kind of value. 999-9999 specifies a phone number.
|
||||
|
||||
Now we borrow some techniques from the Understanding chapter to set up dialing actions:
|
||||
|
||||
{**}Understand "dial [phone number] on [telephone]" as dialing it on. Understand "dial [phone number] on [something]" as dialing it on.
|
||||
|
||||
Understand the commands "phone" or "telephone" or "call" as "dial".
|
||||
|
||||
Understand "call [text]" or "phone [text]" or "dial [text]" or "telephone [text]" as a mistake ("That's not a number you know.").
|
||||
|
||||
Dialing it on is an action applying to one phone number and one thing.
|
||||
|
||||
Report dialing it on:
|
||||
say "You dial [the phone number understood]."
|
||||
|
||||
This much is enough to let us dial telephone numbers and have Inform report that we've done so; it doesn't actually provide a telephone system such that we could reach and converse with other characters (but see the other telephone examples in the recipe book for more on how one might do that).
|
||||
|
||||
We'll set up a little political espionage scenario from which our player can make calls:
|
||||
|
||||
{**}The Senator's Junior Suite is a room. "The Senator appears, unfortunately, to have very precise habits: little in the room has been moved from its usual place; the trash can is empty; the bed has been remade[if the blue paper is unexamined]. There may in fact be nothing to find here[end if]."
|
||||
|
||||
The bed is an enterable scenery supporter in the Junior Suite.
|
||||
|
||||
The player is wearing a housekeeping uniform and a brunette wig. The player carries a telephone called a Nokia.
|
||||
|
||||
Borrowing again from the chapter on Understanding, we might arrange things so that the player knows and can call a few standard numbers with such syntax as CALL HOME:
|
||||
|
||||
{**}Understand "home" as 555-9200.
|
||||
|
||||
And what if we'd like to have the player learn some phone numbers during the game?
|
||||
|
||||
{**}A thing can be examined or unexamined. Carry out examining something: now the noun is examined.
|
||||
|
||||
Understand "Stephen" as 555-2513 when the blue paper is examined.
|
||||
|
||||
This will understand CALL STEPHEN once the paper is examined; before that, the player will just get the "That's not a number you know" response that Inform uses for all attempts to call unknown names.
|
||||
|
||||
We'd better plant this paper for the player to find:
|
||||
|
||||
{**}The blue paper is in the drawer. The description of the blue paper is "It reads: 'Call Stephen - 555-2513'."
|
||||
|
||||
The drawer is part of the dresser. It is closed and openable. The dresser is in The Senator's Junior Suite. The lamp is on the dresser. The description of the dresser is "The single drawer is [if the drawer is open]open[otherwise]shut[end if]."
|
||||
|
||||
Test me with "dial 555-9999 / call home on the telephone / phone the president / call stephen / open drawer / read paper / call stephen / put phone in drawer / close drawer / call stephen".
|
37
Documentation/Examples/AlienInvasion.txt
Normal file
37
Documentation/Examples/AlienInvasion.txt
Normal file
|
@ -0,0 +1,37 @@
|
|||
* Writing and reading tables to external files
|
||||
(Preferences file loaded on replaying; Alien Invasion Part 23)
|
||||
Keeping a preference file that could be loaded by any game in a series.
|
||||
|
||||
Suppose that we have a series of games each of which allows the player to select a puzzle difficulty level. When the player plays a new game in the series, we want him to start out by default with the same difficulty level he faced earlier on, so we store this information in a small preferences file, as follows:
|
||||
|
||||
{*}"Alien Invasion Part 23"
|
||||
|
||||
A difficulty is a kind of value. The difficulties are easy, moderate, hard, and fiendish.
|
||||
|
||||
Understand "use [difficulty] puzzles" as selecting difficulty. Selecting difficulty is an action out of world, applying to one difficulty.
|
||||
|
||||
Carry out selecting difficulty:
|
||||
choose row 1 in the Table of Preference Settings;
|
||||
now challenge level entry is difficulty understood;
|
||||
say "Puzzles will be [challenge level entry] from now on."
|
||||
|
||||
The File of Preferences is called "prefs".
|
||||
|
||||
When play begins:
|
||||
if File of Preferences exists:
|
||||
read File of Preferences into the Table of Preference Settings;
|
||||
choose row 1 in the Table of Preference Settings;
|
||||
say "(The current puzzle difficulty is set to [challenge level entry].)"
|
||||
|
||||
Check quitting the game:
|
||||
write File of Preferences from the Table of Preference Settings.
|
||||
|
||||
Table of Preference Settings
|
||||
challenge level
|
||||
easy
|
||||
|
||||
The Sewer Junction is a room.
|
||||
|
||||
Our preference file is restricted to a single option here for simplicity's sake, but we could keep track of more information -- whether the player preferred verbose or brief room descriptions, screen configurations, and so on.
|
||||
|
||||
If we were disposed to be somewhat crueler, we could use a similar method to make the player finish each episode of the series in order to "unlock" the next. All we would need to do is store a numerical password in our preferences file when the player finished a given level; the next level would check, say, the Table of Completed Levels for that password, and refuse to play unless the right number were present.
|
23
Documentation/Examples/Alliances.txt
Normal file
23
Documentation/Examples/Alliances.txt
Normal file
|
@ -0,0 +1,23 @@
|
|||
* Defining new assertion verbs
|
||||
(Shifting alliances among people; Unthinkable Alliances)
|
||||
People are to be grouped into alliances. To kiss someone is to join his or her faction, which may make a grand alliance; to strike them is to give notice of quitting, and to become a lone wolf.
|
||||
|
||||
The following is best tested by experimentally kissing and/or attacking, and typing RELATIONS after every change to see the effect.
|
||||
|
||||
{*}"Unthinkable Alliances"
|
||||
|
||||
Unthinkable Solutions is a room. Sophie, Daisy, Ryan and Owen are in Unthinkable Solutions.
|
||||
|
||||
Alliance relates people to each other in groups. The verb to help means the alliance relation.
|
||||
|
||||
Sophie helps Ryan. Daisy helps Ryan. Owen helps the player.
|
||||
|
||||
Instead of kissing someone (called the blessed one):
|
||||
say "Smack!";
|
||||
now the player helps the blessed one.
|
||||
|
||||
Instead of attacking someone (called the vilified one):
|
||||
say "Smack!";
|
||||
now the player does not help the vilified one.
|
||||
|
||||
Test me with "relations / kiss sophie / relations / hit ryan / relations".
|
50
Documentation/Examples/Alpaca.txt
Normal file
50
Documentation/Examples/Alpaca.txt
Normal file
|
@ -0,0 +1,50 @@
|
|||
* New commands for old grammar
|
||||
(USE action which divines rational behavior for a wide range of possible nouns; Alpaca Farm)
|
||||
A generic USE action which behaves sensibly with a range of different objects.
|
||||
|
||||
This example takes the ordering of grammar lines to its logical extreme, sorting the player's input into different categories depending on the kind and condition of the objects mentioned.
|
||||
|
||||
{*}"Alpaca Farm"
|
||||
|
||||
Understand "use [an edible thing]" as eating.
|
||||
|
||||
Understand "use [a wearable thing]" as wearing.
|
||||
|
||||
Understand "use [a closed openable container]" as opening. Understand "use [an open openable container]" as closing.
|
||||
|
||||
Understand "use [something preferably held] on [a locked lockable thing]" as unlocking it with (with nouns reversed). Understand "use [something preferably held] on [an unlocked lockable thing]" as locking it with (with nouns reversed).
|
||||
|
||||
Understand "use [a switched off device]" as switching on.
|
||||
|
||||
Understand "use [something]" as using. Using is an action applying to one thing. Carry out using: say "You will have to be more specific about your intentions."
|
||||
|
||||
Understand "use [a door]" as opening. Understand "use [an open door]" as entering.
|
||||
|
||||
The Llama Pen is a room. North of the Pen is the gate. The gate is a door. North of the gate is the Rocky Path. The brown llama is an animal in the Llama Pen.
|
||||
|
||||
Appearance is a kind of value. The appearances are muddy, scruffy, fluffy, and dapper. The brown llama has an appearance. The brown llama is muddy. Before printing the name of the brown llama, say "[appearance] ". Before printing the name of the brown llama while grooming: say "now-[if appearance of the brown llama is less than dapper]merely-[end if]".
|
||||
|
||||
A grooming tool is a kind of thing. Understand "use [a grooming tool] on [something]" as grooming it with (with nouns reversed). Grooming it with is an action applying to two things. Understand "groom [something] with [something]" as grooming it with.
|
||||
|
||||
Carry out grooming it with:
|
||||
if the appearance of the noun is less than dapper, now the appearance of the noun is the appearance after the appearance of the noun.
|
||||
|
||||
Report grooming it with:
|
||||
say "You attend diligently to the appearance and hygiene of [the noun]."
|
||||
|
||||
Instead of using a grooming tool in the presence of the brown llama:
|
||||
try grooming the brown llama with the noun.
|
||||
|
||||
The player carries some nail nippers, a slicker brush, and an apple. The apple is edible. The brush and the nippers are grooming tools. The player wears a sombrero.
|
||||
|
||||
The description of the nail nippers is "Ten inches long, to give you the necessary leverage to cut tough llama toenails. It still helps to soften them up by making the llama stand in a bucket of water first, though."
|
||||
|
||||
The description of the slicker brush is "Fine, angled soft bristles set into a broad back, perfect for removing mud from the coat of a long-woolled llama."
|
||||
|
||||
The industrial-strength blower is a fixed in place device in the Llama Pen. "Attached to the nearest wall, on its own movable boom, is an industrial-strength blower for doing llama hair."
|
||||
|
||||
Understand "use [switched off blower]" as switching on. Understand "use [switched on blower] on [brown llama]" as grooming it with (with nouns reversed). Instead of using the blower in the presence of the brown llama, try grooming the brown llama with the blower.
|
||||
|
||||
Test me with "use gate / use blower / use nippers / use brush / use apple / remove sombrero / use sombrero".
|
||||
|
||||
Whether we actually want a USE action is a subject of some theoretical debate in the IF community. On the one hand, it helps avoid guess-the-verb problems where the player cannot figure out what term to use in order to express a fairly simple idea. On the other, it encourages the player to think that all items have one and exactly one use, rather than getting him to consider the range of possibilities that arise from having a complex vocabulary.
|
21
Documentation/Examples/Alpha.txt
Normal file
21
Documentation/Examples/Alpha.txt
Normal file
|
@ -0,0 +1,21 @@
|
|||
* Regular expression matching
|
||||
(Testing command; Alpha)
|
||||
Creating a beta-testing command that matches any line starting with punctuation.
|
||||
|
||||
Sometimes we want to let testers of a game insert their own comments during a transcript, without those comments wasting turns of the game or producing lengthy or inappropriate parser errors. Many testers have a habit of prefacing comments with a punctuation mark, so let's say that we'd like to catch any command that starts with any punctuation at all:
|
||||
|
||||
{*} "Alpha"
|
||||
|
||||
When play begins:
|
||||
say "Hi, Larry! Thanks for testing my game!!"
|
||||
|
||||
Unimplemented Room is a room. "Room description goes here..."
|
||||
|
||||
The scary troll is a man in Unimplemented Room.
|
||||
|
||||
After reading a command (this is the ignore beta-comments rule):
|
||||
if the player's command matches the regular expression "^\p":
|
||||
say "(Noted.)";
|
||||
reject the player's command.
|
||||
|
||||
Test me with "x me / x troll / !this game is a bit dull so far / kiss troll / ? does this troll do anything? / :yawn".
|
33
Documentation/Examples/AmusingMenu.txt
Normal file
33
Documentation/Examples/AmusingMenu.txt
Normal file
|
@ -0,0 +1,33 @@
|
|||
** Amusing a victorious player
|
||||
(AMUSING menu shown at the endgame; Xerxes)
|
||||
Offering the player a menu of things to read after winning the game.
|
||||
|
||||
Building a menu is moderately tedious, so we will rely on the standard menu extensions provided. Thus:
|
||||
|
||||
{*}"Xerxes"
|
||||
|
||||
Include Basic Screen Effects by Emily Short. Include Menus by Emily Short.
|
||||
|
||||
Table of Amusing Matter
|
||||
title subtable description toggle
|
||||
"Cult Revisions" -- "Did you try... [paragraph break] banning the worship of Seth? [line break] of Dionysus? [line break] assigning all your priests to Re? [line break] assigning male priests to Cybele? [line break] assigning married priestesses to Hestia? [line break] identifying one god as another (e.g., Isis and Hecate)? [line break] identifying a mortal as a god (e.g., Alexander as Helios-Apollo)?" --
|
||||
"Military Revisions" -- "Did you try... [paragraph break] allying a Greek city-state with the Persians? (try >MEDIZE) [line break] playing Athens as a land-based power?" --
|
||||
|
||||
Rule for amusing a victorious player:
|
||||
now the current menu is the Table of Amusing Matter;
|
||||
now the current menu title is "Things to Try";
|
||||
carry out the displaying activity;
|
||||
clear the screen.
|
||||
|
||||
Omitting about a half million words from this rigorous and educational but nonetheless enthralling simulation of centuries of history, culture, and religion, we will skip directly to:
|
||||
|
||||
{**}Athens is a room.
|
||||
|
||||
Use scoring.
|
||||
|
||||
Every turn:
|
||||
if the score is greater than 10000, end the story finally.
|
||||
|
||||
When play begins: now the score is 10001.
|
||||
|
||||
Test me with "z".
|
19
Documentation/Examples/AnnoyotronJr.txt
Normal file
19
Documentation/Examples/AnnoyotronJr.txt
Normal file
|
@ -0,0 +1,19 @@
|
|||
* How many turns?
|
||||
(Child who asks if we're there yet; Annoyotron Jr)
|
||||
A child who after a certain period in the car starts asking annoying questions.
|
||||
|
||||
{*}"Annoyotron Jr"
|
||||
|
||||
The Minivan is a room. The Open Road is outside from the Minivan. Pete is a man in the Minivan. "Pete [if the player has been in the Minivan for 3 turns]is starting to look bored[otherwise]is playing with his travel activity book[end if]."
|
||||
|
||||
Every turn:
|
||||
if the player has been in the Minivan for 5 turns, say "'Are we there [if saying no]now?'[otherwise]yet?' asks Pete.[end if]"
|
||||
|
||||
Instead of saying no:
|
||||
say "'Oh,' says Pete. There is a blessed, momentary silence."
|
||||
|
||||
Instead of going to the Open Road:
|
||||
say "You leap to your death.";
|
||||
end the story.
|
||||
|
||||
Test me with "z / z / look / g / g / g / no / z / z / z / no / z / out".
|
168
Documentation/Examples/AntSensitiveSunglasses.txt
Normal file
168
Documentation/Examples/AntSensitiveSunglasses.txt
Normal file
|
@ -0,0 +1,168 @@
|
|||
* What are activities?
|
||||
(Varying room description text; Ant-Sensitive Sunglasses)
|
||||
What are activities good for? Controlling output when we want the same action to be able to produce very flexible text depending on the state of the world -- in this case, making highly variable room description and object description text.
|
||||
|
||||
Suppose we want to create an object -- or maybe even a series of objects -- that warp the player's perception of every room description and object around him.
|
||||
|
||||
We've already seen some ways to create variations in text. For instance, we could make a room description with if substitutions in it, like so:
|
||||
|
||||
The Kitchen is a room. "[if the player is wearing the sunglasses]Are ants coming out of the sink? No, probably no.[otherwise]A small kitchen tucked into a corner of the vacation house. There is storage space for five or six cups, a sink, a two-ring stove; nothing else to speak of.[end if]"
|
||||
|
||||
That works fine if we have one or two variations we want to add; it's not so good if we're going to have several items that work like the sunglasses, or if we want the sunglasses to override the description of every room in the house.
|
||||
|
||||
A slightly more flexible method is to use a substitution that calls out to a say phrase, like this:
|
||||
|
||||
The Kitchen is a room. "[kitchen-description]"
|
||||
|
||||
To say kitchen-description:
|
||||
if the player is wearing the sunglasses:
|
||||
say "Are ants coming out of the sink? No, probably no.";
|
||||
otherwise:
|
||||
say "A small kitchen tucked into a corner of the vacation house. There is storage space for five or six cups, a sink, a two-ring stove; nothing else to speak of."
|
||||
|
||||
But again this doesn't handle the case of overriding multiple rooms at once very well.
|
||||
|
||||
When we reach a point where we need a given piece of text to be very flexible depending on the world model, it's time to use an activity.
|
||||
|
||||
Activities offer several advantages. One, we can create an activity like this:
|
||||
|
||||
Printing the room-description of something is an activity.
|
||||
|
||||
and then write a rule that applies to multiple rooms at once, like:
|
||||
|
||||
Rule for printing the room-description of a room when the player wears the sunglasses:
|
||||
say "The walls look like they're covered with ants. Just a coincidence, I'm sure."
|
||||
|
||||
Inform's usual rule-ranking also means that more-specific rules will override less-specific ones, so we could add
|
||||
|
||||
Rule for printing the room-description of the Kitchen when the player wears the sunglasses:
|
||||
say "Are ants coming out of the sink? No, probably not."
|
||||
|
||||
and have that rule override the behavior of the activity just in the kitchen. Meanwhile, our base room descriptions remain straightforward and uncluttered by if-statements.
|
||||
|
||||
Several other examples will show how to hook activities into existing actions: Crusoe goes into detail about how how to make the descriptions of things more variable, and Aftershock demonstrates activities for describing the behavior of switchable devices.
|
||||
|
||||
Here, we preview all of those methods, just to get a sense of how they work and why they might be useful in controlling a game. Subsequent chapters go into more detail about the syntax of creating activities and the list of activities that are already defined by Inform.
|
||||
|
||||
{*} "Ant-Sensitive Sunglasses"
|
||||
|
||||
Part 1 - Procedure
|
||||
|
||||
To add a new activity to an existing Inform rule, we need to do three things:
|
||||
|
||||
1) Define our new activity.
|
||||
2) Give a basic rule that says what is supposed to happen when that activity occurs, as in "Rule for..."
|
||||
3) Replace the existing rule in Inform's rulebooks with a new one that calls on our activity.
|
||||
|
||||
Here we do this with examining:
|
||||
|
||||
{**}Section 1 - Item Description
|
||||
|
||||
Printing the description of something is an activity.
|
||||
|
||||
Now, by default, we want to print the description property; we just want the option to write some extra rules overriding that property. So we tell Inform that our most basic rule for printing the description of something is just to give that description text:
|
||||
|
||||
{**}Rule for printing the description of something (called item):
|
||||
if the description of the item is not "":
|
||||
say "[description of item][paragraph break]";
|
||||
otherwise:
|
||||
say "You see nothing special about [the item].".
|
||||
|
||||
Next, we need the standard examining rule to look at our printing-the-description activity:
|
||||
|
||||
{**}The activity-based examining rule is listed instead of the standard examining rule in the carry out examining rules.
|
||||
|
||||
This is the activity-based examining rule:
|
||||
carry out the printing the description activity with the noun;
|
||||
rule succeeds.
|
||||
|
||||
Now we do the same thing to room descriptions.
|
||||
|
||||
{**}Section 2 - Room Description
|
||||
|
||||
Printing the room-description of something is an activity.
|
||||
|
||||
Rule for printing the room-description of a room (called item):
|
||||
if the description of the item is not "":
|
||||
say "[description of item][paragraph break]";
|
||||
otherwise:
|
||||
do nothing instead.
|
||||
|
||||
The activity-based room description body text rule is listed instead of the room description body text rule in the carry out looking rules.
|
||||
|
||||
Our replacement rule this time around is a little bit trickier just because the rule that we're replacing is a complicated one: describing a room already checks to see whether there's light to see by, whether the player has turned off room descriptions when he enters a room for the second time, and whether the player character is (say) inside a closed box he can't see out of.
|
||||
|
||||
But all of those details are re-copied from the standard rules, and the important thing is that, at the end, we again carry out our activity.
|
||||
|
||||
{**}This is the activity-based room description body text rule:
|
||||
if the visibility level count is 0:
|
||||
if set to abbreviated room descriptions, continue the action;
|
||||
if set to sometimes abbreviated room descriptions and
|
||||
abbreviated form allowed is true and
|
||||
darkness witnessed is true,
|
||||
continue the action;
|
||||
begin the printing the description of a dark room activity;
|
||||
if handling the printing the description of a dark room activity,
|
||||
say "It is pitch dark, and you can't see a thing.";
|
||||
end the printing the description of a dark room activity;
|
||||
otherwise if the visibility ceiling is the location:
|
||||
if set to abbreviated room descriptions, continue the action;
|
||||
if set to sometimes abbreviated room descriptions and abbreviated form
|
||||
allowed is true and the location is visited, continue the action;
|
||||
carry out the printing the room-description activity with the location.
|
||||
|
||||
Section 3 - Device Description
|
||||
|
||||
Showing action of something is an activity.
|
||||
|
||||
Rule for showing action of something (called item):
|
||||
if the item is switched on, say "[The item] is switched on.";
|
||||
otherwise say "[The item] is switched off."
|
||||
|
||||
The activity-based described devices rule is listed instead of the examine devices rule in the carry out examining rules.
|
||||
|
||||
This is the activity-based described devices rule:
|
||||
if the noun is a device:
|
||||
carry out the showing action activity with the noun;
|
||||
now examine text printed is true.
|
||||
|
||||
Report switching on something:
|
||||
say "You flip a switch. ";
|
||||
carry out the showing action activity with the noun instead.
|
||||
|
||||
Part 2 - Scenario
|
||||
|
||||
The Kitchen is a room. "A small kitchen tucked into a corner of the vacation house. There is storage space for five or six cups, a sink, a two-ring stove; nothing else to speak of."
|
||||
|
||||
The microwave is a device in the Kitchen.
|
||||
|
||||
South of the Kitchen is the Living Area. The description of the Living area is "A whitewashed living/dining/reclining area in what used to be a shepherd's stone hut, but now costs vacationers 600 euros a week. It offers no mod cons, only a straight view of the Mediterranean and a wobbly writing table."
|
||||
|
||||
Rule for printing the room-description of a room when the player wears the sunglasses:
|
||||
say "The walls look like they're covered with ants. Just a coincidence, I'm sure[antsy]."
|
||||
|
||||
Rule for printing the room-description of the Kitchen when the player wears the sunglasses:
|
||||
say "Are ants coming out of the sink? No, probably not[antsy]."
|
||||
|
||||
Rule for printing the description of something (called the item) when the player wears the sunglasses:
|
||||
say "[The item] [are] [one of]ant-colored[or]ant-legged[or]covered in ants[at random][antsy]."
|
||||
|
||||
Rule for showing action of the microwave:
|
||||
say "The microwave hums meaningfully to itself."
|
||||
|
||||
Rule for showing action of the microwave when the player wears the sunglasses:
|
||||
say "The microwave hums as though inhabited by a billion ants[antsy]."
|
||||
|
||||
The player carries sunglasses of freakiness and an apple. The apple is edible. The sunglasses are wearable.
|
||||
|
||||
ant-paranoia is a number that varies.
|
||||
|
||||
To say antsy:
|
||||
increase ant-paranoia by 1;
|
||||
|
||||
Every turn:
|
||||
if the ant-paranoia is greater than 3:
|
||||
say "Augh! AUUUGH! GET THEM OFF--";
|
||||
end the story saying "You have lost your mind."
|
||||
|
||||
Test me with "look / turn on microwave / turn off microwave / x apple / x sunglasses / s / wear sunglasses / look / x apple / n / turn on microwave".
|
35
Documentation/Examples/Anteaters.txt
Normal file
35
Documentation/Examples/Anteaters.txt
Normal file
|
@ -0,0 +1,35 @@
|
|||
** Stored actions
|
||||
(Device to remember and play back actions; Anteaters)
|
||||
The player carries a gizmo that is able to record actions performed by the player, then force him to repeat them when the gizmo is dropped. This includes storing actions that apply to topics, as in "look up anteater colonies in the guide".
|
||||
|
||||
{*} "Anteaters"
|
||||
|
||||
A book is a kind of thing. Understand "book" as a book. A book has a table name called the contents.
|
||||
|
||||
Report consulting a book about:
|
||||
say "You flip through [the noun], but find no reference to [the topic understood]." instead.
|
||||
|
||||
Instead of consulting a book about a topic listed in the contents of the noun:
|
||||
say "[reply entry][paragraph break]".
|
||||
|
||||
The Guide to Desert Fauna is a book. The contents of the Guide is the Table of Critters.
|
||||
|
||||
Table of Critters
|
||||
topic reply
|
||||
"spines" "You flip through the Guide for a while and eventually realise that spines are flora, not fauna."
|
||||
"anteater colonies" "The giant anteater, which grows to six feet in size and can kill a jaguar, is a solitary animal, found in many habitats, including grasslands, deciduous forests and rainforests. It does not form colonies. That's ants. They're actually quite easy to tell apart."
|
||||
|
||||
Death Valley is a room. The Guide is in the Valley.
|
||||
|
||||
The gizmo is in Death Valley. The gizmo has an action called idea. The description of the gizmo is "The gizmo is hard to describe, but it projects an idea of [idea]."
|
||||
|
||||
Before when the player carries the gizmo and the idea of the gizmo is waiting:
|
||||
say "[The gizmo] eagerly soaks up the whole idea of [the current action].";
|
||||
now the idea of the gizmo is the current action.
|
||||
|
||||
After dropping the gizmo:
|
||||
say "The percussion of the fall seems to have shaken the gizmo's idea loose! There's nothing for it now but [idea of the gizmo].";
|
||||
try the idea of the gizmo;
|
||||
now the idea of the gizmo is waiting.
|
||||
|
||||
Test me with "get guide / look up spines in guide / x gizmo / get gizmo / i / x gizmo / drop gizmo / get gizmo / look up anteater colonies in guide / x gizmo / drop gizmo".
|
64
Documentation/Examples/AppleCount.txt
Normal file
64
Documentation/Examples/AppleCount.txt
Normal file
|
@ -0,0 +1,64 @@
|
|||
* Asking which do you mean
|
||||
(Disambiguation question giving items more explicit names; Apples)
|
||||
Prompting the player on how to disambiguate otherwise similar objects.
|
||||
|
||||
Inform by default detects whether two objects can be disambiguated by any vocabulary available to the player. If so, it asks a question; if not, it picks one of the identical objects at random.
|
||||
|
||||
Generally this produces good behavior. Occasionally, though, two objects have some distinguishing characteristic that doesn't appear in the object name. For instance, suppose we've created a class of apples that can be told apart depending on whether they've been bitten or not:
|
||||
|
||||
An apple is a kind of thing. Consumption is a kind of value. The consumptions are pristine and bitten. An apple has a consumption. The description of an apple is "It is [consumption]."
|
||||
|
||||
Understand the consumption property as describing an apple.
|
||||
|
||||
The player can meaningfully type
|
||||
|
||||
>EAT BITTEN APPLE
|
||||
|
||||
or
|
||||
|
||||
>EAT PRISTINE APPLE
|
||||
|
||||
but if he types
|
||||
|
||||
>EAT APPLE
|
||||
|
||||
Inform will, annoyingly, ask
|
||||
|
||||
Which do you mean, an apple or the apple?
|
||||
|
||||
This gives the player no indication of why Inform is making a distinction. So here we add a special "printing the name" rule to get around that situation:
|
||||
|
||||
{*} "Apples"
|
||||
|
||||
Orchard is a room.
|
||||
|
||||
An apple is a kind of thing. Consumption is a kind of value. The consumptions are pristine and bitten. An apple has a consumption. The description of an apple is "It is [consumption]."
|
||||
|
||||
Understand the consumption property as describing an apple.
|
||||
|
||||
Before printing the name of an apple while asking which do you mean: say "[consumption] ". Before printing the plural name of an apple while asking which do you mean: say "[consumption] ".
|
||||
|
||||
The player carries three apples.
|
||||
|
||||
Instead of eating a pristine apple (called the fruit):
|
||||
say "You take a satisfying bite.";
|
||||
now the fruit is bitten.
|
||||
|
||||
Instead of eating a bitten apple (called the fruit):
|
||||
say "You consume the apple entirely.";
|
||||
now the fruit is nowhere.
|
||||
|
||||
Inform will also separate the bitten from the pristine apples in inventory listings and room descriptions, even though it's not clear why; we can improve on that behavior thus:
|
||||
|
||||
{**}Before listing contents: group apples together.
|
||||
|
||||
Rule for grouping together an apple (called target):
|
||||
let source be the holder of the target;
|
||||
say "[number of apples held by the source in words] apple[s], some bitten".
|
||||
|
||||
Before printing the plural name of an apple (called target):
|
||||
let source be the holder of the target;
|
||||
if every apple held by the source is bitten, say "bitten ";
|
||||
if every apple held by the source is pristine, say "pristine ".
|
||||
|
||||
Test me with "i / eat apple / i / eat apple / pristine / i / eat apple / pristine / i".
|
35
Documentation/Examples/Approximation.txt
Normal file
35
Documentation/Examples/Approximation.txt
Normal file
|
@ -0,0 +1,35 @@
|
|||
*** Text with numbers
|
||||
(Saying a number in round numbers; Ballpark)
|
||||
A new "to say" definition which allows the author to say "[a number in round numbers]" and get verbal descriptions like "a couple of" or "a few" as a result.
|
||||
|
||||
Sometimes it is more sensible to describe numbers roughly than in exact terms. For instance, we might want to have our player perceive "many people" rather than "forty-two people" on entering a room. To achieve this, we might write our own "to say" phrase.
|
||||
|
||||
{*}"Ballpark"
|
||||
|
||||
To say (count - a number) in round numbers:
|
||||
repeat through the Table of Numerical Approximation:
|
||||
if count is less than threshold entry:
|
||||
say "[approximation entry]";
|
||||
rule succeeds.
|
||||
|
||||
Phrases will be explained more thoroughly in a later chapter, but as we have already seen in the examples, we can make a "To say..." phrase that will allow us to create our own text substitutions. In this case, we are going to replace the specific number with a vaguer one chosen from a chart, so:
|
||||
|
||||
{**}Table of Numerical Approximation
|
||||
threshold approximation
|
||||
1 "no"
|
||||
2 "one"
|
||||
3 "a couple of"
|
||||
6 "a few"
|
||||
11 "some"
|
||||
21 "many"
|
||||
1000 "lots and lots of"
|
||||
|
||||
The idea here is that we will work our way through the table until we hit a line where the threshold number is higher than the number we want to express, and then print that output: so if we have less than one item, we'll print "no"; if we have more than none but less than two, we'll print "one"; if we have less than three, we'll print "a couple of"; if we have three, four, or five (but not six), we'll print "a few."
|
||||
|
||||
{**}A room has a number called the population. The population of a room is usually 0. The description of a room is usually "You observe [population of the location in round numbers] [if population of the location is 1]person [otherwise]people [end if]here.".
|
||||
|
||||
The Stadium is a room. The Hot Dog Stand is west of the Stadium. The Women's Restroom is south of the Stadium.
|
||||
|
||||
The population of the Stadium is 500. The population of the Hot Dog Stand is 3. The population of the Restroom is 750.
|
||||
|
||||
Test me with "w / e / s".
|
22
Documentation/Examples/Artemis.txt
Normal file
22
Documentation/Examples/Artemis.txt
Normal file
|
@ -0,0 +1,22 @@
|
|||
* Adjacent rooms and routes through the map
|
||||
(Person who moves randomly; Mistress of Animals)
|
||||
A person who moves randomly between rooms of the map.
|
||||
|
||||
Suppose we want a restless sort of character always pacing from room to room. It is quite easy to use adjacency to achieve this effect:
|
||||
|
||||
{*}"Mistress of Animals"
|
||||
|
||||
Corinth is a room. Athens is east of Corinth. Epidaurus is southeast of Corinth and east of Mycenae. Mycenae is south of Corinth. Olympia is west of Mycenae. Argos is south of Mycenae. Thebes is northwest of Athens. Pylos is south of Olympia. Sparta is east of Pylos and south of Argos. Delphi is northwest of Thebes.
|
||||
|
||||
Artemis is a woman in Thebes.
|
||||
|
||||
Every turn:
|
||||
if Artemis is in a room (called the current space):
|
||||
let next space be a random room which is adjacent to the current space;
|
||||
if Artemis is visible, say "Artemis heads to [the next space].";
|
||||
move Artemis to next space;
|
||||
if Artemis is visible, say "Artemis arrives from [the current space]."
|
||||
|
||||
Test me with "z / z / z / z / z / z".
|
||||
|
||||
Of course, it helps that Artemis is the sort to like open spaces. The implementation would become more complicated if there were doors which might block transit between these locations.
|
17
Documentation/Examples/Aspect.txt
Normal file
17
Documentation/Examples/Aspect.txt
Normal file
|
@ -0,0 +1,17 @@
|
|||
* Understanding things by their properties
|
||||
(Understanding units as part of the name of a thing--Television with aspect ratio; Aspect)
|
||||
Understanding aspect ratios (a unit) in the names of televisions.
|
||||
|
||||
Named properties are not the only kind that Inform is able to understand referring to an object. We can also use unit and number properties to distinguish things from one another, as here, where televisions have aspect ratios:
|
||||
|
||||
{*}"Aspect"
|
||||
|
||||
An aspect ratio is a kind of value. 16:9 specifies an aspect ratio.
|
||||
|
||||
A television is a kind of device. A television has an aspect ratio. Understand the aspect ratio property as referring to a television. Understand "European standard" as 16:9.
|
||||
|
||||
The Office is a room.
|
||||
|
||||
The widescreen TV is a television in the Office. The fifties TV is a television in the Office. The widescreen TV is 16:9. The fifties TV is 4:3.
|
||||
|
||||
Test me with "examine european standard tv / x 16:9 tv / x 4:3 tv".
|
39
Documentation/Examples/Athens.txt
Normal file
39
Documentation/Examples/Athens.txt
Normal file
|
@ -0,0 +1,39 @@
|
|||
*** Adjacent rooms and routes through the map
|
||||
(LOOK [direction] command; A View of Green Hills)
|
||||
A LOOK [direction] command which allows the player to see descriptions of the nearby landscape.
|
||||
|
||||
Suppose a game in which the player is wandering an open landscape with long vistas, allowing him to LOOK in some direction, or even look at an adjacent location.
|
||||
|
||||
{*}"A View of Green Hills"
|
||||
|
||||
Corinth is a room. Athens is east of Corinth. Epidaurus is southeast of Corinth and east of Mycenae. Mycenae is south of Corinth. Olympia is west of Mycenae. Argos is south of Mycenae. Thebes is northwest of Athens. Pylos is south of Olympia. Sparta is east of Pylos and south of Argos. Delphi is northwest of Thebes.
|
||||
|
||||
Understand "look [direction]" as facing.
|
||||
|
||||
Facing is an action applying to one visible thing.
|
||||
|
||||
Carry out facing:
|
||||
let the viewed item be the room noun from the location;
|
||||
if the viewed item is not a room, say "You can't see anything promising that way." instead;
|
||||
try looking toward the viewed item.
|
||||
|
||||
In rules about action handling, "noun" refers to the first object that the player has mentioned in his command, so if the player typed >LOOK WEST, "let the viewed item be the room noun from the location" would be processed as "let the viewed item be the room west from the location", and so on.
|
||||
|
||||
We can at need override the default behavior, if it is not going to be appropriate for the player to see the next room over. There is only sky above at any time, so...
|
||||
|
||||
{**}Instead of facing up:
|
||||
say "Above you is bright sky."
|
||||
|
||||
Understand "look toward [any adjacent room]" as looking toward. Understand "examine [any adjacent room]" as looking toward.
|
||||
|
||||
Looking toward is an action applying to one visible thing.
|
||||
|
||||
Carry out looking toward:
|
||||
say "You make out [the noun] that way."
|
||||
|
||||
This design allows us to create descriptions for rooms (as seen from the outside) which will work regardless of where we're looking from. For instance:
|
||||
|
||||
{**}Instead of looking toward Athens:
|
||||
say "Even from here you can make out the silhouette of the Acropolis."
|
||||
|
||||
Test me with "look north / look south / look up / look east / east / look west".
|
17
Documentation/Examples/Autodoor.txt
Normal file
17
Documentation/Examples/Autodoor.txt
Normal file
|
@ -0,0 +1,17 @@
|
|||
*** Text with variations
|
||||
(Door kind that describes the destination; Whence?)
|
||||
A kind of door that always automatically describes the direction it opens and what lies on the far side (if that other room has been visited).
|
||||
|
||||
It would be fairly tedious reading to have a large game full of doors that describe themselves this way. Nonetheless, if we insisted we could use our knowledge of the map as leverage to make every door in the game describe itself automatically.
|
||||
|
||||
To do this, we make use of the phrase "direction of (the door) from (a room)" -- in this case, the direction of the door we're looking at when viewed from the player's location. Thus:
|
||||
|
||||
{*}"Whence?"
|
||||
|
||||
The temporal vortex is an open door. It is west of Yesterday and east of Today.
|
||||
|
||||
The initial appearance of a door is usually "Nearby [an item described] leads [if the other side of the item described is visited][direction of the item described from the location] to [the other side][otherwise][direction of the item described from the location][end if]."
|
||||
|
||||
Test me with "w / e".
|
||||
|
||||
Yet a further variation on this, which can automatically understand "the east door" and "the west door" when appropriate, may be found in the example "Whither?".
|
87
Documentation/Examples/BNFRules.txt
Normal file
87
Documentation/Examples/BNFRules.txt
Normal file
|
@ -0,0 +1,87 @@
|
|||
*** The preamble of a rule
|
||||
(Backus-Naur form for rules)
|
||||
The full grammar Inform uses to parse rule definitions, in a standard computer-science notation.
|
||||
|
||||
Backus-Naur form, or BNF, is a standard notation used by computer scientists to specify more or less precisely what the valid programs are for a given programming language. It tends to provide a good description for a language such as C or Pascal, where contextual rules are limited, but the authors of Inform are doubtful that it is such a good tool for a natural-language system. For those who are interested, though, the following gives a formal specification for Inform's rules.
|
||||
|
||||
<rule> ::=
|
||||
Definition : A/an <kind> is <new adjectival name> if/unless <definition>
|
||||
| <preamble> : <phrases>
|
||||
| <preamble> , <phrase> (* only allowed for a few cases: see below)
|
||||
|
||||
<definition> ::=
|
||||
<condition>
|
||||
| its/his/her/their <value property name> is/are <value> or less/more
|
||||
| : <phrases>
|
||||
|
||||
<preamble> ::=
|
||||
To <phrase template>
|
||||
| To decide if/whether <phrase template>
|
||||
| To decide which/what <kind of value> is <phrase template>
|
||||
| This is the <rule name>
|
||||
| [[A] Rule for] <circumstances> [(this is the <rule name>)]
|
||||
|
||||
<circumstances> ::=
|
||||
At <time>
|
||||
| When <event name>
|
||||
| [<placement>] <rulebook reference> [while/when <condition>] [during <scene name>]
|
||||
|
||||
<rulebook reference> ::=
|
||||
<rulebook name> [about/for/of/on/rule] [<action pattern>]
|
||||
| <object-based-rulebook name> [about/for/of/on/rule] [<description>]
|
||||
|
||||
<placement> ::=
|
||||
a/an
|
||||
| [the] first
|
||||
| [the] last
|
||||
|
||||
<phrases> ::=
|
||||
<phrase>
|
||||
| <phrases> ; <phrase>
|
||||
|
||||
|
||||
The following examples show how Inform breaks down some typical rules using the system above:
|
||||
|
||||
<rule> = At 2:09 PM: increase the score by 2; say "Progress!"
|
||||
<preamble> = At 2:09 PM
|
||||
<circumstances> = At 2:09 PM
|
||||
At
|
||||
<time> = 2:09 PM
|
||||
:
|
||||
<phrases> = increase the score by 2; say "Progress!"
|
||||
<phrase> = increase the score by 2
|
||||
;
|
||||
<phrase> = say "Progress"
|
||||
|
||||
<rule> = Instead of eating the ostrich during Formal Dinner (this is the cuisine rule), say "It's greasy!"
|
||||
<preamble> = Instead of eating the ostrich during Formal Dinner (this is the cuisine rule)
|
||||
<circumstances> = Instead of eating the ostrich during Formal Dinner
|
||||
<rulebook reference> = Instead of eating the ostrich
|
||||
<rulebook name> = Instead
|
||||
of
|
||||
<action pattern> = eating the ostrich
|
||||
during
|
||||
<scene name> = Formal Dinner
|
||||
(
|
||||
this
|
||||
is
|
||||
the
|
||||
<rule name> = cuisine rule
|
||||
)
|
||||
,
|
||||
<phrases> = say "It's greasy!"
|
||||
<phrase> = say "It's greasy!"
|
||||
|
||||
<rule> = After printing the name of a container: say "!"
|
||||
<preamble> = After printing the name of a container
|
||||
<circumstances> = After printing the name of a container
|
||||
<rulebook reference> = After printing the name of a container
|
||||
<object-based-rulebook name> = After printing the name
|
||||
of
|
||||
<description> = a container
|
||||
:
|
||||
<phrases> = say "!"
|
||||
<phrase> = say "!"
|
||||
|
||||
|
||||
(*) The colon dividing a rule preamble from its definition can be replaced by a comma only if the preamble begins with the words "Instead of", "Before", "After", "Every turn" or "When", and if the definition consists only of a single phrase.
|
57
Documentation/Examples/Ballroom.txt
Normal file
57
Documentation/Examples/Ballroom.txt
Normal file
|
@ -0,0 +1,57 @@
|
|||
** Repeat running through
|
||||
(People who interact with each other each turn; Strictly Ballroom)
|
||||
People who select partners for dance lessons each turn.
|
||||
|
||||
Many simple repetitions can effectively be done with a "now..." instruction: it is quicker to say
|
||||
|
||||
now every person is angry
|
||||
|
||||
than
|
||||
|
||||
repeat with offended party running through people:
|
||||
now the offended party is angry.
|
||||
|
||||
Repeat comes in handy when we have something a bit more complicated to do with each item:
|
||||
|
||||
{*}"Strictly Ballroom"
|
||||
|
||||
A person can be alert or occupied. A person is usually alert.
|
||||
|
||||
When play begins:
|
||||
now the player is occupied.
|
||||
|
||||
Dance is a kind of value. The dances are waltzes, polkas, cha-chas, charlestons, fox-trots, tangos, lambadas, and two-steps.
|
||||
|
||||
The current round is a dance that varies.
|
||||
|
||||
Manner is a kind of value. The manners are swiftly, primly, energetically, suavely, seductively, elegantly, and badly.
|
||||
|
||||
Every turn: now the current round is a random dance.
|
||||
|
||||
Every turn:
|
||||
repeat with dancer running through people who are not the player:
|
||||
if dancer is alert:
|
||||
now dancer is occupied;
|
||||
let partner be a random alert person who is not the dancer;
|
||||
if partner is a person:
|
||||
now partner is occupied;
|
||||
say "[The dancer] [the current round][if a random chance of 1 in 5 succeeds] [a random manner][end if] with [partner]. ";
|
||||
otherwise:
|
||||
say "[paragraph break][The dancer] is forced to be a wallflower. Poor [dancer]. ";
|
||||
say paragraph break.
|
||||
|
||||
Notice we did not say "repeat with dancer running through alert people who are not the player...". This is because Inform would draw up a list of alert people at the beginning of the repeat, and not take into account which people became occupied partway through the repetition. If we want to make sure that each person dances only with one other person, we have to continue checking alertness each time we run through the repetition.
|
||||
|
||||
After all the partners are assigned, we can set up for the next turn by making everyone alert again, and for this we do not need "repeat":
|
||||
|
||||
{**}Every turn: now every person is alert; now the player is occupied.
|
||||
|
||||
Before doing something to someone: now the noun is occupied.
|
||||
|
||||
Before doing something when the second noun is a person: now the second noun is occupied.
|
||||
|
||||
Instead of doing something to someone: say "You successfully distract [the noun]."
|
||||
|
||||
The Pacific Ballroom is a room. "A rather utilitarian space at the moment, since this is a class and not a party." Timmy, Tommy, Joey, George, Mary, Martha, Yvette, McQueen, Linus, and Patricia are people in the Pacific Ballroom.
|
||||
|
||||
Test me with "z / ask linus about blanket / z / z".
|
79
Documentation/Examples/Bargaining.txt
Normal file
79
Documentation/Examples/Bargaining.txt
Normal file
|
@ -0,0 +1,79 @@
|
|||
** Arithmetic with units
|
||||
(OFFER price FOR command allowing player to bargain; Money for Nothing)
|
||||
An OFFER price FOR command, allowing the player to bargain with a flexible seller.
|
||||
|
||||
{*}"Money for Nothing"
|
||||
|
||||
Section 1 - Prices and Bargaining
|
||||
|
||||
Price is a kind of value. $10.99 specifies a price with parts dollars and cents (optional, preamble optional).
|
||||
|
||||
A person has a price called wealth. The wealth of the player is $15.
|
||||
|
||||
A thing has a price called minimum value. The minimum value of a thing is usually $0.50.
|
||||
|
||||
A thing has a price called desired value. The desired value of a thing is usually $5.00.
|
||||
|
||||
Offering it for is an action applying to one price and one visible thing.
|
||||
|
||||
Understand "offer [price] for [something]" as offering it for.
|
||||
|
||||
After taking inventory, say "You have [the wealth of the player]."
|
||||
|
||||
Check offering it for:
|
||||
if the price understood is greater than the wealth of the player, say "You don't have that kind of cash." instead;
|
||||
if the second noun is not carried by someone, say "There's no one in a position to sell you [the second noun]." instead;
|
||||
if the second noun is carried by the player, say "[The second noun] is already yours." instead;
|
||||
if the minimum value of the second noun is greater than the price understood, say "[The holder of the second noun] cackles disdainfully. 'If yer just here to insult me you can take your business elsewhere!' he says." instead;
|
||||
if the desired value of the second noun is greater than the price understood:
|
||||
let difference be the desired value of the second noun minus the price understood;
|
||||
let difference be difference divided by two;
|
||||
decrease the desired value of the second noun by difference;
|
||||
now the last object offered is the second noun;
|
||||
say "'How about [desired value of the second noun]?' suggests [the holder of the second noun]." instead;
|
||||
otherwise:
|
||||
unless the desired value of the second noun is the price understood:
|
||||
say "From the avaricious gleam in the eye of [the holder of the second noun], you guess you could've gotten this purchase for less..."
|
||||
|
||||
Carry out offering it for:
|
||||
increase the wealth of the holder of the second noun by the price understood;
|
||||
decrease the wealth of the player by the price understood;
|
||||
move the second noun to the player.
|
||||
|
||||
Report offering it for:
|
||||
say "You spend [the price understood], and now you possess [the second noun]."
|
||||
|
||||
When play begins: now right hand status line is "Your funds: [wealth of the player]".
|
||||
|
||||
Now, since the man does make counter-offers, it would be reasonable to let the player accept or reject those, as well:
|
||||
|
||||
{**}The last object offered is a thing that varies.
|
||||
|
||||
Instead of saying yes when the last object offered is carried by a person (called seller) who is not the player:
|
||||
if the seller is not visible:
|
||||
continue the action;
|
||||
otherwise:
|
||||
now the price understood is the desired value of the last object offered;
|
||||
try offering the desired value of the last object offered for the last object offered.
|
||||
|
||||
Instead of saying no when the last object offered is carried by a person (called seller) who is not the player:
|
||||
if the seller is not visible:
|
||||
continue the action;
|
||||
otherwise:
|
||||
now the last object offered is the player;
|
||||
say "You reject the offer firmly."
|
||||
|
||||
And we borrow just a line or two from a later chapter to take care of some alternate syntax the player might try:
|
||||
|
||||
{**}Understand "offer [price] to [someone]" as a mistake ("You'll need to specify what you want to buy -- try OFFER $1000.00 FOR BROOKLYN BRIDGE."). Understand "offer [someone] [price]" as a mistake ("You'll need to specify what you want to buy -- try OFFER $1000.00 FOR BROOKLYN BRIDGE.").
|
||||
|
||||
Understand "buy [something]" as a mistake ("You'll have to name your price: try OFFER $1000.00 FOR BROOKLYN BRIDGE.").
|
||||
|
||||
Section 2 - The Scenario
|
||||
|
||||
The Flea Market is a room. The crotchety man is a man in the Market. "A crotchety man here is selling [the list of things carried by the crotchety man]." The crotchety man carries a broken television set, a Victorian rhinestone brooch, and a cracked shaving mug.
|
||||
|
||||
The minimum value of the brooch is $2.50.
|
||||
|
||||
Test me with "offer $0.50 for mug / offer $0.50 to man / offer $6.00 for mug / offer $50.00 for brooch / offer $1.50 for brooch / offer $4.50 for brooch / no / offer $4.50 for brooch / yes".
|
||||
|
51
Documentation/Examples/BaritoneBass.txt
Normal file
51
Documentation/Examples/BaritoneBass.txt
Normal file
|
@ -0,0 +1,51 @@
|
|||
*** Understanding values
|
||||
(Allowing the player to describe his character before starting play; Baritone, Bass)
|
||||
Letting the player pick a gender (or perhaps other characteristics) before starting play.
|
||||
|
||||
The "reading a command" activity is rather advanced; for the moment, what we need to understand is that we're intervening in commands at the start of play and insisting that the player's first instruction to the game consist of a choice of gender. After that point, the gender will be set and play will proceed as normal.
|
||||
|
||||
In order to do the parsing, we define gender as a kind of value, and give several alternate names to each gender.
|
||||
|
||||
{*}"Baritone, Bass"
|
||||
|
||||
Getting Started is a room.
|
||||
|
||||
Gender is a kind of value. The genders are masculine, feminine, and unknown. Understand "male" or "man" or "M" as masculine. Understand "female" or "woman" or "F" as feminine.
|
||||
|
||||
A person has a gender. The gender of the player is unknown.
|
||||
|
||||
When play begins:
|
||||
now the command prompt is "Please choose a gender for your character. >".
|
||||
|
||||
After reading a command when the gender of the player is unknown:
|
||||
if the player's command includes "[gender]":
|
||||
now the gender of the player is the gender understood;
|
||||
if the gender of the player is unknown:
|
||||
say "This story requires a selection of male or female. [run paragraph on]";
|
||||
reject the player's command;
|
||||
if the gender of the player is masculine, now the player is male;
|
||||
if the gender of the player is feminine, now the player is female;
|
||||
say "[line break]Thank you. We now begin...";
|
||||
now the command prompt is ">";
|
||||
move the player to Sandy Beach;
|
||||
reject the player's command;
|
||||
otherwise:
|
||||
say "Sorry, we're not ready to go on yet. [run paragraph on]";
|
||||
reject the player's command.
|
||||
|
||||
Sandy Beach is a room.
|
||||
|
||||
Instead of examining the player when the player is female:
|
||||
say "Congratulations, you are a girl!"
|
||||
|
||||
Instead of examining the player when the player is male:
|
||||
say "Congratulations, you are a boy!"
|
||||
|
||||
If we had a whole series of things to ask the player about, we might define a whole series of kinds of value
|
||||
|
||||
The vocal ranges are soprano, mezzosoprano, contralto...
|
||||
|
||||
and use a "construction stage" variable to keep track of the current stage of character-construction, as in
|
||||
|
||||
After reading a command when the current construction stage is choosing a vocal range:
|
||||
...
|
41
Documentation/Examples/Barter.txt
Normal file
41
Documentation/Examples/Barter.txt
Normal file
|
@ -0,0 +1,41 @@
|
|||
*** Check rules for actions by other people
|
||||
(GIVE action for other characters; Barter Barter)
|
||||
Allowing characters other than the player to give objects to one another, accounting for the possibility that some items may not be desired by the intended recipients.
|
||||
|
||||
By default, if we make no modifications, telling one player to give something to another will fail, even if persuasion succeeds. This is because the default behavior of the GIVE command is interrupted by the "block giving rule" -- since in many cases we do not want people to exchange objects freely.
|
||||
|
||||
However, suppose that we do want characters to be able to exchange articles freely: we allow persuasion to succeed and turn off the "block giving rule".
|
||||
|
||||
{*}"Barter Barter"
|
||||
|
||||
The block giving rule is not listed in the check giving it to rules.
|
||||
|
||||
A persuasion rule for asking people to try giving: persuasion succeeds.
|
||||
|
||||
The Trading Post is a room.
|
||||
|
||||
Meriwether Lewis is a man in the Trading Post. He carries a fluffy handmade quilt and a bag of beans. The beans are edible.
|
||||
|
||||
William Clark is a man in the Trading Post. He carries leather slippers, a journal, and a loaf of bread. The bread is edible. The slippers are wearable.
|
||||
|
||||
Instead of examining someone:
|
||||
say "[The noun] is carrying [the list of things carried by the noun]."
|
||||
|
||||
And now we might want to implement a way to keep track of whether the recipient character wants what's being offered:
|
||||
|
||||
{**}Check someone trying giving something to someone (this is the sneering refusal rule):
|
||||
if the second noun dislikes the noun, stop the action.
|
||||
|
||||
Unsuccessful attempt by someone trying doing something:
|
||||
if the reason the action failed is the sneering refusal rule, say "'Would you care for [the noun]?' [the person asked] asks solicitously of [the second noun].
|
||||
|
||||
But [the second noun] refuses [the noun] disdainfully.";
|
||||
otherwise say "[The person asked] just appears bewildered by this improbable instruction."
|
||||
|
||||
Distaste relates one person to various things. The verb to dislike means the distaste relation.
|
||||
|
||||
Clark dislikes the beans. Lewis dislikes the bread.
|
||||
|
||||
Since we've defined this as a relation, we could change what the characters like and dislike during the course of the game, freely; for instance, characters might grow hungry and suddenly like all the edible articles.
|
||||
|
||||
{**}Test me with "x lewis / x clark / clark, give the slippers to lewis / clark, give the bread to lewis".
|
34
Documentation/Examples/BaseWindow.txt
Normal file
34
Documentation/Examples/BaseWindow.txt
Normal file
|
@ -0,0 +1,34 @@
|
|||
** Doors
|
||||
(Basic window similar to a door; Escape)
|
||||
Window that can be climbed through or looked through.
|
||||
|
||||
Suppose we want to offer the player a window he can climb through, instead of a boring ordinary door. Our window will be like a door in that it connects two rooms, appears in both places, and impedes movement when it is shut. But we also want to add that we can look through it and see what lies on the other side; and we further want to understand "climb through window" or "jump through window" as attempts to pass through it.
|
||||
|
||||
We'll start by defining a couple of rooms and making the window a door between them.
|
||||
|
||||
{*}"Escape"
|
||||
|
||||
Your Bedroom is a room. The bedroom window is a door. It is west of Your Bedroom and east of the Grassy Slope.
|
||||
|
||||
Now we have a "bedroom window" object which can be entered. Now, to catch the case where the player types "LOOK THROUGH WINDOW":
|
||||
|
||||
{**}Instead of searching the window:
|
||||
say "Through the window, you make out [the other side of the window]."
|
||||
|
||||
The other side of a door is always defined to be the room that we are not currently in when doing the check. When we are in the bedrooom, the other side will be the grassy slope, and vice versa. "Searching" is the action that occurs when the player attempts to LOOK THROUGH something. (To review what grammar gives rise to what actions, we can always consult the Actions portion of the Index.)
|
||||
|
||||
Next we want to cover the case where we climb through the window:
|
||||
|
||||
{**}Instead of climbing the window:
|
||||
try entering the window.
|
||||
|
||||
And because "climb window" is understood but "climb THROUGH window" is not, we will have to borrow from the chapter on Understanding to add some new vocabulary to the game (and we'll add Jump too, while we're at it):
|
||||
|
||||
{**}Understand "climb through [something]" as climbing. Understand "jump through [something]" as climbing.
|
||||
|
||||
Now the final piece: Inform will already keep the player from going through a closed window, but it will say "You can't, since the bedroom window is in the way." This is probably not ideal, so we can replace the instruction thus:
|
||||
|
||||
{**}Instead of going through the closed window:
|
||||
say "The window is shut: you'd break the glass."
|
||||
|
||||
Test me with "look through window / climb through window / open window / climb through window / look through window / close window / e / open window / e".
|
116
Documentation/Examples/Batteries.txt
Normal file
116
Documentation/Examples/Batteries.txt
Normal file
|
@ -0,0 +1,116 @@
|
|||
*** Every turn
|
||||
(Witnessed: 1. Batteries, swappable between devices--Batteries that can power devices and eventually run down)
|
||||
A kind of battery which can be put into different devices, and which will lose power after extended use.
|
||||
|
||||
The following example makes fairly ample use of material that we haven't seen yet, but gives some idea of the flexibility of every turn rules. Suppose we want to have a number of electrical devices, all of which may be powered by a set of batteries. The batteries will all need to be discharged as they are used (regardless of what device they happen to be controlling at the moment). So:
|
||||
|
||||
{*}"Witnessed"
|
||||
|
||||
A battery is a kind of thing. A battery has a number called charge. The charge of a battery is usually 15.
|
||||
|
||||
Every turn:
|
||||
repeat with hollow running through battery compartments:
|
||||
if the hollow is part of a switched on device (called the machine):
|
||||
if a battery (called cell) is in the hollow:
|
||||
decrement the charge of the cell;
|
||||
carry out the warning about failure activity with the machine;
|
||||
if the cell is discharged, carry out the putting out activity with the machine;
|
||||
otherwise:
|
||||
carry out the putting out activity with the machine.
|
||||
|
||||
Warning about failure of something is an activity.
|
||||
|
||||
Rule for warning about failure of a device (called the machine):
|
||||
if a random battery compartment which is part of the machine contains a battery (called the power source):
|
||||
if the charge of the power source is 2, say "[The machine] is obviously going to go out quite soon."
|
||||
|
||||
Putting out something is an activity.
|
||||
|
||||
Rule for putting out a device (called the machine):
|
||||
say "[The machine] loses power and switches off![line break]";
|
||||
silently try switching off the machine.
|
||||
|
||||
A battery compartment is a kind of container. A battery compartment is usually closed and openable. One battery compartment is part of every device. Instead of inserting something which is not a battery into a battery compartment, say "Only batteries should go in a battery compartment."
|
||||
|
||||
And to get rid of annoying messages like "Which would you like to close, the flashlight or the flashlight's battery compartment?" when only the compartment is closable, we might add some understanding instructions:
|
||||
|
||||
{**}Understand "turn on [device]" as switching on.
|
||||
|
||||
Understand "turn off [device]" as switching off.
|
||||
|
||||
Understand "open [openable closed thing]" as opening.
|
||||
|
||||
Understand "close [openable open thing]" as closing.
|
||||
|
||||
Understand "put [something] in [container]" as inserting it into.
|
||||
|
||||
Instead of opening a device, try opening a random battery compartment which is part of the noun. Instead of closing a device, try closing a random battery compartment which is part of the noun. Instead of inserting a battery into a device, try inserting the noun into a random battery compartment which is part of the second noun.
|
||||
|
||||
Instead of switching on an empty device:
|
||||
say "Nothing happens, perhaps because there isn't a charged battery in [the noun]."
|
||||
|
||||
Instead of switching on a battery compartment which is part of a device (called the power user), try switching on the power user.
|
||||
|
||||
Definition: a device is empty:
|
||||
if a random battery compartment which is part of it contains a battery (called the power source):
|
||||
if the power source is discharged, yes;
|
||||
no;
|
||||
yes.
|
||||
|
||||
Definition: a battery is discharged if its charge < 1.
|
||||
|
||||
A light source is a kind of device. Carry out switching on a light source: now the noun is lit. Carry out switching off a light source: now the noun is unlit.
|
||||
|
||||
The flashlight is a light source. A D battery is a battery carried by the player.
|
||||
|
||||
The cassette recorder is a device. Every turn: if the cassette recorder is switched on, say "The cassette recorder hisses faintly."
|
||||
|
||||
Rule for warning about failure of the cassette recorder:
|
||||
if a random battery compartment which is part of the cassette recorder contains a battery (called the power source):
|
||||
if the charge of the power source is 2, say "The hiss from [the cassette recorder] begins to warble ominously."
|
||||
|
||||
The player wears a backpack. The backpack is openable. In the backpack is the flashlight and the cassette recorder.
|
||||
|
||||
The description of the cassette recorder is "Useful both for recording your notes and for capturing any odd ghostly sounds you may hear."
|
||||
|
||||
The description of the backpack is "An old familiar pack, which you know so well that you can find all its pockets and take things in and out of it in pitch darkness. To avoid it showing up oddly in photographs, it is entirely black, with no shiny or metallic attachments."
|
||||
|
||||
The description of the flashlight is "You bought a new one just for this occasion, because you were worried about bringing something too small or light. This is a heavy-duty flashlight with an adjustable-focus beam. The case is made of metal, rather than plastic, and there is a spare light-bulb inside as well. You've put a band of masking tape around the handle and written in your initials in red marker.
|
||||
|
||||
There is a piece of red cellophane attached to the business end of the flashlight to keep it from being overly bright."
|
||||
|
||||
The red cellophane is part of the flashlight.
|
||||
|
||||
Instead of doing something to the red cellophane: say "You need the cellophane on the flashlight so that using it does not completely destroy your night vision."
|
||||
|
||||
Thirtieth Street Station is a room. "A huge, high, rectangular room with coffered ceilings, which looks grand but mostly makes you feel lonely and small. There are long benches in rows down the middle of the room, and an information desk with the train times, and a series of ticket windows, none of which matters very much at the moment."
|
||||
|
||||
The benches are an enterable supporter. They are scenery in the Station. The information desk is scenery in the Station. Some ticket windows are scenery in the Station. Instead of examining scenery in the Station: say "You're fairly sure that whatever is going on here has nothing to do with [the noun]." Understand "window" as ticket windows.
|
||||
|
||||
The mural is fixed in place in Thirtieth Street. "At the north side of the station is a particularly pointless and empty annex to the main room. It is dominated by a huge relief of sorts, and this is what you remember." Understand "metal" or "relief" or "huge" as the mural. The description of the mural is "It is both stylized and confusing, but you think it might be supposed to represent the various tasks and occupations of Philadelphia's population. The portions closer to the ground look as though they have recently been subjected to a light dusting of talcum powder. No unusual prints are evident."
|
||||
|
||||
The wind chimes are fixed in place in Thirtieth Street. "Carefully attached to the wall with a piece of duct tape and a hook is a light-weight set of wind chimes. Someone else has been here before you, it seems." The description is "Several of your friends use wind chimes as a sort of ghost alarm, since ghosts sometimes cause very localized movements of air when there is no natural breeze."
|
||||
|
||||
And this last bit, borrowed from the chapter on Understanding, adds some special instructions to help Inform decide when the player is likely to be referring to a compartment and when he's likely to be referring to the device itself.
|
||||
|
||||
{**}Does the player mean doing something other than searching to a battery compartment: it is unlikely. [We discourage Inform from choosing a compartment when the player uses just the name of a device or the word 'battery'.]
|
||||
|
||||
We also need to deal with commands like PUT BATTERY IN FLASHLIGHT, where Inform might construe BATTERY as the D battery, the flashlight's battery compartment, or the cassette recorder's battery compartment -- and might also construe FLASHLIGHT as either the flashlight's battery compartment or the flashlight itself.
|
||||
|
||||
{**}Does the player mean inserting into a battery compartment:
|
||||
if the noun is nothing:
|
||||
it is very likely;
|
||||
otherwise:
|
||||
make no decision.
|
||||
|
||||
Does the player mean inserting a battery compartment into: it is very unlikely.
|
||||
|
||||
Does the player mean inserting something into a device: it is unlikely.
|
||||
|
||||
Does the player mean searching a battery compartment: it is very likely.
|
||||
|
||||
Test me with "test first / test second".
|
||||
|
||||
Test first with "i / open flashlight compartment / put battery in it / turn on flashlight / take d battery / open cassette compartment / turn on cassette / put battery in cassette compartment / turn on cassette / z / z / z / z".
|
||||
|
||||
Test second with "get d battery / put d battery in flashlight compartment / turn on flashlight / z / z / z / z / z / z / turn off flashlight / z / z / turn on flashlight / z".
|
31
Documentation/Examples/Beachfront.txt
Normal file
31
Documentation/Examples/Beachfront.txt
Normal file
|
@ -0,0 +1,31 @@
|
|||
* In the presence of, and when
|
||||
(SEARCHing for an item which moves into play--Evidence hidden until item is searched; Beachfront)
|
||||
An item that the player can't interact with until he has found it by searching the scenery.
|
||||
|
||||
Suppose we have our player, a detective, searching for evidence; we don't want him to be able to use this evidence until he has performed the action that reveals it, but after that it should be visible in the room when he looks.
|
||||
|
||||
A simple way to do this is to start the object -- an envelope, in this scenario -- out of play, and only move it into the location when the player looks for it:
|
||||
|
||||
{*}"Beachfront"
|
||||
|
||||
The Stuffy Office is a room. "The windows are closed, making the sultry air even more unbearable. A narrow slice of Caribbean blue is visible between the scuba gear rental shop and the recreated 17th century pirate tavern.
|
||||
|
||||
The office is cheerfully furnished with wicker chairs and white curtains, but the tropical decorating scheme stopped at the desk, which is heavy oak and absolutely covered with papers."
|
||||
|
||||
The heavy oak desk is a supporter in the stuffy office. It is scenery. Understand "paperwork" as the desk.
|
||||
|
||||
The creamy envelope is an openable container. The description is "There is no return address on the outside of the envelope, just the address of the Doctor's office -- but the legs of the capital A are rubbed down in a characteristic way, and the top of every R is open. There's no question that it comes from the same typewriter as the blackmail note." In the envelope is a letter. The envelope can be found or lost. The envelope is lost.
|
||||
|
||||
Instead of searching the desk when the envelope is lost:
|
||||
now the envelope is found;
|
||||
say "You rifle through the piles of bills and notices; invitations to conventions; advertisements for high-end prescription drugs; pink carbon sheets bearing patients['] names and medical identification numbers in spidery, elderly handwriting. Almost at the bottom of the heap, you find what you were looking for: a creamy envelope with the address typed.";
|
||||
move the envelope to the desk.
|
||||
|
||||
Here we've changed the property of the envelope to keep track of the fact that it has been found, so that if the player tries again, he won't find anything more.
|
||||
|
||||
{**}Instead of searching the desk:
|
||||
say "Further investigation of the desk reveals nothing else suspicious."
|
||||
|
||||
Notice that we have two rules that apply to "searching the desk", but one of them has a more specific set of parameters ("when the envelope is lost"). This means that Inform will consult that rule first and use it if it applies; it will only carry out our plain vanilla "instead of searching the desk" rule when the more restricted rule is not relevant.
|
||||
|
||||
{**}Test me with "x envelope / x desk / search desk / look / get envelope / x envelope".
|
69
Documentation/Examples/Beer.txt
Normal file
69
Documentation/Examples/Beer.txt
Normal file
|
@ -0,0 +1,69 @@
|
|||
** Deciding the scope of something
|
||||
(Telescope allowing view of another room; Ginger Beer)
|
||||
A portable magic telescope which allows the player to view items in another room of his choice.
|
||||
|
||||
Suppose we want to have a pair of linked lenses so that the player can look into one of them and see things which occur in room containing the other lense.
|
||||
|
||||
We begin simply with a bit of environment for the player to wander around:
|
||||
|
||||
{*}"Ginger Beer"
|
||||
|
||||
The Ginger Beer Factory is a room. "In the center of the room is an enormous pot filled with crushed ginger, which seems to be bubbling slightly on its own. The fumes are overwhelming."
|
||||
|
||||
The pot is scenery in the Ginger Beer Factory. The description of the pot is "Cast iron." In the pot is a bubbling brew.
|
||||
|
||||
Instead of smelling the Ginger Beer Factory: try smelling the brew.
|
||||
|
||||
Instead of smelling the brew, say "You blink back tears."
|
||||
|
||||
The Storeroom is south of the Ginger Beer Factory. "The walls here are lined with a prodigious number of small, rounded bottles, each with a screw top and a smiling pirate on the label."
|
||||
|
||||
The Clippings Room is west of the Ginger Beer Factory. "A clean room lined with steel tables, for preparing ingredients."
|
||||
|
||||
Some steel tables are a supporter in the Clippings Room. They are scenery. The description is "They are roughly the size and height of laboratory worksurfaces."
|
||||
|
||||
The quantity of dandelion is on the steel tables. The description is "Horrible common weed."
|
||||
|
||||
The wooden box is on the steel tables. It is openable and closed. The description is "A large wooden box with a lid, used for ingredient storage. There is a label on the lid."
|
||||
|
||||
The label is part of the box. The description is "BURDOCK: the root beaten with a little salt and laid on the place suddenly easeth the pain thereof, and helpeth those that are bit by a mad dog:... the seed being drunk in wine 40 days together doth wonderfully help the sciatica: the leaves bruised with the white of an egg and applied to any place burnt with fire, taketh out the fire, gives sudden ease and heals it up afterwards.... The root may be preserved with sugar for consumption, stone and the lax."
|
||||
|
||||
The quantity of burdock is in the box. The description is "It looks like a kind of thistle."
|
||||
|
||||
Some bottles are in the Storeroom. They are scenery. The description is "They are smaller than the average bottle, because more potent." Instead of taking the bottles, say "Take one away and the whole lineup will cascade to the floor."
|
||||
|
||||
Now for the lenses themselves:
|
||||
|
||||
{**}A lense is a kind of thing.
|
||||
|
||||
The large end of the telescope is a lense in the Ginger Beer Factory. "There is a large glass lense propped against the wall, in which are reflected all the contents of the room." Understand "glass" or "lense" as the large end.
|
||||
|
||||
The small end of the telescope is a lense in the Storeroom. "There is a small glass lense sitting on the floor. Due to some curious effect of the optics, it appears to be giving a view of somewhere else entirely." Understand "glass" or "lense" as the small end. The description is "A gleaming lense about the size of a pound coin."
|
||||
|
||||
Here is the critical bit, which needs to be somewhat flexible, since the large end of the telescope could in theory be left anywhere in the game (and should still work).
|
||||
|
||||
{**}After deciding the scope of the player while the small end is carried by the player:
|
||||
let there be the holder of the large end;
|
||||
place there in scope.
|
||||
|
||||
Before searching the small end when the small end is not carried by the player:
|
||||
say "(first picking up [the small end] and holding it to your eye)";
|
||||
silently try taking the small end.
|
||||
|
||||
Instead of searching the small end when the player is not carrying the small end:
|
||||
say "It's too hard to look through the small end from a distance."
|
||||
|
||||
Instead of searching the large end,
|
||||
say "You see only your own reflection."
|
||||
|
||||
We also want to make sure that the player who looks through the small lense does not see the large lense listed among the contents of the other location:
|
||||
|
||||
{**}Definition: a thing is recognizable if it is not a lense.
|
||||
|
||||
Instead of searching the small end:
|
||||
let the far side be the holder of the large end of the telescope;
|
||||
say "You peer into the little lense and through it see, in [the far side], [the list of recognizable things in the far side]."
|
||||
|
||||
Test me with "examine lense / south / examine lense / look through lense / north / look through small lense".
|
||||
|
||||
And we're done.
|
31
Documentation/Examples/Bees.txt
Normal file
31
Documentation/Examples/Bees.txt
Normal file
|
@ -0,0 +1,31 @@
|
|||
* Now...
|
||||
(Maze with randomized room links; Bee Chambers)
|
||||
A maze with directions between rooms randomized at the start of play.
|
||||
|
||||
Mazes are a traditional element of interactive fiction, often consisting of apparently identical rooms with exits that do not work reciprocally and which cause confusion.
|
||||
|
||||
The methods of mapping mazes are now fairly well understood and mazes themselves tend to be regarded as tiresome rather than enjoyable by a large portion of the playing audience. However, if we did want to ignore the common wisdom and create a maze, randomly generated at the start of play, here would be one way to go about it:
|
||||
|
||||
{*}"Maze of Gloom"
|
||||
|
||||
A Bee Chamber is a kind of room. The printed name of a Bee Chamber is usually "Hexagonal Room". The description of a Bee Chamber is usually "Waxy, translucent walls surround you on six sides; the floor and ceiling are made of the same material, gently uneven. There are exits in every direction, cut into the faces or the corners."
|
||||
|
||||
Bee1, Bee2, Bee3, Bee4, Bee5, Bee6, Bee7, Bee8, Bee9, and Bee10 are Bee Chambers.
|
||||
|
||||
When play begins:
|
||||
now right hand status line is "[number of visited rooms]/[number of rooms]";
|
||||
repeat with place running through Bee Chambers:
|
||||
now a random Bee Chamber is mapped north of place;
|
||||
now a random Bee Chamber is mapped northwest of place;
|
||||
now a random Bee Chamber is mapped west of place;
|
||||
now a random Bee Chamber is mapped southwest of place;
|
||||
now a random Bee Chamber is mapped south of place;
|
||||
now a random Bee Chamber is mapped southeast of place;
|
||||
now a random Bee Chamber is mapped east of place;
|
||||
now a random Bee Chamber is mapped northeast of place;
|
||||
now a random Bee Chamber is mapped above place;
|
||||
now a random Bee Chamber is mapped below place;
|
||||
now a random Bee Chamber is mapped inside place;
|
||||
now a random Bee Chamber is mapped outside place.
|
||||
|
||||
Test me with "in / out / up / down / n / ne / nw / e / w / sw / se / s".
|
11
Documentation/Examples/Belfry.txt
Normal file
11
Documentation/Examples/Belfry.txt
Normal file
|
@ -0,0 +1,11 @@
|
|||
* Articles and proper names
|
||||
(Characters and objects with titles and special articles; Belfry)
|
||||
You can see a bat, a bell, some woodworm, William Snelson, the sexton's wife, a bellringer and your local vicar here.
|
||||
|
||||
{*}"Belfry"
|
||||
|
||||
The Belfry is a room. A bat is in the Belfry. The bell is in the Belfry. Some woodworm are in the Belfry. A man called William Snelson is in the Belfry. A woman called the sexton's wife is in the Belfry. A man called a bellringer is in the Belfry.
|
||||
|
||||
In the Belfry is a man called the vicar. The indefinite article of the vicar is "your local".
|
||||
|
||||
Test me with "look".
|
34
Documentation/Examples/Below.txt
Normal file
34
Documentation/Examples/Below.txt
Normal file
|
@ -0,0 +1,34 @@
|
|||
** Devices and descriptions
|
||||
(Basic switchable light for a room; Down Below)
|
||||
A light switch which makes the room it is in dark or light.
|
||||
|
||||
Suppose we want to have a room with a light switch. Turning the switch off makes the room go dark; turning it on restores the light. This kind of switch is an obvious candidate as a device.
|
||||
|
||||
{*}"Down Below"
|
||||
|
||||
Terrifying Basement is a room. The light switch is a switched on device in the Terrifying Basement. It is fixed in place.
|
||||
|
||||
Here we define our light switch, and we also make it start out as "switched on". The Terrifying Basement will also start out lit (as all rooms do, by default, unless we specifically say that they are dark). We further say that it is fixed in place to avoid the ludicrous possibility of the player picking it up and carrying it away.
|
||||
|
||||
Next we add some instructions to control how turning the light switch on and off affects the room light. These borrow from later chapters on actions, but the gist may be obvious anyway:
|
||||
|
||||
{**}Carry out switching off the light switch: now the Terrifying Basement is dark.
|
||||
|
||||
Carry out switching on the light switch: now the Terrifying Basement is lighted.
|
||||
|
||||
Inform already has the idea of light and darkness built in; we will see more about this later, and the Phrasebook (in the Index tab) also contains a list of all the adjectives (lighted, dark, etc) which are important to use here.
|
||||
|
||||
Speaking of the Index, the Actions tab contains a list of all the grammar that can be used to activate a given command: for instance, the switching action responds to "switch [something]" or "turn on [something]". In this case, we may want to give the player an extra option or two. It would be pretty natural for a player to try >FLIP SWITCH, so let's add that in:
|
||||
|
||||
{**}Understand "flip [something switched off]" as switching on. Understand "flip [something switched on]" as switching off. Understand "flip [something]" as switching on.
|
||||
|
||||
The nuances of this will be explored in the chapter on Understanding. What is useful to know here is that we have taught Inform to understand that >FLIP LIGHT SWITCH means to turn it on when the switch is already off; if the switch is already on, FLIP SWITCH means to turn the switch off. Depending on the kind of device we are modeling (button? lever? dial?), we might want to write similar lines for commands such as PUSH, PRESS, PULL, TURN, and so on.
|
||||
|
||||
Finally, we need to deal with a special case. In general, the player cannot interact with other things in a dark room because he can't see them, but if we adhered strictly to this it would be impossible for him to find the light switch to turn it back on. So we need something from the chapter on Activities to change this:
|
||||
|
||||
{**}After deciding the scope of the player when the location is the Terrifying Basement:
|
||||
place the light switch in scope.
|
||||
|
||||
Upstairs is above the Terrifying Basement.
|
||||
|
||||
Test me with "turn off light / look / flip light switch".
|
57
Documentation/Examples/BestTillLast.txt
Normal file
57
Documentation/Examples/BestTillLast.txt
Normal file
|
@ -0,0 +1,57 @@
|
|||
** Multiple action processing
|
||||
(Reordering multiple objects for dramatic effect; The Best Till Last)
|
||||
Reordering multiple objects for dramatic effect.
|
||||
|
||||
If a single command asks to do many things, some dull and some exciting, we may want to save the good ones for the end.
|
||||
|
||||
{*}"The Best Till Last"
|
||||
|
||||
The Funky Ignition Lounge is a room. "This is where all evenings end." The stick of gelignite, the solid magnesium footstool, the vetiver candle, and the vodka bottle are here.
|
||||
|
||||
The burn description of the vetiver candle is "It burns right down, expensively but gothically."
|
||||
|
||||
The player carries an inexpensive firework. The description of the firework is "It is a cardboard tube with red and green stripes along the outside, and a fuse sticking out of the end." The burn description of the firework is "It ignites gloriously! You take a few hasty steps back in order to avoid burning yourself, and not a moment too soon. Red and green sparks fly out of the tube, and there's a whistling noise punctuated by several loud cracks."
|
||||
|
||||
The player carries a lighter. The description of the lighter is "You don't smoke, but you like to have access to flame now and then anyway."
|
||||
|
||||
Burning it with is an action applying to one thing and one carried thing.
|
||||
|
||||
Understand "burn [things] with [something preferably held]" as burning it with.
|
||||
|
||||
The block burning rule is not listed in any rulebook.
|
||||
|
||||
A thing has some text called the burn description.
|
||||
|
||||
Check burning something:
|
||||
if the player carries the lighter:
|
||||
try burning the noun with the lighter;
|
||||
else:
|
||||
try burning the noun with the noun.
|
||||
|
||||
Check burning something with something when the second noun is not the lighter:
|
||||
say "Your trusty lighter is the best flame source available to you." instead.
|
||||
|
||||
Check burning something with something:
|
||||
if the burn description of the noun is "":
|
||||
say "Best not." instead.
|
||||
|
||||
Carry out burning something with something:
|
||||
remove the noun from play.
|
||||
|
||||
Report burning something with something:
|
||||
say "[burn description of the noun][line break]".
|
||||
|
||||
A multiple action processing rule when the action name part of the current action is the burning it with action (this is the orderly burn rule):
|
||||
let L be the multiple object list;
|
||||
let dull list be a list of objects;
|
||||
let fun list be a list of objects;
|
||||
repeat with item running through L:
|
||||
if the burn description of the item is "":
|
||||
add item to dull list;
|
||||
else:
|
||||
add item to fun list;
|
||||
let F be the dull list;
|
||||
add fun list to F;
|
||||
alter the multiple object list to F.
|
||||
|
||||
Test me with "burn all with lighter".
|
17
Documentation/Examples/Beverage.txt
Normal file
17
Documentation/Examples/Beverage.txt
Normal file
|
@ -0,0 +1,17 @@
|
|||
* Removing things from play
|
||||
(DRINKing a potion which then goes away--Liquid container removed when drunk; Beverage Service)
|
||||
A potion that the player can drink.
|
||||
|
||||
Some kinds of game objects -- food, for instance -- can only sensibly be used once, and should then be destroyed. The EAT command already implements this, but suppose we also had a category of drinkable potions:
|
||||
|
||||
{*}"Beverage Service"
|
||||
|
||||
A potion is a kind of thing. The sparkly blue potion is a potion carried by the player.
|
||||
|
||||
Level 3 is a room.
|
||||
|
||||
Instead of drinking a potion (called the drink):
|
||||
now the drink is nowhere;
|
||||
say "You quaff [the drink]. It goes down beautifully."
|
||||
|
||||
Test me with "drink sparkly / i".
|
47
Documentation/Examples/Bibliophilia.txt
Normal file
47
Documentation/Examples/Bibliophilia.txt
Normal file
|
@ -0,0 +1,47 @@
|
|||
** Context: understanding when
|
||||
(Bookshelf with numerous books; Bibliophilia)
|
||||
A bookshelf with a number of books, where the player's command to examine something will be interpreted as an attempt to look up titles if the bookshelf is present, but otherwise given the usual response.
|
||||
|
||||
Suppose we want a bookshelf with a very large number of books on it. They aren't to be taken or carried around in the game, but they should be mentioned, and the player should be allowed to look them up by name. Furthermore, the player's attempts to examine something unrecognized should be understood as an attempt to look up a title -- but only when the player is in the presence of the books. The rest of the time such requests should be rejected in the usual way.
|
||||
|
||||
{*}"Bibliophilia"
|
||||
|
||||
The Graduate Lounge is a room. "Shabby sofas; plastic cups remaining from the afternoon's pre-lecture espresso; a collection of Xena and Hercules figurines posed for ironic effect. It's somewhat depressing at this hour, when everyone has gone home."
|
||||
|
||||
The Classics Reading Room is south of the Lounge. "Not as large a collection as the one in the Library, but it contains copies of everything really essential for reference."
|
||||
|
||||
Understand "examine [text]" as examining as a book when the player is in the Reading Room. Understand "look up [text]" as examining as a book when the player is in the Reading Room.
|
||||
|
||||
Examining as a book is an action applying to one topic.
|
||||
|
||||
Carry out examining as a book:
|
||||
say "You can't find any such text."
|
||||
|
||||
Instead of examining as a book a topic listed in the Table of Book Titles:
|
||||
say "[description entry][paragraph break]"
|
||||
|
||||
Table of Book Titles
|
||||
topic title description
|
||||
"Reading Greek Death" or "reading/greek/death" or "greek death" "Reading Greek Death" "A dense orange paperback treatise on the development of Greek eschatology."
|
||||
"TAPA/Transactions/134-2" "TAPA 134-2" "Transactions of the American Philological Association from 2004."
|
||||
"Oxford Classical Dictionary" or "OCD/dictionary/classical/oxford" "Oxford Classical Dictionary" "A hefty reference with short articles on everything from Greek meter to ancient cosmetics."
|
||||
"Collected Dialogues of Plato" or "Plato/dialogues/hamilton/cairns" "Collected Dialogues of Plato" "All the Platonic dialogues -- some, admittedly, in rather tired translations -- but still a useful single volume, ed. Edith Hamilton and Huntington Cairns."
|
||||
"Adobe Illustrator CS User Guide" or "user guide" or "adobe illustrator" or "adobe/illustrator/cs/user/guide" "Adobe Illustrator CS User Guide" "Hello, how did this get here? A suspiciously familiar name is scribbled inside the front cover..."
|
||||
|
||||
Some books are scenery in the Reading Room. Understand "copies" or "book" or "shelf" or "shelves" as the books. Instead of examining the books:
|
||||
choose a random row in the Table of Book Titles;
|
||||
say "You scan the shelves and notice, among others, a volume entitled [italic type][title entry][roman type]."
|
||||
|
||||
Test me with "south / examine ocd / examine books / examine books / examine plato / n / x hercules / s / x hercules".
|
||||
|
||||
Now if we type >X HERCULES in the Lounge, we will get
|
||||
|
||||
>x hercules
|
||||
You can't see any such thing.
|
||||
|
||||
thanks to our somewhat slovenly implementation of the Lounge scenery; but in the Reading Room,
|
||||
|
||||
>x hercules
|
||||
You can't find any such text.
|
||||
|
||||
In practice we might also want to extend our coverage somewhat to handle a case where the player tried to take books from the bookshelf: currently that would not be understood.
|
22
Documentation/Examples/Bic.txt
Normal file
22
Documentation/Examples/Bic.txt
Normal file
|
@ -0,0 +1,22 @@
|
|||
* Descriptions
|
||||
(Checking for missed properties; Bic)
|
||||
Testing to make sure that all objects have been given descriptions.
|
||||
|
||||
It may occasionally be useful to check whether all objects in our game have a given property. Here we have a "not for release" section that will run at the start of the game and alert us to any objects lacking description:
|
||||
|
||||
{*}"Bic"
|
||||
|
||||
Section 1 - Testing descriptions - Not for release
|
||||
|
||||
When play begins (this is the run property checks at the start of play rule):
|
||||
repeat with item running through things:
|
||||
if description of the item is "":
|
||||
say "[item] has no description."
|
||||
|
||||
Section 2 - Story
|
||||
|
||||
The Staff Break Room is a room.
|
||||
|
||||
The player carries an orange, a Bic pen, and a napkin. The description of the orange is "It's a small hard pinch-skinned thing from the lunch room, probably with lots of pips and no juice."
|
||||
|
||||
The description of the napkin is "Slightly crumpled."
|
32
Documentation/Examples/BigSainsburys.txt
Normal file
32
Documentation/Examples/BigSainsburys.txt
Normal file
|
@ -0,0 +1,32 @@
|
|||
* Implicitly taking something
|
||||
(Implicit takes require time; The Big Sainsbury's)
|
||||
Making implicit takes add a minute to the clock, just as though the player had typed TAKE THING explicitly.
|
||||
|
||||
Implicit takes are a convenience to players; in general, we would like to avoid asking players to type any more obvious commands than strictly necessary, while allowing the computer to guess as much as it safely can.
|
||||
|
||||
Occasionally, though, we have designed a timed puzzle in which the player has a limited number of moves in which to accomplish his objectives. In that case, the implicit take complicates matters, because it means that a player who types
|
||||
|
||||
>EAT GATEAU
|
||||
(first taking the gateau...)
|
||||
|
||||
gets away with a spare move compared to the precise but naïf dupe who types
|
||||
|
||||
>TAKE GATEAU
|
||||
>EAT GATEAU
|
||||
|
||||
...and really, that doesn't seem quite fair. The way to fix this problem is to fill in the extra minute on the clock during the implicit take; and that is indeed what we do in the following example.
|
||||
|
||||
{*}"The Big Sainsbury's"
|
||||
|
||||
Sainsbury's is a room.
|
||||
|
||||
The crispy duck and the Guinness steak pie are edible things in Sainsbury's.
|
||||
|
||||
Rule for implicitly taking something:
|
||||
follow the advance time rule;
|
||||
continue the activity.
|
||||
|
||||
When play begins:
|
||||
now the right hand status line is "[time of day]".
|
||||
|
||||
Test me with "take crispy duck / eat crispy duck / eat steak pie".
|
15
Documentation/Examples/BikiniAtoll.txt
Normal file
15
Documentation/Examples/BikiniAtoll.txt
Normal file
|
@ -0,0 +1,15 @@
|
|||
* Printing the banner text
|
||||
(Banner printing at appropriate times; Bikini Atoll)
|
||||
Delaying the banner for later.
|
||||
|
||||
{*}"Bikini Atoll" by Edward Teller
|
||||
|
||||
The Hut and the Tropical Beach are rooms.
|
||||
|
||||
The conch shell is in the Hut. After taking the shell for the first time: say "As you gather the oddly-warm conch shell into your arms, you experience a sudden flash of deja-vu...[banner text]"; move the player to the Tropical Beach.
|
||||
|
||||
Rule for printing the banner text when the player is not carrying the shell: do nothing.
|
||||
|
||||
Test me with "look / examine shell / get shell / look".
|
||||
|
||||
(By tradition, and as a courtesy to all the people who have worked on Inform, authors ensure that the banner is printed some time near the beginning of each game played. So please only defer it, rather than suppress it altogether.)
|
24
Documentation/Examples/BlackButton.txt
Normal file
24
Documentation/Examples/BlackButton.txt
Normal file
|
@ -0,0 +1,24 @@
|
|||
** Directions
|
||||
(Exits added to a room; Prisoner's Dilemma)
|
||||
A button that causes a previously non-existent exit to come into being.
|
||||
|
||||
We can change the directions in the map in mid-game, though in practice this is rarely necessary. But suppose we do not want a door or any sign of a door to exist before the player takes some action, in this case pressing a button:
|
||||
|
||||
{*}"Prisoner's Dilemma"
|
||||
|
||||
Challenger's Waiting Room is a room. "The challenge is this: to wait as long as you can endure to do so in a room with no features and no clock. If you wait longer than all the other contestants, you win."
|
||||
|
||||
The button is fixed in place in the Challenger's Waiting Room. "The only item in view is a black recessed button."
|
||||
|
||||
Amid the Cheering Throng is a room.
|
||||
|
||||
Instead of pushing the button for the first time:
|
||||
change the east exit of the Challenger's Waiting Room to Amid the Cheering Throng;
|
||||
change the west exit of the Cheering Throng to the Challenger's Waiting Room;
|
||||
say "With a groan of gears, the east wall swings open! If you've lost now, well, you've lost..."
|
||||
|
||||
Test me with "e / push button / e / w".
|
||||
|
||||
Our instructions about pushing the button will be further explained in the chapter on Actions, but the thing to note here is that we can "change (whatever) exit" in order to set or re-set map directions. Notice that we have to set both directions explicitly: changing the east exit of the Waiting Room does not automatically also change the west exit of Amid the Cheering Throng.
|
||||
|
||||
This allows greater flexibility in our games but does require an extra line or so of work.
|
24
Documentation/Examples/Blackout.txt
Normal file
24
Documentation/Examples/Blackout.txt
Normal file
|
@ -0,0 +1,24 @@
|
|||
* Replacements
|
||||
(Filtering text output in room names; Blackout)
|
||||
Filtering the names of rooms printed while in darkness.
|
||||
|
||||
In this example, we want the names of rooms to be asterisked out if the player wanders around without the benefit of a candle. We can do this by treating the room names as text, then replacing every letter:
|
||||
|
||||
{*} "Blackout"
|
||||
|
||||
Tiny Room is a dark room. Absurdly Long-Named Room is a dark room. It is west of Tiny Room.
|
||||
|
||||
The Candle Factory is north of Tiny Room. It contains a beeswax candle. The beeswax candle is lit.
|
||||
|
||||
Rule for printing the name of a dark room:
|
||||
let N be "[location]";
|
||||
replace the regular expression "\w" in N with "*";
|
||||
say "[N]".
|
||||
|
||||
Test me with "w / look / e / n / get candle / s / w".
|
||||
|
||||
Notice that the hyphen in the Absurdly Long-Named Room does not get replaced. We could replace even that, if we liked, with
|
||||
|
||||
replace the regular expression "\S" in N with "*";
|
||||
|
||||
which would catch every character that is not a space.
|
46
Documentation/Examples/Blakeney.txt
Normal file
46
Documentation/Examples/Blakeney.txt
Normal file
|
@ -0,0 +1,46 @@
|
|||
*** Relations which express conditions
|
||||
(People introduced by relative; A Humble Wayside Flower)
|
||||
Relations track the relationships between one character and another. Whenever the player meets a relative of someone he already knows, he receives a brief introduction.
|
||||
|
||||
First we define the relationships we choose to acknowledge:
|
||||
|
||||
{*}"A Humble Wayside Flower"
|
||||
|
||||
Marriage relates one person to another (called the spouse). The verb to be married to means the marriage relation.
|
||||
|
||||
Fatherhood relates one person (called father) to various people. The verb to engender means the fatherhood relation.
|
||||
|
||||
For brevity, we will ignore the existence of mothers. It is a sad world.
|
||||
|
||||
{**}Siblinghood relates a person (called A) to a person (called B) when a person who engenders A engenders B. The verb to be sibling to means the siblinghood relation.
|
||||
|
||||
Family relates a person (called A) to a person (called B) when A is married to B or A engenders B or B engenders A or A is sibling to B. The verb to be related to means the family relation.
|
||||
|
||||
A person can be known or unknown. After printing the name of an unknown person (called the alien):
|
||||
if a known person (called the contact) is related to the alien:
|
||||
say " ([relation between alien and contact] of [the contact])";
|
||||
now the alien is known;
|
||||
rule succeeds.
|
||||
|
||||
To say relation between (first party - a person) and (second party - a person):
|
||||
if the first party is married to the second party:
|
||||
if the first party is female, say "wife";
|
||||
otherwise say "husband";
|
||||
rule succeeds;
|
||||
if the first party is sibling to the second party:
|
||||
if the first party is female, say "sister";
|
||||
otherwise say "brother";
|
||||
rule succeeds;
|
||||
if the first party engenders the second party:
|
||||
say "father";
|
||||
rule succeeds;
|
||||
if the second party is the father of the first party:
|
||||
if the first party is female, say "daughter";
|
||||
otherwise say "son";
|
||||
rule succeeds.
|
||||
|
||||
Pere Blanchard's Hut is a room. Percival Blakeney is a known man in the Hut. Marguerite is a woman in the Hut. Percival is married to Marguerite. Outside from the Hut is the Garden. Louise is a woman in the Garden. The Road to Paris is west of the Garden. Armand St Just is a man in the Road. Louise is married to Armand. Monsieur St Just is a man. He engenders Armand and Marguerite.
|
||||
|
||||
Test me with "out / west / east / west".
|
||||
|
||||
Monsieur St Just never appears on the scene in this piece, but if we did put him somewhere the player could find him, he, too, would be properly introduced.
|
29
Documentation/Examples/Blankness.txt
Normal file
29
Documentation/Examples/Blankness.txt
Normal file
|
@ -0,0 +1,29 @@
|
|||
* Starting the virtual machine
|
||||
(Blanking the status line before play; Blankness)
|
||||
Emptying the status line during the first screen of the game.
|
||||
|
||||
Occasionally we want to print something as our first screen and then pause the game. By default, Inform will print a rather odd status line, with "You" on the left side and "0" on the right. This is because the left hand status line is set to display the location, but (because we're not done with the when-play-begins rules) the player has not yet even been moved to a room.
|
||||
|
||||
We can tidy this up in the "starting the virtual machine" activity, by temporarily changing the status line content. We will not provide game-pausing code here, because that is easily done by extension; so:
|
||||
|
||||
{*}"Blankness"
|
||||
|
||||
Include Basic Screen Effects by Emily Short.
|
||||
|
||||
When play begins:
|
||||
say "take me home";
|
||||
wait for any key;
|
||||
say " yeah";
|
||||
wait for any key;
|
||||
say " yeah";
|
||||
pause the game;
|
||||
now the left hand status line is "[location]";
|
||||
now the right hand status line is "[turn count]".
|
||||
|
||||
Before starting the virtual machine:
|
||||
now the left hand status line is "";
|
||||
now the right hand status line is "".
|
||||
|
||||
Paradise City is a room. The description of Paradise City is "The grass is green and the girls are pretty."
|
||||
|
||||
Quite a modest effect, but occasionally useful.
|
33
Documentation/Examples/Blink.txt
Normal file
33
Documentation/Examples/Blink.txt
Normal file
|
@ -0,0 +1,33 @@
|
|||
* To say one of
|
||||
(Creating our own text variations rules; Blink)
|
||||
Making a "by atmosphere" token, allowing us to design our own text variations such as "[one of]normal[or]gloomy[or]scary[by atmosphere]".
|
||||
|
||||
Suppose we are writing a game in which the mood of the piece changes, and we would like to have lots of descriptions that vary according to its current state. We might in that case want to create our own "by atmosphere" token, to control text variations, like this:
|
||||
|
||||
{*}"Blink"
|
||||
|
||||
Atmosphere is a kind of value. The atmospheres are normal, melancholy, and creepy.
|
||||
|
||||
The current atmosphere is an atmosphere that varies.
|
||||
|
||||
To say by atmosphere -- ending say_one_of with marker I7_SOO_ATM:
|
||||
(- {-close-brace} -).
|
||||
|
||||
Since we're operating within the untyped Inform 6, we can make use of the fact that kinds of value are (internally) just constants, enumerated in the same order in which they were originally defined. In other words, "normal" at the I6 level translates to 1, "melancholy" to 2, and "creepy" to 3; so we can return the value of the current atmosphere, and thereby select option 1, 2, or 3:
|
||||
|
||||
{**}Include (-
|
||||
[ I7_SOO_ATM oldval count;
|
||||
if (count < (+ current atmosphere +)) return count;
|
||||
return (+ current atmosphere +); ];
|
||||
-)
|
||||
|
||||
And that concludes the hard part. Now to test that it works:
|
||||
|
||||
{**}The Flat is a room. "A small [one of]but cozy[or]depressing[or]imprisoning[by atmosphere] flat. Outside the window, the sun is [one of][or][or]apparently [by atmosphere]shining and there is a brisk breeze through the leaves of the birch trees. [one of]It would be quite nice weather for a walk[or]The rest of the world apparently has no appreciation of what you suffer[or]It all looks deceptively normal[by atmosphere]."
|
||||
|
||||
Instead of waiting when the current atmosphere is normal:
|
||||
say "Everything stretches wide and flat for just a moment, as though all the world around you were painted on a thin rubber sheet that is being [italic type]stretched[roman type]. Then it snaps back into place, leaving your ears ringing. But that little glitch was enough to warn you. Someone is tampering with space-time again. Someone very close by.";
|
||||
now the current atmosphere is creepy.
|
||||
|
||||
Test me with "look / z / look".
|
||||
|
47
Documentation/Examples/Blocks.txt
Normal file
47
Documentation/Examples/Blocks.txt
Normal file
|
@ -0,0 +1,47 @@
|
|||
*** Duplicates
|
||||
(Duplicated blue, red and green building blocks--Paint that colours blocks; Early Childhood)
|
||||
A child's set of building blocks, which come in three different colours - red, green and blue - but which can be repainted during play.
|
||||
|
||||
This would be a one-star example if it were not for the repainting:
|
||||
|
||||
{*}"Early Childhood 1"
|
||||
|
||||
A building block is a kind of thing. A red block, a blue block and a green block are kinds of building block.
|
||||
|
||||
The Nursery is a room. In the Nursery are six red blocks, four blue blocks and a green block.
|
||||
|
||||
Test me with "look / get red block".
|
||||
|
||||
But a kind cannot change during play, so this will not do. Instead, the colour will have to be a property of the block. So we might first try this:
|
||||
|
||||
{*}"Early Childhood 2"
|
||||
|
||||
Colour is a kind of value. The colours are red, blue and green. A block is a kind of thing. A block has a colour. A block is usually blue.
|
||||
|
||||
The Nursery is a room. In the Nursery are six red blocks, four blue blocks and a green block.
|
||||
|
||||
Test me with "look / get red block".
|
||||
|
||||
Which is fine, so far as it goes, but the colour property is not at all visible to the player, who simply sees "eleven blocks". We thought of colour as being something outwardly apparent, but Inform does not know this. To achieve a better effect, we will need features from distant chapters. The first is an activity called "printing the name of":
|
||||
|
||||
{*}"Early Childhood 3"
|
||||
|
||||
Colour is a kind of value. The colours are red, blue and green. A block is a kind of thing. A block has a colour. A block is usually blue. Before printing the name of a block: say "[colour] ". Before printing the plural name of a block: say "[colour] ".
|
||||
|
||||
The Nursery is a room. In the Nursery are six red blocks, four blue blocks and a green block.
|
||||
|
||||
Test me with "look / get red block".
|
||||
|
||||
This too, however, is unsatisfactory. The individual blocks are correctly described, but we are unable to distinguish them during play: we cannot type "take a green block", for instance. And because the blocks are indistinguishable in play, they are still massed together as "eleven blocks" in room descriptions. We need to go one step further:
|
||||
|
||||
{*}"Early Childhood 4"
|
||||
|
||||
Colour is a kind of value. The colours are red, blue and green. A block is a kind of thing. A block has a colour. A block is usually blue. Before printing the name of a block: say "[colour] ". Before printing the plural name of a block: say "[colour] ". Understand the colour property as describing a block.
|
||||
|
||||
The Nursery is a room. In the Nursery are six red blocks, four blue blocks and a green block.
|
||||
|
||||
And now everything works nicely: the blocks are grouped by colour, and can be referred to by colour, and we can even change the colour of an individual block during play, using a bit of extra trickery from later:
|
||||
|
||||
{**}Understand "paint [something] [colour]" as painting it. Painting it is an action applying to one thing and one colour. Check painting it: if the noun is not a block, say "Paints are only for blocks." instead. Carry out painting it: now the colour of the noun is the colour understood. Report painting it: say "The block is now [the colour of the noun]."
|
||||
|
||||
Test me with "get red block / get blue block / g / i / look / paint blue block red / i / look / paint me red".
|
46
Documentation/Examples/Bosch.txt
Normal file
46
Documentation/Examples/Bosch.txt
Normal file
|
@ -0,0 +1,46 @@
|
|||
* Stored actions
|
||||
(FULL SCORE using a list of stored actions; Bosch)
|
||||
Creating a list of actions that will earn the player points, and using this both to change the score and to give FULL SCORE reports.
|
||||
|
||||
We could, if we wanted, make a table of stored actions all of which represent things that will earn points for the player. For instance:
|
||||
|
||||
{*}"Bosch"
|
||||
|
||||
Use scoring.
|
||||
|
||||
The Garden of Excess is a room. The gilded lily is an edible thing in the Garden of Excess.
|
||||
|
||||
The Pathway to Desire is west of the Garden of Excess. The emerald leaf is in the Pathway.
|
||||
|
||||
Table of Valuable Actions
|
||||
relevant action point value turn stamp
|
||||
taking the emerald leaf 15 -1
|
||||
eating the gilded lily 5 -1
|
||||
|
||||
(And our list would presumably continue from there, in the full game.)
|
||||
|
||||
{**}The maximum score is 25.
|
||||
|
||||
After doing something:
|
||||
repeat through Table of Valuable Actions:
|
||||
if the current action is the relevant action entry and turn stamp entry is less than 0:
|
||||
now the turn stamp entry is the turn count;
|
||||
increase the score by the point value entry;
|
||||
continue the action.
|
||||
|
||||
Understand "full score" or "full" as requesting the complete score. Requesting the complete score is an action out of world.
|
||||
|
||||
Check requesting the complete score:
|
||||
if the score is 0, say "You have not yet achieved anything of note." instead.
|
||||
|
||||
Carry out requesting the complete score:
|
||||
say "So far you have received points for the following: [line break]";
|
||||
sort the Table of Valuable Actions in turn stamp order;
|
||||
repeat through the Table of Valuable Actions:
|
||||
if the turn stamp entry is greater than 0:
|
||||
say "[line break] [relevant action entry]: [point value entry] points";
|
||||
say line break.
|
||||
|
||||
Test me with "eat lily / w / full score / get leaf / full".
|
||||
|
||||
This system is tidy, but limited: we cannot give actions interesting names in the score list, like "seducing the pirate's daughter" or "collecting a valuable artifact". So it will not be ideal in all situations, but it has the virtue of being easy to extend, and of listing all of the player's successes in the order in which they occurred in his play-through.
|
75
Documentation/Examples/BowlerHats.txt
Normal file
75
Documentation/Examples/BowlerHats.txt
Normal file
|
@ -0,0 +1,75 @@
|
|||
*** During scenes
|
||||
(Scenes which restrict movement; Bowler Hats and Baby Geese)
|
||||
Creating a category of scenes that restrict the player's behavior.
|
||||
|
||||
Scenes can have properties -- a fact that is very useful when it comes to writing a series of scenes that all need to act alike in some respect.
|
||||
|
||||
Suppose we have a plot that features a number of scripted scenes, where we need the player to stand still and wait while the events of the scene play out. One way to set this up is to create a property for such scenes -- let's call them "restricted" -- and then write a rule that keeps the player in place while the scene happens:
|
||||
|
||||
{*} "Bowler Hats and Baby Geese"
|
||||
|
||||
Section 1 - The Procedure
|
||||
|
||||
A scene can be restricted or free.
|
||||
|
||||
Instead of going somewhere during a restricted scene:
|
||||
say "Better to stay here for the moment and find out what is going to happen next."
|
||||
|
||||
And now let's set up our restricted scene. In it, a clown is going to turn up wherever the player is (it doesn't matter where on the map he's gotten to at this point) and do a performance; the player will not be able to leave the area until the performance completes. We'll start with the setting:
|
||||
|
||||
{**}Section 2 - The Stage and Props
|
||||
|
||||
The Broad Lawn is a room. "A sort of fun fair has been set up on this broad lawn, with the House as a backdrop: it's an attempt to give local children something to do during the bank holiday. In typical fashion, everyone is doing a very good job of ignoring the House itself, despite its swarthy roofline and dozens of blacked-out windows."
|
||||
|
||||
The House is scenery in the Broad Lawn. The description is "A cautious vagueness about the nature of the inhabitants is generally considered a good idea. They might be gods, or minor demons, or they might be aliens from space, or possibly they are embodiments of physical principles, or expressions of universal human experience, or... at any rate they can run time backward and forward so it warbles like an old cassette. And they're always about when somebody dies. Other than that, they're very good neighbors and no one has a word to say against."
|
||||
|
||||
Instead of entering the House:
|
||||
say "You can't go in, of course. It's not a house for people."
|
||||
|
||||
The Gazebo is north of the Broad Lawn. "The gazebo is sometimes used for bands, but at the moment has been appropriated for the distribution of lemonade."
|
||||
|
||||
The clown is a man. "A clown wearing [a list of things worn by the clown] stands nearby." The description is "He winks back at you."
|
||||
|
||||
The clown wears a purple polka-dot bowler hat. He carries a supply of baby geese. The description of the supply of baby geese is "Three or four. Or five. It's hard to count." Understand "goose" or "gosling" or "goslings" as the supply of baby geese.
|
||||
|
||||
There are some eggs. The description of the eggs is "A blur, really."
|
||||
|
||||
There is a Spanish omelet. The description of the Spanish omelet is "Exquisitely prepared."
|
||||
|
||||
...And now the scene itself:
|
||||
|
||||
{**}Section 3 - The Scenes
|
||||
|
||||
The Clown Performance is a restricted scene. Clown Performance begins when the turn count is 3.
|
||||
|
||||
When Clown Performance begins:
|
||||
move the clown to the location.
|
||||
|
||||
Every turn during Clown Performance:
|
||||
repeat through the Table of Clowning:
|
||||
say "[event description entry][paragraph break]";
|
||||
blank out the whole row;
|
||||
stop.
|
||||
|
||||
When Clown Performance ends:
|
||||
now the eggs are nowhere;
|
||||
now the clown carries the omelet.
|
||||
|
||||
Clown Performance ends when the number of filled rows in the Table of Clowning is 0.
|
||||
|
||||
Table of Clowning
|
||||
event description
|
||||
"A clown with a purple polka-dot bowler hat strides into the vicinity and begins to juggle baby geese."
|
||||
"While the clown juggles, the baby geese visibly grow older and larger. The clown becomes unnerved."
|
||||
"In an attempt to resolve the problem, the clown reverses the direction of his juggling. The geese revert to goslings."
|
||||
"The goslings become smaller and smaller until the clown is juggling goose eggs[replace eggs]."
|
||||
"The clown throws all the eggs into the air at once and catches them in the bowler hat. He takes a bow; the audience applauds. As a final gesture, he upends his hat to release a perfectly cooked omelet."
|
||||
|
||||
To say replace eggs:
|
||||
now the supply of baby geese is nowhere;
|
||||
now the clown carries the eggs.
|
||||
|
||||
Free Time is a scene. Free Time begins when Clown Performance Ends.
|
||||
|
||||
Test me with "scenes / n / z/ z / look / x geese / s / x geese / x eggs / z / s".
|
||||
|
82
Documentation/Examples/Broughton.txt
Normal file
82
Documentation/Examples/Broughton.txt
Normal file
|
@ -0,0 +1,82 @@
|
|||
*** Indirect relations
|
||||
(Conversation where characters seek logical connection to foregoing topics; The Problem of Edith)
|
||||
A conversation in which the main character tries to build logical connections between what the player is saying now and what went immediately before.
|
||||
|
||||
Suppose that we have a core set of issues we want to be able to bring up with all the characters, and we want characters to draw intelligent connections between different conversation topics. We will need some model of how things relate to one another, so:
|
||||
|
||||
{*}"The Problem of Edith"
|
||||
|
||||
Suggestion relates things to each other. The verb to suggest means the suggestion relation.
|
||||
|
||||
A subject is a kind of thing. The current subject is a thing that varies. greeting is a subject.
|
||||
|
||||
Understand "ask [someone] about [any subject]" as asking it about the subject. Understand "tell [someone] about [any subject]" as asking it about the subject.
|
||||
|
||||
Asking it about the subject is an action applying to one thing and one visible thing.
|
||||
|
||||
Carry out asking it about the subject:
|
||||
say "'Hmm, [the second noun],' says [the noun]. ";
|
||||
relate the current subject with the second noun;
|
||||
now the current subject is the second noun.
|
||||
|
||||
And if we wanted to offer the player some hints about angles he could pursue:
|
||||
|
||||
{**}Instead of thinking:
|
||||
say "You contemplate [a list of things suggested by the current subject]."
|
||||
|
||||
For that matter, we could use the same system to have characters make sense of any physical evidence the character shows them:
|
||||
|
||||
{**}Instead of showing something which suggests the current subject to someone:
|
||||
say "[The second noun] nods impatiently."
|
||||
|
||||
Instead of showing something to someone:
|
||||
let the next subject be the next step via the suggestion relation from the noun to the current subject;
|
||||
if the next subject is a subject:
|
||||
try asking the second noun about the subject the next subject;
|
||||
otherwise:
|
||||
say "[The second noun] shrugs."
|
||||
|
||||
When play begins:
|
||||
now the left hand status line is "Discussing: [current subject]";
|
||||
now the right hand status line is " ".
|
||||
|
||||
Broughton Hall is a room. Lady Uckfield is a woman in Broughton Hall. "Lady Uckfield sits at her desk, looking wholly composed."
|
||||
|
||||
The nasty letter is a thing carried by the player. The nasty letter suggests infidelity and penmanship. The ten-pound note is carried by the player. It suggests money.
|
||||
|
||||
Infidelity is a subject. Infidelity suggests marriage and divorce. Marriage suggests love. Marriage, love, and divorce are subjects.
|
||||
|
||||
Penmanship is a subject. Penmanship suggests education. Education is a subject. Class status and money are subjects. Class status suggests education. Money suggests class status and marriage.
|
||||
|
||||
The current subject is divorce.
|
||||
|
||||
Now we can define what gets said when the subject is changed, regardless of whether the segue was introduced in speech or by a shown object. Since rows are blanked after use, the speaker will never repeat herself; if we provide more than one line about the same pair of topics, the first one will be used, then the second, and so on, until the table runs out:
|
||||
|
||||
{**}To relate (initial - a subject) with (next - a subject):
|
||||
repeat through Table of Remarks:
|
||||
if the initial is starting entry and the next is the final entry:
|
||||
say "[comment entry][paragraph break]";
|
||||
blank out the whole row;
|
||||
rule succeeds;
|
||||
say paragraph break.
|
||||
|
||||
Table of Remarks
|
||||
starting final comment
|
||||
divorce love "'As it seems to me, all the love is on one side,' she says crisply. 'And that rarely works.'"
|
||||
divorce love "'Stop making that plea: it won't work.'"
|
||||
divorce infidelity "'Frankly, I rather think there would have been cause enough for divorce without the perversely plentiful evidence of unfaithfulness.'"
|
||||
divorce money "'If you mean that the divorce will be expensive, I know it,' she says. 'But I can think of no happier investment.'"
|
||||
marriage money "'If you wish me to understand that it was a marriage for money, you could have spared your energy. That was patent from the outset.'"
|
||||
infidelity money "'I'm sorry, but I don't see how having married for money excuses a subsequent infidelity.'"
|
||||
|
||||
If we had more than one character in the scenario, we could provide multiple tables, but this will do to demonstrate the idea.
|
||||
|
||||
Of course, we can override specific instances, if we want the character always to say the same thing regardless of how we came to this point:
|
||||
|
||||
{**}Instead of asking Lady Uckfield about the subject penmanship:
|
||||
now the current subject is penmanship;
|
||||
say "She sighs. 'So few people write really beautifully these days.'"
|
||||
|
||||
Test me with "think / ask lady about infidelity / show nasty letter to lady / show note to lady / think / ask lady about divorce / ask lady about love / ask lady about marriage / ask lady about divorce / ask lady about love / ask lady about penmanship".
|
||||
|
||||
We would have to be careful about this system, since we have applied a various-to-various relation to every single object in the game. In practice it would probably be wisest to restrict it a bit, with judicious definitions of kind and so on.
|
27
Documentation/Examples/BumpingIntoWalls.txt
Normal file
27
Documentation/Examples/BumpingIntoWalls.txt
Normal file
|
@ -0,0 +1,27 @@
|
|||
*** Going from, going to
|
||||
(GOing an invalid direction produces a list of valid exits--Exits listed when the player tries a wrong direction; Bumping into Walls)
|
||||
Offering the player a list of valid directions if he tries to go in a direction that leads nowhere.
|
||||
|
||||
{*}"Bumping into Walls"
|
||||
|
||||
First we add an instruction to determine which ways lead to other rooms.
|
||||
|
||||
{**}Definition: a direction (called thataway) is viable if the room thataway from the location is a room.
|
||||
|
||||
Now we build in the instruction for what Inform should say if the player tries to head in a direction that leads nowhere:
|
||||
|
||||
{**}Instead of going nowhere:
|
||||
let count of exits be the number of viable directions;
|
||||
if the count of exits is 0, say "You appear to be trapped in here." instead;
|
||||
if the count of exits is 1, say "From here, the only way out is [list of viable directions].";
|
||||
otherwise say "From here, the viable exits are [list of viable directions]."
|
||||
|
||||
There is no theoretical reason why we have to define "count of exits" here: we could, if we wanted, just say "if the number of viable directions is 0", "if the number of viable directions is 1", and so on. However, each calculation of a "viable direction" takes a bit of computing power, so there is some slight savings in not requiring the game to count viable directions more than once in this routine.
|
||||
|
||||
{**}Dome is a room. North of Dome is North Chapel. South of the Dome is South Chapel. West of the Dome is Western End. Quiet Corner is northwest of the Dome, north of Western End, and west of North Chapel. Loud Corner is east of North Chapel, northeast of Dome, and north of Eastern End. Eastern End is north of Dim Corner and east of Dome. Dim Corner is southeast of Dome and east of South Chapel. Ruined Corner is southwest of Dome, west of South Chapel, and south of Western End.
|
||||
|
||||
The Crypt is below the dome.
|
||||
|
||||
The church door is east of Eastern End and west of the Courtyard. The church door is a door.
|
||||
|
||||
Test me with "u / n / n / e / n / s / u / open door / e / n".
|
179
Documentation/Examples/Burning.txt
Normal file
179
Documentation/Examples/Burning.txt
Normal file
|
@ -0,0 +1,179 @@
|
|||
*** New rulebooks
|
||||
(BURN command, and flammable objects--Fire that spreads; In Fire or in Flood)
|
||||
A BURN command; flammable objects which light other items in their vicinity and can burn for different periods of time; the possibility of having parts or contents of a flaming item which survive being burnt.
|
||||
|
||||
|
||||
{*}"In Fire or in Flood"
|
||||
|
||||
Part I - Rules for combustion
|
||||
|
||||
Heat is a kind of value. The heats are whole, damp, and flaming. A thing has a heat. A thing is usually whole.
|
||||
|
||||
A thing has a number called endurance. The endurance of a thing is usually 5. A thing has a number called turns of burning. A thing can be flammable or flame-retardant.
|
||||
|
||||
Before printing the name of something flaming:
|
||||
say "flaming ".
|
||||
|
||||
Before burning something when the player is not carrying something flaming:
|
||||
if a flaming portable thing (called the lighter) is touchable:
|
||||
say "(with [the lighter], which you first take)[command clarification break]";
|
||||
try taking the lighter.
|
||||
|
||||
Instead of burning something when the player is not carrying something flaming:
|
||||
say "You would first need a fire source."
|
||||
|
||||
Instead of burning something flame-retardant:
|
||||
say "[The noun] is not the sort of thing that catches fire."
|
||||
|
||||
Instead of burning something flammable when the player is carrying something flaming (called the flame source):
|
||||
say "You light [the noun] with [the flame source].";
|
||||
now the heat of the noun is flaming.
|
||||
|
||||
Instead of burning something when the player is in the noun:
|
||||
say "That seems dangerous given that you yourself are in [the noun]."
|
||||
|
||||
Instead of burning something when the player is on the noun:
|
||||
say "That seems dangerous given that you yourself are on [the noun]."
|
||||
|
||||
Instead of examining something:
|
||||
say "Hm, the [printed name] appears to be [heat]."
|
||||
|
||||
Before taking a flaming thing:
|
||||
let turns remaining be the endurance of the noun minus the turns of burning of the noun;
|
||||
if turns remaining is less than two, say "There's no portion of [the noun] sufficiently cool for you to pick up." instead.
|
||||
|
||||
|
||||
But that's only a small part of the battle. The thing about fire is that it keeps on doing fiery things even when the player is otherwise occupied: destroying items that are on fire, and spreading to other things nearby. So we need a set of rules for the fire's behavior.
|
||||
|
||||
{**}Every turn when something is flaming:
|
||||
follow the fire rules.
|
||||
|
||||
The fire rules is a rulebook.
|
||||
|
||||
A fire rule (this is the can't hold flaming objects rule):
|
||||
repeat with item running through flaming things:
|
||||
if the item is held by the player:
|
||||
let turns remaining be the endurance of the item minus the turns of burning of the item;
|
||||
if turns remaining is less than two:
|
||||
say "[The item] becomes too hot to hold! ";
|
||||
try dropping the item;
|
||||
if the item is held by the player, say "This is certainly painful."
|
||||
|
||||
A fire rule (this is the flames spread rule):
|
||||
repeat with item running through flaming things:
|
||||
if the turns of burning of the item is one:
|
||||
spread the flames from the item.
|
||||
|
||||
A fire rule (this is the fire destroys things rule):
|
||||
now started printing is false;
|
||||
repeat with item running through flaming things:
|
||||
increment the turns of burning of the item;
|
||||
if the turns of burning of the item is greater than the endurance of the item, destroy the item;
|
||||
if started printing is true, say "[paragraph break]";
|
||||
now started printing is false.
|
||||
|
||||
Because we've labelled all the fire rules, we could swap their order, or turn some of them off, while allowing the others run as usual. For instance, if there were a pair of fireproof gloves in the game, we might want to turn off the "can't hold flaming objects rule" whenever the player is wearing them.
|
||||
|
||||
This sort of flexibility is especially useful in the context of extensions. Someone writing an extension about burning would have no way of anticipating the need for a Fireproof Gauntlet of Thog, but the author would nonetheless be able to implement one easily.
|
||||
|
||||
{**}Definition: a thing is vulnerable if it is flammable and it is whole.
|
||||
|
||||
The contact between things is a critical factor when it comes to fire, so we might add a couple of conditional relations do determine what is touching what.
|
||||
|
||||
{**}Reliance relates a thing (called X) to a thing (called Y) when X is part of Y or X is in Y or X is on Y. The verb to be relying on means the reliance relation.
|
||||
|
||||
Contact relates a thing (called X) to a thing (called Y) when X is relying on Y or Y is relying on X. The verb to be joined to means the contact relation.
|
||||
|
||||
Having these at our disposal makes it much tidier to write what happens next:
|
||||
|
||||
{**}To spread the flames from (item - a thing):
|
||||
now started printing is false;
|
||||
if the item is joined to a flammable whole thing (called the sacrifice):
|
||||
if the sacrifice is visible:
|
||||
now started printing is true;
|
||||
say "Flames engulf [the list of flammable whole things which are joined to the item].";
|
||||
now all the flammable whole things joined to the item are flaming.
|
||||
|
||||
Started printing is a truth state that varies. Started printing is false.
|
||||
|
||||
To destroy (item - a thing):
|
||||
let home be the holder of the item;
|
||||
if the item is part of something (called the superstructure), let home be the holder of the superstructure;
|
||||
if the item is visible:
|
||||
now started printing is true;
|
||||
say "[The item] burns away[if something is relying on the item], leaving [a list of things which are relying on the item] behind[end if]. ";
|
||||
if something is relying on the item,
|
||||
now all the things which are relying on the item are in the home;
|
||||
now the item is nowhere;
|
||||
now the item is damp;
|
||||
now every flaming thing which is part of the item is damp.
|
||||
|
||||
To destroy (item - a door):
|
||||
let home be the holder of the item;
|
||||
if item is visible:
|
||||
now started printing is true;
|
||||
say "[The item] burns away[if something flame-retardant is part of the item], leaving [a list of flame-retardant parts of the item] behind[end if]. ";
|
||||
if home is a room, now all of the flame-retardant parts of the item are in the home;
|
||||
now the item is damp;
|
||||
now the item is open;
|
||||
now the item is unopenable.
|
||||
|
||||
Before printing the name of a damp door:
|
||||
say "burnt-out frame of ".
|
||||
|
||||
Instead of opening or closing a damp door:
|
||||
say "[The noun] can no longer be opened or closed in any meaningful sense."
|
||||
|
||||
Instead of doing something other than examining or dropping to a flaming thing when the turns of burning of the noun is greater than 1:
|
||||
say "Fire has too thoroughly engulfed [the noun] for that to be a good idea."
|
||||
|
||||
Instead of taking something when the noun is in a flaming thing (called the receptacle):
|
||||
say "You don't quite dare reach into [the receptacle]."
|
||||
|
||||
Instead of touching something which is within a flaming thing (called the receptacle):
|
||||
say "It seems a little risky since [the receptacle] is on fire."
|
||||
|
||||
Instead of turning something when the noun is contained in a flaming thing (called the receptacle):
|
||||
say "It seems a little risky since [the receptacle] is on fire."
|
||||
|
||||
Instead of pushing or pulling something when the noun is inside a flaming thing (called the receptacle):
|
||||
say "[The receptacle] deters you."
|
||||
|
||||
Before burning something which is in a container when the holder of the noun contains the player:
|
||||
say "This could make things toasty for you..."
|
||||
|
||||
And that completes the rules which cover burning: things can catch fire, fire will spread, and gradually consume the world in flames. All of that was general and could be used in any setting, but we now provide a small game to show it off.
|
||||
|
||||
{**}Part II - Escape from the Library of the Dead
|
||||
|
||||
The Library of the Dead is a room. "This room -- little, dank, stone -- is filling with some miasma you do not quite dare breathe. It is imperative that you get out."
|
||||
|
||||
The desk is a flammable supporter in the Library. A drawer is part of the desk. The drawer is a flammable closed container. It is openable, lockable, and locked. The desk is scenery.
|
||||
|
||||
A box is in the Library. A metal hinge is part of the box. The hinge is flame-retardant. The box is open, flammable, and openable. The shroud of Laertes is a flammable thing in the box.
|
||||
|
||||
Instead of examining something when something is part of the noun:
|
||||
say "You note [the list of things which are part of the noun]."
|
||||
|
||||
The world's last manuscript of the Psychagogoi by Aeschylus is on the desk. The manuscript is flammable. The manuscript has endurance 1.
|
||||
|
||||
The torch is a flammable flaming thing carried by the player. It has endurance 60. The asbestos sack is a flame-retardant player's holdall in the drawer.
|
||||
|
||||
The trapdoor is up of the Library and east of the Plaza. The trapdoor is a door. It is flammable, closed, lockable, and locked. "A trapdoor in the ceiling is your only hope of escape[if flaming]. Fortunately, it is rapidly burning through[end if]." The trapdoor has endurance 15.
|
||||
|
||||
Instead of going through the closed trapdoor, say "[The trapdoor] is closed."
|
||||
|
||||
We can then add a special fire rule to handle the trapdoor, which will be called as part of the same sequence. Again, this would be most important if the fire rules were part of a standard extension, and the trapdoor fire rule the author's own addition.
|
||||
|
||||
{**}A fire rule:
|
||||
if the trapdoor is flaming and a random chance of 1 in 3 succeeds:
|
||||
let the caught thing be a random flammable whole thing which can be touched by the trapdoor;
|
||||
if the caught thing is a thing:
|
||||
say "A spark from [the trapdoor] catches [the caught thing]!";
|
||||
now the caught thing is flaming.
|
||||
|
||||
Instead of going to the Plaza:
|
||||
say "Out at last!";
|
||||
end the story finally.
|
||||
|
||||
Test me with "get manuscript / get shroud / light desk / look / g / open drawer / look / g / g / g / get sack / put shroud in sack / put manuscript in sack / close sack / light trapdoor / look / g / g / g / g / g / g / g / g / g / g / g / g / g / g / up".
|
181
Documentation/Examples/CHS.txt
Normal file
181
Documentation/Examples/CHS.txt
Normal file
|
@ -0,0 +1,181 @@
|
|||
**** Printing the name of something
|
||||
(Hints leading the player through conversation; Chronic Hinting Syndrome)
|
||||
Using name-printing rules to keep track of whether the player knows about objects, and also to highlight things he might want to follow up.
|
||||
|
||||
Suppose we have a conversation system in which it is important to keep track of which subjects the player has heard mentioned. If we're careful to mark subjects in brackets, we can use the "printing the name of" activity to record which things have been mentioned so far:
|
||||
|
||||
{*}"Chronic Hinting Syndrome"
|
||||
|
||||
A subject is a kind of thing.
|
||||
|
||||
Knowledge relates various people to various subjects. The verb to know means the knowledge relation.
|
||||
|
||||
Awareness relates various people to various subjects. The verb to be aware of means the awareness relation.
|
||||
|
||||
Definition: a subject is pending if the player is aware of it and it is not known by the player.
|
||||
|
||||
Instead of thinking:
|
||||
if the number of pending subjects is 0, say "You have no fresh leads at the moment.";
|
||||
otherwise say "You recall that thus far you have not followed up with questions about [the list of pending subjects]."
|
||||
|
||||
After printing the name of a subject (called idea):
|
||||
now the player is aware of the idea.
|
||||
|
||||
Now suppose that as an added convenience for the player, we let him turn on a mode in which useful conversation topics are always automatically highlighted in the text, so he doesn't waste his time trying to follow up dead leads:
|
||||
|
||||
{**}Setting is a kind of value. The settings are bright and dull. Understand "on" as bright. Understand "off" as dull.
|
||||
|
||||
Highlighting is a setting that varies. Highlighting is dull.
|
||||
|
||||
Understand "highlighting [setting]" as setting highlighting. Setting highlighting is an action out of world, applying to one setting.
|
||||
|
||||
Carry out setting highlighting:
|
||||
now highlighting is the setting understood.
|
||||
|
||||
Report setting highlighting:
|
||||
say "Highlighting is now [if highlighting is dull]off[otherwise]on[end if]."
|
||||
|
||||
Before printing the name of a subject (called idea) when highlighting is bright:
|
||||
unless the player knows the idea:
|
||||
say "[bold type]".
|
||||
|
||||
After printing the name of a subject when highlighting is bright:
|
||||
say "[roman type]".
|
||||
|
||||
...And the rest is peripheral.
|
||||
|
||||
{**}The Sickbay is a room. "A place arranged for Nathan's comfort, since his sickness has been prolonged and because he becomes so irritating when not comfortable." The Hallway is outside from the Sickbay.
|
||||
|
||||
A supporter can be untried or rejected. A supporter is usually untried.
|
||||
|
||||
The Sickbay contains a wobbly pedestal, a table, and a sickbed. Understand "bed" as the sickbed. The pedestal, the table, and the sickbed are supporters. Nathan is a man on the sickbed. The sickbed is scenery. The initial appearance of the wobbly pedestal is "A wobbly pedestal near the door has sometimes been known to support vases of flowers, but is currently bare." The initial appearance of the table is "There is also a table of a more ordinary sort."
|
||||
|
||||
Nathan can be active or passive.
|
||||
|
||||
After printing the name of Nathan: now Nathan is passive.
|
||||
|
||||
Instead of putting the sculpture on the table:
|
||||
now the table is rejected;
|
||||
say "'[Not there],' [Nathan] snaps. 'The table is way too far from the sickbed.'"
|
||||
|
||||
Instead of putting the sculpture on the sickbed:
|
||||
now the sickbed is rejected;
|
||||
say "'[Not there],' [Nathan] rebukes you. 'You don't want me knocking it over if I roll around. In pain.'"
|
||||
|
||||
Instead of putting the sculpture on the pedestal:
|
||||
now the pedestal is rejected;
|
||||
say "The pedestal starts to wobble so ominously that you don't dare let go.
|
||||
|
||||
'[Not there],' says [Nathan]. 'That thing is falling apart.'"
|
||||
|
||||
Before putting something on the down: try dropping the noun instead.
|
||||
|
||||
To say not there:
|
||||
if all the supporters are rejected:
|
||||
say "Look, the floor would be fine";
|
||||
otherwise if the number of rejected supporters is 1:
|
||||
say "Yeah, anywhere but there, I'm afraid";
|
||||
otherwise:
|
||||
say "Come on, use your head -- I can't be watching you all the time, I'm sick".
|
||||
|
||||
Instead of going outside when the player is carrying the sculpture:
|
||||
say "You've still got this sculpture to get rid of."
|
||||
|
||||
Instead of going outside when the breakage is pending:
|
||||
say "You can't very well smash in front of [Nathan] his prize sculpture and then just scamper off without saying something. Appealing though the thought is at the moment."
|
||||
|
||||
Instead of going outside when a subject which is not the breakage is pending:
|
||||
say "'Yeah, go ahead,' says [Nathan], with a martyr-like air. 'It's probably best that you don't hear about [the random pending subject]. It's not something I'd go into normally.'"
|
||||
|
||||
The breakage is a subject. The description is "It's not a big deal. I'll just buy a new [mental wave generator].' A slight awkward pause. 'I mean, this one was a [gift], but don't worry about it". Understand "accident" or "smashing" or "breaking" or "shard" or "mishap" or "shards" or "mistake" as the breakage. Understand "sculpture" as the breakage when the player is not carrying the sculpture.
|
||||
|
||||
Instead of saying sorry in the presence of Nathan when the player is aware of the breakage:
|
||||
try asking Nathan about the matter of breakage.
|
||||
|
||||
Instead of asking Nathan to try saying sorry when the player is aware of the breakage:
|
||||
try asking Nathan about the matter of breakage.
|
||||
|
||||
The mental wave generator is a subject. The description is "They're kind of expensive but I can save up. I really need one, though, because of my [dreams]".
|
||||
|
||||
The dreams is a subject. The description is "They're not the kind of dream you want to have.' He closes his eyes and contemplates these undesirable dreams. 'Have you ever woken up convinced you were dead? No, probably not. Well... At any rate, I need the [generator]. Oh, don't worry, they're expensive but not so expensive that I won't be able to save up for another, in a few months".
|
||||
|
||||
The gift is a subject. The description is "[The mental wave generator] was a present from a girl named [Shari]. Actually I'm not sure she'd take to being called a girl".
|
||||
|
||||
Shari is a subject. The description is "Look, let's just not go into it, okay? I don't really want to relive all that right now. I still have a six-inch [scar] shaped like a banana in the middle of my back".
|
||||
|
||||
The scar is a subject.
|
||||
|
||||
Instead of asking Nathan about the matter of the scar:
|
||||
say "Nathan clears his throat, lowers his voice, and begins to tell you the story...";
|
||||
end the story saying "End of Demo -- Register to Continue!!"
|
||||
|
||||
Understand "ask [someone] about [any subject]" as asking it about the matter of.
|
||||
|
||||
Asking it about the matter of is an action applying to one thing and one visible thing.
|
||||
|
||||
Check asking it about the matter of:
|
||||
if the player is not aware of the second noun, say "What [second noun]?" instead;
|
||||
if the noun does not know the second noun, say "'I've no idea,' replies [the noun]." instead;
|
||||
if the player knows the second noun, say "You've already covered that. The response was '[description of the second noun].'" instead.
|
||||
|
||||
Carry out asking it about the matter of:
|
||||
now the player knows the second noun.
|
||||
|
||||
Report asking it about the matter of:
|
||||
say "'[description of the second noun],' says [the noun]."
|
||||
|
||||
Instead of telling Nathan about something:
|
||||
say "He pinches the bridge of his nose. 'I can't really follow this right now,' he says. 'I'm sorry.'"
|
||||
|
||||
Instead of asking Nathan about something:
|
||||
say "He shrugs weakly."
|
||||
|
||||
When play begins:
|
||||
say "'Just put that down anywhere,' says [Nathan], as you come into the room. He's sitting in the sickbed with his legs straight out in front of him. 'I don't care where.' His voice is weak, but it sharpens up for the last remark: 'And don't make a lot of noise about it.'
|
||||
|
||||
Considering that he woke you from a sound slumber to beg you to bring this thing over, his attitude is a bit much. You stare dubiously at the awkward crystal sculpture in your hands.";
|
||||
now Nathan knows every subject.
|
||||
|
||||
Instead of asking Nathan about something while the player carries the sculpture, say "[Nathan] moans dramatically and refuses to be drawn into conversation."
|
||||
|
||||
The player is carrying an awkward crystal sculpture. Understand "objet" or "objet de hideous" as the sculpture. The description of the sculpture is "It might possibly be natural, or it might be man-made. It might appeal to someone, but it is certainly not to your tastes."
|
||||
|
||||
Instead of showing the sculpture to Nathan:
|
||||
say "'Please put it anywhere,' he says."
|
||||
|
||||
Instead of giving the sculpture to Nathan:
|
||||
say "'No, it doesn't work if I touch it. That's why I couldn't-- well, just put it down.'"
|
||||
|
||||
After dropping the sculpture:
|
||||
now the player is aware of the breakage;
|
||||
now the sculpture is nowhere;
|
||||
say "You are incredibly careful, but somehow the sculpture slips -- you might almost say slithers -- from your fingers and crashes into a thousand shards at the feet of [Nathan].
|
||||
|
||||
There is a tense silence."
|
||||
|
||||
Before reading a command: now Nathan is active.
|
||||
|
||||
Every turn while not asking:
|
||||
if Nathan is passive, rule succeeds;
|
||||
if the player is carrying the sculpture:
|
||||
if showing or giving, rule succeeds;
|
||||
say "[Nathan] opens one eye and stares at you meaningfully. He is waiting for you to deposit his objet de hideous somewhere.";
|
||||
rule succeeds;
|
||||
if the breakage is pending:
|
||||
if dropping, rule succeeds;
|
||||
say "You're not quite sure where to begin, but you can't very well leave without making at least some remark on the smashing of the sculpture.";
|
||||
rule succeeds;
|
||||
if a subject is pending:
|
||||
choose a random row in the Table of Offhand Reminiscences;
|
||||
say "[line entry][paragraph break]".
|
||||
|
||||
Table of Offhand Reminiscences
|
||||
line
|
||||
"'It actually is kind of a funny story about [the random pending subject],' [Nathan] remarks casually."
|
||||
"[Nathan] chuckles under his breath. 'Man, I hadn't thought about [the random pending subject] in ages.'"
|
||||
"He glances sideways at you. 'It's nothing personal, you know, but I don't feel comfortable discussing [the random pending subject] with just anyone.'"
|
||||
"'I don't know why I brought up [the random pending subject] just now,' [Nathan] comments. 'Don't mention it to anyone, if you don't mind.'"
|
||||
"'Okay, see, the thing about [the random pending subject] is...' [paragraph break]'Yes?' you ask, on cue.[paragraph break]'...never mind.'"
|
||||
"[Nathan] makes an explosive exasperated sound. 'Don't you want to ask me about [the random pending subject]?' he demands."
|
||||
|
||||
Test me with "highlighting bright / put sculpture on pedestal / put it on table / put it on sickbed / drop it / think / ask nathan about breakage / think / ask him about generator / ask him about dreams / ask him about gift / ask him about shari / ask him about scar".
|
33
Documentation/Examples/Cabin1.txt
Normal file
33
Documentation/Examples/Cabin1.txt
Normal file
|
@ -0,0 +1,33 @@
|
|||
* Properties depend on kind
|
||||
(Disenchantment Bay: 1. The charter boat)
|
||||
A running example in this chapter, Disenchantment Bay, involves chartering a boat. This is the first step: creating the cabin.
|
||||
|
||||
To begin with the title:
|
||||
|
||||
{*}"Disenchantment Bay"
|
||||
|
||||
There are many Disenchantment Bays across the world, named by eighteenth-century ships' captains - one in Antarctica, another in Tasmania, for instance. The most famous is probably the one where Lewis and Clark's expedition broke through to the Pacific. But ours is the one in Alaska, named in 1791 by a Spanish navigator who had hoped it might lead to the fabled Northwest Passage, and all of this history is beside the point since the game is set in the present day.
|
||||
|
||||
{**}The Cabin is a room. "The front of the small cabin is entirely occupied with navigational instruments, a radar display, and radios for calling back to shore. Along each side runs a bench with faded blue vinyl cushions, which can be lifted to reveal the storage space underneath. A glass case against the wall contains several fishing rods.
|
||||
|
||||
Scratched windows offer a view of the surrounding bay, and there is a door south to the deck. A sign taped to one wall announces the menu of tours offered by the Yakutat Charter Boat Company."
|
||||
|
||||
We might want to start with the glass case.
|
||||
|
||||
{**}The Cabin contains a glass case. In the glass case is a collection of fishing rods.
|
||||
|
||||
Now Inform will have guessed that the case is a container, but its default idea of a container is something like a bucket: permanently open and not able to be opened and shut. We can change that:
|
||||
|
||||
{**}The case is closed, transparent, and openable.
|
||||
|
||||
We get a similar set of guesses if we write
|
||||
|
||||
{**}The bench is in the cabin. On the bench are some blue vinyl cushions.
|
||||
|
||||
Using "some" rather than "a" or "the" tells Inform that the cushions are to be referred to as a plural object in the future. And because of the "on the bench..." phrase, Inform will guess that the bench is a supporter and that it is fixed in place and cannot be moved from room to room. We do have to tell it that the bench can be sat on, though:
|
||||
|
||||
{**}The bench is enterable.
|
||||
|
||||
And now a short script, so that if we type TEST ME, we experiment with the case and bench:
|
||||
|
||||
{**}Test me with "examine case / get rods / open case / get rods / sit on bench / take cushions / get up"
|
11
Documentation/Examples/Cabin10.txt
Normal file
11
Documentation/Examples/Cabin10.txt
Normal file
|
@ -0,0 +1,11 @@
|
|||
* Possessions and clothing
|
||||
(Disenchantment Bay: 10. Clothing and possessions--Basic clothing)
|
||||
Disenchantment Bay: things for the player and the characters to wear and carry.
|
||||
|
||||
At this point we can dress both the Captain and the player with some appropriate props:
|
||||
|
||||
{*}The captain wears a baseball cap. The description of the cap is "It says, THE WORST DAY FISHING IS BETTER THAN THE BEST DAY WORKING."
|
||||
|
||||
The player is carrying a backpack and a bottle of water. The player is wearing a pair of sunglasses. The description of the sunglasses is "The light off the water and the ice does get pretty bright sometimes."
|
||||
|
||||
(At present the backpack can't be worn, but see the next version.)
|
21
Documentation/Examples/Cabin11.txt
Normal file
21
Documentation/Examples/Cabin11.txt
Normal file
|
@ -0,0 +1,21 @@
|
|||
* The player's holdall
|
||||
(Disenchantment Bay: 11. The player's backpack--Basic holdall)
|
||||
Disenchantment Bay: making a holdall of the backpack.
|
||||
|
||||
If we wanted, we could make the player's backpack infinitely capacious, so:
|
||||
|
||||
{*}The backpack is a player's holdall.
|
||||
|
||||
...And now whenever the player character is unable to hold everything, he will automatically stow some of his possessions therein.
|
||||
|
||||
This is only useful if the player doesn't have infinite carrying capacity himself, so perhaps we also need
|
||||
|
||||
{*}The carrying capacity of the player is 3.
|
||||
|
||||
Perhaps mercifully, items which are worn are not counted against the player's carrying capacity. We might want to let him take advantage of that, too:
|
||||
|
||||
{*}The backpack is wearable.
|
||||
|
||||
This capacity system makes a compromise between the realistic and the absurd: on the one hand, it acknowledges that people can't carry an infinite number of items in their hands, while at the same time providing a sack that can.
|
||||
|
||||
Many games will have no use for object-juggling of this kind at all; others will want to be much more rigorous about questions of capacity and volume. Fortunately, it is easy to leave the whole business out by assigning no carrying capacity to anything.
|
25
Documentation/Examples/Cabin2.txt
Normal file
25
Documentation/Examples/Cabin2.txt
Normal file
|
@ -0,0 +1,25 @@
|
|||
* Scenery
|
||||
(Disenchantment Bay: 2. Scenery--Basic scenery)
|
||||
Disenchantment Bay: creating some of the objects in the cabin's description.
|
||||
|
||||
If we compile our last version of the cabin, we get a room where the glass case and the bench are listed separately from the room description, even though they have already been mentioned once. We can prevent this by making the already-mentioned things scenery:
|
||||
|
||||
{*}"Disenchantment Bay"
|
||||
|
||||
The Cabin is a room. "The front of the small cabin is entirely occupied with navigational instruments, a radar display, and radios for calling back to shore. Along each side runs a bench with faded blue vinyl cushions, which can be lifted to reveal the storage space underneath. A glass case against the wall contains several fishing rods.
|
||||
|
||||
Scratched windows offer a view of the surrounding bay, and there is a door south to the deck. A sign taped to one wall announces the menu of tours offered by the Yakutat Charter Boat Company."
|
||||
|
||||
The Cabin contains a glass case. In the glass case is a collection of fishing rods. The case is closed, transparent, and openable. The case is scenery.
|
||||
|
||||
The bench is in the cabin. On the bench are some blue vinyl cushions. The bench is enterable and scenery. The cushions are scenery.
|
||||
|
||||
Generally speaking, it is a good idea to recognize the player's attempts to interact with any objects mentioned in the room description, so we should also provide
|
||||
|
||||
{**}Some navigational instruments, some scratched windows, a sign, a radar display, and some radios are scenery in the cabin.
|
||||
|
||||
Test me with "examine instruments / x windows / x sign / x display / x radios".
|
||||
|
||||
The door and the view will need to be done as well, but they are special cases which we will get to shortly.
|
||||
|
||||
As noted, making something scenery also means that the player will be prevented from picking it up and carrying it away. This is sensible, though: if an object can be removed from the room where it first appears, we should be careful about mentioning it in the main room description; otherwise, it will continue to be described as present even when someone has carried it off.
|
7
Documentation/Examples/Cabin3.txt
Normal file
7
Documentation/Examples/Cabin3.txt
Normal file
|
@ -0,0 +1,7 @@
|
|||
* Backdrops
|
||||
(Disenchantment Bay: 3. Glacier view--Basic backdrop)
|
||||
Disenchantment Bay: adding a view of the glacier.
|
||||
|
||||
Suppose we wanted to have the glacier visible from the Cabin of our boat, and anywhere else we might add to the game:
|
||||
|
||||
The view of the Malaspina glacier is a backdrop. It is everywhere. The description is "The Malaspina glacier covers much of the nearby slope, and -- beyond it -- an area as large as Rhode Island."
|
37
Documentation/Examples/Cabin4.txt
Normal file
37
Documentation/Examples/Cabin4.txt
Normal file
|
@ -0,0 +1,37 @@
|
|||
* Two descriptions of things
|
||||
(Disenchantment Bay: 4. Descriptions of things--Basic descriptions)
|
||||
Disenchantment Bay: fleshing out the descriptions of things on the boat.
|
||||
|
||||
Currently we have provided objects for most of what is on the boat, but it's not very interesting to look at. We might want to give some more description to these things.
|
||||
|
||||
{*}"Disenchantment Bay"
|
||||
|
||||
The Cabin is a room. "The front of the small cabin is entirely occupied with navigational instruments, a radar display, and radios for calling back to shore. Along each side runs a bench with faded blue vinyl cushions, which can be lifted to reveal the storage space underneath. A glass case against the wall contains several fishing rods.
|
||||
|
||||
Scratched windows offer a view of the surrounding bay, and there is a door south to the deck. A sign taped to one wall announces the menu of tours offered by the Yakutat Charter Boat Company."
|
||||
|
||||
The Cabin contains a glass case. In the glass case is a collection of fishing rods. The case is closed, transparent, and openable. The case is scenery.
|
||||
|
||||
The bench is in the cabin. On the bench are some blue vinyl cushions. The bench is enterable and scenery. The cushions are scenery.
|
||||
|
||||
Some navigational instruments, some scratched windows, a radar display, and some radios are scenery in the cabin.
|
||||
|
||||
The description of the instruments is "Knowing what they do is the Captain's job."
|
||||
|
||||
The description of the windows is "They're a bit the worse for wear, but you can still get an impressive view of the glacier through them. There were whales earlier, but they're gone now."
|
||||
|
||||
The description of the radar is "Apparently necessary to avoid the larger icebergs."
|
||||
|
||||
The description of the radios is "With any luck you will not need to radio for help, but it is reassuring that these things are here."
|
||||
|
||||
The order in which we define these things is fairly open. We could also define an object so:
|
||||
|
||||
{**}A sign is scenery in the Cabin. The description is "You can get half-day and full-day sight-seeing tours, and half-day and full-day fishing trips."
|
||||
|
||||
Where "the description" is assumed to refer to the thing most recently defined, if no object is specified.
|
||||
|
||||
{**}The view of the Malaspina glacier is a backdrop. It is everywhere. The description is "The Malaspina glacier covers much of the nearby slope, and -- beyond it -- an area as large as Rhode Island."
|
||||
|
||||
Test me with "examine sign / examine glacier / examine instruments / examine windows / examine radar / examine radios / take the cushions / take the glacier".
|
||||
|
||||
These last two commands show how scenery and backdrops are automatically impossible for the player to take.
|
9
Documentation/Examples/Cabin5.txt
Normal file
9
Documentation/Examples/Cabin5.txt
Normal file
|
@ -0,0 +1,9 @@
|
|||
* Doors
|
||||
(Disenchantment Bay: 5. Cabin door and deck--Basic door)
|
||||
Disenchantment Bay: adding the door and the deck to our charter boat.
|
||||
|
||||
We mentioned that there is a door out to the deck in our example. The following two sentences will create both the door and the other room:
|
||||
|
||||
{*}The cabin door is south of the Cabin and north of the Deck. It is a door and scenery.
|
||||
|
||||
Now Inform has constructed a generic room called "Deck" to the south. It has neither a description nor any contents yet, but we could fix that in time. It does have a view of the glacier, though, since we defined the glacier view to be everywhere.
|
9
Documentation/Examples/Cabin6.txt
Normal file
9
Documentation/Examples/Cabin6.txt
Normal file
|
@ -0,0 +1,9 @@
|
|||
* Locks and keys
|
||||
(Disenchantment Bay: 6. Locked-up fishing rods--Basic locked container)
|
||||
Disenchantment Bay: locking up the charter boat's fishing rods.
|
||||
|
||||
It stands to reason that the captain wouldn't let just anyone meddle with his fishing equipment; maybe he keeps that case locked. We could replace the case description with this one, instead:
|
||||
|
||||
{*}The Cabin contains a glass case. In the glass case is a collection of fishing rods. The case is closed, transparent, openable, lockable, and locked. The case is scenery. The small silver key unlocks the case.
|
||||
|
||||
Now there's a silver key that will unlock it -- though since we haven't said where the key is, the player will never be able to find it in the game. (If we look at the World index, we find "small silver key" right at the bottom, not inside any of the rooms. That is as good as not existing at all -- though we usually use the term "out of play" -- but as we will later see, it is possible to have things initially out of play but brought into existence later on.)
|
11
Documentation/Examples/Cabin7.txt
Normal file
11
Documentation/Examples/Cabin7.txt
Normal file
|
@ -0,0 +1,11 @@
|
|||
* Devices and descriptions
|
||||
(Disenchantment Bay: 7. Radar and instruments--Radar aboard ship)
|
||||
Disenchantment Bay: making the radar and instruments switch on and off.
|
||||
|
||||
If we would like the player to be able to turn instrumentation on and off, we could add a line to this effect:
|
||||
|
||||
{*}The radar, the instruments, and the radios are devices.
|
||||
|
||||
And since the captain is probably not navigating blind, we might also want to say
|
||||
|
||||
{**}The radar and the instruments are switched on.
|
13
Documentation/Examples/Cabin8.txt
Normal file
13
Documentation/Examples/Cabin8.txt
Normal file
|
@ -0,0 +1,13 @@
|
|||
** Vehicles and pushable things
|
||||
(Disenchantment Bay: 8. Pushable chest of ice--Basic pushable object)
|
||||
Disenchantment Bay: a pushable chest of ice for the boat.
|
||||
|
||||
We probably do not need a vehicle to ride around our boat, but there might be a heavy ice chest that can only be pushed from room to room:
|
||||
|
||||
{*}The ice chest is a closed openable container in the Deck. "A very heavy ice chest sits on the ground." It is fixed in place and pushable between rooms. A quantity of ice is in the chest. The description is "Ready and waiting just in case there's any fish needing to be kept cool."
|
||||
|
||||
This anticipates a later chapter, but it would probably be a good idea to hint to the player, if he tries to take the ice chest, that there is another way to move it:
|
||||
|
||||
{**}Instead of taking the chest: say "It's too heavy to lift, but you might be able to push it, and just inch it over the frame of the door."
|
||||
|
||||
Otherwise, attempts to pick it up will just reply with "That's fixed in place."
|
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue