When you open a project in Workbench for Windows, Workbench now
creates a project.tdbconfig file in the project directory to
store your user interface settings for the project. The stored
settings include things like which files are open in Workbench editor
windows, window sizes and positions, past search strings, text editor
option settings, and many other settings specific to the Workbench UI
for the project. The new file has the same base name as the project
(.t3m) file, with the .t3m suffix replaced by .tdbconfig.
In the past, these UI settings were stored directly in the project
(.t3m) file itself. There are two main reasons for moving them into a
separate file. First, the old arrangement was problematic for
collaboration, because the UI settings aren't really project-level
settings at all; they're really per-user settings, since each user
collaborating on a project might have different UI preferences. With
this change, collaborators can share the .t3m file, which contains
only the project-level build settings, but keep individual .tdbconfig
files for their personalized UI settings. Second, the single-file
setup wasn't great for use with source control systems, because
Workbench updated the .t3m file virtually every time you opened the
project. The constant updating tended to create numerous superfluous
history updates for a .t3m file under source control. Workbench still
writes a fresh copy of the .t3m file each time a project is closed, so
the .t3m file's timestamp will be updated, but the contents should be
left unchanged as long as you don't make any actual changes to the
build settings (in which case you'd want to update the source control
version of the file anyway to capture the changes in the build
settings).
Workbench still recognizes the old single-file format, but now
always saves updates in the two-file format. This means that you can
open old projects without having to make any manual changes. When you
open an old project, Workbench automatically converts it to the
new two-file format when you close the project.
Several bugs in the automatic code formatter in the Workbench
text editor on Windows have been fixed:
Changes in Release HT-22 (Windows build Win116; TADS 2.5.15/3.1.0)
Released 12/21/2011
- The Windows interpreters now send transcript output to the disk
file immediately after each command, rather than buffering the output
in memory. This usually isn't noticeable one way or the other, but it
does matter when using an external tool that reads from the transcript
file while the game is running. Some IF mapper tools do this, for
example, to produce a dynamic visual map of the game while you play.
The buffering in past versions meant that output text might be delayed
in reaching the disk file (and thus in reaching any tools monitoring
the disk file) for several turns. Output is now written immediately
to the disk file, so monitoring tools should be able to keep in sync
with what you see in the game window.
- The fading parameters for <SOUND> tags are now handled
a little differently for repeated tracks. In the past, fading was
simply applied to each iteration of a repeated track individually,
so a track with REPEAT=3 would fade in, play back, fade out, then
fade in a second time, play back, fade out, and again for a third
fade in, play back, fade out. This was probably undesirable for
most practical purposes, since repeated sounds are most useful for
constructing continuous ambient background music and effects.
So the sound player now applies a fade-in only to the first iteration
of a looped sound, and applies a fade-out only to the last iteration.
- The Windows versions of Workbench and HTML TADS for builds Win111
through Win114 refused to run on older versions of Windows -
specifically, 95, 98, ME, and NT 4. This was due to an "upgrade" we
made to the latest version of the Microsoft C++ compiler (version
2008), which by design produces EXEs that won't run on those older
systems. Starting with this build, we have returned to the older
version of the Microsoft compiler to prepare the release builds. This
should allow the system to run on the older OS versions again.
(However, note that Windows 95 and 98 users will have to upgrade their
version of Microsoft Internet Explorer to IE 5 or later in order to
run Workbench. This ensures that you have a system DLL that Workbench
depends on. This isn't necessary for newer Windows versions, since
they come with the required DLL.)
- In TADS 3 Workbench for Windows, starting in version 3.0.18, the
Build Web Page command generated an invalid HTML file. This was
actually a side effect of a bug in the TADS 3 interpreter (bugdb.tads.org
#0000065). The interpreter bug has been corrected, which fixes
the Build Web Page problem. (bugdb.tads.org
#0000064)
- Workbench for Windows is now a little more consistent about the
word-wrapping margins when auto-formatting strings and comments (such
as via the Alt-Q command). In the past, strings were filled one
character short of the right margin as set in the options, and
comments were filled to about three characters short. (bugdb.tads.org
#0000058)
- The syntax coloring in the Workbench editor on Windows didn't
properly handle embedded << >> expressions within HTML
attribute values in strings, as in "<img src='foo.jpg'
width=<<width>> height=<<height>>>".
The syntax colorer incorrectly treated the first >> as the
end of the tag. The colorer now handles this case correctly.
(bugdb.tads.org
#0000072)
- In Workbench for Windows, some of the tabbed or "wizard"-style
dialogs were displayed at the wrong size on some systems, which
could cut off some of the text and/or buttons in the dialogs,
making them essentially unusable. The problem was due to an
outdated font dependency in the dialog definitions; this has
been corrected to use current Windows standards, so the dialogs
should display correctly on all systems now.
(bugdb.tads.org
#0000087)
- In Workbench for Windows, the debugger used to bring the game
window to the foreground at the start of each new run, even when
execution immediately stopped in the debugger at a breakpoint or
single-step trace. This was slightly annoying because you had to
manually switch back to the debugger window. The debugger window now
stays in the foreground in this case. The game window still comes to
the foreground when execution doesn't immediately stop in the
debugger, of course.
- A bug in Workbench for Windows caused a crash if a text file
was saved with no project (.t3m file) open. This is now fixed.
(bugdb.tads.org
#0000092)
- The output of Workbench's Project Search results (on Windows)
contained an HTML syntax error if any of the files listed in the
project window were non-existent. This didn't affect the appearance
of the search results themselves, but it did log an error in the
Debug Log window. This is now fixed.
(bugdb.tads.org
#0000097)
- A bug in the TADS 3 coloring mode for Scintilla caused the wrong
coloring if a "..." token was used within an embedded string expression,
as in "<<func(a...)>>". This is fixed.
(bugdb.tads.org
#0000094)
- In Workbench for Windows, the "new project" command omitted
all libraries when the "Plain T3" configuration was selected.
The command now includes the core system library in the new project.
In most cases, even the most stripped-down build configuration will
want to include the core system library, since it contains the basic
program startup code and necessary support classes for the intrinsic
classes. You can still manually remove these files from a new project
after creating it if desired.
- If you have a file open in the Workbench text editor,
and you edit and save the same file with another application,
Workbench automatically detects the change the next time you bring
Workbench to the foreground, offering you the option of reloading the
updated copy of the file from disk. In the past, if you chose to
reload the file, the editor reset the cursor and scrolling position
back to the start of the file, and also cleared any breakpoints and
bookmarks in the file. Workbench now scrolls back to the same
position and selects the same text range, and retains breakpoints and
bookmarks.
(Of course, if you make extensive changes to the file with another
other program, the cursor and marker positions might not correspond to
the same text after reloading. The editor only keeps track of these
locations by line and column numbers. It doesn't attempt to analyze
the differences in the file to find the same actual text that was
previously selected.)
- The Windows debugger didn't respond properly to the
Terminate Program command when the game was started via a Step In or
Step Over command (rather than the Go command). This has been
corrected.
(bugdb.tads.org
#0000105)
Changes in Release HT-21 (Windows build Win115; TADS 2.5.14/3.0.18.1)
Released 1/29/2010
- In releases Win113 and Win114, audio playback of
compressed sound types (MP3, OGG) didn't work for resources embedded
in a .t3 or .gam file. The audio generally just didn't play back when
embedded, and the audio player sometimes showed a spurious error or
warning. This has been corrected; an embedded version of an audio
stream should once again work the same way as the stand-alone file
version of the same stream. (bugdb.tads.org #0000080)
Changes in Release HT-21 (Windows build Win114; TADS 2.5.14/3.0.18.1)
Released 5/5/2009
(This build has no changes specific to the Windows version or the
HTML renderer - it's just an update of the TADS 2 and TADS 3
components. See their release notes for details.)
Changes in Release HT-21 (Windows build Win113; TADS 2.5.13/3.0.18)
Released 4/28/2009
- HTML TADS for Windows now supports fade-in and fade-out in the
<SOUND> tag. You can use this to fade in the sound at the
beginning of a track, fade out the sound at the end, and fade out a
track being canceled in mid-play (rather than just cutting it off
abruptly). You can also do cross-fades between a track being canceled
and the new track replacing it. The new features are described in
detail in the Sound chapter of
the HTML TADS documentation.
- The new VOLUME attribute of the <SOUND> tag lets you control
the relative playback volume of a track. The VOLUME value is from 0
to 100, where 0 is silence and 100 is the full, unattenuated level
recorded in the files. This is currently only implemented in the
Windows version.
- The Windows version of TADS 3 now has better support for
localizations that use MBCS (multi-byte character set) code pages.
(On Windows, MBCS code pages are used for languages whose writing
systems use large numbers of glyphs, such as Chinese or Japanese.) In
the past, there were a number of problems with MBCS display: moving
the text editor cursor through text containing double-byte characters
sometimes garbled the on-screen display of the characters, as did
selecting the text with the mouse, and it was possible in the text
editor to delete or overwrite one byte at a time of a double-byte
character. These problems have been fixed; the text editor and the
interpreter now correctly handle multi-byte characters from the system
default code page. (Note that the new support is specifically for the
system default code page, which is the code page associated
with the system localization. On XP, this can be changed via the
"Language for non-Unicode programs" option.)
- When you build a stand-alone game with the HTML interpreter for
Windows, the toolbar in the game window now omits the "Load New Game"
button. The corresponding menu command was excised some time ago from
the main menu in stand-alone builds, but the toolbar button was still
present; for consistency, the toolbar button has now been removed as
well.
- In Workbench for Windows, the editor now highlights the entire
source line where an error occurred when you double-click on an error
message in the compiler output window. This is designed to make it
faster to find the cursor by making the location more visually
apparent.
- In Workbench for Windows, in the "Welcome" dialog, un-checking the
checkbox to "show this dialog again next time" had no effect. This
has been corrected.
- In Workbench for Windows, the build option "treat warnings as errors"
wasn't properly read from the saved project configuration when a project
was loaded. This has been corrected. (bugdb.tads.org #0000044)
- The HTML renderer incorrectly allowed line breaks within preformatted
text (<PRE> ... </PRE>) at explicit typographical space
characters (&emsp,  , etc). This has been corrected.
(bugdb.tads.org #000050)
- The HTML renderer incorrectly treated (non-breaking
space) characters as potential line-break points when sizing a banner
according to the width of its contents. This has been corrected.
(bugdb.tads.org #000051)
- In Workbench for Windows, there was a situation where the program
could get stuck in a loop repeatedly showing the dialog asking you
whether you want to terminate the running program before recompiling.
This happened if execution was stopped in the debugger (at a
breakpoint, or single-stepping) in an Exception constructor called to
handle a run-time error, and you activated one of the Compile
commands. The problem has been fixed.
Changes in Release HT-20 (Windows build Win112; TADS 2.5.12/3.0.17)
Released 9/8/2008
- In TADS 2 Workbench on Windows, the "Compile and Run" command
caused Workbench to go into an infinite loop of building the
program over and over. This has been corrected.
(bugdb.tads.org #0000022)
- In the past, when TADS 2 Workbench on Windows tried to open a
source file, and the file wasn't present in the main project folder,
Workbench searched for the file by looking in each directory where
other source files were previously found. In cases where you had
several files with the same name in different directories, this
sometimes loaded the wrong copy of the file. This was particularly
noticeable if you created your own private copies of system files,
such as adv.t or std.t - Workbench tended to find the system versions
rather than your private versions, because the system include folder
was usually first in Workbench's internal directory cache. Now,
Workbench checks the list of "include" directories first, in the order
given in the Build Settings dialog - this ensures that Workbench
searches for source files in the same places that the compiler does
when you build your program, which will generally ensure that
Workbench finds the right version of the file.
(bugdb.tads.org #0000034)
- In text editor windows in Workbench for Windows, the text caret is
now colored as the inverse of the main "Default" style background
color for the window. For example, if the main background is black,
the caret will be white; if the background is yellow, the caret will
be bright blue (because blue is the RGB inverse of yellow). As an
exception, a black caret is used if the background is a mid-level gray
(because the RGB inverse of a mid-level gray is another mid-level
gray, which wouldn't provide sufficient contrast). This helps ensure
that the caret will be visible regardless of the background color.
(In the past, the caret was always black, which made it difficult or
impossible to see when using a dark color as the background.)
(bugdb.tads.org #0000025)
- The text editor in Workbench for Windows now adjusts the
horizontal scrollbar limits to accommodate the width of the line
containing the cursor, if the line is too wide for the current limits.
Scintilla normally uses fixed limits for the horizontal scrollbar,
because of the performance cost of determining the actual maximum
width of all of the lines in the entire file; but its default is too
narrow for very long lines of text. Workbench still doesn't scan the
entire file, but it now checks the current line each time the cursor
moves to ensure that the scrollbar is wide enough for that line.
(bugdb.tads.org #0000029)
- In TADS 2 Workbench for Windows, in the "Welcome" dialog that's
displayed at launch, the "Open a project" button didn't work properly
if you selected a .t file (rather than a project file - .tdc). The
problem was that this skipped the normal source file wizard, which
sets up the project configuration; without this setup work, Workbench
wasn't convinced that a project had actually been loaded, so it
prompted you to set up this information manually through the
Build Settings dialog. This has been corrected; Workbench now runs
the source file wizard when you select a .t file to load at startup.
(bugdb.tads.org #0000028)
Changes in Release HT-20 (Windows build Win111; TADS 2.5.11/3.0.17)
Released 8/9/2008
- In Workbench for Windows, breakpoint indicators (the little red
circles in the left margin of a source file window) weren't updated
properly when lines were inserted or deleted in the file above a
breakpoint line. In particular, a duplicate breakpoint appeared for
each actual breakpoint each time a line was added or removed earlier
in the file. This has been corrected. (bugdb.tads.org #0000007)
Changes in Release HT-19 (TADS 2.5.10/3.0.16)
Released 4/10/2008 - Windows build Win110
- The Windows version has been updated to the latest support
libraries for the PNG and MNG formats; specifically, libpng 1.2.22,
zlib 1.2.3, and mnglib 1.0.10.
- TADS 3 Workbench for Windows didn't properly restore the "treat
warnings as errors" project setting when loading a project (in other
words, Workbench always forced this option to the default "on" setting
every time a project was loaded). This has been fixed.
- In Workbench on Windows, double-clicking on an error message in
the Debug Log window when said window was maximized left all of the
window's text up to the cursor click selected. Only the error message
line itself should have been left selected; this is fixed now.
- A bug in the TADS 3 editor mode caused incorrect auto-indenting
if there was trailing whitespace after the function's open brace.
This has been corrected.
- In Workbench for Windows, the "Build Source ZIP" command sometimes
omitted extension files that were directly in the "Extensions" folder
set in the options - that is, files that were stored directly in this
directory, rather than in a sub-folder. This happened when the
only extension files in a project were in the main Extensions
folder (i.e., the project didn't include any extension files that were
in sub-folders of that main folder). This is now fixed.
- The HTML renderer sometimes incorrectly calculated the width of
tables and banners that contained hyperlinks. The renderer
incorrectly treated a hyperlink as implying a possible link-break
point for the purposes of the width calculation, even though
hyperlinking doesn't by itself have this effect on layout. This
didn't affect the way hyperlinks were actually laid out, but rather
affected the size calculation for containers such as tables and
banners. The visual effect was that banners and tables containing
hyperlinked text that didn't were sometimes to narrow for their
contents. This has been corrected.
Changes in Release HT-18 (TADS 2.5.10/3.0.15.3)
Released 11/2/2007 - Windows build Win109
- HTML TADS for Windows sometimes "froze" when running on systems
localized for East Asian languages. The problem was sporadic - it
sometimes happened and sometimes didn't, essentially at random; but
when it happened, the triggering conditions were (a) that the Windows
default code page for non-Unicode applications was for a multi-byte
character set (such as code pages 932, 936, 949, or 950), and
(b) certain HTML entity (&xxx;) markups where displayed, such as
the typographical quote marks (‘, ’, “,
”). The bug was a bookkeeping error in the HTML parser in
the handling of multi-byte characters; it has been corrected.
- In the past, if the HTML source text for a table was of just the
right length, it was possible for the text following the table to be
rendered twice when first displayed. (This only happened during the
initial layout - manually forcing a display refresh, such as by
resizing the game window slightly, corrected the displayed text.) The
problem was triggered by a particular arrangement of the HTML source
text in the system's internal output buffers, so the output had to be
of just the right length and had to occur at just the right point in
the output sequence. The chances of encountering the bug in practice
were therefore fairly remote. The bug has been fixed.
- HTML TADS for Windows didn't correctly play back digital audio
files (WAV, OGG) encoded with odd (non-even) sampling rates (e.g.,
11025 samples per second). Depending on the playback duration, such
files would play back partially correctly, then switch to bursts of
white noise. This has been corrected.
- Under certain rare conditions, Workbench on Windows failed to
properly restore the docked-window configuration when loading a new
project while another project was already loaded. The symptom was
that one or more docked windows would show up along the wrong edge of
the window - for example, a window that was docked along the left edge
of the screen when the project was last used might be docked along the
bottom edge instead when the project was re-opened. The exact
conditions that triggered the problem were essentially random, so even
if you encountered this bug, it probably only happened some of the
time. The problem is now fixed.
Changes in Release HT-17 (TADS 2.5.10/3.0.15.2)
Released 9/13/2007 - Windows build Win108
- The Workbench debugger on Windows now tries to be smarter about
selecting the expression text for "tooltip" evaluation. (Tooltip
evaluation happens when you let the mouse pointer hover over an
expression in the source code for a few moments: the debugger
evaluates the text under the mouse as an expression, and shows the
result in a little pop-up window.) In the past, the debugger simply
used the single word under the mouse as the expression text. The
debugger now looks beyond the single word, as follows:
- First, if the mouse is over a parenthesis ("()") or square
bracket ("[]"), the debugger looks for the matching delimiter,
and uses the entire stretch between (and including) the
delimiters. Otherwise, the debugger uses the single word under
the mouse.
- Next, if the result so far starts with a "[", and the preceding
character isn't an operator of some kind, the debugger adds the
part before the "[", applying the first rule above to find its limits.
Otherwise, if the character preceding the result so far is a ".",
the debugger adds the part before the ".", using the first rule above
to find its limits.
- The debugger repeats the second rule above as long as it finds
more "prefix" expressions to add.
The new rules are convenient for index expressions ("lst[i]") and
object property expressions ("obj.prop"). If you point to either of
the brackets in an index expression, the debugger evaluates the entire
list-and-index expression; you can still get just the index part by
pointing to the part within the brackets, and just the list part by
pointing to the part before the brackets. Similarly, if you point to
the property name in an "obj.prop" expression, you get the whole
"obj.prop" expression result; if you want just the object part, point
to it.
Note that if you select a range of text with the mouse and point to
the selected range, the debugger evaluates the entire selection, just
as in the past. This lets you override the default "smart" behavior
to evaluate the exact expression you want, for times when the default
selection rules don't give you the results you're looking for.
- The Workbench debugger on Windows incorrectly showed "tooltip"
expressions while the program was actively running. These expressions
should only pop up when the program is stopped in the debugger; when
the program is running, there's not a meaningful context in which to
evaluate anything. This has been corrected.
- TADS 3 Workbench for Windows didn't properly restore the "no
verbose errors" project setting when loading a project (in other
words, Workbench always forced this option to the default "verbose
errors" setting every time a project was loaded). This has been
fixed.
- Workbench for Windows rearranged docked windows incorrectly when a
running game was terminated while the main Workbench window was
minimized. Docked windows were shrunk down to zero size on restoring
the main window in this case. This has been corrected.
- HTML TADS on Windows now uses the native Windows half-tone drawing
mode for scaling images. This is a slightly slower drawing mode, but
yields much better results when an image is drawn at an on-screen
pixel size different from its native dimensions.
- The TADS 3 editor mode in Workbench for Windows incorrectly
colored "this" as a keyword; it no longer does this. (This came about
because the TADS 3 coloring module is based on Scintilla's C++
coloring module: "this" is a keyword in C++, so this simply reflects
some inherited code that needed further customization.)
- The New Project Wizard in TADS 3 Workbench for Windows erroneously
copied some information from a currently open project to the new
project being created: bookmarks, special files, Web extra files,
"feelie" files, and Notes & Miscellaneous files. This has been
corrected.
- On some Windows systems, the Workbench documentation search
feature was unable to build its search index due to a permissions
violation creating a temporary file. The indexer tried to create a
temporary file in the root directory of the C: drive, but on some
Windows systems this location is protected against writing by normal
users. The indexer now uses a different temp file location that
should be more reliable.
- On some systems, the Windows Workbench documentation searcher
sometimes failed to build the search index on the first search attempt
due to a filename error. This has been corrected.
- Starting in build Win107, Workbench for Windows automatically
creates the object and symbol file output directories as needed when
running the compiler to build the project. However, it didn't also
create the output directory for the .t3 file itself. Workbench now
also creates the .t3 output directory if it doesn't already exist.
- The TADS syntax coloring mode in Workbench on Windows didn't
correctly color text within a double-quoted string that contained an
embedded << >> expression within an HTML tag. The syntax
colorer treated the part after the first > at the end of the
embedded expression as though it were the closing > of the
enclosing HTML tag, whereas it should have treated that > as part
of the >> sequence delimiting the embedded expression. The
coloring from that point forward within the string was wrong, because
the colorer's internal state was out of sync with the contents of the
string. This has been corrected.
- In the TADS 3 Library Reference Manual, hyperlink references to
the class ExitLister incorrectly pointed to the object exitLister.
This was due to (a) the LRM generator's use of the symbol name as the
file name for a given object's reference page, and (b) the Window's
file system's insensitivity to case. (The Windows file systems are
generally case-preserving [they remember the case specified when a
file is created, and faithfully reproduce it in the file index] but
case-insensitive [two names that differ only in case are considered to
refer to the same object]). The LRM generator now tweaks the
filenames for object pages when necessary to ensure that each object
has a distinct filename on case-insensitive file systems.
Changes in Release HT-16 (TADS 2.5.10/3.0.15.1)
Released 7/19/2007 - Windows build Win107
- TADS 3 Workbench for Windows has a new option for the Project
Search function that lets you search for text that spans multiple
lines. To use this new option, open the File Search dialog and tick
the checkbox "Collapse spaces and newlines." When this option is
selected, the project searcher effectively "collapses" all of the
whitespace in each file before searching it - that is, the searcher
converts each series of consecutive spaces, tabs, and newline
characters into a single space. The searcher then searches the file
for your string or regular expression pattern. Since newlines are
treated as though they were ordinary spaces, the string or pattern
you're looking for will be matched even when it's split across
multiple source lines. This is especially handy when searching for
text within long strings in the source code, since long strings tend
to be split up over several lines for readability.
- TADS 3 Workbench for Windows has a new option setting that lets
you specify the main folder where you keep your extension libraries.
This option is in the main Options dialog, on the new
System/Extensions page. You aren't required to keep your extensions
here, but there are two benefits of doing so:
- Workbench automatically includes this folder in the library
path list. Workbench and the compiler will look for files here
when they're not found within your project directory.
- The Source ZIP packager treats this directory specially.
When a project file is found directly in this directory
(not in a subdirectory), the Source ZIP packager will include
only the stand-alone file in the ZIP file. Normally,
the packager includes the entire directory (including
subdirectories) of each file in your project tree, on the
assumption that any files actually included in the project are
probably accompanied by one or more ancillary files, such as
README files or documentation. When a file is found directly
in the Extensions folder, though, Workbench takes it to be a
simple, stand-alone extension file.
- As described above, the Source ZIP packager now treats the
Extensions directory specially when building your source ZIP file.
When a file is found directly in the Extensions folder (rather
than in a sub-folder), the Source ZIP packager assumes that the file
is a stand-alone extension, without any accompanying files. The logic
is that a more elaborate extension that includes documentation or
other related files would warrant its own separate subfolder, so
anything that's directly in the Extensions folder must not have any
separate files associated with it. Any file that's in a separate
subdirectory of the Extensions folder, or that's entirely outside of
the Extensions folder, is considered to be part of a complex extension
that includes ancillary files; in this case, the ZIP packager bundles
up the entire contents of the directory containing the file.
- TADS 3 Workbench for Windows now automatically creates the output
directories for object (.t3o) and symbol (.t3s) files if they don't
already exist. Workbench creates the directories as needed just
before running the compiler during each build. This eliminates the
need to create these directories manually when moving a project to a
new machine.
- The new <BODY> attribute INPUT lets you specify the text
color for command-line input. This new attribute is parallel to the
existing TEXT, BGCOLOR, LINK, VLINK, ALINK, and HLINK attributes: it
takes as its value as an HTML color name or a #xxxxxx RGB value, and
sets the text color for command input text throughout the document.
For example, <BODY INPUT=GREEN> sets the color for input text to
green. ("Input text" is text within <FONT FACE="TADS-Input">
tags.) The <BODY INPUT> attribute is useful because it lets you
set a suitable contrasting text color for input text globally when you
change the main window's background color with <BODY
BGCOLOR=xxx>. In the past, it wasn't possible to change the input
color globally - you had to use <FONT COLOR=xxx> tags on each
input line instead - which sometimes left older parts of the
transcript illegible after a background color change.
- In Workbench, the editor language mode for TADS 3 incorrectly
classified periods as parts of identifiers when they occurred after a
series of alphanumeric characters with no intervening spaces. This
caused incorrect syntax highlighting in some cases. This is now
fixed.
- The Workbench editor language mode for TADS 3 now recognizes
VerbRule as a kind of object definition. In the past, VerbRule
definitions didn't auto-indent properly because the editor mode
thought they looked like function definitions.
- In the TADS 3 language mode in the editor, the Alt+Q command
(Edit.FillParagraph) could get stuck in an infinite loop if it was
used to reformat a string with a block of text containing no spaces
that was too long to fit within the margins. This has been corrected;
when an unbreakable block of text within a string is too long to fit
between the margins, the word wrapper now simply lets the block
overflow the right margin, then breaks the line just after the block.
- In Workbench for Windows HT-15, the auto-script QUIT-trimming
feature (which optionally removes QUIT commands and/or other
game-terminating event sequences from the end of an automatically
captured session script) didn't function. It should now work as
advertised.
- Workbench for Windows now stores its documentation search index
file in the system All Users\Application Data folder, under a TADS 2
Workbench or TADS 3 Workbench subfolder. This should ensure that
Workbench is able to create the index file as needed, even on machines
where the user doesn't have write permission to the Program Files
installation directory. (In the past, Workbench stored the index file
in the program directory; on shared computers, this sometimes didn't
work due to user permissions settings.)
- In Workbench for Windows HT-15, the Compile-and-Run command got
stuck in an infinite loop of repeatedly recompiling the project. This
has been corrected.
- Workbench on Windows crashed if it was terminated (either via the
File/Exit command or by closing the main Workbench window) while the
project was still running in the debugger. This is now fixed.
- In the past, when you created a new project in Workbench, the
auto-script counter from any previously loaded project was propagated
into the new project, so the new project's auto-scripts were numbered
from whatever the last counter in the old project was rather than from
1. Workbench now resets the counter when a new project is created.
- Starting with Workbench HT-15, the position of Find and Restore
dialogs was saved with the project and restored each time the dialogs
were subsequently displayed. Workbench now ensures that the restored
position is within the actual physical display area. In cases where
the project is saved on a machine with a large monitor and then moved
to another machine with a smaller monitor, this check prevents the
dialog from being hidden by appearing outside of the visible display
area.
- In the past, the flashing text caret sometimes failed to appear
when bringing the interpreter window to the foreground after another
application had been in the foreground. This happened under different
circumstances, such as when asynchronous output (such as from a
real-time fuse or daemon) occurred while the interpreter was in the
background. This has been fixed.
- On Windows, the interpreter sometimes left a few stray pixels on
the screen during command-line editing when ClearType (Windows's font
anti-aliasing system) was enabled. This has been fixed.
- The TADS 3 editor mode in Workbench for Windows didn't formerly
recognize the "function" keyword for function definitions when
figuring the syntax indenting. This has been corrected.
- In Workbench for Windows, using the Edit/Find command sometimes
incorrectly reported "No more matches" when searching backwards in
a file and more matching text was present. The editor should now
properly find matching text in reverse searches.
- In Workbench for Windows, the Edit/Find Again command incorrectly
reported "No more matches" if the search was started with the cursor
at the very start of the file. This has been corrected.
- In Workbench for Windows, the Edit/Find Again command incorrectly
failed to wrap the search back to the start of the file, even when the
previous search had the wrapping option enabled. The wrapping option
is now respected.
- In Workbench for Windows, the Edit/Find dialog has a new scoping
option that lets you search the project files, excluding libraries and
extensions. The dialog now offers three scopes: Current File, which
searches only within the file displayed in the active window; Project
- No Libraries, which searches only within files that are part of the
project tree and stored within the project directory; and
Entire Project, which searches all files in the project tree, whether
they're in the project directory or in separate library or extension
directories.
- The Edit/Find Again command in Workbench for Windows now respects
the search-scope option from the last search conducted through the
Edit/Find dialog. That is, Find Again will search through the current
file, the local project files, or the entire project, according to the
option settings in the last Find dialog.
- When using the tabbed document UI in Workbench for Windows (that
is, with the MDI child windows maximized), switching back and forth
between the Help window and other document windows sometimes caused
the Help window's contents to scroll slightly. This should no longer
occur.
- In Workbench for Windows, docked tool windows were sometimes
rearranged as the debugger opened and closed windows to match
preference settings when switching between design and debug modes.
For example, suppose that in design mode, you had the Project window
and the Scripts window docked along the left edge of the main
Workbench application window, with the Projects window on top; and
suppose that you set the preferences so that the Scripts window was
hidden when switching to debug mode and was shown again when switching
back to design mode. In this case, on returning to design mode,
Workbench sometimes rearranged the windows so that the Scripts window
re-appeared above the Projects window. Workbench should now restore
the original window order in these situations.
Changes in Release HT-15 (TADS 2.5.10/3.0.15)
Released 3/8/2007 - Windows build Win106
- TADS 3 Workbench's "Build Source ZIP Package" feature now includes
external libraries in the ZIP file it builds. Each external library
folder is bundled into a ZIP file of its own, and then these ZIPs are
included in the overall source ZIP package. This ensures that
recipients of the source package have everything they need to build
the project on another machine, without having to find and download
third-party libraries (or, more problematically, unpublished custom
libraries created by the project's author).
- TADS 3 Workbench for Windows now accepts folders in the "Notes
& Miscellaneous" section of the project list. The main purpose of
the Notes & Misc section is to specify additional files to be
included in the Source ZIP package; the ability to add folders here is
convenient if you want to include a whole batch of notes, since you no
longer have to add them individually to the list. Folders in this
section work just like they do in the Resource Files section:
Workbench remembers the folder in the project list, not its
contents, and retrieves the current contents of the folder each time
you build a Source ZIP package. This ensures that you always get the
current contents at the time of a build, so you don't have to worry
about keeping the project list up to date as you add and remove files
in the folder.
- In TADS 3 Workbench for Windows, the auto-scripting system can now
optionally trim QUIT commands from the end of a script file. You can
configure the particular QUIT commands to trim using the Scripts page
of the Project Settings dialog. Enter one or more lists of events to
trim; each list is a set of one or more regular expressions, one event
per line. You can enter multiple alternative lists by separating
lists with blank lines. Each time you run the game, Workbench scans
the resulting auto-script file for each of the QUIT sequences listed
in the project settings; if it finds a match at the very end of the
new auto-script file, Workbench will delete the entire matching
sequence from the end of the script.
- Workbench's integrated text editor in Windows build Win105 added a
feature that wasn't documented in that release's change log: a new
User Keywords syntax coloring feature. On the Syntax Coloring page of
the Options dialog, for the TADS 3 language mode, new "syntax element"
categories are now included for User Keywords 1, 2, and 3. These
categories let you specify custom coloring for three sets of keywords
of your choosing. You can specify the keywords for each category
selecting the category in the Syntax Element list, then clicking the
Keywords button. This opens a dialog that lets you type in the
keywords to associate with the category. Whenever these keywords
appear in TADS 3 files, the editor will color them according to the
custom colors you select for their categories. For example, you could
use this to set custom coloring for certain library macros
(DefineAction, VerbRule, etc).
- Workbench for Windows now remembers the position of the Find and
Replace dialogs, and restores the last position each time one of these
dialogs is redisplayed. This means that if you move the dialog so
that it's not covering any of the source windows, the new position
will stick - you won't have to move the dialog again each time you
bring it up again. In the past, Workbench centered the dialog each
time it was displayed, so you had to manually move it out of the way
again on each use.
- Workbench for Windows now keeps keyboard focus in the Find dialog
after each "Find Next" operation, whether or not a match was found,
and whether or not the latest result was in a different window from
the previous result. In the past, focus moved to the current text
editor window after an unsuccessful multi-file Find Next and each time
the latest match was found in a new window; this was inconvenient when
operating the dialog via the keyboard, since keyboard focus didn't
reliably stay in the dialog after a Find Next.
- In the Windows Workbench, the TADS 3 language mode's code folding
had a problem in some cases folding methods. This has been corrected.
- In the Workbench default key mapping on Windows, the keys for
Edit.PopBookmark and Edit.JumpToNamedBookmark have been swapped from
the previous release. Edit.PopBookmark is now Alt+J, and
Edit.JumpToNamedBookmark is now Ctrl+J. The change makes the default
key mapping the same as the Epsilon-style key mapping for
Edit.PopBookmark, which was originally intended but was entered
incorrectly in the mapping in the prior release.
- Workbench for Windows has a new command,
Edit.JumpToPreviousBookmark, which jumps backwards to the previous
bookmark. This does the same thing as Edit.JumpToNextBookmark, but
goes the opposite direction through the source. This command isn't
assigned to any key in the standard mappings.
- Workbench for Windows has two new commands to delete bookmarks.
Edit.ClearAllBookmarks deletes all bookmarks throughout the project,
while Edit.ClearFileBookmarks deletes all bookmarks in the current
file. These commands aren't assigned to any keys in the standard
mappings.
- In Workbench for Windows, you can now set the color for selected
text in the editor and tool windows. This is done via the Fonts page
of the Options dialog - simply select the new colors in the Selected
Text drop-down lists. The color selections you make here apply to
tool windows, but by default they don't apply to text editor
windows. This is because Scintilla normally shows selected text with
the syntax-sensitive font color against a gray background, which
allows most syntax coloring to remain visible even in a selected
region. If you want to override this feature and use custom colors,
check "Override Scintilla selection color in editor windows."
Sight-impaired users who use screen readers should note that some
screen readers use the font color to detect selected regions, so
Scintilla's non-standard selection coloring will prevent such screen
readers from detecting selections. To make Scintilla use the standard
Windows selection colors, set the Selected Text colors to "Automatic"
and check the "Override" box.
- The integrated editor in Workbench for Windows didn't show the
selected custom coloring for keywords in the "User Keywords 3" list.
This has been corrected.
- The TADS 3 editor mode's syntax coloring didn't properly color
continuation lines of preprocessor directives (i.e., with "\" at the
end of the prior line) as preprocessor directives. It also didn't
indent continuation lines properly. For both purposes, the editor
incorrectly treated continuation lines as regular code. This has
been corrected.
- In Workbench for Windows, some of the error message dialogs were
"unowned" windows, meaning they came up with their own separate
Windows taskbar entries, almost as though they were separate
applications. This could be slightly annoying in that clicking on the
main Workbench window when one of these message dialogs was displayed
brought the Workbench window to the front, but that window wouldn't
accept any input until the error dialog was dismissed. To dismiss the
error dialog, you had to manually navigate back to its window, which
might be hidden behind the main Workbench window by now. These
dialogs are now all "owned" by the Workbench window, meaning they'll
always stay in front of the Workbench window; this should eliminate
the navigation problem by ensuring that the error dialogs are never
hidden behind the Workbench window.
- In the past, the HTML Interpreter didn't recognize
<BASEFONT> as a tag with global effect when pruning old text to
reduce memory usage. It now properly treats <BASEFONT> as a
global tag, so it retains these tags when pruning. (The HTML
Interpreter discards old text and HTML tags from the top of the window
whenever the total amount of text in the window exceeds a
user-specified memory threshold. The Interpreter discards only enough
text to keep the total under the memory limit; since the usual limits
are pretty large, this process is normally transparent to the user,
since all of the discarded text should have scrolled off the top of
the window long ago whenever this happens. When discarding old text,
the HTML parser makes a point of discarding only tags which have no
global effects, so that their removal doesn't affect any of the text
that remains after the pruning.)
- In the past, Workbench for Windows didn't update the project list
to reflect changes to a .tl file made within the integrated editor.
This has been corrected - whenever you save a .tl file that's part of
the project, the project window will automatically refresh its list of
the library's contents.
- Due to a bug in Scintilla, the Stuttered Page Down command didn't
work properly if the current page contained wrapped lines. This has
been corrected.
Changes in Release HT-14 (TADS 2.5.10/3.0.14)
Released 2/9/2007 - Windows build Win105
- Important note: if you're upgrading from a previous version
of Workbench, and you want to use one of the updated standard key
mappings, you'll have to manually load the new mapping file of your
choice. Your previous settings are stored in the Workbench
configuration file, and Workbench will respect your old settings until
you explicitly load a new key file. To do that, go to the Keyboard
page of the Options dialog, click the Load Key Map button, and select
the *.keymap file you want to load (the standard mappings are in the
Workbench program directory). Click OK in the Options dialog to save
the new mappings.
- A few new editor features have been added to Workbench for
Windows. These are described more fully in the editor help file.
- The integrated editor has been updated to the latest,
just-released version of Scintilla, 1.72.
- The Alt+/ key binding has been replaced in this version. In
HT-13, Alt+/ was bound to Ext.Edit.FormatComment. This key is now
used for setting a bookmark instead (see below). The old binding
isn't needed any longer because Alt+Q now serves as a multi-purpose,
context-sensitive reindent command: press Alt+Q while the cursor is in
a TADS comment to reformat the comment; press Alt+Q while the cursor
is in a TADS string to reformat the string; press it in other TADS
code to reindent the code line or region; press it in a non-TADS
window to reformat a text paragraph.
- The new command Edit.CommentRegion adds or removes commenting at
the start of each line in the selected region. The command is bound
to the Ctrl+8 key in the standard key mappings (this key was chosen
because 8 is the asterisk key, and asterisks are commonly involved in
commenting in many languages). The TADS language mode handles this by
adding or removing "//" at the start of each line; other modes
currently ignore the command. This command is handy when you want to
quickly disable some code for testing purposes, and then later
re-enable it.
- The editor now provides a "bookmarking" feature, which lets you
mark locations in source files for easy return later on. This new
feature is described in detail in the Workbench help, in the Advanced
Editor Features section.
- The new editor command Edit.FindDefinition (on the F6 key in the
standard keyboard mappings) searches the project for the definition of
the symbol at the cursor location. The editor searches for a TADS
3-style object, class, or function definition, looking in all files
included in the project list. If a definition is found, Workbench
opens the file containing the definition and selects the matching
symbol. Since the cursor is positioned at the matching symbol in the
definition, you can search for another definition of the same symbol
simply by pressing F6 again - this is useful for symbols that have
more than one definition, such as via 'modify' or 'replace'.
- The TADS mode adds a new command to reformat a literal string,
applying word-wrapping and auto-indenting. You can invoke this by
positioning the cursor within a string and pressing Alt+Q. The editor
will automatically re-flow the string to fill out lines to the current
right margin, wrapping lines at word boundaries. The reformatting
leaves line breaks intact when they're adjacent to explicit formatting
line break codes (\n, \b, <br>, <p>, <.p>), and
won't break a line in the middle of a {format code} sequence.
- The TADS mode now distinguishes statement braces ("{" and "}")
from other operators for syntax coloring purposes. This lets you set
a separate color for braces.
- The editor now supports "code folding," which lets you selectively
show and hide blocks of code. The folding system detects the lexical
hierarchy of the TADS code - that is, it recognizes an object
definition as a block of code, a method within an object as a block,
and a set of statements enclosed in braces within a method as a block.
Enable code folding using the Show Folding Controls command on the
Edit menu. When folding is enabled, the editor shows "+" and "-"
controls in the left margin; these work like buttons in the ordinary
Windows tree control, to expand or collapse a block of the code.
Folding is often helpful with large object or method definitions,
because it lets you hide details so you can more easily see the
big-picture structure of the code.
- The editor now maintains a "mark," which is a temporary, ad hoc
bookmark, similar to the Emacs mark. The mark is set automatically
whenever you set a selection mode anchor (Edit.SelectionMode, etc.),
jump to the start or end of the document, or start a regular or
incremental search. You can jump to the mark with the new command
Edit.SwapMark, and you can select the text between the cursor and the
mark with the new command Edit.SelectToMark.
- The incremental search command can now be used to extend a
selection range. If a selection mode is in effect at the start of an
incremental search, and the search is successful, the selection range
is extended at the end of the search to include everything between the
original selection anchor and the end of the matching search text.
- A new Options page, Wrapping & Margins, lets you control how
the editor handles long lines. You can set a right margin, which
controls the line width for certain commands, and you can make the
editor display a visual guide at that column. You can also tell the
editor to automatically word-wrap text as you enter it when you type
past the margin.
- The TADS-mode comment formatter now uses the new margin setting as
the line length when doing its word-wrapping.
- A new command, Edit.FillParagraph, auto-formats a paragraph of
plain text, filling out each line to the margin width and breaking
lines on word boundaries to fit.
- When an editor window is in TADS 3 language mode, the
Edit.FillParagraph command doesn't do ordinary paragraph filling, but
instead does context-sensitive TADS-code reformatting, depending on
where the cursor is positioned. If a region is selected, the command
reindents each line in the region, as though you'd used the
Ext.Edit.SyntaxIndent command. Otherwise, if the cursor is in a
comment, the command reformats the comment, the same as
Ext.Edit.FormatComment; and if the cursor is within a string, the
command reformats the string, the same as Ext.Edit.FormatString. This
means that you don't really need to bind separate keys to the
Ext.Edit.FormatString and Ext.Edit.FormatComment commands - you can
simply use the Edit.FillParagraph command (Alt+Q) to do whichever type
is right for the context.
- Editor windows can show the line number for each line in the
margin. Use the Show Line Numbers command in the Edit menu to
control this.
- A new option (set via the Library Paths page of the Options
dialog) lets you specify that library files are to be opened in
read-only mode by default. When this option is set, the editor will
open any file not located within your project folder as read-only.
This lets you avoid accidentally editing a library file when you're
browsing the file or stepping through it in the debugger. You can
always make a library window writable by using the Edit.ChangeReadOnly
command (which isn't assigned to a key in the default mapping). By
default, this option is not set, meaning that all files are opened as
writable by default.
- The project window now recognizes a few additional resource
filename extensions as indicating text files that can be opened in the
integrated text editor: .log, .cmd, .c, .cpp. (When you double-click
on a resource file in the project window, Workbench tries to guess
whether the file in question is a text file by looking at the filename
suffix. If the suffix is one typically associated with plain text
files, Workbench opens the file in the internal editor; otherwise,
Workbench asks the operating system to open the file using whatever
application is normally associated with that type of file.)
- A bug in Workbench for Windows sometimes occured when loading a
project. The problem manifested as a Workbench crash in some cases,
and in other cases as random rearrangement of some of the windows left
open in the previous session. The problems were particularly likely
to occur when loading a project after Workbench was already open. The
bug has been fixed, so these problems should no longer occur.
- In HT-13, the Compile-And-Run command in Workbench initiated the
build correctly, but didn't start the project running after the build
completed. This has been corrected.
- The regular expression option for the project-wide search command
(Find in Project Files) didn't work in the previous release - checking
the regular expression box always yielded a regular expression syntax
error. This has been corrected.
Changes in Release HT-13 (TADS 2.5.10/3.0.13)
Released (1/19/2007) - Windows build Win103
- Workbench for Windows now has a built-in text editor. The
integrated editor is Scintilla, which is a highly stable open-source
text editing component designed specifically as a programmer's editor.
Scintilla has the features you'd expect from a source code editor:
multi-level undo, syntax coloring, regular expression searching, and
much more.
The Scintilla editor takes the place of the former read-only source
code display window, so when you're stepping through code in the
debugger, you're actually using a live editing window - this means you
can make changes directly in the debugger window when you discover a
problem or otherwise find something you want to change. (Of course,
changes you make to the source code while debugging won't affect the
running version of the program until you recompile.)
- Scintilla can be programmed to understand different programming
languages, to provide appropriate syntax coloring. The integrated
version recognizes TADS 3 code (of course), and it also includes
support for HTML and XML. In fact, Scintilla has pre-defined syntax
modes for numerous other languages - C, C++, Python, Perl, Java,
BASIC, Fortran, and on and on - but to avoid clutter in the Workbench
UI, we've only exposed the language modes that are likely to be useful
within TADS projects.
- The TADS 3 editing mode not only provides syntax coloring, but
also provides a sophisticated auto-indenter and comment formatter.
The auto-indenter attempts to keep your code properly indented as you
write it; whenever you press a "hot" key, the auto-indenter tries to
fix up the current line to make it fit the standard indenting style.
Hot keys include the return key, braces, square brackets, semicolons,
and colons. The comment formatter automatically reformats a block
comment when you type the "*/" sequence; it fills the comment's
paragraphs for an 80-character line width and sets up a column of
asterisks at the left edge.
These auto-formatting features are designed to make your life
easier - much easier - by saving you the trouble of manually fussing
with the indenting as you write your source code. But they can take a
little getting used to: some people find it disconcerting to have the
code jumping around on its own so much. If you find that you don't
like the auto-indenting scheme, you have several options for
controlling it, moderating it, or eliminating it. The Indenting page
in the Options dialog lets you set the auto-indent style to
"syntax-based," "same as previous line," or "off." If you turn it
off, the source text will be left exactly as you type it. If you set
it to "same as previous line," the indenter will merely indent each
new line to the same level as the previous line whenever you press
return, and otherwise will leave everything alone. This page also
lets you turn off the comment auto-formatter, if you find its behavior
annoying. If you want to go beyond these pre-defined choices, there's
one more option: you can go in and change the TADS 3 mode to make it
behave exactly the way you want. We supply the source code for the
TADS 3 mode - it's in tads3addin.cpp - so you can make whatever
customizations you like and then recompile the plug-in DLL.
- You can now customize the keyboard, to define your own command
keys. Use the Keyboard page of the Options dialog to customize
key bindings. The keyboard mapping system is particularly useful
if you want to make the new built-in text editor behave like another
editor you're already familiar with.
- The language-mode features we just described are fully extensible
with a plug-in system, in case you want to add support for another
language you find useful within Workbench. The plug-in system uses
DLLs containing COM objects - we chose that infrastructure because it
lets you write these objects in virtually any programming language on
Windows. We've provided a set of C++ classes that makes it relatively
easy to write a plug-in in C++. If you're interested, refer to the
"addins" directory for a bunch of source files that provide
specifications and examples. The main file is itadsworkbench.h, which
contains the specification of the plug-in interface. Also see
wb_addin.h, which defines the framework classes. We've also supplied
source code for the TADS 3 and HTML modes, both to serve as examples
of how to build add-ins, and to make it easy to make minor tweaks to
the behavior of those modes. Everything related to the add-ins is in
the "addins" subdirectory of the main install directory.
- TADS 3 Workbench for Windows has a new Project Search feature.
This lets you search all of the text files in your project for a given
string or regular expression - it's like the Unix "grep" command. Use
the Search for Text command on the Project menu to perform a search.
If you check the Regular Expression box, the search string will be
interpreted as a regular expression pattern, using exactly the same
syntax that the TADS 3 VM uses in rexSearch() and the like.
- The Find dialog (for searching for text in a source file) now has
a Regular Expression checkbox option. (A "regular expression" is a
special kind of wildcard pattern, sort of like those "*.TXT" file
searches you can do in Windows, but much more powerful.) Check this
box to perform a regular expression search of a text editor window.
As with Project Search, this uses the full TADS 3 regular expression
syntax.
- The Find dialog is now "modeless," meaning that you can switch
back to the editor window while the Find dialog is still displayed,
to move the cursor or make changes to the text.
- A new Incremental Search command provides a more convenient way of
searching for text in an editor window. Incremental search skips the
dialog, so it can be run entirely via the keyboard. Unlike the
regular Find dialog, incremental conducts the search continuously as
you type in the search string; this saves time by letting you type in
only as much of the search term as you actually need to locate the
text you're looking for. Incremental searches have several options
that can be selected via keystrokes within a search, including regular
expression matching, whole-word matching, exact-case matching, and
forward/reverse searches.
- A new Replace command lets you search for text in an editor window
and replace each occurrence with a new bit of text. Like Find,
Replace can optionally search for a regular expression pattern. The
dialog lets you find and replace occurrences of a search term one at a
time, so that you can individually inspect and approve each
substitution, and also has a button to replace all remaining
occurrences without further prompting. The dialog is modeless,
meaning that you can switch back to the text window while the dialog
is still running, if you want to make additional edits between
replacements.
- In TADS 3 Workbench, the Project window has several new sections:
- The Feelies section lets you list additional files to include
in release packages. These files are automatically included in
the ZIP Package and Windows SETUP Package builds.
- The Web Page Extras section lets you add extra files to include in
the Web page package. Any files you drop here are automatically added
as links in the "Download" box on the generated Web page. This lets
you add things like hints, maps, walk-throughs, and any other extra
material you want to make available for download from your Web site,
but which you don't want to include in the release package itself.
For each file, you can set a title for its hyperlink on the generated
page by right-clicking the file in the Project window and choosing
"Set File Title..." from the menu. If you don't set a title for a
file, its hyperlink will simply be a "friendly" version of the
filename (any path or extension is removed, the first letter is
capitalized, underscores are changed to spaces, and each embedded
capital is preceded by a space: so misc\readMe.txt will be shown as
"Read Me", for example).
- The Notes and Miscellaneous section is a place to add files that
you want to keep track of as part of the project's overall source
materials, but which don't belong in any of the other Project window
sections. You can use this section for things like your "to do"
list, your working notes, and so on. The benefits of listing files
here are (1) that you can easily open a file by double-clicking it
in the list, and (2) that the "Build Source ZIP Package" command
will automatically include these files.
- The Special Files section is a little different from the other
sections. Rather than containing a list of files of a particular
type, it contains slots for a number of files with special purposes in
certain of the release packages. Each slot is labeled with its
special purpose, plus the currently assigned file, if any; you can
assign a new file to a slot by dragging a file from the Windows
desktop and dropping it on the slot, or by right-clicking the slot and
selecting "Set File" from the pop-up menu.
- If you go to the "Windows SETUP" page of the Build Settings dialog
in TADS 3 Workbench, and you click the "Edit" button to display the
SETUP options editor, you'll find that many of the options that were
formerly presented have been removed. The missing options have been
replaced with slots in the Special Files section (see above). The new
arrangement has the advantage of being more consistent overall: these
special files are really just some additional, special-purpose source
files for the project, and the new arrangement recognizes this by
moving them into the Project window's list, where all of the other
source files for the project are managed.
- In the Project window in TADS 3 Workbench, you can explicitly set
the "Start Menu" title for any file in the Feelies list, and for
certain of the files in the Special Files list. Set a file's Start
Menu title by right-clicking on the file in the Project window, and
selecting "Set File Title" from the menu. The title is only used in
the Windows SETUP package; it's ignored for the Release ZIP package.
Each Feelie item that's assigned a Start Menu title will be added to
your game's Start Menu group, with the title you specify appearing in
the group menu; other feelies are included in the package and will be
copied to the user's hard disk at installation, but won't be listed in
the Start menu.
- In TADS 2 Workbench for Windows, the Build Settings dialog has a
new page, "Files - Special." This page lets you specify (1) a Cover
Art image, which (if specified) is bundled into your compiled .gam
file for use by game browsers (such as TADS Game Chest); and (2) a
Windows icon (*.ICO) file to use for the Windows .EXE version of your
game. Note that the EXE icon was specified in past versions via the
"Windows SETUP" page of the Build Settings; that older setting has
been removed, so you should use the new "Special" page to set the
icon from now on.
- TADS 3 Workbench has a new set of Build commands that let you
create release packages with a couple of menu clicks. These commands
automate procedures that, in the past, had to be done manually using
other tools, such as a ZIP program. The new packaging commands are:
- Build Release ZIP Package: This creates a ZIP file
containing the release version of your game, suitable for distributing
to players or uploading to the Web (to the IF Archive, for example).
The ZIP file contains a freshly compiled release build of your game
(the .t3 file), plus all of the Special Files and Feelies listed in
the Project window. The Resource Files listed in the Project window
are automatically bundled into the compiled game. The resulting ZIP
file is the "universal" edition of your game for distribution: UNZIP
tools are available on virtually every platform, and the .t3 file
bundled in will work on any computer with a TADS Interpreter. To
distribute the game, you simply distribute the ZIP file to players.
To play the game, a player just needs (1) your ZIP file, (2) an UNZIP
tool for her operating system, and (3) a TADS 3 Interpreter for her
OS. Almost everyone these days will already have an UNZIP tool
installed, and many regular IF players will already have a TADS
Interpreter. Set the output ZIP file via the "Release ZIP" page
of the Build Settings dialog.
- Build Windows SETUP Package: This command (which was
included in previous Workbench versions as well, under the name "Build
Windows Installer") builds an automatic SETUP program for the Windows
edition of your game. The resulting SETUP program contains a freshly
compiled copy of your game, compiled as a Windows executable (.EXE)
program, plus all of the Special Files and Feelies listed in the
Project window. The game .EXE file will automatically contain the
Resource Files listed in the Project window. The resulting SETUP file
is a completely stand-alone edition of your game - to distribute it,
you just distribute the single installer .EXE file; to install, a
player simply runs the installer. You don't need to distribute any
other files, and players don't need to download or install anything
else. Unlike the ZIP file edition, players don't need to have an
UNZIP tool or a separate TADS Interpreter installed - the installer
contains everything they need. As a result, this is by far the most
convenient distribution format for players on Windows - but, of
course, it has the disadvantage that only Windows users can use
it. If you plan to distribute this edition, it's a good idea to
distribute the ZIP edition as well - that way, Windows users get the
ease of use of the SETUP edition, but people on other operating
systems can still run the game. Set the output EXE file (and other
options) via the "Windows SETUP" page of the Build Settings dialog.
- Build Source ZIP Package: This creates a ZIP file
containing everything that goes into building your game: the project
(.t3m) file, the source files, header files, resource files, Special
Files, and Feelies. This makes it easy to transfer your project to
another computer, or to distribute the project to other people. Note
that only "local" files are included - that is, files within the
folder containing the .t3m file (or subfolders of that folder);
anything else is assumed to be a third-party library, which you
normally wouldn't want included since it's not part of your project's
source. Set the output ZIP file via the "Source File ZIP" page of the
Build Settings dialog.
- Build Web Page: This creates a simple Web site for your
game, suitable for uploading to a Web hosting service. The main page
is created by filling in a template with the bibliographic information
from your GameInfo.txt file (which is usually, in turn, generated from
the versionInfo object defined in your game's source code), and
includes a link to download the game (either as just the .t3 file or
as the release ZIP package), and optionally to the Windows SETUP
package and the Source ZIP package. The page will also include links
for any additional files that you list in the Web Page Extras section
of the Project window. Set the output directory and other options via
the "Web Page" page of the Build Settings dialog. The web page
builder uses a standard template to determine the layout of the page,
but you can create your own custom template instead if you want to
change the appearance or add special features; you can specify your
custom template file using the "Custom Web Template" item in the
Special Files section in the Project window.
- Build All Packages: This builds a fresh copy of each of the
packaging options: the release ZIP, the Windows SETUP, the source ZIP,
and the Web Page. To be more precise, this actually builds all of the
selected packages, the selections being made via the Build
Settings dialog. Each package has a page in the Build Settings dialog,
and each package page has a checkbox labeled "Include in 'Build All
Packages'". If this box is checked, the package will be included in
the build; otherwise it won't. By default, the box is checked for
every package. If there are packages you don't plan to distribute,
you can make the Build All Packages process run a little faster
by un-checking the boxes for the unwanted packages.
- TADS 3 Workbench for Windows can now automatically capture all
input events each time you run your game, creating a "script" that you
can replay on a later run of the game. Here's how this works:
- Each time you run the game, Workbench automatically creates a
script file, with a name like "Auto 5.cmd", in the Scripts subfolder
of your main project folder.
- The Scripts tool window shows the list of script files, sorted
from newest to oldest.
- To replay an entire script, right-click on the desired script in
the Scripts tool window and select "Replay" from the menu.
- To replay a script only to a certain point, first open the script
in the text editor by double-clicking on the script file in the
Scripts window, then right-click on the last line of the script to
execute, and select "Replay to Cursor" from the menu.
- When you replay a script, Workbench will tentatively create a new
auto script for the replay session, in case you type some new commands
after the replay has completed. However, if you don't end up typing
any new commands, so that the new script is in the end identical to
the one being replayed, Workbench will discard the redundant new
script. This avoids cluttering the Script list with multiple copies
of the same script if you're repeatedly playing through a script as
you test a series of changes.
- Most people work on a game one section at a time, so the scripts
that Workbench captures are typically most useful when they're fresh.
As you move on to focus on new parts of the game, older scripts will
probably become less useful, since they exercise portions of the game
that you're not currently working on. This is why Workbench sorts the
Script window from newest to oldest - we figure you'll usually want
the most recent scripts to be closest at hand.
- What's more, Workbench can help keep the Scripts window tidy by
automatically discarding older scripts. By default, Workbench keeps
the latest 25 "Auto N" scripts: each time a new script is created,
Workbench deletes any Auto scripts beyond the most recent 25. You can
change the maximum number of Auto scripts to keep, or you can turn off
this auto-delete feature entirely, using the Scripts page of the
Options dialog. No matter what the settings, Workbench will
never include a renamed script in this cleanup process - the
cleanup process will only delete scripts with the "Auto N" name
pattern. So, if there's a script you want to keep permanently, simply
rename it to something other then "Auto" followed by a number - you
can do this by right-clicking on the file in the Script window and
selecting "Rename" from the menu.
- You can disable the auto-scripting feature and change the other
scripting settings using the Scripts page of the Options dialog.
- Workbench for Windows has a number of enhanced user-interface
features. Most of these should be familiar to most Windows users,
since they're common in other applications:
- Workbench now has multiple toolbars instead of a single main
toolbar. The new documentation search and integrated editor features
have increased the number of toolbar commands to the point where a
single toolbar would have become quite large. The new arrangement
creates groups of related commands, and puts each group in its own
separate toolbar.
- The real advantage of the separate toolbars is that you can now
rearrange the layout of the toolbars, to suit your working style and
the amount of space you have available on your monitor. You can move
a toolbar by dragging on its left edge. You can also hide and show
each toolbar individually - right-click on a toolbar to access a menu
that lets you select which toolbars are visible. The main menu is
itself a toolbar now, so you can arrange its position the same way
(you can even hide it if you want).
- When you maximize the document windows (the "MDI" windows),
Workbench now displays a list of "tabs" that let you navigate among
the windows. The tabs are displayed at the top of the document window
area; click on a tab to bring up another window. Many people find the
tabbed style of interface easier to navigate than the MDI style, since
each window gets the full workspace when it's active, but the list of
other windows is always close at hand. To switch to the tabbed
interface, simply maximize a document window; to switch back to MDI
mode, click the "restore" button at the right of the tab list.
- Menu items now display icons that correspond to the toolbar
buttons for the same commands. Many people find that this makes menus
easier to navigate, by providing a visual cue to help spot the command
you're looking for at a glance.
- You can now tell Workbench to show or hide the various "tool"
windows when switching between Debug and Design modes. (Workbench is
in "Debug" mode when the game is running, and "Design" mode when the
game isn't running.) You can specify which windows to show and hide
in each mode using the new "Tool Windows" page of the Options dialog.
For the most part, the tool windows are useful only in one mode or the
other; for example, the Stack window is useless in Design mode, since
there's no active stack to display. This new feature is designed to
give you more room to work by letting you optimize the set of tool
windows displayed in each mode.
- Workbench for Windows now lets you perform a full-text search of
the documentation. To run a search, type your search terms into the
text box in the new Search toolbar, and click the button (or just
press Return). Workbench will display a Search Results window showing
a list of the pages found within the documentation containing the
search terms.
- By default, the search engine looks for pages containing all
of the keywords you type; if you want to look for documents containing
one of several keywords, separate the words with OR (the upper-case
letters are required); for example, operator OR expression
searches for pages with either keyword. If you want to exclude
pages that contain a certain word, type NOT (in upper-case) before the
word: operator NOT expression returns pages that contain
"operator" and which don't contain "expression." By default,
the search engine looks for common variations of the words you type,
such as plurals and verb tenses; to look for the exact word you type,
put it in quotes: "operator" will match only "operator", not
"operators" or "operated" or "operating". Similarly, if you want to
look for an exact phrase, put the whole phrase in quotes: "thing
class" searches for the whole phrase, not just the individual
words.
- If you installed the version of the Author's Kit that includes the
full documentation, the search engine will search your local copy of
the documentation. This requires building a local index, which uses a
few megabytes of disk space and could take a minute or so, but only
needs to be done once. If you installed the smaller Author's Kit with
no documentation, Workbench will run the search using the tads.org
on-line search engine, which obviously requires an internet connection
to perform the search. The on-line and local versions work the same
way (they use the same search engine), but the local version is
usually faster because it doesn't involve any network latency.
- The Search toolbar also lets you perform a quick search of the
current document window, or a quick project-wide text search. Use the
drop-down arrow in the Search bar to select "Search Current File" or
"Search Project Files"; after you've done this, the Search bar will
search the current file or the project source code rather than the
documentation. This is a little quicker than going through the normal
Find dialogs. Note that unlike Doc searches, Project and Current File
searches are not keyword searches - these are simple
literal-text searches that simply look for the exact text you type.
The OR and NOT keywords and the quoting syntax used in the Doc search
don't apply here. These searches use the default Find options
(case-insensitive literal text, not regular expressions). You'll have
to use the normal Find dialog, accessible through the Edit menu, if
you want to set non-default search options: regular expression
matching, whole-word matching, or exact-case matching.
- Workbench for Windows has some new commands on the Tools menu to
work with IFIDs (Interactive Fiction Identifiers, as defined by the Treaty of Babel and used in the
TADS GameInfo metadata system). First, the command "Generate IFID"
randomly generates an IFID for you to use in your project. Second,
the command "Read IFID From..." reads the IFID from an existing TADS
game. Importantly, the Read IFID command generates the "implied" IFID
for a game that was originally released without an IFID defined in its
GameInfo data (or without any GameInfo data at all). This is useful
because the Treaty of Babel specifies that you must use this implied
IFID as the explicit IFID for any future version updates of a game
previously released without an IFID - this ensures that the IF Archive
and other tools will be able to recognize the new and old releases as
different versions of the same game. The Babel didn't appear on the
scene until mid-2006, so the many TADS games released before that time
obviously don't have explicit IFIDs.
- The Windows SETUP builder has a new feature that lets you add your
own custom items to the Start Menu group for your game. For users
running your SETUP version, it will be much easier to find any
"feelie" items you include if you put them on the start menu - most
Windows users will never look at the "C:\Program Files\My Game"
directory on their own after installing your game, so they'd probably
never find your feelies otherwise. You can add an item to the Start
menu by including syntax like this in the list of installation
settings (the "Installer Options" field in the Windows SETUP page of
the Build Settings dialog):
startmenu="My Item Title" item1.htm
This shows "My Item Title" as the title in the Start Menu group.
When the user selects this item, Windows opens the file "item1.htm"
using whatever program is associated with that file type on the user's
machine. The installer automatically includes the given file in the
install set, so you don't need to list it separately with a FILE=
line.
A note on file formats: It's pretty safe to assume that everyone
has software installed for viewing plain text (.txt) and HTML (.htm)
files, and most Windows machines have a Portable Document Format (aka
Acrobat, or .pdf) reader as well. Other formats, such as Word (.doc)
or other word processor formats, are less universal, so you're much
better off with HTML or PDF if you want fancy formatting.
- The HTML formatter didn't properly align the text of the first
line of an <LI> item in a numbered list
(<OL>...</OL>). The text position was off by a few pixels
to the left or right of the list margin. This has been corrected.
- In the past, in Workbench for Windows, the font popup list in the
Formatting page of the Debugger Options dialog sometimes showed
multiple copies of a font name. This happened because the popup list
showed one copy of the name for each code page (localized character
set) installed for the font; some of the system fonts support numerous
code pages, so a font like "Courier New" might have shown up five or
six times. The dialog now displays only one copy of each font name.
- In Workbench for Windows, when you change a #define symbol in the
Project Settings dialog, Workbench reloads the list of files in the
Project window to make sure that any affected libraries reflect the
new #define values. Libraries (.tl files) can refer to #define
symbols to determine which source files to include, so changing a
#define can affect the list of included project files. In the past,
this refresh operation had the side effect of forgetting all of the
"file exclusions" for libraries. That is, if you had unchecked any of
the checkboxes next to source files within a library in the Project
tree, the checkboxes were all checked again after the refresh.
Workbench now retains the checkbox settings. (Note that this only
applies to files that are included both before and after the #define
change. If you change a #define in such a way that the list of
included files changes - say, because you change the LANGUAGE symbol
from "en_us" to "fr_fr" - the checkbox settings for any old files that
are no longer included in the project will be lost, and the checkboxes
for any new files that weren't previously included in the project will
be checked by default. Workbench can't guess at the correspondence
between files in, say, the en_us library and the fr_fr library, so it
can't carry over the exclusion settings when the libraries change.)
- In certain cases, Workbench for Windows was inconsolable about
finding a missing source file. If you added a source file to your
project, and the source file was in a subdirectory under one of the
existing library directories (the directories listed in the "Library
Paths" page of the Options dialog), Workbench remembered the source
file's name with a relative path - so, for example, the source file
was listed in the project tree as "MyLib\mysource.t". If you later
moved this source file to another directory, Workbench asked as always
for your help in locating the missing file. The problem appeared when
the new directory didn't have the same final path element ("MyLib" in
our example). In these cases, Workbench insisted on finding a file
with the exact relative path "MyLib\mysource.t" - even if you
explicitly selected the new "mysource.t" location, Workbench refused
to accept it, repeatedly popping up the "Missing File" dialog until
you hit Cancel. This has been corrected; Workbench now automatically
drops the relative path prefix in these cases and just looks for the
unadorned source file name.
- In a TADS 3 game, if you used a library (.tl) file in the game,
and the library included multimedia resources, Workbench sometimes
failed to find the resources when running a debugging build. This
happened when the library you included was in a subdirectory of your
main project directory, or a subdirectory of a directory in your
global library path; in these cases, Workbench didn't properly take
into account the relative path to the library's subfolder when looking
for the resources. This has been corrected.
- The Windows HTML Interpreter didn't play back Ogg Vorbis sounds
properly when they were embedded as resources in the .t3/.gam file.
This has been corrected.
Changes in Release HT-12 (TADS 2.5.10/3.0.12)
Released September 15, 2006 - Windows build Win102
This is the TADS 3.0 General Release version.
- Due to a bug in Workbench for Windows, the "Help/User Manuals"
menu command sometimes failed to actually open the manual. The
problem occurred when no other browser windows were open; if any
browser windows were already open, the manual was launched properly.
This has been corrected: the command should now work properly whether
or not any other browser windows are open.
Changes in Release HT-11 (TADS 2.5.10/3.0.11)
Released September 8, 2006 - Windows build Win101
Note: starting with this release, HTML TADS has its own
release numbering, separate from that of the underlying TADS VMs.
TADS 2, TADS 3, and HTML TADS are all essentially on their own
separate release cycles, so the past practice of treating the HTML
TADS version number as equivalent to the underlying VM version numbers
was too confusing. From now on, HTML TADS releases will be identified
by an "HT-n" version number. We're starting this new practice with
HT-11, since this is the 11th public release. In addition, the
Windows build will be identified with its own port-specific build
number, so that any future bug-fix versions that only affect Windows
can be differentiated.
- The Windows HTML interpreter failed to match a parameterized font
name when the name was the last of multiple font names in a <FONT
FACE="x,y,z"> list. This has been corrected.
Changes in version 2.5.10/3.0.10
Released August 17, 2006
- In Workbench for Windows, the debugger incorrectly allowed
evaluating a new expression while the debugger didn't have control
(i.e., while the game program was actively executing). This shouldn't
have been allowed because the current context for evaluation changes
continuously while the game is executing, and as a result attempts to
evaluate expressions at such times could yield unpredictable results.
In certain rare circumstances, this could have caused Workbench itself
to crash. This has been fixed: expression evaluation is now correctly
suspended during game execution. If the user enters a new expression
(into the "watch expression" window, for example) while the game is
executing, Workbench accepts the new entry, but simply leaves the
value part blank until the next time the debugger gains control (by
hitting a breakpoint, for example), at which point the expression is
evaluated in the current context as usual.
- In Workbench for Windows, the New Project Wizard now sets verbose
error messages by default. You can change this by going to the Build
menu, selecting Settings, selecting the Diagnostics tab, and
un-checking the "Verbose error messages" checkbox.
- In Workbench for Windows, if the option "Clear Debug Log when
starting new build" is selected (on the Messages page of the Debugger
Options dialog, accessible from the View menu), the debug log will
not automatically scroll to the bottom as new messages appear.
If a large number of messages are displayed during the build, this
saves you the trouble of manually scrolling the window back to the top
to see the first few error messages, which are almost always the ones
to tackle first.
Changes in version 2.5.9/3.0.9
Released August 29, 2005
- The Windows HTML interpreter recognizes the new "Default" setting
for a game's presentation profile. If a game's GameInfo record uses
the "Default" setting, the Windows interpreter now uses the current
default theme when playing the game. The current default theme is
marked as such in the Themes menu, and the player can change the
default at any time using a new command in that same menu. The player
can also manually set a game to use the "Default" theme by editing the
game's profile on the Game Chest page. Also, if a game doesn't have a
GameInfo record at all, then the interpreter uses the current default
theme for the game. In the past, the interpreter used the Multimedia
theme in these cases.
- On Windows, the default display font for the "TADS-Script"
pseudo-font is now Comic Sans MS (at 11 point). In the past, the
default was Times New Roman; that's obviously not a script-style font,
but it was chosen as the default because there aren't any script fonts
that are guaranteed to be installed on all Windows systems. Comic
Sans is a better default because (a) it actually is a script font, and
(b) it's present on almost every Windows system, since it's
installed as part of Internet Explorer. On those rare systems where
Comic Sans MS isn't available, the operating system will automatically
fall back on the default application font (usually Arial), so even
these systems aren't any worse off with this change.
- The Windows HTML interpreter didn't retain the bold and italic
attributes of the "TADS-Input" pseudo-font when another <FONT>
tag (such as one changing the size or color of the text) was nested
within the <FONT> tag that selected the "TADS-Input" font. This
is now fixed.
- The Windows interpreter no longer shows anything in the status
area at the bottom of the interpreter window when the mouse is
hovering over a hyperlink with an explicitly empty title attribute
(TITLE=""). In the past, the interpreter acted as though the TITLE
attribute wasn't present at all, and displayed the hyperlink's HREF
text. In many cases, the HREF text is just some internal code for the
game's own use, and so isn't meant for the player's eyes. In the
past, the only way to suppress the status area display of the HREF was
to use a non-empty TITLE attribute instead, which supersedes the HREF
text in the status area display. In some cases, though, it's useful
to be able to show nothing at all in the status area for a link.
You can now do that by using TITLE="" in the <A> tag.
- The HTML interpreter didn't properly show TITLE tags when the
mouse was hovering over a hyperlinked image. This now works correctly.
- A bug in the HTML renderer resulted in an incorrect display layout
when a table cell contained nothing besides a nested table, and the
nested table used a background color or image. In these cases, the
background of the nested table was sometimes displayed at an incorrect
location on the screen. (The problem only occurred when the nested
table was the only thing in its cell - if there was anything else in
the cell, even a "\n" or one of the special HTML non-breaking space
characters, the display was correct.) This is now fixed.
- The HTML renderer sometimes gave a nested table too much space in
its enclosing table's layout, leaving unwanted empty space in the
enclosing column. This problem usually only showed up when a table
contained a cell that contained only a nested table. This has been
fixed.
- A bug in the HTML interpreter caused unpredictable beahvior,
including crashing the interpreter, when using animated images within
a banner-API window. The bug usually manifested when the program
deleted a banner window that was displaying an animated image at the
time of the deletion. This has been corrected.
- In the past, the <NOBR> tag didn't always work properly
within tables. Depending on the table's surroundings, <NOBR>
sections within a table sometimes caused incorrect layout of the
table's contents. This is now fixed.
- In some cases, an IMG tag with separate ASRC and/or HSRC images
didn't update the display properly on a click on the image or when the
mouse hovered over the image. This has been corrected.
- On Windows, the inputDialog() function used a fixed size for the
buttons it displayed, so a long name could overflow the space allowed
for the button. This made the dialog confusing, since the label text
was clipped to the button's display size, hiding part of the label.
The dialog now takes the label length into account, and makes the
buttons wider if necessary to accommodate longer labels.
Changes in version 2.5.9/3.0.8
Released September 12, 2004
- The HTML interpreter's table layout rules have changed for cells
that span multiple rows and/or columns. In the past, the interpreter
divided up the width of a multi-column cell evenly over the columns it
spanned, and divided up the height of a multi-row cell evenly over its
rows. This made it difficult to achieve certain effects, because it
tended to add a lot of extra space to rows and columns that would
otherwise have been small. The interpreter now uses a more
sophisticated algorithm described in the
table layout section.
- A bug in the HTML interpreter caused the interpreter to crash, on
rare occasions, when using the Find or Find Next commands. The
problem was tied to unpredictable particulars of memory allocation, so
it was essentially random - it didn't depend in any obvious way on
what game was being played or on what appeared on the screen. This
has now been fixed.
- In the past, clearing a banner window created through the TADS 3
banner API stopped any sounds playing in the main window. This no
longer occurs.
- <SOUND> tags are no longer allowed in banner windows created
through the banner API. Such sound tags were allowed in the past, but
this caused various problems, because all windows effectively shared
the "sound queues" of the main window - that is, all sounds were
effectively coordinated through the main window even when played from
banner windows. Any <SOUND> tags that appear in banner API
windows will now simply be ignored.
- In the HTML interpreter, going back to review a page (with the "go
to previous page" command) incorrectly showed the contents of any
<TITLE> tag on the page as part of the page's text. This no
longer happens.
- The HTML parser is now more tolerant of missing "close tags" (HTML
tags of the form </xxx>). When a close tag is found that
doesn't match the latest open tag, the parser now searches for an
enclosing open tag that matches; if a matching open tag is found, all
of the nested tags are closed. This change generally produces results
closer to what was intended, despite the error in the HTML. In
particular, when a close tag is missing somewhere within a complex,
nested structure like a table or a banner, the change ensures that the
larger structure is still parsed correctly, even though its contents
have a missing close tag.
- A problem in the HTML interpreter occasionally caused
unpredictable behavior, including crashing the interpreter, when TADS
3 banner API windows were used with the "MORE mode" style. The
problem only occurred when the windows were layed out in particular
ways, so it happened only rarely. This has been fixed.
- "https:" has been added to the list of recognized internet
hyperlink prefixes for the <A HREF> tag. (See the <A HREF> documentation
for more details.)
- In the Windows HTML interpreter's "Customize Theme" dialog, in the
"Colors" page, the Status Line color buttons are now disabled when the
"Override game colors" option is selected. When this option is
selected, the Main Text color settings are used for everything, so the
status line text colors can't be specified separately in this case.
Changes in version 2.5.8/3.0.7
Released June 12, 2004
- The HTML interpreter's command history feature (which lets you
recall recent commands to the command line, so that you can edit them
and re-use them) has a couple of enhancements:
- On Windows, the F8 key now acts the same way it does in the DOS
shell: it recalls the most recent prior command that starts with
what's currently on the command line. If you press the key
repeatedly, it recalls in turn each prior command that starts with
that prefix. This handy shortcut lets you recall a complex past
command with just a few keystrokes.
- The command history now omits a command if it's an exact duplicate
of the immediately preceding command. This ensures that the history
doesn't fill up with a run of "WAIT" or "AGAIN" commands, for example.
Note that this only applies to the most recent previous command; so if
you type an alternating sequence of commands (WAIT, AGAIN, WAIT,
AGAIN, etc), for example, the entire sequence will be stored in the
command history.
- Workbench for Windows now correctly handles the various Edit menu
commands (Cut, Copy, Paste, Delete, Undo), and their corresponding
accelerator keys, when editing an expression or value in the "Locals"
or "Watch Expression" windows. In the past, these commands were
ignored.
- The Windows HTML interpreter now understands Ctrl+Insert to mean
"Copy," Shift+Insert to mean "Paste," and Shift+Delete to mean "Cut."
These accelerator keys were standard in the first few versions of
Windows, and while they've long since been deleted from the Windows UI
guidelines, many applications still support them anyway because some
long-time Windows users are accustomed to them. Note that the modern
equivalents are still supported, too, of course - you can still use
Ctrl+C for Copy, Ctrl+V for Paste, and Ctrl+X for Cut.
Changes in version 2.5.8/3.0.6
Interim build 2.5.8/3.0.6q: 5/9/2004
- Due to a bug introduced several releases ago, the Windows HTML
interpreter didn't obey the Ctrl+Left and Ctrl+Right keys, which
should move the caret left and right a word at a time while editing a
command line. This bug has been fixed, so the word-at-a-time keys now
work again.
Interim build 2.5.8/3.0.6p: 4/25/2004
- In the past, the HTML interpreter didn't stop with a MORE prompt
in a banner window if a long block of text was displayed, the banner
was cleared, and then another long block of text was displayed. This
could be seen, for example, in some "chapter list" menus in TADS 3
games, by stepping through a series of long chapters. This has been
corrected.
- The HTML interpreter now accepts .JPE as a valid suffix for JPEG
image resources. The suffixes .JPG and .JPEG are also still
recognized, of course.
- The Windows HTML interpreter did not properly initialize the size
of a new banner window that didn't yet have a size explicitly set or
any text displayed, occasionally causing a new banner window to appear
at a random size if the game didn't explicitly set the size soon after
creation. This has been corrected; a new banner window is initially
set to zero width and height, ensuring that it won't be visible until
the game finishes setting it up properly.
Interim build 2.5.8/3.0.6o: 3/14/2004
- A problem with vertical spacing after a command line, caused by a
change in 3.0.6n, has been corrected. In 3.0.6n, a &zwnbsp;
character was added after each command line. This proved to be a
problem if a "\b" sequence was displayed after a command line, because
it caused two blank lines to appear in the display window (the
extra line was the one containing the &zwnbsp; character). So,
the &zwnbsp; has been removed. In its place, a refinement of the
pre-3.0.6n mechanism is now used: after each command input line, and
only after a command input line, the interpreter simply adds an
extra line's worth of scrolling height to the window. This has the
desired effect of scrolling up the window one line after each user
input, which provides the user with immediate visual feedback that the
command line has been accepted, while eliminating the undesirable side
effects of both the 3.0.6n change and the pre-3.0.6n mechanism.
- The HTML interpreter now treats multiple calls to the T3 function
inputLineCancel() as significant. This is important in cases where
several calls are made with the "reset" parameter set to nil, and
later a call is made with "reset" set to true. In the past, calls
were ignored if an interrupted input was not still pending, so only
the first call after an interrupted input was obeyed. This meant that
it was impossible to reset the input buffer if the input had already
been canceled but not reset. This has been corrected.
- TADS 3 Workbench for Windows now inherits the TADSLIB environment
variable, if set, and passes it along to the compiler. This allows
you to add directories to the library file search path globally. The
library folder list you specify in the Workbench options comes before
the TADSLIB environment variable in the search order; that is, the
compiler will first look for a library file in each folder specified
in the Workbench options, and then will turn to the folders listed in
the TADSLIB environment variable.
Interim build 2.5.8/3.0.6n: 3/6/2004
- Workbench for Windows now remembers whether or not the source file
window has been maximized (within the main work area in the Workbench
window), and restores the same status when the project is reloaded in
future sessions.
- Workbench for Windows now stores the debugging image file name
using a directory path relative to the project directory, if possible,
even if you enter the filename with an absolute path in the build
settings dialog. This makes it easier to move the project from one
machine to another, or relocate it to a different folder on the same
machine. (In the past, this filename was stored with a relative path
in most cases, but Workbench didn't force it to a relative path if you
manually entered an absolute path. Workbench now automatically
changes the filename to use a relative path even if you enter an
absolute path.)
- In the past, the HTML interpreter always showed some extra blank
space below the last line of text if the last line ended in some sort
of line-breaking markup sequence (such as a paragraph break, or the
end of a <TABLE> tag). This was intentional, to provide better
feedback to the player when the player pressed the Enter key at the
end of a command line, but had the undesirable side effect of leaving
extra blank space when merely pausing for input. The extra space is
no longer shown. If you want to show extra space at the bottom of a
display when pausing, you can do so by displaying line breaks to the
desired height, then displaying a "&zwnbsp;" character (a
zero-width non-breaking space), which has no visual appearance of its
own but forces the HTML renderer to immediately show all of the extra
space preceding the character. The interpreter itself now uses this
trick to achieve the effect that was formerly achieved with the
now-defunct extra vertical spacing.
- In the Windows HTML interpreter, the hyperlinks in the "About"
box are now shown even when the preferences are set to hide
hyperlinks. Similarly, the hyperlink to return to the Game Chest
page after a game has ended is now shown as a hyperlink, regardless
of the preference settings. (In the past, these controls followed
the preference settings for hyperlink visibility; since they're part
of the interpreter user interface, not part of the game text, it
makes more sense for these controls to override the preference
settings and show as hyperlinks unconditionally.)
- The HTML renderer sometimes got the margins wrong on the initial
layout if a "floating" image was at or near the start of the layout.
The correct margins displayed on subsequent redraws in these cases,
but the initial layout sometimes had negative margins, which left
some text partially outside the main window. This has been corrected.
- In the past, TADS 3 games compiled into Windows executables (.exe
files) didn't load bundled multimedia resources (images, sounds, etc.)
properly. This is now fixed.
Interim build 2.5.8/3.0.6m: 11/15/2003
- The HTML interpreter now supports the BACKGROUND attribute in
TABLE, TH, and TD tags. This attribute sets the background image for
a table or a cell within a table. If the image is larger than the
bounding rectangle of the table or cell, the interpreter clips the
image to the table or cell size; if the image is smaller than the
bounding rectangle, the interpreter "tiles" the image, drawing as
many copies of the image across the width and/or down the height of
the bounding rectangle as are needed to fill the space.
- In Workbench for Windows, if the game program was waiting for a
keystroke (via inputKey() or the like), and you tried to terminate
the program (by starting a new build, for example), Workbench got
stuck in a loop trying to terminate the game. The game program will
be terminate correctly now.
- The Windows HTML interpreter's "mute" button on the toolbar now
uses two icons, one for when sounds are on and one for when sounds
are muted, showing the current status. The old icon looked too
much like a status icon indicating that the sound was always mute.
- The HTML parser now accepts closing </BODY> tags. Since
the special TADS dialect of HTML doesn't treat <BODY> as a
container, it's never necessary to include closing </BODY>
tags, and if you do, they interpreter simply ignores them. In the
past, though, the parser didn't accept </BODY> tags at all (it
flagged an error), which caused some confusion among people who
already know standard HTML, where <BODY> is a container.
- In Workbench for Windows, an incompatibility with Windows ME
caused Workbench to crash under certain obscure conditions. The
crash was due to a Windows API problem that appears to exist only
in ME, and happened when using the "new project wizard" to create
a new game, and then only when the Debug Log was the only window
open. This problem has been corrected.
- The HTML interpreter had a problem that sometimes prevented a
game's bundled resources from being loaded properly when several games
were run in sequence in a single interpreter session. This is now
fixed.
- A bug in the HTML renderer caused whitespace characters following
a <Q> start or end tag to be ignored when a character entity (an
"&" sequence) immediately preceded the tag. (This is a pretty
rare combination of markups, so this hardly ever showed up in
practice, but it's obviously perfectly valid.) The whitespace is now
properly retained.
Interim build 2.5.8/3.0.6k: 8/17/2003
- Workbench for Windows now automatically converts any forward-slash
characters ('/') to backslashes in filenames entered into the Build
Settings dialog. (In the past, using forward slashes as path
delimiters was allowed, but it caused odd behavior in certain cases,
because Workbench treated forward slashes as distinct from backslashes
for the purposes of comparing filenames and paths.)
- The HTML interpreter froze up if a table was displayed that contained
no columns (no <TD> tags), but had a WIDTH setting for the table
itself. This type of table is usually ill-formed anyway, in that the
lack of any columns is probably due to missing table structure tags,
but the interpreter will now gracefully accept such tables.
- The Windows HTML interpreter is a little better at deferring redraws
when clearing the screen. This eliminates flicker in some cases,
especially when a banner window is being added or removed right before
or after the screen is cleared.
- The Windows HTML interpreter is better at handling MORE scrolling
in very small windows. In the past, if a window was very small
(around five or ten pixels high, for example), pressing the space bar
could sometimes actually make the window scroll backwards. This has
been corrected; even very small windows will handle MORE scrolling
properly now.
- A bug in the HTML interpreter caused occasional drawing problems
when first displaying certain tables. When a table had a large
"cellpadding" or "cellspacing" value, one or two rows of pixels were
sometimes not drawn when the table was first shown (but did redraw
properly on subsequent refreshes, such as resizing the window).
This is now fixed.
- A bug in Workbench for Windows caused a breakpoint marker (the
little red circle in the left margin of a source file) to appear in
the first source window when a global breakpoint existed. The
spurious breakpoint marker will no longer appear.
- A bug in Workbench for Windows caused the program to open extra
file handles open each time the application was activated. This has
been corrected.
Interim build 2.5.8/3.0.6j: 8/2/2003
- Workbench for Windows now uses different window icons for the main
Workbench window and for the game window, so that it's easier to tell
which is which on the Windows taskbar or Alt-Tab window selector.
- Workbench for Windows has a new command (on the toolbar and in the
Build menu) that terminates a build in progress. This is handy if you
started a build accidentally and don't want to wait for it to
complete. Note that interrupting a build can sometimes leave
intermediate files (such as symbol and object files) incomplete, so
if you interrupt a build, you might have to subsequently perform a
full build to make sure everything is rebuilt properly.
- Workbench for Windows now offers the option of automatically
clearing the Debug Log window before each new build. The option is on
the Messages page of the options dialog ("View" menu, "Options..."
command). Some people like to start each new build with an empty
Debug Log window, to eliminate any clutter from past builds.
- TADS 3 Workbench for Windows now automatically clears the old list
of Include files from the Project window when you use the "Scan for
Includes" command. This ensures that the Include list contains all of
the actual header files used in the project, and only those header
files.
- The "New Project" wizard in TADS 3 Workbench for Windows now
offers an option to create a bare-bones project that doesn't include
the standard TADS 3 adventure library (adv3). This is convenient
for creating special-purpose projects that don't require the full
adventure library.
- In the Windows HTML interpreter, if the window was scrolled to the
right, then resized so that the scrollbar wasn't needed any longer,
then scrolled back all the way to the left, the horizontal scrollbar
didn't always disappear as it should. It should now disappear
reliably in these cases.
- A bug caused Workbench for Windows to crash when compiling a game,
if the compiler wrote an extremely long message to the log window.
This has been corrected.
- A bug in the HTML interpreter caused a crash when cutting and
pasting long bits of text under certain circumstances. This is now
fixed.
- The HTML interpreter now uses the <BODY> tag's BGCOLOR
attribute even if a <BACKGROUND> image is also set. This
ensures that the background color will show through any transparent
sections of the background image.
- In the Windows HTML interpreter, right-clicking on a hyperlink
will no longer follow the link; right-clicking now simply brings up
normal context menu.
- In the Windows HTML interpreter, previous page viewing is more
functional and flexible. The mouse wheel now works properly, you
can use the Find command, and the window is properly refreshed if
you change themes while viewing a past page.
- In Workbench for Windows, some of the keyboard accelerators
(such as Ctrl+C for Copy, or Ctrl+Q for Quit) didn't work properly
in the game window. This has been corrected.
- In Workbench for Windows, the "Windows" menu wasn't kept properly
updated when source windows were maximized (so that the source windows
took up the entire MDI "client area"). This is now fixed.
- A bug in the HTML interpreter occasionally left banner windows
only partially redrawn; this was particularly apparent with things
like hint menus. The problem has been corrected.
- In Workbench for Windows, the expression evaluation windows now
accept a few more keystrokes, to make the keyboard interface a little
more convenient. The Page Up and Down keys now scroll the window a
page at a time, the Home key moves to the first row, and the End key
moves to the last row. In addition, in the "watch" window, when no
row is selected, starting to type an expression (or pressing Enter or
F2) will automatically scroll to and select the empty last row; this
saves a mouse click in the common case that you just want to add a new
expression to the list when no other expression is selected.
Interim build 2.5.8/3.0.6i: 6/15/2003
- Due to a bug in a change made in the previous interim build, MORE
mode didn't work properly in the Windows HTML interpreter. MORE mode
works correctly again.
- Workbench for Windows didn't allow re-running the game if, in the
course of running the game, a file selector dialog was used to navigate
to a different directory. (On re-running, Workbench displayed an error
dialog saying "VM Error: image file not found.") This is now fixed.
- The Windows HTML interpreter crashed on startup if the Game Chest
file, as selected in the interpreter options, didn't exist. This crash
has been fixed.
- In the Windows HTML interpreter, if you change the Game Chest
file setting in the options dialog, and the new file you select
doesn't already exist, the interpreter now automatically saves the
current Game Chest contents to the new file. In the past, you had to
copy your old file manually. If the new file you select does
already exist, the interpreter will simply load the new file rather
than overwrite it.
Interim build 2.5.8/3.0.6h: 6/7/2003
- The Windows HTML interpreter's user interface for setting display
options (such as fonts and colors) has been slightly reorganized to
make it more intuitive and easier to navigate. Some of the changes:
- The term "Theme" is now used instead of "Profile"; this
is more consistent with the prevailing Windows terminology.
- The visual settings - fonts, colors, "MORE" style, media type
enabling - have been separated into their own dialog, which can be
accessed directly with the "Customize Theme" command on the new
"Themes" menu, as well as from a toolbar button. This dialog is now
called "Customize Theme," to make it more obvious that all of these
visual settings are part of the current theme.
- The main options dialog no longer has the tabs for visual
settings, but it has a new tab, "Appearance." This tab lets you
select the current visual theme, create new themes, and delete themes.
This also has a button to open the visual settings dialog to customize
the currently selected theme, and a button to reset the current theme
to its "factory defaults" (but this button only works for the standard
pre-defined themes, since only the built-in themes have defaults).
The old dialog tab arrangement mixed the settings that are part of the
visual theme and those that are simply global option settings; the new
arrangement keeps all of the visual theme settings together in a
separate dialog.
- A new "Themes" menu has been added, and the theme-related
items that were previously in the "View" menu have been moved to the
new menu instead. This change is intended to make it more obvious
which items are theme-related by grouping them on a single menu.
- Several of the items formerly on the "View" menu (graphics,
sound, music, link display mode) have been removed from the menu and
added instead to the new "Media" page of the "Customize Theme" dialog.
These options are all part of the theme; moving them to the dialog
makes this much more obvious in the user interface. Most users hardly
ever change these settings, so it seems unlikely that the extra step
needed to open the dialog will noticeably inconvenience anyone.
- The Windows HTML interpreter no longer uses the F5 key to
toggle the hyperlink display mode. Some users found this keyboard
shortcut to be too convenient, in it was too easy to hit the
key unintentionally, resulting in an unexpected change in the link
display mode; this was especially a problem for Workbench users, since
the Workbench debugger uses F5 as the "go" button.
- A new "Mute Sound" command (on the View menu and on the
toolbar) lets you turn off all sound output. This doesn't actually
disable playback of audio media types; it merely mutes the speakers
temporarily. Playback or music and sound effects proceeds while
muting is on, but with the volume control effectively turned all the
way down. (In contrast, turning off sound or music on the "Media" tab
in the Customize Theme dialog makes the interpreter behave as though
it simply doesn't support the disabled media types. This is visible
to games when they query the interpreter capabilities. Muting is not
visible to games.)
- In the Windows interpreter, the list of recent games shown in the
"File" menu now shows the title (instead of the filename) of each game
that you've entered into your Game Chest favorites. Recent games that
aren't in your Game Chest favorites list are still listed by filename.
- A bug in Workbench for Windows caused the "build for release"
process to fail if the debug game file in the build settings
was specified as going in a folder other than the main project
folder (the one containing the .t3m file). (Yes, you read that
right: the location of the debug game file caused problems creating
the release game file.) This has been corrected; the release build
should work properly now for any valid output directory settings.
- A bug in Workbench for Windows caused a spurious error code to be
displayed in the release build process for the command that's included
in the build sequence to delete the temporary directory created for
the intermediate files created during the release build. The error
code display was itself the error; the directory removal actually
worked correctly, but Workbench showed an error anyway. The spurious
error has been removed (but any actual errors that occur will
still be displayed, of course).
- On Windows, a bug in the preference system caused preference
settings to be saved incorrectly in certain situations. If more than
one HTML TADS interpreter was running simultaneously, of if both the
normal interpreter and Workbench were running simultaneously, and the
games weren't all using the same profile (for example, if one game was
using the standard "Multimedia" profile, and another was using "Plain
Text"), then it was possible for the font and color settings of one of
the profiles to be incorrectly saved over the settings for the other
profile. For example, it was possible to make the Multimedia profile
take on the settings of the Plain Text profile. These settings are
saved in the registry, so once the wrong settings were saved, they
stayed wrong until the user manually changed them back. This
problem has been corrected; multiple interpreter windows won't
interfere with one another (or with Workbench) any longer.
- When multiple HTML TADS interpreters are running simultaneously,
if you make changes to the option settings in one interpreter window,
the other running copies of the interpreter will automatically
update with the same changes.
- Workbench for Windows now automatically selects the default
"Multimedia" preferences profile on startup. In the past, the
debugger simply used whatever profile was active in the game most
recently played.
- A problem in the Windows HTML interpreter caused crashes under
certain very rare conditions. In particular, if a game asked the
interpreter (via the systemInfo() built-in function) if it supports
any of the digital audio formats, and the user had previously closed
the interpreter window (so the game was in the process of being
terminated, but hadn't yet exited), the crash occurred. This has
been corrected.
- Due to a bug, text-grid windows weren't being redrawn immediately
after being cleared. This has been corrected.
- In the HTML interpreter, if a banner window was initially created
with a size of zero, the interpreter showed the banner with an arbitrary
small height (about 20 pixels) until the program explicitly set the
window's size. New windows are now correctly created with zero height
instead.
- The Author's Kit uninstaller for Windows no longer deletes your
global Workbench configuration file; this is a file called
"htmltdb3.t3c", located in the main Author's Kit install directory.
The uninstaller leaves this file intact, because it contains option
settings for Workbench, such as the font settings for source files.
If you're uninstalling in preparation for installing a new version,
and you install the new version in the same directory as the previous
version you're uninstalling, this change will ensure that your option
settings are retained. However, if you're uninstalling the Author's
Kit permanently, this change means that you'll have to manually delete
the "htmltdb3.t3c" file and the Author's Kit directory.
- A problem in the interpreter caused link underlines to fail to
draw properly in rare cases. In particular, in some fonts, a link
that appeared as the very last thing displayed sometimes was missing
its underline, at least until the window was drawn again for some
reason (due to resizing, for example). Links should now draw
correctly all the time.
- In the past, the HTML interpreter didn't display typographical
quotes for <Q> tags (using regular ASCII "straight" quotes
instead) under certain localization conditions. For example, the
Windows interpreter didn't display typographical quotes on systems
localized to use a character set other than Windows US/Western Europe
(code page 1252). The interpreter is now more flexible; it should now
display typographical quotes on a localized machine as long as the
machine has the proper character sets installed. (For Windows
machines, this means that typographical quotes will be displayed
regardless of the default system character set, as long as a cp1252
version of the selected font is also installed.)
- The Windows HTML interpreter now pays attention to the command
script MORE prompt mode when playing back a command script (using
the "@" syntax in TADS 2, or the new REPLAY command in TADS 3).
In the past, the interpreter always showed MORE prompts, even when
the game requested that the prompts be skipped.
Interim build 2.5.8/3.0.6g: 4/12/2003
- TADS 3 Workbench for Windows now lets you set the filename of the
game file (.t3) compiled for debugging. In the past, this filename
was always derived from the name of the project (.t3m) file, so it
couldn't be set independently. The Build Settings dialog now allows
you to change the filename. Note that this means that you are now
free to use your project name for the release version of the game
file, as long as you choose another name for the debug version. The
New Project wizard takes advantage of this change: it sets the
default debug game file to reside in a .\debug subfolder of the
project folder (which the wizard creates for you automatically), and
it sets the filename for the release build to use the same name as
the project. (In the old scheme, since the project name was always
reserved for the debug build, the release build had to have some
other name, which by default used the project name plus a "_rls"
suffix. Most people didn't want to actually distribute the released
version with the "_rls" suffix on its name, so this convention
created a manual file renaming step for most people when distributing
their games. The new scheme saves you this trouble by letting you
use any name you want for the release file. The only restriction is
that the debug and release builds must have different names from one
another.)
- The Windows HTML interpreter now draws thick table borders with
diagonal joins at the corners. (In the past, the corner joins were
squared, which didn't look great with border thicknesses greater
than one pixel.)
- Workbench for Windows has a couple of new text editor interface
parameters. First, you can now include the code "%c" to pass the
target column number to your text editor. Second, the "%n" (line
number) and "%c" (column number) parameters can be qualified with an
inserted "0" (hence "%0n" and "%0c") to indicate that the line and/or
column number should be passed to the editor using a 0 base - you
should use this qualifier if your editor expects 0 for the first line
(or column), 1 for the second, and so on. The Epsilon
auto-configuration has been updated to take advantage of these new
features.
- The Windows HTML interpreter has a new command-line option,
-noalphablend, that lets you explicitly turn off alpha-blending
support for semi-transparent images. By default, alpha blending
will be used when it's supported by the underlying platform (it's
supported on Windows ME, 2000, and XP). It might rarely be
desirable to turn it off despite system support, such as when
the system hardware is too slow with alpha blending enabled, or
(more likely) if the local implementation is buggy, as it appears
to be in WineX. Attention WineX users: WineX reportedly
crashes when alpha blending is enabled, apparently due to a bug in
the WineX graphics code. If HTML TADS crashes when you start it up
on WineX, try running with the -noalphablend option.
- The Windows HTML interpreter handled the "Escape" key incorrectly
when running some games. In particular, games that read individual
keystrokes received two copies of each escape key press. This has
been corrected.
- The HTML interpreter did not correctly calculate the contribution
of some of the typographical spaces (" " and the like) to
the width needs of a table. This sometimes caused unnecessary line
wrapping in tables containing these characters. The renderer now
calculates the table widths of the typographical spaces correctly.
- The Windows HTML interpreters are a little smoother in drawing
the window when the game has a pause for computation right after
displaying some text that results in scrolling. In the past, the
interpreter left a little bit of the old text at the bottom of the
window, which created a slightly jumpy appearance. The interpreter
now updates the exposed area more quickly after scrolling, reducing
the apparent flashing.
Interim build 2.5.8/3.0.6f: 3/23/2003
This version has no changes related to HTML TADS.
Interim build 2.5.8/3.0.6e: 3/16/2003
- TADS 3 Workbench for Windows now allows only project makefiles
(.t3m files) to be opened as projects; source files and executable
(.t3) files are no longer openable as projects. This doesn't affect
TADS 2 Workbench. (Opening source and executable files in TADS 3
Workbench was an historical carry-over from TADS 2, where there isn't
a formal project file, but rather a "debugger configuration" file that
Workbench maintains alongside a .gam file. In TADS 3, the project
makefile is an important part of each project, regardless of whether
the project was created with Workbench or with the command-line
compiler or other tools. You can create project files manually with a
text editor, or you can let Workbench create them for you using the
New Project command on the File menu.)
- Workbench for Windows now knows how to auto-configure the
Imaginate program
editor. If you have Imaginate installed on your system, Workbench will
include it in the list of known editors, and will automatically set up
the necessary command options to invoke Imaginate when you want to edit
a source file. Open the Options dialog with the View/Options menu, select
the Editor tab, and click the "Auto Config" button to bring up the list
of known editors.
- In the past, TADS 3 games sometimes caused the Windows HTML TADS
interpreter to crash if the interpreter window was closed while the
game was waiting at a "More" prompt. This has been fixed.
Interim build 2.5.8/3.0.6d: 2/23/2003
- Fixed a problem that prevented TADS 3 games from using the
<ABOUTBOX> tag. The HTML parser was overly zealous in
disallowing <BANNER> tags in TADS 3 games, and incorrectly
applied this prohibition to <ABOUTBOX> tags as well. This
has been corrected.
- The HTML interpreter didn't always properly calculate the range
(or sometimes even the existence) of the horizontal scrollbar when a
<TABLE> exceeded the width of the window. Tables are now
properly included in figuring the range of horizontal scrolling.
- The Windows HTML interpreter uses a slightly different color
scheme than it did in the past for displaying table borders. The top
and left sides of each table border are now shown in the "button face"
color (as set in the Windows system color scheme); in the past they
were shown in the "highlight" color. This improves upon the old color
scheme in that the highlight color is the same as the default system
window background color in most Windows color schemes, so these
portions of the table border were effectively invisible in many cases.
This change makes borders visible with typical system settings.
- The HTML renderer's table layout algorithm has been improved to
make table layout more controllable. There are two main changes, both
relating to the way the renderer decides how wide to make the columns
in a table. First, when the renderer is choosing the overall width of
a table, it tries to ensure that the table will be wide enough that
any columns specified with percentage widths can be laid out with the
requested percentage. Second, when a column's width is specified in
pixels, the renderer tries to match the requested width as closely as
possible; in the past, the renderer used width specifications as hints
but didn't attempt to match the requests exactly. These changes
should have minimal impact on existing games; the old behavior didn't
provide much control over column widths, so it's unlikely that any
games were able to achieve particular effects that would be affected
by the changes. A more detailed description of the new layout
algorithm can be found in the Table
Layout Rules documentation.
- In the Windows HTML interpreter, the keyboard event processing had
a problem that prevented the end-of-file indication from being
returned properly to TADS intrinsics in certain cases. This problem
made it impossible in such cases for the game program to detect that
the user intended to terminate the game by closing the main HTML TADS
application window. This has been corrected.
- The HTML interpreter incorrectly calculated the width of banner
windows under certain circumstances. In particular, if a vertical
(left or right) banner contained only a table, the full width of the
table wasn't properly counted to determine the natural width of the
banner. This has been corrected.
- The interpreter had a problem that caused it to crash if an animated
image (an MNG) was used as the background of a BODY tag. (The crash only
occurred if the window was subsequently cleared.) This has been corrected.
- A problem in the HTML parser caused character entities ("&"
sequences) to be displayed incorrectly in rare cases. The problem had
to do with buffering of text output at higher layers of the system,
and only showed up if an entity happened to be split up due to a
buffer flush. This was most likely to occur when displaying large
amounts of text at once, such as in a room description. This has
been fixed; entities should display properly regardless of any
higher-level buffering.
Interim build 2.5.8/3.0.6c: 2/1/2003
- The Windows HTML interpreter now adds an appropriate default
extension when the TADS 2 askfile() function or TADS 3 inputFile()
function is used to select the name of a file to write. The default
extension depends on the type of file that the program requests.
(In the past, the interpreter didn't add a default extension except
for saved-game files. The lack of an extension was inconsistent
with the behavior of askfile/inputFile on searching for an existing
file to open, since the dialog by default only shows files matching
the appropriate extension for the file type.) This change is limited to
the Windows interpreter; it doesn't affect any other platforms.
- A bug in the HTML interpreter occasionally caused banners created
with the <BANNER> tag to ignore an explicit WIDTH attribute.
The behavior was unpredictable, and varied from session to session
with the same game program. This has been corrected; the WIDTH
attribute should now be reliably obeyed.
- The Windows HTML interpreter no longer accepts the <:BANNER>
tag when running a TADS 3 game. TADS 3 games must use the new
banner API instead of using <BANNER>tags. (The banner API is
more powerful than the <BANNER> tag, and works not only on
HTML interpreters but on many text-only interpreters as well. The
new API cannot interoperate with the original tag-based banner
mechanism, though, so to avoid confusion, the tag-based banners
simply are not allowed in TADS 3 programs. If a TADS 3 program
attempts to use a <BANNER> tag, the interpreter will show
a message in the debug message window, if there is one, and will
otherwise ignore the banner and its contents.)
- Fixed a problem that prevented multi-byte characters (primarily
used in East Asian languages) from displaying under some
circumstances. (This problem was introduced in the 12/15/2002
interim build, and has now been corrected.)
Interim build 2.5.8/3.0.6b: 12/15/2002
- The HTML renderer now provides the game with much better control
over the way lines are broken during the text layout process. In the
past, the formatter used simple word wrapping. By default, the line
breaking process acts the same as it used to, but several new features
let the game override the default behavior. These changes are
described in detail in the Line Breaking
chapter of the documentation, but here's a summary:
- A new HTML tag is now supported: <WRAP> tag, which controls
the line breaking method. <WRAP WORD> selects the default mode,
word-wrapping mode, which breaks lines only at word boundaries
(defined as spaces and hyphens). <WRAP CHAR> selects
character-wrapping mode, which breaks lines between any two
characters.
- A new markup, the "zero-width non-breaking space," written as
"&zwnbsp;", lets the game specify a point at which text cannot
be broken, even if the line breaking rules would otherwise allow it.
- A new markup, the "zero-width space," written as "&zwsp;",
lets the game specify a point at which the formatter can insert a
line break, even if the line breaking rules would otherwise forbid it.
- The soft hyphen markup, "­", is now recognized. This
lets the game specify a point at which the formatter can optionally
insert a line break by hyphenating a word. If the formatter does
elect to break at a soft hyphen, the soft hyphen will be displayed
as a regular hyphen; otherwise, a soft hyphen is invisible.
- Several new "typographical space" markups give the game fine
control over spacing.
Interim build 2.5.8/3.0.6a: 11/23/2002
- Whitespace between a <BANNER> tag and the first text within
the banner's body is no longer significant. In the past, if any whitespace
appeared between a <BANNER> tag and the first text in the body of
the banner, the banner was displayed with a leading space. Leading
whitespace is now ignored, so that a banner's body is treated as
starting with a new paragraph. (If a game explicitly wants to show
leading whitespace in a banner, it can use the sequence to
add a non-breaking space, which the HTML renderer will display even
where ordinary whitespace is suppressed.)
- A problem in the Windows HTML interpreter caused the
main window's size and placement to be forgotten when the interpreter
application was minimized and then closed from the task bar. The
interpreter now correctly remembers its size as it was before being
minimized.
- A problem in the Windows interpreter caused music
playback to stop whenever the interpreter discarded the oldest text in
the game window. (The interpreter periodically discards the oldest
text to save memory, according to the "Text Memory Limit" setting in
the options dialog.) This is now fixed.
- A problem in the Windows interpreter caused the "Profile" list (in
the Profiles submenu of the Edit menu, and in the drop-down menu in
the profile button on the toolbar) to be shown with no active profile
selected in some cases. If the game had a Game Chest entry, and the
entry's profile name setting was left completely empty, no profile was
selected in the profile menu. This is now fixed; games with empty
Game Chest profile settings will use the "Multimedia" profile by
default, the same as a game whose Game Chest profile setting refers
to any other non-existent profile name.
- In the Windows interpreter, it is now less visually intrusive when
old text is discarded to save memory. In past versions, it was obvious
that the window was being refreshed at these times. The interpreter
is now a little better at hiding these updates, so they should usually
be less noticeable now. When discarding old text, the interpreter must
recalculate the layout of all of the remaining text in the window, to
account for any change in paragraph flow or other layout features that
result from discarding the old text. In most cases, the new layout
matches the old layout for all of the text visible in the window, since
the window usually shows the most recent text, which is the least likely
to be affected by discarding the oldest text; the interpreter tries to
take advantage of this to make the layout recalculation invisible.
- Fixed a problem that caused output to be hidden when the game
opened a <TABLE> tag but never got around to closing it before
reading a command line. This sort of thing isn't legal, but the
interpreter didn't recover very gracefully from such input. The
interpreter now automatically closes any <TABLE> tags left open
when starting a new command line, ensuring that the HTML formatter
won't get stuck waiting for a </TABLE> that the game
accidentally omits.
Changes in version 2.5.7
Released September 22, 2002
- The Windows interpreter now keeps the display option settings
(fonts, colors, and so on) in a "Profile," which is simply a named
group of saved settings. Profiles let you switch all of your display
settings at once, so they're especially convenient if you like to use
one display style with some games, and a different display style with
other games. Here's how profiles work:
- At any given time, there's a current profile;
you can change the current profile using the "Profiles" command on
the "Edit" menu (there's also a toolbar button that does the same
thing). Whenever you make changes to your display settings with
the Options dialog, the settings are saved with the current profile.
- Initially, the system automatically creates two profiles for you:
Multimedia, and Plain Text. The system sets up these profiles with
default settings, but you can customize the settings with the Options
dialog any way you like.
- You can also create new profiles of your
own, using the "Manage Profiles" command (part of the "Profiles"
submenu of the "Edit" menu, and also a toolbar button). Whenever
you create a new profile, its initial settings will be copied from
the current profile.
- The interpreter remembers which profile was last used with
each game, and automatically switches to the same profile each time
you play the game. For games you've added to your Game Chest,
you can change the profile setting for each game with the "Edit"
link displayed next to the game's listing on the Game Chest page.
The interpreter also remembers which profile was last used with the
Game Chest page itself.
- When you load a game for the first time, the interpreter checks
to see if the game includes GameInfo metadata with a
"PresentationProfile" setting. If the game does include that setting,
the interpreter uses the setting to select an initial profile for the
game, if there's a profile with the same name. This gives the game's
author a way to recommend a display style for the game.
- The Windows HTML interpreter now allows you to set the size of
each font individually in the Preferences dialog. Sometimes, two
different fonts don't look quite right together when displayed at the
same nominal point size; this new feature lets you adjust the
individual point sizes of the fonts you're using to give a uniform
visual size. On the Fonts tab of the dialog, each font now has a
drop-down list that lets you specify the point size for the font.
Note that this sets the "base size" for the font; whenever the game
selects larger and smaller sizes via its formatting commands, the
sizes are relative to this base size. In addition, if you set the
"Text Size" item on the "View" menu in the interpreter to a size other
than "Medium," all of the fonts will be scaled up or down from the
base size you set in the preferences. Whenever the game displays a
font by name, rather than using one of the fonts you select in the
Preferences dialog, the interpreter will use the point size of the
Main Game Font as the base size of the named font.
- The Windows HTML interpreter has a new page of Game Chest options
in the Preferences dialog.
- You can now select the location of the
Game Chest database file, GameChest.txt, which stores your list of
game and web site links. The file's default location is the "My
Documents" folder (in a "TADS" subfolder), but you can use this new
option to set a custom location. Note that if you change this option,
you'll have to manually move the GameChest.txt file to the new location
you choose, if you want to use the original copy; if you don't, Game
Chest will create an empty new GameChest.txt file for you. Also, you'll
have to change this setting again if you re-install the Player Kit in
the future.
- You can select a custom picture (using a PNG or JPEG image file)
for the background image displayed on the Game Chest page, or you can
choose to use no image at all.
- The new BODY tag attribute HLINK allows you to specify the color
of hyperlinked text for "hovering," which means that the mouse cursor
is positioned over the hyperlink but the mouse button isn't being held
down. Note that not all systems use a special appearance for hovering
over a hyperlink, and even on systems that do, the special appearance
may be controllable through user preferences (it is on Windows, for
example); this attribute won't have any effect in these cases.
- The Windows HTML interpreter no longer uses full alpha blending
when running on Windows 98; only simple transparency is now used on
Win98. This change was made because the alpha blending support built
in to the operating system has some serious flaws in Windows 98; these
OS bugs made it impossible for the TADS renderer to work reliably.
This change does not affect any other Windows platforms: full alpha
blending is still supported on Windows ME, 2000, or XP.
(Thanks to Lukas Fichtinger for point out this problem.)
- A bug in Workbench for Windows caused Workbench to crash
occasionally after performing build command steps that produced no
output. This has bee corrected.
- A bug in Workbench for Windows caused sporadic crashes when making
changes to source window formatting settings from in the Options
dialog. This should no longer occur.
- Due to a bug in the combined TADS 2/3 Windows interpreter,
double-clicking a saved game file from a Windows Explorer desktop
window did not correctly start and restore the saved game. This is
now fixed.
- A bug in the Windows interpreter caused the game to stop responding
in some cases where the game used the morePrompt() function to wait for
the user to acknowledge a display. This has been corrected.
- Due to a bug, the Windows HTML interpreter's Game Chest was unable
to run a game listed in the "favorites" list when the game's directory
path contained an apostrophe ("'") character. This has been fixed;
Game Chest can launch a game from any valid path now.
- The Windows HTML interpreter's Game Chest showed some accented
characters incorrectly when the characters were taken from GameInfo
metadata embedded in TADS 2 games, and the GameInfo files were
prepared using UTF-8 enabled text editors. This has been corrected.
(Note that you might need to remove and re-add Game chest entries for
any games with accented characters shown incorrectly, because the
Game Chest will have already stored in the wrong accented characters
in its configuration file. If you remove and re-add the entries,
Game Chest will interpret the characters correctly when it stores
the new entries.)
- The Windows HTML interpreter's Game Chest froze up when attempting
to read GameInfo data stored in certain invalid formats (this showed
up in particular when the GameInfo file was stored in the UCS-2 Unicode
encoding). This has been corrected; the interpreter now tolerates
invalid formats and shows a warning dialog when it detects one.
(Thanks to Lukas Fichtinger for catching this.)
- Several of the third-party libraries that the Windows interpreter
uses have released updates recently, so the interpreter has been
updated to use the latest releases, as of this writing: MNG is now
supported through mnglib 1.0.4 and zlib 1.1.4; and Ogg Vorbis playback
now uses libvorbis 1.0.
- The HTML parser is now more tolerant of text written piecewise.
In the past, if the game wrote out a partially-completed tag and then
flushed the output stream or forced a redraw, the parser saw only the
incomplete tag, and flagged an error. The parser now defers parsing
an incomplete tag, even after an explicit buffer flush, saving the
partial tag for later completion. The parser has a limit of 4k bytes
for partially-flushed tags; if the source text of an incomplete tag
exceeds this limit, the parser will assume the tag will never be
completed and issue an error. This change will be mostly invisible to
games; the only noticeable difference should be that the parser will
gracefully handle unusual cases where a game flushes the output buffer
explicitly in the midst of writing a tag. (Note this type of
situation doesn't arise very often in normal game execution, but it
can easily occur when stepping through a game with the debugger, since
the debugger can be configured to flush output on every pause.)
- The Preferences dialog enabled and disabled the Apply button on
the font selection page incorrectly in some cases. This is now fixed.
- A bug in the HTML renderer caused spurious "MORE" prompts in some
cases when the game displayed a table with lots of cells. This has been
fixed.
Changes in version 2.5.6
Released June 1, 2002
- The new ASRC and HSRC attributes of the <IMG> tag provide
a way of implementing simple roll-over buttons. Refer to
Roll-over Images in
the documentation for details.
- Fonts can now specify a BGCOLOR (background color) attribute in
addition to the COLOR attribute. When a font specifies a background
color, the area behind any text displayed with the font is filled
with the background color. The area filled with the background color
is dependent on the font, but is a rectangle that is usually slightly
taller than the tallest character in the font, and just wide enough to
hold the displayed characters.
- The Windows HTML interpreter now supports Ogg Vorbis compressed
audio in <SOUND> tags. Ogg Vorbis is an open-source audio
format similar to MPEG audio but said to have superior compressions
and fidelity. The Windows interpreter uses the Xiphophorus reference
implementation, version 1.0rc3, for decoding. Ogg Vorbis files are
identified by resource names that end with the suffix ".ogg". An Ogg
Vorbis resource can be played in any sound layer. Refer to vorbis.com and xiph.org for information on the Ogg
Vorbis format, and for links encoders and other Ogg Vorbis-enabled
software.
- The Windows HTML interpreter now supports MNG (Multiple-image
Network Graphics), on an experimental basis. MNG is an animated image
format related to PNG, and, like PNG, is an open standard unencumbered
by patents; MNG is said to be superior to animated GIF's in a number
of ways. (HTML TADS doesn't support GIF images, static or animated,
because of patent restrictions applying to the GIF format.) MNG is
supported by several popular applications, including Jasc's Animation
Shop (part of Paint Shop Pro). The MNG web site has information
on the standard, including links to applications that can be used to
create and manipulate MNG images. In HTML TADS, you can use an MNG
file as the SRC of an <IMG> tag, an <HR> tag, or an
<LI> tag. Note that MNG images can NOT be used as the main body
background; only static images (PNG's and JPEG's) can be used as the
body background.
- The new system information code __SYSINFO_OGG allows a game
to sense whether or not the interpreter supports the Ogg Vorbis
audio format.
- The new system information codes __SYSINFO_MNG,
__SYSINFO_MNG_TRANS, and __SYSINFO_MNG_ALPHA sense whether or not the
interpreter supports the MNG image format, transparency masks in MNG
images, and "alpha channel" partial transparency in MNG images,
respectively. In most cases, MNG transparency and alpha support
will mirror PNG support for the same features.
- The Windows HTML interpreter now supports full alpha-channel
(partial transparency) rendering of PNG images on Windows 98, ME,
2000, and XP. Alpha rendering is automatic. This functionality is
not available when running on Windows 95 or NT 4, because these
versions of Windows do not provide support for alpha rendering in
their native graphics subsystems; on Windows 95 and NT 4, images with
alpha channels are rendered against a fixed background (either the
default background specified in the PNG itself, or a default chosen by
the interpreter if the PNG doesn't specify one) as in past versions.
For PNG's with paletted alpha, on 95/NT 4, the paletted alpha is
treated as simple transparency. Note: the system information
code __SYSINFO_PNG_ALPHA (introduced in version 2.5.4) indicates
whether or not the system supports full PNG alpha channel rendering;
this allows a game to include two copies of a graphic (usually, one
optimized for full alpha and the other optimized for simple
transparency), displaying one or the other according to the
capabilities of the interpreter.
- The Windows HTML interpreter now includes an "Exit" command on
the "File" menu. This is equivalent to closing the interpreter window.
Similarly, the former "Quit" command in Workbench has been renamed
to "Exit" for conformance with standard Windows user interface
conventions.
- The Windows HTML interpreter features the "Game Chest" start
page. The interpreter shows the Game Chest page when it first
starts, and also offers a link to the Game Chest page whenever a game
ends. The Game Chest page gives you a customized list of your favorite
games; you can start a game on your list by clicking its title, saving
you the trouble of finding the game file on your hard disk. The
Game Chest page is easy to use and self-explanatory.
- The Windows HTML interpreter has a new "Find Text" command, which
lets you search for text in the game window. This makes it easy to
locate a passage that you remember seeing earlier and want to read
again. To begin a search, select the menu item "Find text on current
page" from the "Edit" menu; this will bring up a dialog box. Type
the text you want to find and click the "Find Next" button in the
dialog (or just press Enter). The interpreter will look for the
text, and then highlight the first occurrence it finds. Select the
"Find Next" item from the "Edit" menu to find the next occurrence
of the same text, or just press the F3 function key.
- TADS Workbench for Windows has a new feature that lets you go to
a selected line number in the active source window. To use the
command, select the "Go to line number" item from the "Edit" menu, or
type Ctrl+G. This will show a dialog asking for a line number; type
the line number and click "OK" (or press Return). The cursor will be
positioned on the selected line number in the active source window.
- In Workbench for Windows, the debugger log message window is
now a "dockable" window. As with the other dockable windows, you
can switch the window between document-style ("MDI") mode and
docking mode by right-clicking on the window's title bar and
selecting the new mode from the pop-up menu.
- The Windows HTML interpreter now includes a toolbar, for fast
access to frequently-used commands. The toolbar is optional; if you
want to hide it, un-check the "Show Toolbar" menu item on
the "View" menu.
- The keyboard accelerators in the Windows interpreter have been
changed slightly to better match the usual Windows conventions.
"Restore game" is now on Ctrl+R, and "Open new game" is on Ctrl+O.
- The Windows HTML interpreter now continuously displays the
elapsed time since loading the current game at the right side of the
status line. The timer shows elapsed time for the current session
only, so if you save a game, turn off your computer, then come back
to the game later, the timer will be reset when you start your new
session. If you find the timer distracting, you can hide it by
un-checking the "Show Timer" menu item on the "View" menu. You can
also choose whether to display hours, minutes, and seconds, or just
hours and minutes: right-click on the status bar, and select your
desired time display format from the pop-up menu.
- The Windows HTML interpreter now allows keyboard entry of
character code 255. (This primarily affects users on machines
localized outside of the US and Western Europe, since the Windows
Western European character set doesn't use character code 255 for
anything. In past versions, the interpreter incorrectly failed to
allow keyboard entry of this particular character code.)
- In the Windows interpreter, the parameterized font named
"TADS-Input" selects the text's color, bold, and italics attributes
as well as the typeface, according to the settings that the player
makes in the Preferences dialog. In the past, it was not possible to
override the additional attributes, even with explicit
<font> tags nested within the tag that selected the
"TADS-Input" face. This has been changed so that <font
color=xxx>, <i>, and <b> tags
nested within a <font face='TADS-Input'> tag are
obeyed. (Note, however, that any color attribute specified in the
same <font> tag as a face='TADS-Input'
attribute is still ignored: the preference color associated
with the "TADS-Input" font still overrides any other color setting
made in the same tag. This isn't necessarily the most intuitive
behavior, but think of it as an arbitrary choice to resolve a
conflict: since "face=TADS-Input" and "color=xxx" attributes in a
<font> tag both select a text color, one of them has
to be ignored.)
- The Windows interpreter now uses the TITLE attribute of an <A>
tag as the "tip" text for the link. That is, if the mouse cursor hovers
over a link for a few moments, the interpreter displays a small pop-up
window showing the link's TITLE attribute text.
- Hyperlinks can now be displayed with explicit font colors. In
the past, a <FONT COLOR=xxx> tag within an <A HREF> tag
was ignored, and the hyperlinked text always displayed in the system
hyperlink text color despite the explicit color setting of the
interior tag. The renderer now obeys the color setting of a
<FONT> tag enclosed within an <A HREF> tag, overriding
the default system color settings. Note that when the color is
explicitly overridden in this fashion, the explicitly specified
color is used for all states of the linked text, so the link doesn't
change its visual appearance in response to the mouse position as
it does with the default colors.
- The following parameterized color names have been added:
- link: hyperlink text
- alink: "active" hyperlink text (on Windows, this is the color
of a link while the mouse button is being held down with the mouse over
the link; the meaning may vary on other systems)
- text: the default text color
- bgcolor: the default background color
- The Windows HTML interpreter now waits to attach to the
DirectSound system (a part of Windows that handles sound playback)
until a game first requires sound playback, rather than at interpreter
start-up as it did in the past. This means that the interpreter won't
attempt to use the DirectSound subsystem at all when the game or games
played during an interpreter session don't use any sound effects.
When an application connects to the DirectSound system, other
applications are sometimes unable to use DirectSound simultaneously;
although HTML TADS uses a "cooperative" sharing level for its
DirectSound use, some other applications require exclusive access, and
so cannot use DirectSound at the same time as HTML TADS. By waiting
to attach to DirectSound until a game actually needs sound playback,
the interpreter avoids unnecessarily locking out other, less
cooperative applications.
- A bug in the Windows interpreter caused the interpreter to crash
if a game attempted to display a JPEG image encoded in gray-scale
(monochrome) format. This has been corrected.
- The Windows interpreter now shows more immediate visual feedback
(by scrolling the window down a line) after a command is entered if
the command takes a perceptible amount of time to process. (This is
a purely cosmetic change. In the past, the interpreter didn't show
any visual change until a command was finished; this was harmless,
but looked a little weird for commands that took more than a few
tenths of a second to complete.)
- The scrollbars in the main window in the Windows interpreter now
track the mouse a little differently: when you click and drag the
scrollbar's "thumb" to change the scroll position, the scrollbar will
continue tracking the mouse as long as you hold down the mouse
button, no matter how far you move the cursor away from the
scrollbar. In the past, as is typical for Windows scrollbars, the
thumb snapped back to its original position whenever the mouse
strayed more than about the width of a scrollbar away from the
scrollbar; some people (your present correspondent included) found
this extremely irritating, since it's hard to keep the mouse lined up
with the narrow little scrollbar area when moving the thumb any
substantial distance.
- The Windows interpreter (and Workbench) now provide "native" mouse
wheel support. In the past, it was necessary to use the mouse
manufacturer's extra driver software for the scroll wheel to work in
HTML TADS, but this was a problem for users who don't use the extra
driver software; many people must disable the extra driver software
because of incompatibilities with other applications. The new native
mouse wheel support means the mouse wheel will work properly on any
Windows 98/Me/NT 4/2000/XP system, even if the extra driver software
is disabled. (Windows 95 and NT 3.1 users must still use the extra
driver software, because those versions of Windows do not have native
mouse wheel support.)
- Workbench for Windows has a new "auto configuration" dialog for
text editors. When you're configuring a text editor (in the "Editor"
panel of the main options dialog, reachable from the "Options" item
on the "View" menu), you can click on the new "Auto Config" button to
bring up the automatic configuration dialog. The new dialog lets you
choose an editor from a list of pre-configured editors, plus any
editors that you have installed that have registered Windows Explorer
file associations for files of type ".c", ".h", ".cpp", or ".txt".
If your preferred editor is included in the list, all you have to do
is select your editor from the list and click the OK button; the
appropriate settings will be entered automatically into the editor
panel. If your favorite editor isn't on the list, please contact
TADS's author to request adding your editor to the list in a future
version. Sadly, text editor vendors have not yet been lining up with
large cash offers for promotional consideration in the auto-config
list; until they do, I'll add any editor to the list upon receipt of
the relevant configuration parameters. Note: if you select
a pre-configured editor (as opposed to one deduced from file associations),
you might need to go the "Advanced" dialog after selecting your editor
from the list to set the full path to the editor's executable file.
- The mechanism that searches for source files in the Windows
debugger has been improved slightly to eliminate a problem that
occurred in some cases where a header or source file was not in the
working directory at compile time. In some such cases, the debugger
managed to open the source file but did not properly show breakpoint
and execution pointer icons. This has been corrected.
- The Windows TADS 3 Workbench debugger now automatically stops
when the interpreter is about to throw a run-time error, allowing
you to see the location in the code where the error occurs, and
possibly to intervene manually. If you change the execution point
and then step or go, the interpreter will not throw the
error; if you leave the execution point unchanged, the interpreter
will proceed to throw the run-time error as normal. In some cases,
you may be able to correct the conditions that caused the error (by
changing the values of variables, for example); in these cases, you
might wish to avoid throwing the error by moving the execution point
back a line or two in the source and retrying the operation.
- The Windows TADS 3 Workbench allows files in the Project window
to be reordered, simply by clicking on an item with the mouse and
dragging it to its new location. Files can only be reordered within
a folder; a file cannot be dragged to a different folder.
- Workbench for Windows now provides the "Find" command within the
Debug Log window, to search for text within the debug log text.
- The HTML renderer now flows text around tables with ALIGN=LEFT or
ALIGN=RIGHT settings. This lets a table "float" in a margin in the
same way that images can, which can be useful for a variety of text
effects. Note: the renderer's treatment of such tables
deviates slightly from the HTML standard, in that a left- or
right-aligned table is effectively treated as an in-line item rather
than a block item, so no paragraph break is visually displayed at the
point where the table appears in the text. For strictly compliant
HTML treatment, one can place a <P> tag immediately before and
immediately after a table with left or right alignment. Tables with
no explicit alignment and tables that specify ALIGN=CENTER are not
affected by this change.
- The HTML interpreter did not correctly display PNG images that
use a gray-scale format (one of the several PNG color storage
formats); gray-scale images were displayed with random colors that
changed unpredictably during redraws. This has been corrected;
gray-scale images are now displayed correctly.
- The Windows HTML interpreter now uses libpng 1.2.2 (the latest
version, as of this writing, of the reference open-source PNG library)
for handling PNG files. This expands the range of PNG sub-formats
supported on Windows.
- The Windows HTML interpreter is now faster at queuing digitized
sound effects (the WAV, MPEG, and Ogg Vorbis formats). The
interpreter's latency sensing the end of playback for digitized
sounds has been reduced substantially, so loops and queues now
proceed with a much smaller delay between adjacent effects.
- A bug in the HTML renderer caused list items (specified
with the <LI> tag) to be indented improperly. In the past,
the bullet or number of each list item was shown at the same indent
level as the rest of the list text; instead, the bullet or number
should be displayed in the left margin of the first line, with the
text of each line left-aligned to the right of the bullet or number.
This has been corrected.
- A bug in the HTML renderer caused unpredictable results when
switching out of HTML mode (using "\H-") immediately following
certain types of closing tags. This problem only appeared when
an "\H-" sequence appeared immediately after an affected close
tag with no other intervening text or tags. This is now fixed.
- A bug in the Windows HTML interpreter caused some font preference
settings to change by themselves when brining up the Preferences
dialog. In particular, if the originally selected font was the
first font in the popup list for a given font type, the font
switched upon bringing up the dialog to the second item in the
list. This problem no longer occurs.
- A bug in the HTML renderer caused incorrect displays in certain
cases where a <TABLE> tag was nested within a
<BLOCKQUOTE> tag, and no text or markups came between the
closing </TABLE> tag and the closing </BLOCKQUOTE> of the
enclosing structure. Typically, some of the text immediately
following the </BLOCKQUOTE> was not displayed at all or was
displayed with incorrect margins. This has been corrected.
- The Windows installer now automatically looks up the local
"Program Files" path and uses it to select the default installation
directory. This applies to the system installer as well as to game
installers you create using Workbench. When you're creating an
installer for your game, you should use only a relative path for
your "Default Program Directory" setting (in the Installer Options
subdialog of the Build Settings dialog); the installer will automatically
insert the correct prefix for the local computer at installation time.
For example, rather than typing "C:\Program Files\My Game" into the
Default Program Directory text box, you should type simply "My Game";
the installer will expand this to "C:\Program Files\My Game" or
"C:\Programme\My Game" or whatever is appropriate on the local
system at install time.
- A couple of bugs in the HTML renderer caused crashes in some cases
when <BANNER> tags were not closed before reading text input
from the keyboard. The effects of unclosed <BANNER> tags
varied according to the banner's contents, but several common types
of contents, including <FONT> and <TABLE> tags, sometimes
caused interpreter crashes. The renderer should now be tolerant
of unclosed <BANNER> tags (at the very least, it should no
longer crash when confronted with such things).
- The <CAPTION> sub-tag of a <TABLE> is now implicitly
closed by a <TR>, <TD>, or </TABLE> tag. In the
past, the HTML parser complained if a <CAPTION> was not closed
with an explicit matching </CAPTION>; the parser now implictly
closes a <CAPTION> at the end of a table or at the start of
any other table structure sub-tag.
- Tables that had explicit WIDTH settings but contained no data
are now displayed at the given width. In the past, a table without
any contents was shown with zero width, even if an explicit WIDTH
attribute was given.
- On Windows, the HTML interpreter did not always correctly choose
fonts on systems localized for locales other than Western Europe/US.
In the preferences dialog, the font selector pop-up controls sometimes
showed the same font several times (possibly with suffixes on the
name) when several different character set versions of the same font
were installed on the system. Furthermore, the interpreter sometimes
showed characters from the incorrect character set when displaying
HTML entities. This has been corrected; the list of fonts should
now show only one instance of each typeface name, even when several
different character sets of the same typeface are installed, and
the interpreter should show the correct characters for all
HTML entities that can be displayed.
- Due to a bug in HTML TADS, if the player terminated a game by
closing the interpreter window while the game was specifically pausing
for some amount of time (for example, to allow a sound to finish
playing), the interpreter did not immediately exit, but continued
waiting for the interval specified by the game. In the case of long
delays, this could leave the interpreter process running for some time
after it was ostensibly terminated. This was mostly harmless, but
unnecessarily consumed system resources. This has been corrected.
Changes in version 2.5.5
- Fixed a problem in the Windows HTML interpreter that eventually
stopped MIDI sounds that were intended to loop infinitely. (The problem
was that the MIDI player was unnecessarily re-opening the MIDI file after
each repetition; this eventually consumed all available file handles,
at which point the looping stopped because the MIDI player couldn't
open the file again.) This has been corrected.
- Fixed a problem in the Windows HTML interpreter that prevented
playback of very short MP3 audio files. In the past, MP3 files under
about half a second in total duration did not play back. This has
been corrected.
- Fixed a problem in the HTML interpreter that sometimes caused
crashes when certain font-related tags were not properly balanced
(i.e., begin and end tags were not matched up correctly in the HTML).
While these sorts of sequences are still invalid HTML and hence might
still confuse the renderer and result in strange displays, they
should no longer cause crashes.
Changes in version 2.5.4
- The Windows HTML interpreter now supports transparent PNG images.
Transparent PNG images can be used to show non-rectangular icons and
to superimpose images over backgrounds. Check your PNG creation
tools for information on how to create images with transparency
information. (Note that only simple transparency is supported;
"alpha blending," which allows images to be partially transparent, is
not supported. Images with alpha information are treated as
having simple transparency: each pixel that is partially but not
completely transparent is treated as completely opaque.) Note that a
new systemInfo flag, SYSINFO_PNG_TRANS, has been added to test for
PNG transparency support; systemInfo(SYSINFO_PNG_TRANS) will now
return true under the Windows HTML interpreter.
- In TADS Workbench on Windows, any sounds still playing when you
terminate the running game are canceled. (In the past, sounds continued
to play even after terminating a game, until either the sounds finished
playing by themselves or you restarted the game.)
- On Windows, a bug prevented playback of MIDI files containing
certain sequences. This has been corrected (The exact conditions
that caused the problem are complicated, but the bug involved long
MIDI messages occurring at certain boundaries within the file.)
- On Windows, a bug in MIDI playback caused a crash if playback
failed due to an error within the MIDI file. This has been corrected.
- On Windows, if MIDI playback was cancelled in the middle of
certain types of operations (such as pitch bends), a new MIDI
playback started after the cancellation sometimes "inherited" the
channel settings of the interrupted file, resulting in incorrect
playback. This has been corrected: all MIDI channels are now reset
to default conditions at the start of each new playback.
- For users running certain early versions of Windows 95, Workbench
crashed when the "Settings..." item was selected from the "Build"
menu, due to an incompatibility with a Windows system DLL. This
problem apparently only occurred for Windows 95 version 4.00.1111;
the problem has been corrected.
Changes in version 2.5.3
- The HTML interpreter's table layout algorithm has been improved
slightly in the way it calculates the layout for rows within tables
with explicit heights. This will be particularly noticeable in tables
with HEIGHT=100%. In the past, the table layout system apportioned the
extra vertical space in tables with specified heights according to the
total height of the table; it now counts only the interior heights
of the cells, which results in much more accurate layout when the table
is intended to stretch to the limits of the window height.
- The HTML interpreter for Windows now reformats the text on any
change to the window size, vertical or horizontal. In the past, as
an optimization to avoid excessive redrawing, the system only reformatted
on a change to the horizontal size of the window. However, it is possible
for formatting to depend on the vertical size, too; tables whose heights
are set to percentages of the window height, for example, must be
reformatted when the window is vertically resized. So, this optimization
has been removed; changes to either the width or height of the main window
will now result in reformatting.
- When you build a stand-alone game with the HTML interpreter for
Windows, the stand-alone game executable will no longer display the
recent games section of the "File" menu, nor will it offer the
"load new game" command. These menu items were not appropriate for
stand-alone games, so they've been removed. This change doesn't
affect the HTML interpreter during normal use - only when used to
build a stand-alone game executable.
- The game installer has a new option, "readme", that lets you
specify a file to display to the user immediately after completing
an installation. Specify an HTML or text file in this field, and
the installer will open this file after the install completes
successfully and the user dismisses the installation "wizard" dialog.
- The HTML interpreter did not properly update the display in some
situations where a game used repeated updates to animate a sequence
of graphics. This problem affected the title sequence of Neil K. Guy's
Six Stories, for example. This has been corrected.
- The HTML interpreter for Windows crashed if you closed the application
while a sound was still playing. This has been corrected.
Changes in version 2.5.2
- The Windows interpreter now allows you to use certain web
addresses in <A HREF> links. The interpreter opens these links
using the user's normal web browser, so the user must have a Windows
web browser (such as Microsoft Internet Explorer, Netscape Navigator,
or Netscape Communicator) installed and configured as the default
browser in order to follow these links. Any properly configured
Windows web browser should work. If a web browser is installed,
the Windows interpreter will use it to show any link whose HREF
starts with one of the following prefixes:
- http:
- ftp:
- news:
- mailto:
- telnet:
Note that you can use the systemInfo() function to check
the interpreter to determine if these link types are supported,
using the new __SYSINFO_LINKS_HTTP, __SYSINFO_LINKS_FTP,
and related capability codes. Refer to the
TADS 2.5.2 release notes for
details.
- The Windows HTML TADS Interpreter now keeps a list of recent games
under the "File" menu. The four most recently-played games will be
displayed under the file menu; to load one of these games, just select
it from the menu. Similarly, the Windows Debugger keeps a list of
recent game projects, under the "Recent Games" submenu of the "File"
menu (the debugger uses a submenu to allow for the future addition
of a "Recent Files" submenu listing recently-opened source files).
- Workbench will now work properly with relative directory
paths in all build settings. In the past, it was usually best to make
these paths absolute (i.e., including a full path specification with
drive letter prefix), because Workbench's working directory was
always the same as where the Workbench executable was stored. This is
no longer the case; Workbench now sets the working directory to the
directory containing the project (".tdc") file each time a game is
loaded, so all of the paths in the build settings can specified relative
to the project directory. This is especially helpful if you're moving
a project file between different computers with different drive letters
or directory layouts, because it allows a project's build settings to
be fully self-contained within the project directory.
- The Windows debugger now lets you control flushing output to the
game window. In the past, the game window frequently did not show
any output that had occurred since the last user input; this
sometimes made it difficult to debug display code, because the
immediate effects on the game window could not be seen while stepping
through the code in the debugger. A new menu command, "Flush Game
Window Output" on the "View" menu, lets you explicitly flush most
pending output to the game window. In addition, another menu item,
"Auto Flush Game Window" (also on the "View" menu), lets you control
whether or not the debugger automatically flushes the game window
on entry; if this menu item is checked, the debugger will automatically
flush the game window's output each time you step through a line of
code or encounter a breakpoint. Note that some types of HTML structures,
such as tables and banners, will not always display anything until fully
formed (that is, the entire structure, including the ending tag, has
been written to the output), so you will not always see all pending
text displayed even when explicitly flushing output.
- The Setup program (for installing TADS itself, as well as for
installing games using the installer created by MKSETUP or through
the Workbench "Compile Installer" command) now accepts bacsklashes
in the "Program Folder" setting that the user enters during the install
process. In the past, Setup treated backslashes as invalid characters,
and simply converted them to underscores. The installer now accepts
backslashes as path separators, allowing the user to place the
installed software in any submenu within the Start menu.
- The Windows debugger now responds to the left and right arrow keys
while the local variable and watch windows are active. In these
expression list windows, the left arrow key closes the sub-list of
the current item if it's open, otherwise moves to the parent item;
the right arrow key opens the sub-list of the current item if it's
closed, otherwise moves to the first child, if any, or the next
item, if not. These keys provide a more convenient keyboard interface
to the expression list windows, and is more consistent with Windows
conventions for this type of window.
- The Windows debugger now responds to function key F2 in an expression
editor window by activating the currently selected expression or value
for editing, for consistency with Windows conventions.
- The Windows interpreter is now much less intrusive when
it discards old text during a long game. In the past, whenever the
interpreter discarded old text to save memory, the interpreter
cleared the text window then re-drew all of the text after a short
delay. Since this usually happens with a frequency of every thirty
to fifty turns after playing for a while, the screen clearing could
be quite annoying. Starting with this version, the interpreter no
longer clears the screen while it's working. In most cases, this
makes text disarding almost invisible; most of the time, you'll
probably notice nothing more than a brief flash of the "Working"
message in the status line.
- The interpreter now shows the active game file in the window title.
In the past, the interpreter's window title only changed when a game
explicitly set it using the <TITLE> tag. The title now reflects
the ".gam" file name if the game doesn't specify a <TITLE> tag.
This is especially helpful if you're switching among different games
in the course of a single session.
- Fixed a bug in the <TAB> tag. When <TAB MULTIPLE> was
specified, with no value specified or with a value of zero for the MULTIPLE
attribute, the Windows interpreter crashed. This has been corrected;
an unspecified MULTIPLE value or a MULTIPLE value of zero is now treated
as through MULTIPLE were set to 1.
- Fixed a bug in the clearscreen() function. In past
versions, if the game called clearscreen() after displaying
some text containing an HTML tag sequence near the end, and the text
did not end with a newline of some kind (a "\n" or
"\b" sequence), the interpreter occasionally would display
part of the HTML tag as plain text. This should no longer occur.
- Fixed a bug in the Windows interpreter that caused a crash under
certain very obscure circumstances. In particular, if you activated
another application while the interpreter was running, and brought up
a dialog (such as a file selector dialog) so that the dialog was
directly over the interpreter's main window, then did something to
dismiss the dialog that involved a mouse double-click (for example,
double-clicking on a file in the file selector dialog), the interpreter
would sometimes crash. This has been corrected.
- Fixed a problem in Workbench for Windows that sometimes caused
compiler error messages in the Debug Log window to be split over two
lines. When this happened with the line break in the middle of the
filename portion of the message, double-clicking on the message to
go to the error line in the source file didn't work: Workbench
couldn't read the complete filename from the log window, because the
filename was broken up over two lines. This has been corrected; each error
message will now always appear on a single line.
- A bug in the Windows interpreter prevented a stand-alone game
executable from starting properly if the user set the preferences so
that the interpreter didn't ask for a game at startup ("ask for a
game to open on starting HTML TADS" on the "Starting" page of the
preferences dialog). This has been corrected.
Changes in version 2.5.1
- The Windows HTML TADS Interpreter now uses a fixed palette
(sometimes called a "rainbow" or "color cube" palette) when the video
hardware is set to display 8-bit (256-color) graphics. In past
versions, the Windows interpreter dynamically set the hardware
palette according to the images that were displayed, allocating the
256 available palette colors according to the order in which the
images were displayed; while this optimized color fidelity for some
images, it sometimes gave poor results when multiple images with very
different color schemes were displayed simultaneously. The new fixed
palette is designed to give reasonably good results for a wide range
of images; because the palette is fixed, the order in which images
are displayed will no longer affect their appearance. Note that this
change only affects 256-color display modes; when the video hardware
is set to display 16- or 24-bit color ("65536 colors" or "True Color"
in the Display Properties control panel), the interpreter does not
use a palette at all, since it can display all of an image's colors
directly.
- On the Windows interpreter, keyboard focus now stays
in the main input panel more consistently. In past versions, clicking
in a banner moved focus to the banner, making it necessary to
click back in the main input panel to enter a command. Input focus
now moves back to the main panel after any click in a banner,
except when you select a range of text in the banner, in which case
focus stays in the banner until you explicitly click in the main
text panel or clear the selection in the banner. (Focus stays in
a banner with a selection so that you can use the Ctrl+C keyboard
command to copy the selection.)
- The Windows interpreter in the past acted as though the player
had responded to a "MORE" prompt whenever the timeDelay()
function was used to pause the game. This no longer occurs.
- Fixed a problem in the interpreter that omitted the
display of a game's closing message in certain cases. When the
interpreter's preferences were set so that the interpreter continued
running after quitting the game, any message that the game attempted
to display after its last line of input was not visible (for example,
a closing message after a QUIT command was not shown). This has been
corrected; any closing message from the game is now properly displayed.
- On the Windows interpreter, the systemInfo()
built-in function incorrectly reported that MPEG Audio was not
supported. This has been corrected.
- On the Windows interpreter, the morePrompt()
built-in function incorrectly displayed the text "[More]" in the main
output window, rather than using the normal "More" prompt (as selected
in the preferences). This has been corrected.
- The interpreter showed a horizontal scrollbar unnecessarily in
certain cases when a game displayed tables containing long lines of
text, even when the lines were wrapped within the table cells.
This has been corrected.
- Fixed a bug in the interpreter that prevented
<BANNER REMOVALL> sequences from working correctly under
certain conditions. This has been corrected.
- On the Windows interpreter, if you displayed a banner
with its height set to 100%, the interpreter made the banner too tall,
so that it covered the status line. This has been corrected.
- On the Windows interpreter, the "More" prompt is no longer
displayed if the main text panel is very tiny. This will improve the
display behavior for games that use full-window banners to achieve
special effects (especially animation effects) by suppressing the
unnecessary "More" prompts that this type of effect generated in the
past.
- The mechanism that discards old text during long game sessions has
been improved slightly to make the text discarding more consistent.
In past versions, the system sometimes waited to discard any text until
the total text size was far over the limit set in the preferences, and
then discarded all or almost all of the old text. The interpreter
should discard a much more reasonable amount of old text and do so
closer to the time the text starts exceeding the preferences limit.
- The Windows interpreter incorrectly discarded old text from
time to time even when the memory preference setting was "No Limit."
This has been corrected; all text is now retained with this setting.
- The Windows interpreter now displays the "Working" message in the
status line only during really long reformatting jobs. In the past,
the "Working" message was displayed during any reformatting, so the
status line flashed a lot during game play, which was often distracting.
The "Working" message now only shows up after a couple of tenths of
seconds have elapsed during reformatting, which prevents the message
from flashing on and off during quick display operations.
- The Windows interpreter had a bug that caused various problems
if a new, non-HTML-aware game was loaded while an HTML-enabled game
was previously running. This has been corrected.
- Fixed a debugger bug that caused a spurious error message
("attempting to free a locked object"), and in some cases a crash,
when the game used the delete statement to delete an object
which had at some point earlier been "opened" in an expression window
to show its property values. This will no longer occur.
- Fixed a problem that made it impossible to terminate the game
by closing the main game window when the game was stopped at a "more"
prompt while running under the debugger. In the previous version,
closing the game window at a "more" prompt made the debugger lock up
and stop responding; this no longer occurs.
- Fixed a bug in the debugger that caused Workbench to crash when
a game running in HTML mode caused an HTML parsing error, and the source
text near the error contained a "\)" sequence (to turn off highlighting,
using the traditional non-HTML formatting codes). This has been
corrected.
- Fixed another debugger problem that caused a crash when breakpoints
were set in a source file containing no executable code at all.
Changes in version 2.5.0
Released on July 10, 1999
- Important programming note:
The Windows debugger now requires that you compile your game with
the new -ds2 option. Use this option instead of the
traditional -ds option. (The only difference between
-ds and -ds2 is that the -ds2 option instructs
the compiler to generate a new style of debugging information in your
game; the Windows version of the debugger, starting with version 2.5.0,
requires this new style of information, and will not work with games
compiled using the -ds option.)
- Another important programming note: On Windows, the TADS
Debugger is now called "TADS Workbench." I've changed the name
because the program is now more than just a debugger: TADS Workbench
is an integrated environment that lets you build your program as well
as debug it. Refer to the TADS Workbench
help page for details on the new features.
- The Windows HTML TADS interpreter now lets you load a new game
without exiting and restarting the interpreter. You can select the
"Load Game" item from the "File" menu at any time to start a new
game. Loading a new game immediately ends the current game,
so the interpreter displays a confirmation dialog when you select
this menu item if a game is already underway.
- The Windows HTML TADS interpreter offers new option settings
for the interpreter's action when first launched. The new "Starting"
tab in the options dialog has these options:
- Ask for a game to open on starting. If this box is checked,
when you launch the interpreter, it immediately displays an "Open"
dialog asking you to select a game file. If you uncheck this box,
the interpreter will display the main game window, but take no
further action on its own; to load a game, select "Load New Game"
on the "File" menu.
- Initial game folder. This text field lets you choose the folder
on your hard disk where the interpreter start the first time
it displays an "Open" dialog. If you usually store your TADS
game files in a particular location on your hard disk, you can
enter that folder here; whenever you start HTML TADS, the interpreter
will automatically initialize the "Open" dialog to start in this
location, saving you the trouble of navigating to the folder each
time you run the interpreter.
- The Windows HTML TADS interpreter now offers option settings for
the interpreter's action after you quit the game (normally by entering
a QUIT command at the game's command prompt). You can choose this
option in the "Quitting" tab of the options dialog. The options are:
- Wait for a keystroke, then exit. This is the traditional
action: after the game ends, the interpreter waits for you to
press a key, then the interpreter program exits. (The interpreter
waits for you to press a key, rather than exiting immediately,
so that the game window doesn't disappear before you have a chance
to read any messages that the game displays as it ends.)
- Keep running. When you select this setting, the interpreter
simply keeps running even after the game has ended. To exit the
interpreter, close the game window (by clicking on the game window's
close box, or by selecting "Exit" from the game window's system menu).
This setting allows you to start another game, using the "Load Game"
item on the "File" menu, after a game has finished.
- The Windows HTML TADS interpreter now offers different option settings
for the interpreter's action when you close the game window (by clicking
the close box on the game window's title bar, or selecting "Close" in
the game window's system menu). You can select the close action in
the "Quitting" tab of the options dialog. The options are:
- Send QUIT command to game. This is the traditional action: when
you close the game window, the interpreter simply acts as though you
had typed QUIT into the game.
- Prompt before closing window and exiting. The interpreter will
display a dialog box asking for confirmation that you really want to
quit. If you click "Yes," the interpreter will terminate the game,
bypassing any prompt that the game would normally display at this point.
- Close window and exit without prompting. The interpreter will
immediately close the game and exit when you click the game window's
close box. The interpreter will not prompt for confirmation, and will
also bypass any prompting that the game would normally do upon quitting.
- The <BANNER> tag now accepts percentage values for the WIDTH
and HEIGHT attributes. If you put a percent sign ("%") after the
WIDTH or HEIGHT value, the size will be a percentage of the main window
size. This lets you scale a banner to the size of the main window.
Refer to Banner Size Attributes
for full details.
- When a game is running in HTML mode, the yorn() built-in
function now displays the player's input in the input font set in the
preferences. (In the past, the Interpreter did not switch to the
input font for yorn() in HTML mode. The Interpreter has
always switched to the input font for yorn() as well as for
input() when the game was not in HTML mode, and continues to
do so.)
- "$$ABEND", the emergency abort command, now works properly in the
Windows HTML TADS interpreter. This command was ignored in past
versions.
- The Windows debugger, now part of TADS Workbench, has a number of
new user interface features that make it easier and more convenient
to use:
- You can now add or remove a breakpoint simply by clicking in the left
margin of a source line (the gray area to the left of the text).
- You can now reload your game file from disk
without quitting and restarting the debugger. The "Reload Game File"
item on the "File" menu terminates the current debugging session and
reloads the game from disk. If you're making numerous small changes
to your game as you run through it in the debugger, this new reload
option can be convenient, since it allows you to edit the source,
recompile the game, and reload it in the debugger without having to
exit and restart the debugger. Note: you should not attempt to
recompile your game at the same time that the game is running in the
debugger, since this could result in a file sharing conflict (the
compiler would attempt to overwrite the game file while it's in use
by the debugger); instead, you should quit the game first. You can
leave the debugger itself running during compilation, but you should
be sure the debugger's title bar shows the "[game terminated]"
status; this indicates that the debugger is not using the game file.
After recompiling, use the "Reload Game File" command to load the
game back into the debugger for another run.
- You can now load a new game file without
quitting and restarting the debugger. The "Load Game" item on
the "File" menu terminates the current game (if any) and loads a
new game.
- The special debugger windows that display the stack, local variables,
watch expressions, and call history now feature "docking" support, which
means that these windows can be attached to an edge of the main debugger
window. This new feature gives you substantially greater power to customize
your display layout. Look here
for more information.
- The debugger now checks for modified source files each
time the main debugger window is activated. If you edit and save a
source file with another program (your text editor, for example)
while the file is open in the debugger, the debugger will now offer
you the option to load the updated source file when you switch back
to the debugger window. The debugger will display a prompt for each
source file that has been modified; you may choose to keep the old
version in memory or load the updated version. Note that you'll
generally only want to load the new version of a source file if you've
also recompiled the game and then reloaded the game into the debugger;
if you merely edit a source file, but continue debugging the old version
of the compiled game, the source and compiled game would no longer be
synchronized, hence you wouldn't want to load a new source for the old
compiled game.
- Right-click on the background area of the main debugger frame window
(the "MDI client area") to pop up a menu of the special debugger windows.
- The debugger now has preference settings that let you control
which confirmation and notification dialogs that the debugger displays.
Some people like to be prompted for confirmation when a
command would have a possibly dangerous side effect, while others
would prefer the debugger to assume they know what they're doing.
The "Messages" tab in the debugger's "Options" dialog lets you turn
many of the debugger's notifications and confirmations on or off to
suit your working style.
- When you close the debugger (by closing the main debugger window
or by selecting the "Quit" item on the "File" menu), the debugger no
longer waits for a keystroke before exiting. This extra pause at
exit served no useful purpose for the debugger, so it has been
removed.
- The debugger now obeys accelerator keys for debugging
commands (such Ctrl+F for "Find") when the debugger's main window is
active, even while the game is running. (In past versions, the game's
accelerator keys were active at all times while the game was running
(rather than being paused in the debugger at a breakpoint or in
single-step mode), even when the debugger's main window was on top.
This was confusing and inconvenient. The debugger's accelerator
keys now work any time the debugger's main window is active, whether
the game is paused in the debugger or is running, and the game's
accelerator keys are active any time the game window is active.)
- Fixed a bug in the MKSETUP program (which builds an installer for
a game). If the setup configuration file contained a FILE option (to
include an extra file in the installation file set), MKSETUP got stuck
in a loop adding the file over and over. This has been corrected.
Changes in version 2.4.0
- On Windows, in the "Options" dialog, the settings formerly
in the "Command Font" panel now appear in the "Fonts" panel, and the
"Command Font" panel has been removed. In addition, the "Command
Font" popup list now offers a selection for "(Main Game Font)"; this
allows you to use the normal game text font, but still set the style
of the command input font (color, bold, italics) specially. (The
separate checkbox for using the default game font has been removed,
since it's redundant with the new popup entry.)
- In version 2.3.0 on Windows, a bug in the "Options" dialog caused
the interpreter to crash if the "Command Font" tab in the dialog was
selected and the dialog was subsequently dismissed with the "Font"
popup showing no selection. This has been corrected.
- In the Windows version, a new "Options" dialog page allows
setting the memory limit on previously-displayed text. As text
scrolls off the top of the window, the interpreter keeps the text
in memory (and any related information, such as graphical images)
so that you can scroll the window back to review the old text.
During long game sessions, this can use up an excessive amount of
memory. In version 2.3.0, the interpreter started automatically
limiting its memory usage to keep memory usage under control; the
interpreter had a fixed limit of 128 KBytes for the text buffer.
In version 2.4.0, the default limit has been reduced to 64 KBytes,
but you can now control this limit with the new "Memory" options
page. This new options page allows you to select a lower setting.
If you frequently run low on system memory during long game sessions,
try setting a lower memory limit with this option page.
- On Windows, displaying PNG images in 256-color display modes is
now much faster.
- Fixed a bug in the pop-up evaluation system ("tooltip evaluation")
for the Windows debugger.
In version 2.3.0, multiple evaluation pop-ups sometimes appeared, and they
didn't all disappear correctly. This should work correctly now.
- The Windows version is now somewhat smarter about adjusting the
scrolling position after the window is resized or reformatted. In
particular, when the text is scrolled all the way to the bottom (as it
tends to be most of the time during play), and you resize the window,
the interpreter will keep the window scrolled to the bottom after the
resize.
- A bug caused the interpreter to fail to display any text after a
game program displayed an empty <TITLE> tag. This has been
corrected.
Changes in version 2.3.0
Changes of interest to both players and authors:
- The interpreter now produces a much more usable transcript (a
"script" or log file) for games that use HTML. Script files are now
created as plain text files, with all of the HTML codes translated to
plain text where possible or removed entirely where not; the effect
is exactly the same as when the game is played through the text-only
version of the TADS interpreter. In past versions, HTML codes were
passed through to the script file, which made the script file very
difficult to read.
- In the Windows version of HTML TADS,
the "Options" dialog has a new tab, "Command Font," that lets
you set the typeface, color, and style for text entered on
command lines. If you click the checkbox for "normal game font,"
command lines will use the same typeface as the rest of the game;
if you uncheck this box, you can select the type style for commands.
Non-HTML games will always obey your settings; note, however, that
HTML-enabled games can override the input font, so some games may
not always use the preference setting.
- In the Windows version, when the mouse is hovering over an image,
the system now displays a small pop-up label (sometimes called a "tool
tip") showing the ALT text for the image. Game authors can supply text
for the ALT attribute of each image to provide a textual description
of the image.
- The Windows version now limits the amount of old text that the game
keeps around during a session. In the past, all of the text ever displayed
during a session stayed around until the end of the session, consuming
memory. HTML TADS now discards the oldest text periodically, which
helps keep memory consumption under control. The system still keeps lots
of old text, so players will continue to be able to scroll back through
the game transcript, but the amount of old text retained is now limited
to about 128k (which is, for example, enough to play all the way
through The Plant once, and then restart and play about
halfway through again).
- In past versions, HTML TADS did not obey the traditional highlighting
escape codes, "\(" and "\)", when not running in HTML mode (i.e., when
the game didn't display the "\H+" sequence to activate HTML). This has
been fixed; standard TADS games that don't activate HTML mode will now
display highlighted text correctly.
- HTML TADS did not show tab sequences ("\t") correctly for non-HTML
games. Rather than skipping to a tab stop, the system simply displayed
a few spaces, which in most proportional fonts did not create the
right effect. This has been fixed; standard text-mode games will now
show proper tabs when played with the HTML TADS interpreter.
- Fixed a bug that caused old pages to display with an incorrect
background image. In some cases, if clearscreen() was called, then
a background image was displayed (with <BODY BACKGROUND=xxx>),
then clearscreen() was called again, and after all of this the player
used the "Previous Page" command (on the "Go" menu) to look at the old
pages, the background image from the middle page could be displayed as
the background image of other pages in the history, even though those
pages were originally displayed without a background image. This
has been corrected; old pages are now displayed with the correct
background image (or lack thereof).
- In past versions, when a banner was re-used for new contents, the
old contents weren't always completely erased from the window. If the
new contents took up less space than the previous contents of the banner,
this left garbage on the screen. This problem has been corrected; a
banner window is now completely erased when a new BANNER tag replaces
the contents of an existing banner window, leaving only the new contents
in the window.
- Fixed a bug in MIDI playback that caused problems with looping
MIDI sounds. Symptoms of the problem were sporadic; in some cases,
the MIDI sound simply wouldn't repeat, and in other cases TADS caused
a GPF. This problem has been corrected; looping MIDI sounds should
now play back reliably.
- WAV file playback occasionally "glitched," causing stuttered
playback, looping playback, or random noise, or sometimes causing
sounds not to play at all. These problems should now be corrected.
- Fixed a bug that occasionally caused problems displaying vertical
banners (that is, banners along the left or right edge of the main window).
In some cases, if the player restored a game, and the restored game
immediately displayed a left or right banner, the system incorrectly
set the size of the banner so that it took up almost the entire width of
the display window, leaving no space for the main text area. This
has been corrected.
- On the Windows version, the entities Ő and ő
were reversed, so that Ő displayed a lower-case "o" with
double acute accent, and ő displayed an upper-case "O"
with double acute accent. This has been corrected.
- The "MORE" prompt's wording on the Windows version has been changed
slightly; the prompt now advises players to press "the space bar" rather
"any key," because the "MORE" prompt did not in fact respond
to just any key, but only certain keys. (The "MORE" prompt actually
responds to a few keys besides the space bar, such as the Return key and
the Page Up and Page Down keys, but the new prompt text is considerably
less misleading.)
Changes of interest to authors:
- The Windows version now supports MPEG 2.0 audio layers II and III
(usually referred to as MP2 and MP3 files, respectively). For
more details refer to the sound documentation.
- Because the Windows version supports MPEG 2.0 audio layers II and III,
the systemInfo() function returns true for the new
feature codes related to MPEG: __SYSINFO_MPEG_AUDIO,
__SYSINFO_MPEG_AUDIO_2, and __SYSINFO_MPEG_AUDIO_3.
- The <A> and <AREA> tags now accept two additional
attributes that let you control how they enter their HREF commands.
See the section in "Deviations from Standard HTML"
on <A HREF> for details.
- A new parameterized font, TADS-Input, lets the player
specify the typeface, color, and style for text entered on command
lines. If you're not trying to achieve a special effect of some
kind during command entry, you're encouraged to use TADS-Input
as the font for all commands. By default, std.t now activates this
font in the commandPrompt function; you can replace this
function definition with your own if you want to override this
behavior. See the documentation on
parameterized font names for details.
- The treatment of whitespace following <P> and <BR> tags
is now slightly different than it was in past versions. In the past,
if a <P> or <BR> tag occurred at the end of a line of
source code, and more text followed on the subsequent source line,
HTML TADS rendered the text with a leading space on the second line.
This no longer occurs; HTML TADS now omits any spaces between these
tags and the subsequent non-blank text, so that the new line after
a <P> or <BR> tag starts without a leading space. This
new behavior is more consistent with the way that TADS handles the
"\n" and "\b" sequences, and is also consistent with the way popular
web browsers render similar HTML mark-ups.
- HTML TADS now includes the normal bottom margin spacing in horizontal
banners. In past versions, horizontal banners were too compressed
vertically because this space wasn't included in the way the formatter
calculated banner heights. (If you've written a game that compensated
for this problem by adding some extra padding of your own, you might want
to remove the padding in future versions of your game.)
- The <BANNER> tag accepts a new attribute, REMOVEALL, that
indicates that all banners should be removed. REMOVEALL does
not take a value; when this attribute is specified, no other attribute
(not even ID) is needed.
- If the <BANNER> tag was used to replace an existing banner, and
the new banner had different ALIGN or BORDER settings than those of the
original banner, the new settings were ignored. This has been corrected;
the new banner's settings now replace any settings that were previously
in effect.
- In past versions, alignment settings in <TD> (table cell)
tags propagated to the first block within the cell, but not to any
additional blocks. So, if you created a table cell which contained
more than one paragraph, the first paragraph was aligned correctly,
but subsequent paragraphs were aligned according to the enclosing
division's block alignment. This has been corrected; any <TD>
alignment setting now affects every block within the cell.
Changes in version 2.2.6
- The interaction between the inputkey() built-in function and
the automatic "MORE" prompt has been changed slightly to correct a problem.
In the past, the inputkey() function could retrieve keystrokes
even when a "MORE" prompt was being displayed, which could create confusing
situations when the text prompting for the keystroke had not yet been
scrolled into view itself. This has been corrected; inputkey
will never retrieve a keystroke until any after pending "MORE" prompt has
been acknowledged.
- Very long sequences of characters with no intervening spaces sometimes
caused incorrect formatting in past versions. This happened in particular
when long sequences of HTML entities appeared, such as twenty consecutive
sequences with no intervening spaces (note that using
the backslash-space sequence instead of produces the
same result). This has been corrected.
- A bug that occasionally crashed the HTML TADS debugger has been fixed.
The crash sometimes occurred as the debugger attempted to take control
when a run-time error occurred in the game.
Changes in version 2.2.5
- The <A> tag accepts a new attribute, PLAIN, that specifies that
any text within the link should be rendered as ordinary text, rather than
using the normal link attributes. Refer to
<A> changes for more information.
- In the preferences dialog, players can now select a fixed-width font,
if desired, for the main game font. In the past, the main game font popup
only offered proportional fonts; there was no particular reason for this
restriction other than to reduce the size of the list to make it more
manageable; some people didn't like the restriction, so fixed-width fonts
are now included in the list as well.
- In past versions, the HTML interpreter did not always work properly when
started from a DOS command prompt. In particular, if the command line
was specified using a relative path to the game file (for example:
htmltads games\mygame.gam), the interpreter did not properly load
resources (JPEG images, WAV sounds, etc.) bound into the .GAM file or
bound into a .RSn file. This problem has been corrected; starting the
HTML interpreter from a command prompt should work properly now, regardless
of whether the .GAM file is in the current directory or a different
directory specified with a relative or absolute path.
- The inputkey() built-in function did not work correctly in
past versions of the HTML interpreter. Although the function did wait until
the user pressed a key, the function did not return the correct value for
the key. This has been corrected.
- In past versions, table cell tags did not accept WIDTH attributes
with percentage values. Percentage-based cell WIDTH values are now
supported.
- Tables with empty cells (specified by a <TD> tag followed
immediately by another <TD> tag or a </TD>
tag) were not always formatted correctly in past versions; these sequences
usually caused the entire table to be displayed at the wrong position.
This problem was particularly noticeable in banners. This has been
corrected; empty cells are now handled correctly.
- A bug in the formatting of the <BANNER> tag caused a banner
to be displayed in certain situations even after a <BANNER REMOVE>
tag had been issued for the same ID. This has been corrected.
- In the past, the traditional TADS non-breaking space sequence,
"\ " (a backslash followed by a space), did not work correctly in the
HTML TADS interpreter; in particular, multiple consecutive backslash-space
sequences were displayed as a single space. This has been fixed.
- In previous versions, graphics placed in banners were not always
updated immediately after a palette change, which occasionally caused
brief drawing glitches. This has been corrected.
- If the user selected "highlight on
hovering" in the link color settings in the options dialog, the interpreter
did not always remove highlighting from a link positioned very close
to the edge of a banner if the mouse was moved off of the link and into
another banner (or the main text window). This works correctly now.
- A bug in past versions caused a crash on exit under obscure
circumstances: if the status line (or any other banner that was updated
after each turn) contained a link, and the mouse was positioned over the
link when the user typed "quit" and then left there, a crash sometimes
occurred. This has been corrected.
- See Recent Changes to TADS for
information about several generic TADS interpreter improvements and
corrections that affect the HTML interpreter as well:
- A new parser feature lets you define new methods, dobjCheck
and iobjCheck, that are always called before the
verb handlers (verIoVerb and so on).
- The HTML interpreter now supports external (native code) functions;
you can place native code into a DLL and call the code from within
your TADS program.
- A parser bug, involving using AGAIN with a command directed to an
actor that is no longer present, has been fixed.
- A parser bug caused incorrect prompts to be displayed when an unknown
word was entered in a command that required an additional object;
this has been corrected.
- A parser bug that caused doSynonym and ioSynonym
handling to work incorrectly with overridden methods is now fixed.
- The init function is no longer incorrectly invoked prior to
initRestore when restoring a saved game during start-up
(for example, when you double-clicked the saved game from Explorer).
- Backslashes in text captured by the outcapture() built-in
function are now handled correctly.
- An incompatibility with games compiled by old (pre-2.2.0) versions
of the compiler has been corrected.
Changes in version 2.2.4
Here's a quick index to some selected highlights in
this release:
Changes of Interest to Players:
- HTML TADS
is now distributed with a self-extracting installer.
Simply download the installer executable and run it; the setup program
will lead you through a brief series of dialogs to gather information
on how you want HTML TADS installed, and then will install the files
on your computer. The setup program will automatically create file type
associations that will let you double-click on a .GAM file to start
it at run-time, and will also create associations that let you
double-click on a .SAV file to start the associated game and restore
the saved position.
- As part of the new setup procedure, the installer creates an
uninstaller program that you can use to remove HTML TADS from your
computer. The uninstaller will remove all of the files, directories,
"Start" menu folders, and registry settings associated with HTML TADS.
- The interpreter can now
automatically restore a saved game immediately
upon starting. If you double-click a saved game (.SAV) file, the HTML
TADS interpreter will attempt to find the game that created the saved game
file, start the game, and immediately restore the saved position. Refer
to the description of the new interpreter command line option "-r" in
Recent Changes to TADS for more information.
- The "Preferences" dialog now provides an option to set the status
line color scheme. This setting will control the status line colors
for all non-HTML games, and for HTML games that use the default status
line color scheme. Some HTML-enabled games may not use the default
status line colors, and some may not have a traditional status line
at all, so the status line color preference settings will not affect
all HTML-enabled games.
- You can now
set hyperlink highlighting so that links are only
highlighted temporarily while you're holding down a key. Some people
find links distracting if they're visible all the time, but still
want an easy way to see links at certain times. The "View" menu now
has a "Link Highlighting" submenu for setting the visibility of links.
You can turn link highlighting entirely on or off as before, and in
addition you can set links to highlight only when the Ctrl key is
being held down. Note that you have to hold down the Ctrl key a short
time before the links are highlighted; this slight delay is intended
to avoid distracting redrawing when you're just pressing the control
key to activate an accelerator command.
- In addition to providing momentary spring-loaded link highlighting
via the control key as described above, you can now quickly switch back
and forth between having link highlighting on and off via the F5 key.
- The interpreter now allows you to click on a link even when the game
is in "MORE" mode (which means that the game has displayed too much
text to fit in the window, and is waiting for you to press a key to
scroll down through the extra text). In the past, the interpreter disabled
links while in "MORE" mode, because we felt that it could be confusing
to let the user click on a link when no command prompt was showing.
Unfortunately, visible but inactive links have proved to be even more
confusing. Now, the interpreter keeps links active even while in "MORE"
mode. If you click on a link while in "MORE" mode, the interpreter
scrolls to the bottom of the pending text, then enters the link command
as normal.
- For
players who prefer the traditional text game experience
and find graphics distracting, but still like the text
formatting power of HTML, the interpreter has a new option that
lets you turn off graphics.
The "Graphics" item on the "View" menu lets you toggle graphics on
and off. When the "Graphics" menu item is unchecked, HTML TADS
will display only text. Any <IMG> tags that include an ALT
attribute will be displayed as text using the value of the ALT
attribute; other <IMG> tags will simply not be displayed
at all. Other tags that can optionally incorporate graphics, such
as <LI> and <HR> will be displayed in their normal
non-graphical format, and background images (specified via
the <BODY BACKGROUND> tag) will not be displayed.
- The interpreter now provides a "file
safety level" setting, which allows the player to specify exactly
what types of explicit file I/O operations a game can perform. This
setting is available from the command line, and is also available
through the "Preferences" dialog. Refer to Recent Changes to TADS for details about
this new setting.
- The interpreter now provides a preference setting controlling how
the Alt+V keystroke is interpreted: you can set Alt+V to scroll up
a page (as some Emacs and similar editors behave), or to use the
normal Windows treatment as a menu shortcut. (In the past, the HTML
TADS interpreter always interpreted Alt+V as an Emacs-style "page up"
key, which non-Emacs users didn't like. The new default setting
treats Alt+V as a conventional Windows menu shortcut key.)
- While playing a game, the F1 key now enters the command "help"
on the command line, for processing by the game.
- The HTML TADS interpreter now uses large
memory settings (for -mh and so on) by default. This allows you
to play extremely large games without having to use special memory
options when starting the interpreter. The new default settings for
the HTML TADS interpreter are:
- -mh 65535 (heap size)
- -ms 512 (stack size)
- -u 60000 (undo size)
The debugger limits have been similarly increased.
- HTML TADS
now supports DirectX version 3 for digitized sound
playback (version 5 was previously required). This is especially
important for Windows NT version 4 users, because DirectX 3 is the
latest version available for Windows NT 4, and Microsoft has not
announced plans to support a higher version for NT users until NT 5
is released. Windows 95 users are still encouraged to upgrade to
DirectX 5 if possible, because it provides more efficient sound
playback; however, all features are supported using DirectX 3.
- On startup, HTML TADS now displays a warning dialog if
DirectSound initialization fails (which usually simply means
that DirectX isn't installed), to clarify why
sound isn't working. The dialog provides a checkbox to indicate
that you don't want to see it on startup in the future, so that
you can skip the warning if you're never planning to install DirectX.
If you select the View/Sound Effects menu item after DirectX
initialization failed, the interpreter will display the dialog
again (even if you've selected the checkbox to hide it on startup).
- On startup, HTML TADS checks to ensure that you have the correct
version of a required system file, ComCtl32.DLL, installed on your
system. (This file is included with Windows 95 and NT, but some
versions of the operating systems included an older version of
this file that is incompatible with HTML TADS, which requires
version 4.70 or later.) If the incorrect version of the DLL is
installed, HTML TADS displays a warning dialog; the dialog allows
you to proceed despite the problem, but this will usually make
HTML TADS work incorrectly (and the program will probably crash).
If you see this warning, you should upgrade your DLL by downloading
and running this file from the Microsoft web site:
ftp://ftp.microsoft.com/softlib/mslfiles/com32upd.exe.
I'd like to thank Klywarre (The Avatar) [aka: James Mallette]
for discovering the DLL incompatibility and tracking down the
solution.
- This version corrects several problems related to the "Next Page"
and "Previous Page" navigation items on the "Go" menu. The following
are all fixed:
- A bug caused crashes in some games when
using the "Next Page" and "Previous Page" navigation items on the "Go"
menu.
- There were a couple of small problems involving
the placement and visibility of the insertion point (the text caret) when
using these same navigation items.
- After clearing the screen, if the game immediately displayed a large
amount of text on the new page, the "More" prompt was not properly
displayed.
- When returning to a page with the "Previous Page" navigation command,
the window always displayed the page scrolled to the top. The window now
remembers the scrolling position that was in effect when the page was last
viewed and restores that position.
- The title bar now displays "HTML TADS" for games that don't explicitly
set the window title (it was "TADS HTML").
Changes of Interest to Game Authors:
- TADS now offers improved support for localized character sets.
In particular, TADS provides a way to use extended (non-ASCII) characters
in a game while retaining game portability. This new TADS feature is
supported in HTML TADS as well. Refer to the
character set notes for more information.
- The
BANNER tag has been extended to allow banners to be placed
at the top, bottom, left, or right edges of the window. Refer to
the new banner documentation for details.
- A new utility lets you build a
custom installer for your game, without any programming.
Refer to the game distribution
documentation for details.
- A
game author can now optionally create multiple resources bundle
files, separate from the .GAM file, for distributing a game and its
resources separately without having to distribute the individual
JPEG, WAV, and other files. This new mechanism allows game authors
to distribute their games in multiple configurations, so that players
can choose how much of a game they want to download and install.
This new mechanism is described in the
resource file documentation.
Note that this new feature requires the TADS resource manager
(tadsrsc) version 2.2.4 or higher; the resource manager
accompanies the TADS compiler and tools distribution.
- If
you build a stand-alone executable version of your game based
on the HTML TADS interpreter, you can now specify the desktop icon that
your executable uses. You specify this with the maketrx32
command when you build your stand-alone game. Refer to the
game distribution documentation for
more information.
- If you build a stand-alone executable version of your game based
on the HTML TADS interpreter, you can now specify a custom filename suffix
(extension) to use for saved game files created by your game. If you
do this, the stand-alone game will automatically create system registry
entries that associate the saved game files with your stand-alone game
executable, allowing the player to start your game and restore a saved
position in a single action by double-clicking on a saved game file.
Refer to the game distribution
documentation for more information.
- The new
TADS systemInfo() built-in function provides a way for
you to determine in your game code whether the interpreter which is
executing your game has certain capabilities, including whether
HTML can be used to format text. This function can
be especially useful if you want to customize your game for
different interpreter configurations. Refer to
Recent Changes to TADS for details.
- TADS has a new parser hook that gives you more control over how
the TADS parser handles unknown words in player commands. Refer to
Recent Changes to TADS for full details.
- TADS has a new language feature that lets you specify the
superclass from which you want a method to inherit when you use the
inherited keyword. Refer to Recent
Changes to TADS for information.
- TADS now allows you to change the object that represents the player
character dynamically, using the new parserSetMe built-in function.
Recent Changes to TADS has details.
- HTML TADS now supports the <Q> tag from HTML 4.0. This
tag encloses a passage in quotation marks. <Q> automatically
uses typographical quotation marks if they're available in the
character set. Nested <Q> tags alternate between double
and single quotes.
- The
typographical character extensions have been changed for
compatibility with HTML 4.0, which includes the same characters
with different names than were originally assigned by TADS.
The following character names have been changed to match the HTML 4.0
specification:
- &lsq; has been changed to ‘
- &rsq; has been changed to ’
- &ldq; has been changed to “
- &rdq; has been changed to ”
- &emdash; has been changed to —
- &endash; has been changed to –
Note that the old character codes are still allowed, but they're no
longer documented and should be considered obsolete.
- The following new special character codes from HTML 4.0 have been added.
- ‚ produces a single low-9 quote
- „ produces a double low-9 quote
- ‹ produces a single left angle quote
- › produces a single right angle quote
- † produces a dagger
- ‡ produces a double-dagger
- Πproduces a capital "OE" ligature
- œ produces a small "oe" ligature
- Ÿ produces a capital "Y" with an umlaut (diaeresis)
- Š produces the capital letter "S" with a caron
- š produces the small letter "s" with a caron
- ‰ produces a per-thousand sign
- In addition to the special characters listed above, HTML TADS now
supports all of the HTML 4.0 named character entities listed in the
HTML 4.0 specifications as "symbols, mathematical symbols, and Greek
letters." This list is not reproduced here because of its length,
but you can refer to the
HTML 4.0
specification for the full list. The only named character entities
that HTML TADS does not support are the spacing and joiner entities
(ensp, emsp, thinsp, zwnj, zwj), and the bidirectional markers (lrm, rlm).
- HTML TADS now provides an additional set of named character entities
to provide access to ISO Latin-2 characters. ISO Latin-2 is a character
set designed for Eastern and Central European languages. Standard HTML
does not yet provide named entities for these charaters, but HTML TADS
extends the standard entity list to support these additional characters.
Refer to the HTML TADS Latin-2 table for the
complete list.
- You can now enter hex digits in character entities by putting an
"x" after the "#"; for example, "ó" enters the hex value
F3.
- The Windows HTML TADS Debugger now uses MDI (Multiple Document
Interface). MDI is a common Windows application style in which all
of an application's windows are grouped together into a single container
window. The MDI style is well suited for applications such as the
Debugger that have a large
number of related windows that share common user interface controls,
such as toolbars and menu bars. Many users found the original Debugger
user interface to be unwieldy, because the various windows weren't
grouped together.
- The Windows version of the debugger will now ask you to locate
source files as it needs them, rather than requiring that all of the
proper include paths be specified on the command line. Whenever
the Windows debugger needs to open a source file, and the file isn't
in the .GAM file directory or anywhere on the include path, the
debugger will display a dialog asking you to locate the
source file. In addition, the debugger saves the list of directories
obtained in response to these prompts with the per-game configuration
information (in the game's .TDC file), so these settings are retained
in future sessions.
(Note that the DOS character-mode debugger still operates as before,
requiring source files to be on the include path at start-up.)
- The Windows version of the debugger now lets you access the
main debugger window's menu through the keyboard interface (using
the Alt key) even while one of the other debugger windows is active.
- The Windows version of the debugger now displays the game status
(running, paused, terminated) in the main debugger window's caption.
- In a source file window in the Windows version of the debugger,
certain keystrokes are now handled slightly differently, to make the
handling more consistent with other Windows programs. The Home and
End keys now move the cursor to the start and end of the current line,
respectively; Control+Home goes to the start of the file, and
Control+End goes to the end of the file. Page Up and
Page Down now move the cursor up and down a page; Control+Page Up and
Control+Page Down scroll the window without moving the cursor.
- To accomodate the editing key changes above, the Control+Home key
no longer goes to the current line, but now goes to the start of the
file. The Alt+Keypad * key now goes to the current line.
- For
game developers' use, the interpreter now displays diagnostic
messages in the debug log window for resource loading problems.
Whenever a JPEG, PNG, WAV, or MIDI resource cannot be loaded or
encounters an error, the interpreter displays information about the
problem in the debug log window. (Note that the debug log window
is only shown if you run with -debugwin specified on the command
line when invoking the interpreter. These messages won't interfere
with the main game window.)
- This version corrects a few bugs with tables:
- Under certain circumstances, using alignment attributes in TR
or TD tags caused the alignment settings to continue beyond
the table.
- If a table was the very first item in a banner, the table was
invisible.
- If a table had an explicit height specified (with a HEIGHT attribute
on the TABLE tag), the height was ignored.
- A table whose WIDTH setting exceeded the maximum width actually
necessary to display the table sometimes ignored the width setting.
(This only happened when the table had simple contents, such as
columns that only contained single words or pictures.)
- Some bugs involving banners are now fixed:
- If you used multiple banners, the status line was not always
updated properly when the player moved the mouse cursor over
a link.
- A text link appearing in a banner did not always use the correct color.
- This version corrects a problem with the debugger that caused the
debugger to crash sometimes when you single-stepped through code at the
very end of a source file.
-
The FACE attribute of the FONT tag now accepts a set of new "parameterized"
font names. The new parameterized fonts do not directly select a system
font by name, but instead select a style of font that can be mapped
to an appropriate installed font on each system. Because the parameterized
font names are mapped at run-time on each system, parameterized names are
much more portable than explicit system font names while still providing
you with some flexibility in specifying different styles. In addition,
some systems allow the player to select the actual system font that will
be displayed for a given parameterized font, thus giving greater control
over the final presentation to the player while still giving considerable
control over the style to the game author. Refer to
the HTML deviations documentation for
full details.
- In addition to the
standard HTML color names and numerical RGB values, the HTML parser now
provides a set of new "parameterized" color names. The parameterized
values do not map directly to hard-coded colors, but instead use
system-dependent colors that the player can change at run-time on
some systems. For example, the new color names "statusbg" and "statustext"
are system-defined colors for the status line background and status line
text, respectively; on Windows, the player can control the values of these
colors through the "Preferences" dialog. You can use the new parameterized
color names in any of the tag attributes that take a color value.
Refer to the HTML deviations documentation
for full details.
- The
HTML status line code in adv.t, which is enabled when
you compile your game with the preprocessor symbol USE_HTML_STATUS
defined, now automatically senses whether the game is running in HTML mode
or in standard mode, and generates an appropriate status line for the
current mode. This makes it easier to write a game that will run under
both HTML and standard interpreter systems, while still taking advantage of
HTML features when they're available. The enhanced status line code uses
the new systemInfo built-in function, described in
Recent Changes to TADS,
to sense whether HTML features are available at run-time. Note that,
even if you customize the status line, you may want to refer to the
new adv.t status line code and use similar logic in your custom
implementation, to support both types of interpreters.
- The default status line color scheme in adv.t now uses
the new "statustext" and "statusbg" parameterized color attributes,
which makes the status line colors controllable through the player
preferences (for platforms that provide a preferences mechanism).
- TADSERR.MSG (the TADS error message file) is now linked directly
into the interpreter, so the separate message file is no longer needed
when playing or distributing a game.
- Some small documentation problems have been fixed:
- the link from the introductory page to the debugger page is fixed
- the debugger page is now part of the normal interpreter distribution
- the debugger page no longer has its last few paragraphs in boldface.
- Some cosmetic problems have been fixed:
- The HTML TADS interpreter and debugger "About" boxes now display
the TADS version number
- The usage messages for the HTML TADS interpreter and debugger now
display their correct executable names