home *** CD-ROM | disk | FTP | other *** search
/ Sunny 1,000 Collection / SUNNY1000.iso / Files / Dos / infoco3 / LIBRARY.ZIP / changes.txt next >
Encoding:
Text File  |  1995-10-24  |  43.9 KB  |  832 lines

  1.  
  2. Life and Times of the Inform Library                       23rd October 1995
  3. ====================================
  4.  
  5. This modification history takes release 5/5 of the Inform library as a base,
  6. and runs up to release 5/12.  5/5 is the state described in the first
  7. edition of the Designer's Manual and 5/12 the one in the second edition:
  8. thus everything here is integrated into the new DM.
  9.  
  10. Designers changing up to 5/12 are asked to note no. 155 particularly,
  11. as this is a change inconsistent with previous library releases.
  12.  
  13. Thanks to Gareth Rees, Mike Threepoint, Torbj|rn Anderson, Brendon Wyber,
  14. Robert Dickau, Brad Jones, David Wagner, Robert Stone, Matthew Russotto,
  15. Sam Hulick, Mike Phillips and many, many others.
  16.  
  17. Changes in Release 5/6 (941112)
  18. ===============================
  19.  
  20. 1. The game banner is tidier and a line shorter (some people felt the old one
  21.    overdone: use the command "version" for more code numbers)
  22. 2. EnglishNumber printing fixed up to work nicely across the whole range of
  23.    signed integers (i.e. about plus-minus 30000), with "forty" correctly spelt
  24.    this time: e.g. "minus twelve thousand, three hundred and eight"
  25. 3. The bug "the game crashes if you try to take what you're sitting on or in"
  26.    is fixed
  27. 4. Two new bits are available for WriteListFrom styles.  ISARE_BIT prints
  28.    " is " or " are " before the list, according to its size, and CONCEAL_BIT
  29.    (which only works if WORKFLAG_BIT isn't used) misses off items which have
  30.    "concealed" or "scenery"
  31. 5. Containers now aren't called "open" or "closed" in lists unless actually
  32.    "openable": thus, messages like "a paper cup (which is open but empty)"
  33.    will now read "a paper cup (empty)"
  34. 6. Concealed or scenery items now not mentioned inside vehicles or on top of
  35.    things (see (4)!)
  36. 7. The "found_in" property is enhanced.  If an object O1 is given in the
  37.    found_in list of O2 which isn't a room, then O2 is counted as being in the
  38.    same room as O1, wherever that is at the moment.  (But be warned: this is
  39.    only updated when the player changes rooms.)
  40.    Moreover, the "found_in" property of O can instead of a list of places be
  41.    a routine.  This returns true if O should be in location, false otherwise.
  42.    For instance,
  43.  
  44.      Object Sun "Sun",
  45.        with ....
  46.             found_in
  47.             [; if (location has light) rtrue;
  48.             ],
  49.        has  scenery;
  50.  
  51.    This saves bother with long lists of places, and also makes it much easier
  52.    for objects to spread out or contract (like fire, or flooding) in play.
  53. 8. A bug making YesOrNo() corrupt a customised status line has been removed
  54. 9. Under earlier library files, returning 0 from a token-parsing routine
  55.    was illegal and might hang the parser (see p. 41 in the Designer's Manual
  56.    for the old specification).  Returning 0 is hereby legalised and indicates
  57.    "accept the text the word marker has been skipped over, and count it as
  58.    not specifying any particular object or number".  For example, given
  59.  
  60.      [ PolyAdj w;
  61.        w=NextWord(); if (w=='on' or 'at' or 'in') return 0;
  62.        return -1;
  63.      ];
  64.  
  65.    the token PolyAdj will accept "on", "at" or "in" as alternative choices of
  66.    adjective (and forget which one the player actually typed).
  67.    Similarly,
  68.  
  69.      [ Anything w; 
  70.        while (w~=-1) w=NextWord(); return 0;
  71.      ];
  72.  
  73.    makes the token Anything accepts the entire rest of the line.
  74. 10. The grammar "shut off", "climb up", "close up", "dig", "dig with" has been
  75.     added
  76. 11. Taste and Touch are now required to take objects: as a result the
  77.     old TouchThing action has gone, and there is simply a Touch action.
  78.     (Strictly speaking this is an incompatible change but hardly anyone has
  79.     used these actions anyway.)
  80. 12. The Escape key now acts as Q to get out of menu displays (if your
  81.     interpreter is well enough written to recognise an escape key)
  82. 13. A convenience (but also problem) is that the Receive fake action is
  83.     generated both when the player tries to put an object in something, or
  84.     on it.  This is no problem unless the recipient is trying to be both at
  85.     once, in which case it may need to know why the Receive has been
  86.     generated - i.e., which the player's trying to do.  The "right" solution
  87.     would be to have two different fake actions, but that would be a rather
  88.     incompatible change and make a certain amount of existing code work
  89.     differently.  Instead, a variable called "receive_action" is set to either
  90.     ##PutOn or ##Insert depending on which is causing the Receive to happen.
  91. 14. Several people have asked for easier ways to have several kinds of
  92.     containment at once, all on the same object - on top, inside, under,
  93.     behind, component parts of, etc.  For these (and other) purposes a brand
  94.     new property called "add_to_scope" has been added.  Anything listed under
  95.     this property is also in scope when the parent object is.  (This also has
  96.     consequences for light considerations.)
  97.     See the modest example "A Nasal Twinge" for two applications of this.
  98.     Note for true scope hackers: this scope addition does _not_ occur if the
  99.     object is moved into scope by the programmer explicitly calling
  100.     PlaceInScope (since this must allow completely arbitrary scope
  101.     selections), but that it does happen when objects are moved in scope
  102.     by calls to ScopeWithin(domain).
  103.     The "add_to_scope" property is aliased, so there's no cost in property
  104.     consumption.
  105. 15. Trying to type "undo" on the very first turn now produces a more sensible
  106.     error message.
  107. 16. 5/5 had an especially embarrassing bug - "go north" didn't work!  Which
  108.     goes to show how thoroughly hooked on abbreviations we all are now,
  109.     because hardly anybody noticed.
  110. 17. The initial room description (printed after the game banner) is now
  111.     properly done with a Look action (in particular, before and after
  112.     routines are invoked).  This is in case some horrid "before" hack is
  113.     being applied to the description of the first location.
  114. 18. Likewise, the library now works correctly if the game begins in darkness
  115.     (Steve Meretzky is fond of this trick - e.g. "Hitchhikers", "Sorcerer")
  116. 19. "out" used not to work properly in a dark room with an out map
  117.     connection, but now does
  118. 20. A somewhat brutal test (Torbj|rn Anderson constructed 450 daemons!)
  119.     revealed that the daemon/timer routines stored object numbers in bytes
  120.     rather than words (thus getting them wrong in big games): not any more
  121.     they don't
  122. 21. It is now legal to return 3 from a routine attached to DoMenu (which
  123.     usually prints some text out, such as a hint: return values of 0 or 1
  124.     make the game wait for a space then return to the menu, 2 makes the
  125.     game return directly): this makes the game quit the menu altogether
  126.     as if Q had been pressed (which is useful for juggling submenus around).
  127.  
  128. Changes in Release 5/6 (941117)
  129. ===============================
  130.  
  131. 22. "You open the box, revealing ." bug fixed (when box is empty)
  132. 23. A character got seriously corrupted in the timers routines: fixing this
  133.     was urgent, hence the rapid re-release
  134.  
  135. Changes in Release 5/7 (941214)
  136. ===============================
  137.  
  138. 24. add_to_scope can now take a routine instead of a list of objects.
  139.     This routine has to call AddToScope(obj) for each obj it wants to add
  140.     to the scope. (It may not use ScopeWithin or any other scoping routines)
  141. 25. The direction objects now have the general-purpose "number" property
  142.     provided, as it's sometimes convenient to have a scratch variable for
  143.     each direction (when programming mazes, for instance).
  144. 26. If the constant WITHOUT_DIRECTIONS is defined before inclusion of the
  145.     library files, then 10 of the default direction objects are not defined
  146.     by the library.  The designer is expected to define alternative ones
  147.     (and put them in the "compass" object); otherwise the game will be
  148.     rather static.  (The "in" and "out" directions are still created, because
  149.     they're needed for getting into and out of enterable objects.)
  150. 27. The routine ChangeDefault(property, value) dynamically changes the
  151.     game's default value for that property (i.e. the value that property has
  152.     for any object not explicitly giving a value of its own).  For instance,
  153.  
  154.       ChangeDefault(cant_go, "You're a Master Adventurer now, and still \
  155.                               you walk into walls!");
  156.  
  157. 28. The reverse-order form of "show" didn't work when addressed to a third
  158.     party, as in
  159.  
  160.       charles, show diana the phone bill
  161.  
  162.     but now does.
  163. 29. Very subtle bug in object-name printing (it had a peculiar and very rare
  164.     side-effect which I think only turned up when using odd combinations of
  165.     debugging commands, and took me ages to find!) fixed.
  166. 30. The not very sad demise of another piece of Inform antiquity: the
  167.     use of the "special" token in the library grammar.  The only substantial
  168.     use left was in the grammar for looking up or consulting things, like
  169.     books (an old Curses mainstay).  Now it's tricky to parse lines like
  170.  
  171.       look up figure 18 in the engineering textbook
  172.  
  173.     because almost anything could appear in the first clause, and even its
  174.     format depends on what the second clause is.  So the new arrangement
  175.     is: if an object wants to be "consultable", it should have a before rule
  176.     for the "Consult" action.  The Consult action will happen when the
  177.     player types, for instance,
  178.  
  179.       look up <any words here> in <the object>
  180.       read about <any words here> in <the object>
  181.       consult <the object> about <any words here>
  182.  
  183.     and the object has to parse the <any words here> part itself.
  184.     (Note that "second" doesn't hold any value in a Consult action; internally,
  185.     the <any words here> part is treated as an adjective by the parser.)
  186.     To help the object to do this, variables are set up:
  187.  
  188.       consult_from       -        number of the first word in the <any...>
  189.       consult_words      -        number of words in the <any...>
  190.                                   (which must be at least 1)
  191.  
  192.     It can then use NextWord(), TryNumber(word-number) and the like
  193.     to decide on the topic.  If you really need more elaborate topic-parsing
  194.     then grammar replacement is probably a better bet.
  195. 31. The verbs "read" and "examine" are now separated - this has been a
  196.     popular request for about a year now!  They still both ordinarily
  197.     generate the Examine action, but it is now possible to add or replace
  198.     grammar for "read" without doing so for "examine" at the same time.
  199.     Consequently one may now easily create a separate Read action, if
  200.     required.  E.g.:
  201.  
  202.       Attribute legible;
  203.  
  204.       Object textbook "textbook"
  205.         with name "engineering" "textbook" "text" "book",
  206.              description "What beautiful covers and spine!",
  207.              before
  208.              [; Consult, Read:
  209.                    "The pages are full of nasty equations which \
  210.                     make no sense to you.";
  211.              ],
  212.         has  legible;
  213.       [ ReadSub; <<Examine noun>>; ];
  214.       Extend "read" first
  215.                 * legible                        -> Read;
  216.  
  217.     Note that "read" is automatically translated to "examine" for anything
  218.     which doesn't have "legible", or indeed does but doesn't provide any
  219.     "before" rule for Read.
  220. 32. Many actions (all those which do something substantial and then print a
  221.     message saying they've done it), viz.:
  222.  
  223.       Take, Drop, Insert, PutOn, Remove, Enter, Exit, Go, Unlock, Lock,
  224.       SwitchOn, SwitchOff, Open, Close, Wear, Disrobe, Eat
  225.  
  226.     now consult a variable called "keep_silent".  If this is 1, they say
  227.     nothing in the event of _success_ (if they fail, as they may do in many
  228.     different convoluted ways, they still complain out loud).
  229.     It is essential to reset this variable to 0 after use.
  230.     This feature makes implicit actions much easier to "properly" implement,
  231.     i.e. to implement without bypassing any lurking game rules.
  232. 33. (As indeed here.)  The library used to be a bit casual about putting
  233.     items away automatically into the SACK_OBJECT (if there was one defined),
  234.     but now it applies the full normal rules by causing an Insert action.
  235.     Thus, the sack needs to be open, any odd behaviour coded up for the
  236.     sack will now work, the sack's capacity cannot be exceeded and so on.
  237. 34. The Enter and Exit actions sometimes missed possible location "after"
  238.     rules; they've now been tidied up.
  239. 35. Silly bug in scoring "scored" objects (picked up by take all) fixed.
  240. 36. "your" is now understood in some contexts by the parser: so that
  241.  
  242.       george, give me your ukelele
  243.  
  244.     works (if someone called George is holding a ukelele).
  245. 37. In 5/6 and before, if you put a green box inside a red bag, and then
  246.     tried to put the red bag into the green box, they would collapse in on
  247.     themselves into a black hole and vanish from the game.  (An amusing
  248.     thing to do is then to use the "tree" debugging command on the green
  249.     box.)  The library now insists on the Axiom of Foundation (i.e., won't
  250.     let you put something indirectly inside or on top of itself).
  251.  
  252. Changes in Release 5/7 (941220)
  253. ===============================
  254.  
  255. 38. The "the box of tarot cards is empty already." sentence now capitalises
  256.     the "The".
  257. 39. Bug in the parser fixed.  Occasionally grammar like
  258.  
  259.       ... * scope=MicroScope "at" noun  -> ...
  260.  
  261.     would mistakenly apply the MicroScope scope rules to the second, plain
  262.     noun token.  This no longer happens.
  263. 40. Minor darkness bug (to do with getting out of enterable objects when in
  264.     a dark place) fixed.
  265. 41. Single rather than double new-line now printed when light returns to the
  266.     game (after all, some people have small displays).
  267. 42. If a "supporter" (say, a mantelpiece) holds up only items which have
  268.     "scenery" or "concealed", the library used to say "On the mantelpiece."
  269.     and stop: now it omits such a line entirely.
  270. 43. The treatment of "concealed" possessions of containers is slightly
  271.     tidied up (though using such is not recommended except in scenery, as
  272.     it's likely to need some effort to make inventories do the right thing).
  273. 44. (Cf. (4) above.)  At Gareth Rees' proposal, WriteListFrom now has a
  274.     policy on what to do if both CONCEAL_BIT and WORKFLAG_BIT are set,
  275.     causing a clash.  In this instance, the "workflag" rule applies at the
  276.     top level, but not below, and the "conceal" rule applies below but not
  277.     at the top level.
  278. 45. A soupcon of new grammar: "climb over" (just does the Climb action);
  279.     "thump" and "punch" now equate to "attack"; "present" and "display" to
  280.     "show"; one can now "stand on" something.
  281. 46. It's Christmas, and a new fake action is born.  This one is called
  282.     "ThrownAt" and is analogous to "Receive" for containers: i.e., it runs
  283.     before rules for the object which something is being thrown at.  E.g.,
  284.  
  285.         before
  286.         [;  ThrownAt: if (noun==dart)
  287.                       {   move dart to self; "Triple 20!"; }
  288.                       move noun to location;
  289.                       CDefArt(noun); " bounces incongrously off the board.";
  290.         ],
  291.  
  292.     Note: "after" rules don't apply, as the default behaviour of ThrowAt
  293.     is to do nothing but rebuke the player.
  294.  
  295. Change in Release 5/7 (941230)
  296. ==============================
  297.  
  298. 47. Last and most embarrassing bug fix of 1994: removing a spurious tracing
  299.     message, "Else clause", left in by accident from earlier debugging.
  300.  
  301. Changes in Release 5/7 (950109)
  302. ===============================
  303.  
  304. 48. Minor enhancement to the "tree" debug verb; new "gonear" debug verb,
  305.     such that "gonear frog", say, takes you to the room the frog is in.
  306. 49. The library often needs to print a property value if it's a string, or
  307.     run it if a routine.  There's now a routine to do this:
  308.  
  309.         PrintOrRun(object, property, flag);
  310.  
  311.     If the (optional) flag is given and non-zero, a new-line is printed
  312.     after a string (but only if it was a string).
  313.     The library now makes extensive use of this, tidying up the code
  314.     somewhat, but the reason for the change was that it was previously
  315.     doing signed comparisons to work out where addresses lie in memory,
  316.     which begins to fail when the total game size exceeds about 180K.
  317.     Two new useful primitives are:
  318.  
  319.         UnsignedCompare(x,y)  returns   1  if x>y
  320.                                         0  if x=y
  321.                                        -1  if x<y
  322.  
  323.     and
  324.  
  325.         ZRegion(addr)         returns   1  if addr is a valid object number
  326.                                         2  if addr is a routine address
  327.                                         3  if addr is a string address
  328.                                         0  otherwise.
  329. 50. The "NewRoom" entry point was previously not always being called when
  330.     a new room was entered, as the manual claimed; now it is.
  331. 51. The "purloin" debugging verb now clears "concealed" from anything it
  332.     magically takes - this prevents nuisance in later use.
  333. 52. The "article" property can now hold a routine to print one, in line
  334.     with standard library practise.  One might imagine "a mouse" changing
  335.     dynamically to "some mice", perhaps.
  336. 53. Inelegant messages like "(which is closed) (which is empty)" tidied
  337.     up into "(which is closed and empty)".
  338. 54. New debugging verbs are provided to take advantage of the Z-machine's
  339.     own game-testing features.  These may not fully work under ITF, but
  340.     do work under Zip.  (For either Standard or Advanced games.)
  341.  
  342.     "recording" (or "recording on") saves all the commands typed in a
  343.        session to a file,
  344.     "recording off" stops this,
  345.     "replay" plays back the script (i.e. reads commands from the file);
  346.  
  347.     in order to make the Z-machine predictable (that is, deterministic)
  348.     one would like to make the random number generator do exactly the
  349.     same thing each time, and this is achieved by typing
  350.  
  351.     "random", which internally does @random -100.  It should be noted that
  352.     this in particular depends very much on how good your interpreter
  353.     (and its port) is: on my machine, this doesn't appear to do anything,
  354.     for instance.
  355.  
  356. Changes in Release 5/8 (950118)
  357. ===============================
  358.  
  359. 55. Trying to ask somebody else to repeat something by, e.g.,
  360.  
  361.         major, resign     rather than     major, resign
  362.         major, again                      again
  363.  
  364.     would sometimes (horrifyingly) hang the Z-machine - now it produces a
  365.     polite reply.  Apologies for having missed this case.
  366. 56. And another crude parser bug.  "get all except" hasn't always been
  367.     working recently: now it works again.
  368. 57. A popular request (well, three people asked, anyway) is for a way of
  369.     changing some of the parser's assumptions about what to do with vague
  370.     requests by the player.  The notorious one is: should "take all"
  371.     attempt to take objects marked as "scenery", and thus reveal their
  372.     existence as game objects?  (Infocom games did, and Inform usually
  373.     does.)
  374.     The new entry point
  375.  
  376.         ChooseObjects(object, code)
  377.  
  378.     is provided for this.  It is called in two circumstances.  If code is
  379.     0 or 1, that means the parser is contemplating including this item in
  380.     an "all", and the code is 0 if the parser intends not to, 1 if it
  381.     intends to do so.  Returning 1 forces it to be included, returning 2
  382.     forces it to be excluded and returning 0 (the default, i.e. rfalse)
  383.     makes the parser do what it had previously decided anyway.
  384.  
  385.     The other time is when code is 2.  This means that the parser is having
  386.     to sort through a list of items, trying to decide which is intended.
  387.     Return a number from 0 to 9 (0 is the default, i.e. rfalse again) to
  388.     give the item a score for how appropriate is.
  389.     For instance:
  390.  
  391.         [ ChooseObjects obj code;
  392.           if (code<2) { if (obj has scenery) return 2; rfalse; }
  393.           if (action_to_be==##Eat && obj has edible) return 3;
  394.           if (obj hasnt scenery) return 2;
  395.           return 1;
  396.         ];
  397.  
  398.     (The parser's internal variable "action_to_be" is always set to the
  399.     action that will be generated if the current line of grammar is
  400.     successfully matched.)
  401.     Scenery is penalised twice in this example - it never appears in any
  402.     multiple lists, and non-scenery is always preferred over scenery when
  403.     sorting out an ambiguous input.  Unless, that is, the object is edible,
  404.     and the player is trying to Eat something.  ("eat black" will now choose
  405.     a Black Forest Gateau rather than a black rod with a star on the end).
  406. 58. Another popular request (popular with everyone except me, as it was
  407.     horrid to implement) was for a mechanism for changing the Library's
  408.     habitual messages - many people become very irritated when their own
  409.     games say "Violence isn't the answer, you know" for the dozenth time.
  410.     Of course this was always possible by massive means (replacing huge
  411.     numbers of routines, for instance), but now it's much easier.
  412.  
  413.     This feature is provided in an unusual way.  You may optionally
  414.     provide a special object called LibraryMessages (but if you do so,
  415.     you must define it in between the inclusion of "Parser" and the
  416.     inclusion of "Verblib").  Here is an example, changing two of the
  417.     library's standard messages:
  418.  
  419.         Object LibraryMessages "lm"
  420.           with before
  421.                [;  Jump: "You jump and float uselessly for a while in \
  422.                           the zero gravity here on Space Station Alpha.";
  423.                    SwitchOn:
  424.                        if (lm_n==3)
  425.                        {  print "You power up "; DefArt(lm_o); "."; }
  426.                ];
  427.  
  428.     The object never appears in the game, of course, and exists solely
  429.     to have a "before" routine.  As usual, returning false (0) causes the
  430.     library to carry on as it normally would, while returning true (1)
  431.     indicates that you've printed the message and it doesn't need to.
  432.  
  433.     The Jump action only ever prints one message, but more elaborate
  434.     actions such as SwitchOn have several (the extreme case is Take, with
  435.     13).  lm_n holds the message number, which counts upwards from 1
  436.     essentially in order of use in VerbLib.  It would be too inefficient
  437.     to define 250 constants to give these cute names, and instead the
  438.     programmer is referred to the last few pages of the source code of
  439.     VerbLib.  The stock of messages has changed very little in the last
  440.     six months and, while it may occasionally be added to, there shouldn't
  441.     be any need to renumber the present ones.  An amusing way to observe
  442.     LM in action is to add
  443.  
  444.         Object LibraryMessages "lm"
  445.           with before
  446.                [;  print "[", sw__var, ",", lm_n, "] ";
  447.                ];
  448.  
  449.     to your game (arcane note: sw__var, the "switch variable", always
  450.     holds the action number used by Inform in working out which paragraph
  451.     of code to run in a before/after/life routine).  Another amusing
  452.     effect is to simply write "rtrue" for the before routine, which
  453.     results in an alarmingly silent game - blindfold Adventure, perhaps.
  454.  
  455.     Note that LM can be used as a sneaky way to add extra rules onto the
  456.     back of actions, and to make messages more sensistive to game context.
  457.  
  458.     One could even use LM to translate absolutely everything the Library
  459.     says into Middle English during a medieval section of a game.  This is
  460.     left as an exercise to the reader.
  461.  
  462.     This new feature imposes a slight speed overhead, which should hardly
  463.     be noticed (text printing being something which isn't repeated hundreds
  464.     of times per second) and a slight code size overhead, which might:
  465.     about 2K.  I regret this but consider the gain to outweigh the loss.
  466. 59. "him"/"her" now never become the player when the player self-refers.
  467.     Of course people never refer to themselves in the third person...
  468. 60. There was a slight bug in the method of Asking people about things, and
  469.     anyway the existing documentation is a bit unclear (read: slightly
  470.     wrong).  The way to code for this is:
  471.  
  472.         Ask: if (second=='bug') "Graham says, ~It's mended now.~";
  473.  
  474.     though you can also look at special_word directly.  What you can't do
  475.     is look at noun and expect to find the word there: noun is of course
  476.     set to Graham.
  477. 61. "graham, tell me about bug" is now equivalent to "ask graham about bug".
  478.     Likewise, one can Tell people about things (this is a new action).
  479. 62. One now can't Enter or Exit a closed container.  (Enterable objects
  480.     which aren't containers or doors don't need to be open, though.)
  481. 63. The Curses-style "objects" and "places" verbs have been added.  These
  482.     are normally present in the library but can be made not to appear by
  483.     defining the constant NO_PLACES before the inclusion of VerbLib.
  484.     (A neat trick, if an object or place is going to be misleadingly named
  485.     in such a list (e.g. if it represents 40 different nearly-identical
  486.     rooms) is to give an object a different short_name when the action is
  487.     ##Places or ##Objects than the rest of the time.)
  488.  
  489. Changes in Release 5/8 (950201)
  490. ===============================
  491.  
  492. 64. "You aren't in anything at the moment" bug (if you don't know what this
  493.     means, you haven't seen it) fixed.
  494. 65. In 5/8, after a ChangePlayer the former player's object was not properly
  495.     short-named in some cases: now it's usually called "your former self".
  496. 66. Actions causing death or victory could sometimes make LibraryMessages
  497.     replacement go wrong: this is fixed.
  498. 67. MAX_TIMERS bound checking corrected (at long last).
  499. 68. "places" no longer says "You have visited" twice, and "objects" now says
  500.     "None." if you've never held any objects in the game.
  501. 69. The prompt "^>" is now printed via the library messages system, with the
  502.     (fake) action Prompt.  Thus, you might use:
  503.  
  504.         Object LibraryMessages "lm"
  505.           with before
  506.                [;  Prompt: print "^What now? "; rtrue;
  507.                ];
  508.  
  509.     to change the prompt.  Likewise you can adapt it to events, or get rid
  510.     of the "skipped line on screen each turn" convention.
  511.     This prompt is only used in ordinary game play, and not at such keyboard
  512.     inputs as yes/no questions or the RESTART/RESTORE/QUIT game over choice.
  513. 70. Subtle change in transparency rules.  If you ChangePlayer to some
  514.     creature, then any animate objects which are (directly or indirectly)
  515.     holding the creature at the time are made "transparent".  This prevents
  516.     you from finding yourself in darkness for a reason which is now
  517.     obselete.
  518.  
  519. Changes in Release 5/9 (950217)
  520. ===============================
  521.  
  522. 71. "initial" routines for rooms and NewRoom were being called on every
  523.     Look action, which was wrong behaviour: now they're gone through only
  524.     before a Look action occurs in a different location from the previous
  525.     one in which a Look took place.
  526. 72. Two messages generated by Enter now differ for trying to get onto
  527.     an enterable supporter (as opposed to getting into an enterable
  528.     container).
  529. 73. Yet another foolish bug in "objects" fixed: the spurious "None".
  530. 74. The parser error NUMBER_PE (generated when a "number" token fails to
  531.     match) has been demoted in importance.  Previously it took precedence
  532.     over almost every other error, now the reverse is true: so in grammar
  533.     like
  534.            "take" * noun    -> Take
  535.                   * number  -> TakeNumber;
  536.  
  537.     if nonsense like "lkjhkjh" is typed, then "You can't see any such thing"
  538.     is replied in preference to "I didn't understand that number".  The
  539.     assumption behind the change is that when both errors are possible, the
  540.     former is the "natural" use of the verb, the latter an exceptional one.
  541. 75. In some circumstances "location" briefly had the wrong value when
  542.     running a vehicle's "before" routine for the Go rule to see whether it
  543.     will allow the player to travel in it.  This is now fixed.
  544. 76. Small new feature: returning 2 from a vehicle's "before" in such
  545.     circumstances tells the library to give up and print nothing.
  546. 77. Large presentational feature.  If a collection of game objects - say,
  547.     all the edible items in the game - have a common non-zero value of the
  548.     property "list_together", say 1, they will always appear adjacently in
  549.     inventories, room descriptions and the like.
  550.     If, moreover, instead of being a small number the common value is a
  551.     string such as "foodstuffs" then lists will cite, e.g.
  552.  
  553.            three foodstuffs (a scarlet fish, some lemmas and an onion)
  554.  
  555.     in running text, or
  556.  
  557.            three foodstuffs:
  558.              a scarlet fish
  559.              some lemmas
  560.              an onion
  561.  
  562.     in indented lists.  (This only happens when two or more are together.)
  563.     If, moreover, the common value is a routine, e.g.
  564.  
  565.            [; if (inventory_stage==1) print "heaps of food, notably ";
  566.               else print ", which would do you no good";
  567.            ],
  568.  
  569.     then this will be called twice: once, with "inventory_stage" set to
  570.     1, as a preamble to the list of items, and once (with 2) to print any
  571.     postscript required.  It is allowed to change "c_style" (the current
  572.     list style) without needing to restore the old value and may, by
  573.     returning 1 from stage 1, signal the list-maker not to print a list at
  574.     all.  The simple example above results in
  575.  
  576.            heaps of food, notably a scarlet fish, some lemmas and an onion,
  577.            which would do you no good
  578.  
  579.     Such a routine may want to make use of the variables "parser_one" and
  580.     "parser_two", which respectively hold the first object in the group
  581.     and the depth of recursion in the list (this might be needed to keep
  582.     indentation going properly).  Applying x=NextEntry(x,parser_two);
  583.     moves x on from parser_one to the next item in the group.
  584.     Another helpful variable is "listing_together", set up to the first
  585.     object of a group being listed (or to 0 whenever no group is being listed).
  586.     For further examples, see the little example "List Property", which
  587.     sorted out the following 24 objects into...
  588.  
  589.       You can see a plastic fork, knife and spoon, three hats (a fez, a Panama
  590.       and a sombrero), the letters X, Y, Z, P, Q and R from a Scrabble set, a
  591.       defrosting Black Forest gateau, Punch magazine, a recent issue of the
  592.       Spectator, a die and eight coins (four silver, one bronze and three gold)
  593.       here.
  594. 78. The parser used to overflow occasionally when dealing with a very vague
  595.     request which matches against far too many items; now it checks the size
  596.     of the match list before adding to it.  (In practice, this only happened
  597.     when one tried to, e.g., "purloin all" in a game of more than 64 items.)
  598. 79. The Search (e.g. "look inside") action sometimes produced mysterious
  599.     messages when the only contents of the object in question were all
  600.     "concealed", and similar misfortunes befell some room descriptions.
  601.     Now mended.
  602. 80. A between-routines jump inside the parser has been removed, as it was
  603.     unnecessary and Mark Howell didn't like the idea.
  604. 81. The "wake" grammar is slightly improved, and the WakeOther action (for
  605.     waking someone else up) is now routed through that person's "life"
  606.     routine.
  607. 82. PlayerTo(...) used only to work for moving a player to a room, but now
  608.     it can also move a player to something in a room (like a chair).
  609. 83. Message for "putting something on a non-supporter" mended.
  610. 84. The "In the ... you can see ..." message (printed when you're also in
  611.     the whatever) is now In or On as appropriate for containers/supporters.
  612. 85. "pick up", "look into" and "lie in/on" added to the grammar.
  613.  
  614. Changes in Release 5/10  (950525)
  615. =================================
  616.  
  617. 86. "notify off" no longer perversely replies "Score notification on."
  618. 87. Bug in "objects"/"places" when the player's in transformed form, fixed.
  619. 88. The parser is now capable of making an inference and then asking a
  620.     clarifying question, in the same turn: e.g. "unlock" is expanded by
  621.     the parser into "unlock chest"; "with" is further assumed; then it asks
  622.     "What do you want to unlock the chest with?" and understands the answer.
  623.     Likewise it can now infer two successive prepositions, e.g. "next to".
  624. 89. PlayerTo(1) (moving the player without a subsequent Look) now calls
  625.     NewRoom, sorts out floating objects and so forth, as it should.
  626. 90. An additive property (one for which inheritance from classes piles up
  627.     a list of values) can now contain a list in which some items are strings
  628.     and others routines.  Should this occur, then on a PrintOrRun the
  629.     the entries are executed in sequence - run if routines, printed if
  630.     strings.  A printed string in such a list always has a new-line printed
  631.     after it; and it never stops the process of execution.  In other words,
  632.     the string "Hello" is equivalent to the routine [; print "Hello^"; ],
  633.     (which returns false), not to the routine [; "Hello"; ], (which would
  634.     return true and stop execution).
  635.     This will seldom be useful but protects the Z-machine stack against
  636.     certain misfortunes on some machines.
  637. 91. The parser once again copes with "put all except the key in the bag".
  638. 92. "objects" now tells of "(worn)" objects.  (A bug used to prevent this.)
  639. 93. Returning 3 from a "before" routine of a vehicle which the player's
  640.     trying to move inside, says "do nothing, I have moved the player".
  641.     (Merely returning 2 for "do nothing" may result in the old location
  642.     being restored.)
  643. 94. A subtle bug to do with low strings having mysteriously not-quite-right
  644.     contents has now been fixed: it was due to a library mistake which
  645.     Inform 5.4 was unable to detect, but which 5.5 spotted as an error.
  646. 95. Small bug in timer/daemon listing debug verb fixed.
  647. 96. PlayerTo(somewhere,2) will |Look| as if the player had arrived in the
  648.     room by walking in as usual (so only a short description appears if
  649.     the room is one that has been seen before).
  650. 97. The parser's "take all" rules work slightly better for actors other
  651.     than the player, and when the actor is inside something.
  652.  
  653. Changes in Release 5/11  (950619)
  654. =================================
  655.  
  656. 98. *** You have died *** style messages are now in bold-face, except in
  657.     V3 games.
  658. 99. It's now legal to put things into, or take things out of, containers
  659.     that happen to be worn.  I noticed this was illegal when players of
  660.     Curses complained about the rucksack; and couldn't think of any good
  661.     reason why it should be illegal!
  662. 100. A more appropriate message is produced on attempts to push, pull or
  663.     turn animate objects.
  664. 101. If Initialise() returns 2, then no game banner is printed; thus, it
  665.     can appear later on instead, as in "Sorcerer".
  666. 102. PlayerTo() now works in the (dark room) -> (dark room) case.
  667. 103. A bug to do with message passing (which only existed under a rough
  668.     to-get-Inform-tested copy of 5/10 anyway) has been fixed.
  669. 104. A really disastrous bug to do with the parser asking supplementary
  670.     questions (causing interpreters to behave badly on some machines, e.g.
  671.     by repeatedly saying "I beg your pardon") has hopefully now been fixed,
  672.     largely thanks to detective work by Robert Stone and Matthew Russotto.
  673.     My own interpreter never showed this bad behaviour, and I was barking
  674.     up the wrong tree in attempts to find it.  I now believe it was caused
  675.     by over-writes in the multiple_object array corrupting the "length"
  676.     byte of the (immediately following) input buffer "buffer2" used by the
  677.     parser for disambiguation questions.  I have taken three different
  678.     precautions to prevent this occurring in future.
  679. 105. A bug to do with changing the player character and then entering dark
  680.     locations (when one might spookily bump into one's former self) has been
  681.     fixed.
  682. 106. "ask someone for something" is now automatically translated into
  683.     "someone, give something to me" (i.e., this ##Order is generated).
  684. 107. Multiple-object commands (such as "take all") generate a list of actions,
  685.     which all make contextual sense at the time when the command is typed.
  686.     However, a weakness of the parser is that when some of these actions have
  687.     been processed, the remaining ones may no longer make sense.  For
  688.     instance, if the player has been teleported to the planet Mars halfway
  689.     through picking up a pile of ten items.  The parser now stops the list
  690.     if the player has either (a) moved location, or (b) fallen into darkness,
  691.     as a result of earlier actions.
  692. 108. When the parser is working on a "creature" token, and the player typed
  693.     something which is ambiguous but definitely isn't animate, then no
  694.     question is now asked to resolve this ambiguity (as there's no point).
  695.     (Such a question used to read slightly oddly.)
  696. 109. print (DirectionName) x;  will now (under I5.5) print the name of the
  697.     direction whose door_dir is x.  Thus, x==n_to results in "north" being
  698.     printed.
  699. 110. The property "capacity" can now take a routine returning a value,
  700.     instead of a value.
  701. 111. "full score" is now understood as "fullscore".  ("full" always was.)
  702.  
  703. Changes in Release 5/12 (951023)
  704. ================================
  705.  
  706. 112. Parser bug fixed: the pronouns ("it", "him", etc.) now work when
  707.     referring to objects moved explicitly into scope by (e.g.) PlaceInScope.
  708. 113. Pushing objects into dark rooms now works (it used to lose them in the
  709.     dark).
  710. 114. The status-line-drawing routine is now more sensitive to changes of
  711.     text window size (and to small windows).
  712. 115. One can no longer order other characters about with meta-verbs like
  713.     "score" and "verify".
  714. 116. Asking people for things has a better "no" message, and asking oneself
  715.     for something causes an inventory.
  716. 117. "take newt from livingstone" now behaves just as "take newt" does when
  717.     a character called Livingstone is holding the newt.
  718. 118. "There is no more room on the nothing" (error message bug) fixed.
  719. 119. "get all from O", where O is a something you can't see through (like
  720.     an opaque closed box), now doesn't put the contents of O into scope
  721.     (which would reveal to the player what they were).
  722. 120. Two parser diagnostic messages, and one code comment, have been made
  723.     more truthful.
  724. 121. A bug to do with "all from a compass direction" (which can happen,
  725.     for instance, with "take all from south wall") has been fixed.
  726. 122. Under some circumstances, "put O1,O2,O3 in something" used to fail,
  727.     but this is now (I believe) fixed.
  728. 123. "pick something up" added to the grammar ("pick up something" always
  729.     worked).
  730. 124. Explicit multiple takes, such as "take ball and bat", now don't ask
  731.     foolish questions like "what from?" when none of the objects in
  732.     question are on the ground.
  733. 125. "take all" now does not fall into "what do you want to take those
  734.     things from?", etc., when "all" fails to make any good match; likewise,
  735.     it now never infers the actor's object as the target of "all" when
  736.     everything else has failed to match.
  737. 126. A new entry point "AfterPrompt" has been created.  This is called just
  738.     after the prompt is printed, and gives the game a useful opportunity
  739.     to box up quotations without them scrolling away.
  740. 127. If the player pushes the only light source into a dark room, then
  741.     there is now no intervening period of "Darkness".
  742. 128. The "thedark" object has initial and short_name properties provided
  743.     (so they can be altered to change darkness rules at run-time).
  744. 129. A location's now only given "visited" (and scored for) after the
  745.     room description is printed for the first time (not at some point
  746.     during, as used to be the case).
  747. 130. An "invent" property can now be a string; if so, or if it returns true
  748.     at inventory_stage 1, new-lines are now properly printed (if the
  749.     list style asks for this).
  750. 131. New entry point ParseNoun, to do the job of parsing the |name|
  751.     property (if parse_name hasn't done it already).  This takes one
  752.     argument, the object in question, and returns a value as if it were
  753.     a parse_name routine.
  754. 132. New library routines WordAddress(wordnum) (returns address in the
  755.     command buffer of the word with that number) and WordLength(wordnum)
  756.     (returns its length in characters).
  757. 133. parse_name routines no longer need to leave the word marker wn
  758.     in any particular place.
  759. 134. "s" generates a Go action; "go south" used to generate an Enter
  760.     action with the same effect, but this is clumsy and unfortunate from
  761.     the point of view of before rules.  So "go <direction> now generates
  762.     a Go action, as one might expect.
  763. 135. Action tracing (in the debugging suite) much enhanced.
  764. 136. Bug in the parser making it impossible to give orders to an actor
  765.     whose name is parsed by a parse_name routine but isn't in the
  766.     dictionary, removed.
  767. 137. action_to_be set to -1 in the parser's opening phases, to make it
  768.     easier to change the scope here.
  769. 138. The value 1000 (used internally for "please reparse") is now a
  770.     constant REPARSE_CODE whose value is actually 10000.  This allows for
  771.     over 1000 objects and clarifies the code.  Also, this code is now a
  772.     legal reply for a general parsing routine.
  773. 139. "I beg your pardon?" made one of the LibraryMessages (see Miscellany).
  774. 140. LM 3 for ##Exit improved.
  775. 141. Minor (never observed in real use) bug fixed in list writer.
  776. 142. "all" list processing is now halted if the player dies or wins at
  777.     some intermediate stage.
  778. 143. Properties react_before and react_after added, to interfere with
  779.     other objects' actions.
  780. 144. "scope_reason" and various _REASONS added; routines LoopOverScope
  781.     and TestScope added; a new debugging verb "scope" added.
  782. 145. BeforeParsing entry point added (it's called before any parsing takes
  783.     place).
  784. 146. grammar and orders properties added (for animate creatures).
  785. 147. Conversation generally reformed (but without any incompatible changes).
  786.     Ask, Tell, Answer now prepare consult-style topics and accept multiple
  787.     word topics.  talkable objects can now be Asked, Told, AskedFor, etc.
  788. 148. A few bugs to do with scope calculations for people in distant places
  789.     have been removed.
  790. 149. The "undo" and "oops" parser messages have been moved to
  791.     LibraryMessages, under Miscellany.
  792. 150. Any text beginning "undo" and then continuing is now parsed as usual,
  793.     not misinterpreted as an undo command.  (Thus, "undo knot" is now
  794.     parsable.)
  795. 151. list_together now works when the compass objects are undefined (no,
  796.     don't ask why it wouldn't).
  797. 152. Pronouns such as "it" are now set, line by line, when a multiple object
  798.     list is being processed: so after "take all", itobj will be the last
  799.     thing taken.
  800. 153. A rare bug dating back to 5/9, which had been occasionally observed
  801.     but not found in a repeatable way, has been fixed: to do with
  802.     list_together when an action takes place which disrupts the order of
  803.     two groups of objects in a particular configuration.  The symptoms were
  804.     for strange items to appear in the resulting list, such as "yourself"
  805.     or "nothing".
  806. 154. The "direction" attribute is no longer needed and has been withdrawn.
  807.     What defines a direction object is membership of the compass.
  808. 155. The use of the player's "before" routine to constrain what actions
  809.     he produces is withdrawn.  Instead, the player's "orders" routine now
  810.     performs this task.  It was always unsatisfactory to use "before" in
  811.     two different inconsistent ways for player objects, and this is a much
  812.     better solution, but *** it is a change which is inconsistent with
  813.     previous behaviour *** and the author apologises for inconvenience.
  814. 156. Accordingly, the player object "selfobj" is created with an "orders"
  815.     property, so that it can be altered later.
  816. 157. A call to ChangePlayer now changes the actor to the new player object,
  817.     if it was previously the old player object.  This is useful if the
  818.     change took place half-way through action processing.
  819. 158. The "door_to" property can now return 1.  This means "stop processing
  820.     the movement here and print nothing more" and is provided so that
  821.     games can tidily apply rules to people going through a door.
  822. 159. Menus are now nestable in plain text style as well as Invisiclues
  823.     style.  The first argument to DoMenu can now be a routine to print a
  824.     string instead of just a string.  This should make adaptive hints
  825.     easier to implement, for instance.
  826. 160. The parser no longer gives a bizarre error in reply to "person,".
  827. 161. A bug in the list-writer, which made it inaccurate when printing
  828.     listed_together entries in a list using WORKFLAG_BIT, has been fixed.
  829.     (This became famous as a bug in Release 1 of "Christminster" to do
  830.     with coloured wires described in a box.  But it was my fault really.)
  831. ----------------------------------------------------------------------------
  832.