Inform library 6/5 released
Graham Nelson
Inform library 6/5 released
===========================
I have recently upgraded the Inform compiler to v6.13, by making a
small patch to fix a minor bug in some new code in v6.12, but details
of that are posted elsewhere. This post is to announce a more
substantial improvement: library 6/5 is the first version of the
Inform library to offer new game-design features for over a year
(changes 206 and 207), and there are also improvements for language
definition files and some bug fixes (one, change 208, quite important).
As for 6/3 and 6/4, the library consists of eight text files:
parser.h verblib.h grammar.h
parserm.h verblibm.h
linklv.h linklpa.h
English.h
(where "English.h" is the default language definition file).
The library files should appear at ftp.gmd.de shortly. If you can't
wait, then as a temporary measure you can get hold of a tar file
containing all 8 from the Inform 6 Home Page:
http://www.gnelson.demon.co.uk/inform.html
Please note that there may be a delay of one to three days before the
new file becomes "visible" from your region of the Internet, because
of the regrettable way that my Internet service provider organises its
WWW space. So if it doesn't show up immediately, please be patient.
The library history page at the above site has also been updated, and
again the update may not show at once.
My thanks, as ever, to those who have emailed me bug reports. I am
always grateful for these, though it can sometimes take me a couple of
weeks to reply when I have a serious email backlog, for which I
apologise. Please try to send me a short piece of source code
demonstrating what you think is wrong, if possible: this saves on long
explanations and makes it much easier for me to find the problem.
Finally, apologies to everyone who has been promised that 6/5 would
appear "any day now". I would like to blame the inventors of the
Spanish and German languages for this, or at least Jose Luis Diaz de
Arriba and Ralf Herrmann as their representatives on Earth.
Graham Nelson
26 March 1997
------------------------------------------------------------------------
The changes present in library 6/5, serial number 970405 are as
follows:
205. Grammar for "get" adjusted so that "get up" is not misinterpreted
as "take the ceiling". Grammar for "close up" fixed so that
"close up noun" now works as it should (not that it occurs very
often).
206. The library has been enhanced to make it possible for the player
to be inside an object or a sequence of objects (for instance,
in a box which is on top of a table). One or more of these
objects can now be closed and can even block off visibility,
so that the player can be sealed in and unable to see the
room outside. The changes made have implications for scope,
light and the handling of "take", "remove", "insert", "put", "empty",
"look", "enter", "open" and "exit".
The new rules extend the usual ones: you can see through anything
which is "transparent", or a "supporter", or a "container" which
is "open", and this affects both scope and the presence of light;
you can take through anything which is a "supporter" or a
"container" which is "open". A special case is that, even in
darkness, the immediate object containing the player is always in
scope, as that prevents the player from shutting himself in a dark
cupboard and then being unable to say "open cupboard" to get out
again. (To test these rules, you may want to use the "scope"
debugging verb, which lists all the objects currently in scope.)
The "enter" verb automatically moves the player out of and into
as many intermediate stages as needed to reach its destination.
Note that Receive and LetGo actions (asking containers and
supporters if they mind objects being inserted or removed)
are not generated when the player is already inside or on
the holder.
A new property has been created called "inside_description".
Anything which is "enterable" may wish to provide a string or
routine to print something here: perhaps what an interior looks
like, or what a vehicle looks like to the occupant.
For instance, here is a room description which results from
the player getting into a huge cupboard, closing the door
behind her, and then getting into a plastic cabinet inside that:
The huge cupboard (in the plastic cabinet)
-----------------
(*) It's a snug little cupboard in here, almost a room in itself.
In the huge cupboard you can see a pile of clothes.
(*) The plastic walls of the cabinet distort the view.
Note that the exterior room description has vanished altogether.
The two lines marked (*) are values of "inside_description"
for the cupboard and cabinet. Note that there's absolutely
no obligation to provide an "inside_description" for an "enterable"
object.
I wish to thank the many people who made suggestions on this
subject, but especially Daryl McCullough and Fredrik Ramsberg,
who analysed it in detail, and Admiral Jota, who organised a
response.
207. A further significant change has been to introduce a formal idea
of what the player can touch and manipulate. Up to now, the
library has confused together what can be seen with what can be
touched: obviously, if the player is inside a closed glass cabinet,
there's a significant difference.
The rule is that you cannot touch something if there is a closed
container between you and it. This applies either if you're in
the container, or if it is. The former case will not have applied
before, but the latter may cause inconsistencies with previous
library behaviour. That is, in the library as it stood, you could
unlock something which was inside a closed glass box, and it's
possible that some games have exploited this loophole.
Note that the rule is only applied after "before" rules have been
consulted. The actions affected are as follows:
Take, Remove: The item must be touchable. Furthermore, it must
not be (directly or indirectly) in the possession of anyone
"animate", or (directly or indirectly) in the possession of
anything which is neither a "container" nor a "supporter".
(These last two rules have always been part of the library:
only the touchable condition is new.)
Insert, PutOn: The destination must be touchable.
Empty: The container to be emptied must be touchable. Since all
the transfers of objects from it are made via Insert, PutOn
or Drop actions, the destination must be touchable too.
Enter: The item must be reachable by a sequence of Exit and Enter
actions, which ensures that it is touchable.
Search, Unlock, Lock, SwitchOn, SwitchOff, Open, Close, Disrobe,
Wear, Eat, WakeOther, Touch, Wave, Pull, Push, Turn, Squeeze,
ThrowAt, Kiss, Attack:
The noun must be touchable. Note that this includes a few
actions which ordinarily have no effect (Push, Pull, Turn)
simply to improve the messages produced.
(The actions Give, Show, Drop, Insert and PutOn do have to have
touchable nouns, but since they always required their nouns
to be directly possessed by the player, this makes no change
to the established rules.)
Designers who want to apply the same kind of rule to their own
actions can use the library routine
ObjectIsUntouchable(obj)
which determines whether obj is touchable or not. If it is
touchable, the routine returns false and nothing is printed. If
untouchable, the routine prints a suitable message explaining why
and returns true. This means that only a single line of code
needs to be introduced to the action routine to handle this
issue. For instance, the library's Eat action routine now reads:
[ EatSub;
if (ObjectIsUntouchable(noun)) return;
if (noun hasnt edible)
...etc.
Finally, an optional second parameter to ObjectIsUntouchable
will make the routine work silently:
ObjectIsUntouchable(obj, true)
returns true or false but prints nothing.
208. A serious but recent bug fixed: the recent tidy-up of the code for
the Go action in 6/4 missed a case, so that if one walks into a
door with a door_to routine which returns true (meaning: you can't
proceed), the library moves one to a room numbered 1. If the
player has a light source, he can see that this room is actually
"Class" and that the classes of the game are scattered about like
objects (a somewhat Platonic journey into the world of forms).
209. Four library messages (Miscellany 42 and 47; Show 2; Take 9) have
prints changed to print_rets, thus making sure they have a new-line
printed after them. Three further library messages (Look 1, 2 and 3)
have been extended: these used to print the words "on", "in" and
"as", but now print the phrases " (on the whatever)" and so on.
(This should assist translations, as the named object may have
to be named in the dative rather than accusative.)
The library message Drop 1 has been reworded slightly to make better
sense when the player isn't in a place with an obvious floor.
The messages Miscellany 48 and 49 have been rewritten to include
calls to a library routine which prints out the player's command.
(These messages handle "What do you want to take?" and similar.
The change makes it easier for language definition files to cope
with this difficult case.)
Both the library messages for Transfer (1 and 2) have been removed
as redundant.
Finally, there are two new library messages, Enter 6 and 7.
210. Games using 6/3 or 6/4 could crash when trying to print a suitable
error message if the player uses a pronoun which has never been
set in the course of the game (e.g. "her" in a generally masculine
environment).
211. The pronouns system has a complicated mechanism, in English only,
to carry on supporting the "itobj", "himobj" and "herobj" variables
(for the sake of old code). In 6/4 this didn't quite work and some
settings of these variables would have no effect.
212. The official rewording-routine for language definition files,
called LanguageToInformese, wasn't being called: instead, a routine
called LanguageReword was. I have changed this to
LanguageToInformese as per the documentation. Any routines called
LanguageReword in language definition files will no longer work.
Apologies for this elementary error.
213. Containers which are neither "open", "openable" nor "transparent"
but which are empty are no longer reported as empty in inventory
lists. (After all, how could the player tell?)
214. The debugging verbs "purloin" and "abstract" are now protected
against moving or taking classes or system objects like
"InformLibrary", and also against moving objects so that they
indirectly contain themselves, which can lead to Z-machine crashes
or infinite recursions.
215. Problems saying things to unspecified people in large games might
have occurred because of a complicated mistake in coding the
new (6/3 and later) parser. Thanks to Magnus Olsson for finding,
diagnosing and correcting this mistake.
216. The "PrefaceByArticle" not correctly pluralising articles in
some cases. Thanks to Andreas Hoppler and Ralf Herrmann for
fixing this.
217. The "objects" verb no longer reports items left on enterable
supporters as being "in" rather than "on" something.
218. The parser now has a better system for handling extension input,
that is, text typed by the player in response to a question like
"What do you want to take?". The previous system did not behave
well in languages other than English, as Ralf Herrmann and Jose
Luis Diaz de Arriba pointed out. Similarly, the "again" system
has been rewritten, which should make it work slightly better
even in English.
219. Bug in handling of "short_name_indef" removed. (This is a feature
not needed in English language games.) Thanks to Ralf Herrmann
for mending this.
220. The library now calls "LanguageInitialise" immediately before
calling "Initialise", if the language definition file provides
one. (This is convenient for German, for instance, to give the
darkness-object "female".)
221. The language definition file can (optionally) provide a routine
called "LanguagePrintShortName" to print the short name of an
object. Specifically,
LanguagePrintShortName(o)
(which will only be called if o is a valid object number) should
either return false, or print the short name of o and return true.
At the time of the call, the variable "indef_mode" will be set
if an indefinite article has just been printed.
The "English.h" definition doesn't use this feature, but if it
did then the appropriate code would be:
[ LanguagePrintShortName o;
if (indef_mode && o provides short_name_indef
&& PrintOrRun(o,short_name_indef,1)) rtrue;
if (o provides short_name && PrintOrRun(o,short_name,1)) rtrue;
@print_obj o;
rtrue;
];
(Note that "PrintOrRun(o,X,1)" is very similar to sending the
message X to object o, but doesn't print a new-line if o provides
a string for property X.)
222. The parser's fundamental routine "Refers", which determines whether
a given English word refers to a given game object, now calls
"LanguageRefers" if the language definition file provides this.
The syntax is LanguageRefers(obj, word_number), and the return value
should be true or false to indicate the result, or -1 to indicate
"make the decision as usual". Note that the word doesn't have to
be in the game dictionary, which is why it's referred to by its
number (in the sequence of words typed in as the present command),
not by its dictionary address.
223. And the language definition file can also optionally provide a
routine called
LanguageIsVerb(buffer, parse, word_number)
If provided, this should look at the numbered word in the given
text buffer (which has been tokenised into the given parse buffer
already) and decide whether it's a verb. If so, the routine should
return a dictionary word for that verb. If not, it should return
false. (This is provided to allow automatic inflection of verbs:
e.g. automatic conversion of the various German alternative verb
endings into one standard one.)
224. When printing short names, the variable "indef_mode" is now:
true if an indefinite article has just been printed; false if a
definite article has just been printed; and equal to NULL if no
article was printed at all. (For instance, it will be NULL when
the list-writer prints a list with the NOARTICLE_BIT style set.
This assists the German translation.)
225. In order to make it easier to adjust cases in lists written in
inflected languages: a language definition file can now define
a constant called LanguageCases, which should be a number.
The default value is 1. The library creates a variable called
"short_name_case", initially with value 0, and which is free to
be changed by the game or the language definition file routines.
Its value should always be between 0 and LC-1 (thus, in English
it will always be 0): I suggest that code like...
Constant LanguageCases = 4;
Constant NOMINATIVE_CASE = 0;
Constant ACCUSATIVE_CASE = 1;
Constant GENITIVE_CASE = 2;
Constant DATIVE_CASE = 3;
...may simplify things. The "LanguagePrintShortName" routine may
want to make use of the value of "short_name_case", if such a
routine is provided. The library itself uses the case only when
printing articles. If LC is 1, so there are no cases, then the
array LanguageArticles is unchanged from its old definition:
Array LanguageArticles -->
! Contraction form 0: Contraction form 1:
! Cdef Def Indef Cdef Def Indef
"The " "the " "a " "The " "the " "an " ! Articles 0
"The " "the " "some " "The " "the " "some "; ! Articles 1
But if LC is more than 1, then there extra rows for the extra cases.
For example, if we had an extra case in English which required all
articles to be given in capital letters, we could then have LC=2,
with ordinary case as number 0, and the exotic new one as number 1:
the table might look like...
Array LanguageArticles -->
! Contraction form 0: Contraction form 1:
! Cdef Def Indef Cdef Def Indef
"The " "the " "a " "The " "the " "an " ! Articles 0
"THE " "THE " "A " "THE " "THE " "AN "
"The " "the " "some " "The " "the " "some " ! Articles 1
"THE " "THE " "SOME " "The " "THE " "SOME ";
(The effect is actually quite interesting.)
226. Grammar tweaked slightly to ensure that "get X from Y" is handled
better when X is ambiguous.
------------------------------------------------------------------------
--
Graham Nelson | gra...@gnelson.demon.co.uk | Oxford, United Kingdom