This file contains a list of changes that have been made to TADS
since the initial 2.0 release.  Most of the changes are fixes to
bugs, so they don't change the documented behavior, but a few, as
explained below, add new functionality to TADS.


2.0.11  12/20/92  bug fixes

  - Goto statement labels were occasionally not released properly,
    resulting in spurious internal errors.

  - The 'continue' statement did not work as documented in 'for'
    statements.  Instead of jumping to the re-initializer expression,
    as it now does, the 'continue' incorrectly jumped to the condition.

  - The run-time is slightly smaller and faster.

  - The compiler did not process locals correctly when multiple disjoint
    blocks within a function or method had locals, and a later block had
    fewer locals than a previous block (yes, it's a somewhat obscure bug).

2.0.10  No such release (to synchronize with Mac release levels)

2.0.9  12/12/92  MS-DOS bug fixes and new features

  - The file selector dialog displayed incorrect information when a
    directory name that used all 11 characters was displayed.

  - The file selector now saves and restores all default directory and
    disk information.  The current disk, and the current directory on
    each disk, will be the same when TR is terminated as it was when
    TR was first run.  (This applies to TDB as well.  It's particularly
    important for TDB, because TDB needs to have the source files in
    the current working directory if an absolute path was not specified
    with -I.)

  - NEW FEATURE:  the new user function commandPrompt, if provided by
    the user's game program, will be called prior to each player command.
    If the commandPrompt function is provided, the default ">" prompt is
    NOT displayed; if no commandPrompt function is defined, the default ">"
    is used.  This should not affect existing games at all, unless a game
    defines its own function, method, or property called commandPrompt
    having a different purpose.  The commandPrompt function returns no
    value.  The function takes a single argument:  a number, indicating
    the type of command that the system is prompting for:

       0  - normal command
       1  - command after invalid word (allowing "oops" to be used)
       2  - disambiguation (after "which x do you mean..." question)
       3  - command after askdo (after "what do you want to x?")
       4  - command after askio

    Note that the default prompt in all cases is simply ">", and in all
    cases a new command can be entered.  However, when the type code is
    2, 3, or 4, a question has just been displayed by the run-time, so
    the commandPrompt function may want to suppress any pre-command
    information or prompt text.  Case 1 is generally identical to case 0.

  - NEW FEATURE:  A new built-in function has been added, which allows
    the game program to suppress the display of text that would normally
    be displayed with double-quoted strings or the say() function.  The
    function is called outhide(), and it takes one argument:  a flag,
    indicating whether to suppress or re-enable the display of output.
    If the flag is true, output is suppressed; if the flag is nil, output
    is re-enabled.  Any output that occurs between outhide(true) and
    outhide(nil) is discarded.  However, outhide(nil) returns a value
    indicating whether any output did in fact occur since the call to
    outhide(true); this allows you to determine if any output would have
    occurred, even though the output is not seen by the player.  Note
    that this is effectively the same mechanism used by the player command
    parser for noun disambiguation using the verDoXxx and verIoXxx
    methods, as described in the TADS author's manual.  There is no way
    to recover the text that was suppressed by outhide(); the text is
    simply discarded, so the only information available is whether any
    text was generated.

2.0.8  12/03/92  (tc/tdb 2.0.7, tr 2.0.8) MS-DOS bug fixes and minor changes

  - The display initialization code was incorrectly attempting to clear
    a zero-line region of the display.  This resulted in extremely long
    delays on some computers (due to an incorrect BIOS call made by TADS).

  - NEW FEATURE:  When the keyword $$ABEND is typed as the entire command,
    the run-time immediately terminates and returns to DOS.  This emergency
    escape is provided so that TR can be terminated if the game somehow
    gets into a state where a more graceful exit is not possible.

  - NEW FEATURE:  The parser now calls two new optional methods in the
    game program.  These new methods are intended to help speed up the
    identification of words when many objects have the same vocabulary.
    If the new methods are not present, behavior is the same as before,
    so existing games will run unchanged.  The new methods are validDoList
    and validIoList; they are associated with the "deepverb" object for
    the current command.  They are called with three parameters:  the actor,
    the prep, and the other object (indirect object for validDoList and
    direct object for validIoList; the value of the parameter will be nil
    if not applicable).  These methods are called prior to the disambiguation
    pass (using verDoXxx/verIoXxx), and prior to testing any objects with
    validDo/validIo.

    The return value of validDoList/validIoList is a list of all of the
    valid objects for the verb.  It is fine for these methods to return
    *too many* objects, since each object is still tested with validDo
    (or validIo) and the appropriate verDoXxx/verIoXxx methods.  Generally,
    these methods should simply return a list of all of the accessible
    objects in the actor's current location (or the actor's location's
    location), plus a list of all of the "floating" objects (which use
    methods for the location properties).

    An appropriate definition for validDoList in the deepverb object
    appears below:

       validDoList(actor, prep, iobj) =
       {
           local ret;
   	   local loc;

	   loc := actor.location;
	   while (loc.location) loc := loc.location;
	   ret := visibleList(actor) + visibleList(loc)
	          + global.floatingList;
	   return(ret);
       }

    This same definition (with the name changed) is appropriate
    for validIoList in deepverb.  This returns a list of all of the
    objects visible in the current location, plus the global list of
    all floating objects; this should be a superset of the list of
    accessible objects in most games.  The only verbs that normally
    requires a different value of validIoList/validDoList are verbs
    such as "ask" and "tell" that allow any object (whether accessible
    or not) to be used as indirect objects; for these, simply use this
    definition:

       validIoList = nil

    This takes advantage of the reverse compatibility feature:  when the
    method returns nil, all objects with matching vocabulary are used.

    The one additional game change required to take advantage of this
    new feature is that global.floatingList must be built during
    initialization.  This can be done easily with the following loop:

       global.floatingList := [];
       for (o := firstobj(floatingItem) ; o ; o := nextobj(o, floatingItem))
   	   global.floatingList += o;

    This should be placed in the preinit or init function.  Note that
    all objects which have location methods should be declared to be
    of class floatingItem:

      class floatingItem: object;

    This class doesn't do anything except serve as a flag that an
    object should be placed in the floatingList.

2.0.7  12/01/92  MS-DOS bug fix release

  - The run-time occasionally missed the \ in an escape sequence in
    output strings.

  - The run-time couldn't operate in 132 column mode.

  - The run-time abnormally terminated in the file selection dialog
    when the dialog box was exactly filled.

2.0.6  11/24/92  first general MS-DOS TADS 2.0 release