Inform library 6/6 released
Graham Nelson
Inform Library 6/6 now released
===============================
Library 6/5 has a number of annoying, if minor, bugs -- as Dan
Schmidt wrote on a backtrace showing the parser running,
*** Golly this line looks suspicious ***
(how right he was) and "oops" didn't work at all, an irony which
I'd better not take any credit for. Since the annual competition
is very nearly upon us it's high time for library 6/6, in which all
known bugs are mended. A new version of the compiler will follow
in a few days. Like every library since 6/3, this release of the
library will only work with compiler version 6.10 or later.
As will be seen, the parser is slightly enhanced (see changes 237
and 247) but there are no dramatic new features.
As a temporary measure, you can get hold of the new library from the
Inform 6 Home Page:
http://www.gnelson.demon.co.uk/inform.html
(in the form of a tar archive containing all 8 of the files
making up the library). It will be filed in its proper place at
ftp.gmd.de shortly, and then the temporary uploads page will be
taken out.
(Due to my Internet Service Provider caching its web pages,
there may be a slight delay before the new files become visible,
depending on where you live.)
I should like to thank everybody who emailed me with their woes
and to sympathise with one and all, not least the authors of the
forthcoming and marvellous "Zork: The Undiscovered Underground".
Graham Nelson
18 August 1997
-----------------------------------------------------------------------------
Extracted from the 6-series library modification history, which
resides on the World Wide Web at:
http://www.gnelson.demon.com/lhistory.html
-------------------------
227. Parser code cleaned slightly to prevent it from testing attributes
of object 0, which in theory is an abuse of the Z-machine (though in
practice it was harmless on existing interpreters).
228. As Anson Turner kindly observed, any library 6/5 game could be hung
up into an infinite loop by typing three characters: "i.g", that is,
"inventory. again" which would perform an inventory and then repeat
the command "inventory. again"... "again" now works properly as one
of a chain of commands separated by full stops: e.g. "s.g.g.n.i.g"
makes three moves south, one move north and then takes inventory
twice.
229. Very minor rule change concerning inventory entry printing. If an
object's "invent" property replies "true", in old libraries the
game will omit any English language punctuation after the list entry
for the object -- this only tends to occur when giving a wide-format
inventory listing (try typing "inventory wide"). The feature was
supposed to add flexibility, but didn't in any practical way, and
caused problems with string-valued "invent"s (which automatically
replied true on being called). Anyway, the new arrangements are
far more natural and this rule change is more of a bug fix.
230. Grammar for "get" tweaked so that the bare command "get" replies
"What would like to get?", and not "What would you like to get in?"
231. "oops" didn't work. An oversight on my part -- when rehashing the
parser to be more textually based, and less reliant on dictionary
parses, I forgot to rehash "oops". It seems healthy now (and is
a better implementation than it used to be anyway).
232. "found_in" routines are now properly sent messages, (so that for
instance "self" has the correct value in a "found_in" routine).
233. Numbers above 100 printed textually are now correctly spaced if
the US_DIALECT option is set.
234. Returning 0 from "door_to" routines did not always work. This
code has been rewritten so that the library consults "door_to"
as a message in the natural way. So you can either quote
door_to 0,
door_to 1,
door_to Balcony,
door_to "Some invisible force prevents your entry.",
door_to
[; if (random(2)==1) "The swing-doors push you back.";
print "Through the doors the path becomes confused.^";
return random(Room1, Room2, Room3);
],
To recap, the result of consulting "door_to" has to be either
0: this leads nowhere and please print a message saying so,
1: this leads nowhere but I've already printed something
or the object number of the room to go to.
235. The extra space on the status line in "time" games, when the
time is just after noon or midnight, has been removed.
236. A serious but rare error, causing the parser to crash while parsing
prepositions at the end of some grammar lines, removed.
237. If the player types "get two of hearts", what is being referred to,
a single object (a card from a pack of cards) or two from a
collection (say, a freezer full of transplant organs)? The 6/5
parser would always assume the latter; the 6/6 parser now tries
both assumptions. To demonstrate:
Card School
A room full of green baize tables.
You can see a two of hearts, a two of spades, a jack of hearts,
a seven of spades, a three of clubs and a seven of clubs here.
>get two of spades
Taken.
>get two of clubs
three of clubs: Taken.
seven of clubs: Taken.
>get two
(the two of hearts)
Taken.
>drop two twos
two of hearts: Dropped.
two of spades: Dropped.
Similarly, phrases like "two of hearts" are now always assumed to
refer to single objects if the grammar in question would require
a singular and not a plural. (For instance, "examine two of hearts"
implicitly calls for only one object to be examined.) Finally,
the treatment of "one" is now subtly different from "a" or "an"
to allow for its possible use as a noun: so you could have a
"one of diamonds", say, without parsing trouble.
238. "drop me" now produces a reasonable response.
239. "noun=FilterRoutine" grammar tokens sometimes caused mysterious
crashes in large games where the routine in question was towards
the end of the program. (Thanks to Magnus Olsson for pointing
out both problem and solution.)
240. The time at which "MoveFloatingObjects()" is called has been
slightly altered. This affects objects which are present in many
rooms simultaneously (e.g. "sky" or "water"). What has changed
is that objects are now correctly moved into place even when the
room in question is in "Darkness" -- this is particularly
important if the object itself is the only light source, e.g. if
it is the Moon, or a strip-light running down a long corridor.
241. Objects which are handled only very briefly because of "implicit
take commands", like so:
>give bun to elephant
(first taking the bun)
The elephant swallows the bun and trumpets.
...are now given the attribute "moved", will give you any score
that should accrue from having once held them, and will appear
in the output of the "Objects" command. (Previously the period
of ownership was so brief that the library failed to apply these
rules.)
242. Messages involving "it", "that", "those", etc. now correctly
use "her", "him", etc., as needed: e.g.
You need to be holding the elephant before you can put
him in the striped box.
243. If the player is on top of something which itself rests on
something (say, on a chair on top of a billiards table) then the
room description no longer lists any objects on the lower
supporter(s) twice.
244. The parser sometimes used to misunderstand answers to the questions
asked when the player typed so little original input that the parser
had to infer a preposition, and then ask a question: e.g.
>put key
What do want to put the key in? [Notice inferred "in"]
>box
You can't see any such thing.
even though there is a box in scope. This is now mended.
245. A bug occurring with multiple alternative prepositions in grammar
lines (of games so large that the dictionary extends past 32K in the
game's memory map) has been removed.
246. The newish rules requiring objects to be touchable (see 207 above)
are now waived in the case of anything explicitly declared to be
present using "add_to_scope": that is, as long as object O is
touchable, then anything added to scope by O will be considered
touchable as well (including any children of anything added to scope
by O, and so on down).
247. Disambiguation has been made slightly more sensitive. Previously,
when parsing for a "noun" (or a "multi") token the parser would
prefer anything in the actor's location to something the actor is
carrying. This preference is withdrawn for "noun" tokens.
As well as preventing the parser from leaping to conclusions, the
change gives the designer's "ChooseObjects" routine a greater weight
in deciding between objects. E.g., given the routine...
[ ChooseObjects candidate code;
if (code == 2)
{ if (action_to_be == ##Push)
if (candidate ofclass Button) return 2;
}
return 0;
];
...if the player were to type "push red" while holding a device
with a red button on, and standing in front of a red pillar box,
"ChooseObjects" would have the casting vote and the button would
be pushed (even though it's being held and Push is an action
normally considered to apply externally).
The preference for things on the floor is continued for "multi"
tokens (where it helps "get all" to work), but with new exceptions:
no preference is made for (a) scenery, (b) "concealed" objects or
(c) the actor himself.
-----------------------------------------------------------------------------
--
Graham Nelson | gra...@gnelson.demon.co.uk | Oxford, United Kingdom