-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathtadsver.htm
2502 lines (2022 loc) · 105 KB
/
tadsver.htm
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<html>
<title>TADS Revision History</title>
<body>
<br><br><br>
<center><font size=+3>Recent Changes to TADS</font>
</center>
<h4>Index to Versions</h4>
<ul>
<!-- {$version-index} -->
<li><a href='#tads2517'><b>Version 2.5.17</b></a><br>
<li><a href='#tads2516'><b>Version 2.5.16</b></a><br>
<li><a href='#tads2515'><b>Version 2.5.15</b></a><br>
<li><a href='#tads2514'><b>Version 2.5.14</b></a><br>
<li><a href='#tads2513'><b>Version 2.5.13</b></a><br>
<li><a href='#tads2512'><b>Version 2.5.12</b></a><br>
<li><a href='#tads2511'><b>Version 2.5.11</b></a><br>
<li><a href='#tads2510'><b>Version 2.5.10</b></a><br>
<li><a href='#tads259'><b>Version 2.5.9</b></a><br>
<li><a href='#tads258'><b>Version 2.5.8</b></a><br>
<li><a href='#tads257'><b>Version 2.5.7</b></a><br>
<li><a href='#tads256'><b>Version 2.5.6</b></a><br>
<li><a href='#tads255'><b>Version 2.5.5</b></a><br>
<li><a href='#tads254'><b>Version 2.5.4</b></a><br>
<li><a href='#tads253'><b>Version 2.5.3</b></a><br>
<li><a href='#tads252'><b>Version 2.5.2</b></a><br>
<li><a href='#tads251'><b>Version 2.5.1</b></a><br>
<li><a href='#tads250'><b>Version 2.5.0</b></a><br>
</ul>
<h4>Organization of this Page</h4>
<p>This page is a list of recent changes to TADS, arranged
chronologically: changes are grouped by release, with the most recent
release listed first. Each release incorporates all new features and
corrections of each prior release unless otherwise stated.
<h4>Generic and Platform-Specific Changes</h4>
<p>
Since version 2.2.6, the TADS change log has been divided into
two separate files: one for "generic" changes that apply to TADS on
all types of computers and operating systems, and one for changes
that apply only to specific platforms. This file contains the
generic release notes. Platform-specific release notes are in a
separate file for each platform:
<blockquote>
<p><a href='dosver.htm'>Changes specific to MS-DOS and Windows</a>
</blockquote>
<h4>Multimedia vs. Text-Only Interpreters</h4>
<p>These release notes sometimes refer to the "character-mode" or
"text-only" TADS Interpreter. This is meant to distinguish the
traditional TADS Interpreter, which can only display text, from the
multimedia interpreters such as HTML TADS and HyperTADS, which can
display graphics as well as text. The traditional TADS Interpreter
has a graphical user interface on some systems, such as the
Macintosh, so it's not really a character-mode application on those
systems; nonetheless, we still refer to it here as the character-mode
Interpreter simply to make it clear that we're not talking about one
of the multimedia versions.
<h4><a name='oldlog'>Older Revisions</a></h4>
<p>To keep the size of this page under control, changes are listed here
only for the most recent several versions of TADS. Older release notes
are in separate files:
<ul>
<li>Generic changes from version 2.2.3 through 2.4.0 are in TADSV240.TXT.
<li>DOS-specific changes from version 2.2.3 through 2.4.0 are in
TADSV240.DOS.
<li>For DOS, all revisions from 2.0 through 2.1.0 are available in the
file TADSV200.DOS; those from 2.1.1 through 2.2.2 are in TADSV222.DOS.
<li>Similar files are available for
other platforms; please refer to your platform-specific release
notes for details.
</ul>
<p>Because the older revision history files are quite large and are
static (they are, after all, historical), they're not included in the
normal TADS distributions, but you can download them from the
Interactive Fiction Archive via the internet at <a
href='ftp://ftp.ifarchive.org/if-archive/programming/tads2/manuals/'>
ftp://ftp.ifarchive.org/if-archive/programming/tads2/manuals/</a>
(note that ftp.ifarchive.org is the new home, effective August 2001,
of the former ftp.gmd.de archive).
<!-- {$new-version-insertion-point} -->
<!------------------------------------------------------------------------>
<br><br><hr>
<h3><a name='tads2517'>Version 2.5.17</a></h3>
<i>Released May 16, 2013</i>
<ul>
<li>In the past, HTML <PRE> blocks were problematic if you
wanted to use <PRE> for precise indentation. The complication
was that the output formatter in the VM pre-filtered the text sent to
the HTML parser to consolidate each run of whitespace into a single
space. If you wanted to use spaces in a <PRE> block for
alignment purposes, you had to use quoted spaces (<tt>"\ "</tt> sequences)
to make sure that all of the spaces were sent through to the HTML parser.
<p>Now, the VM formatter layer watches for <PRE> tags. Within
a <PRE> block, the VM formatter passes spaces and
newlines through to the HTML parser without any filtering. This
change addresses
<a href="http://bugdb.tads.org/view.php?id=0000178">bug #0000178</a>
(which was filed as a TADS 3 bug, but effectively applied to TADS 2 as
well, because the output formatting and HTML handling are very similar
in TADS 2 and TADS 3).
<p>Note that there's another slight complication if you're writing
multi-line preformatted blocks with spacing for indentation. The
compiler normally removes the spaces that follow a line break within a
string. To preserve spaces after a line break within a string, put an
explicit <tt>\n</tt> sequence at the start of each line within a
multi-line string.
<li>On 64-bit Linux platforms, a bug in the compiler caused spurious
errors ("invalid property value") when an object definition contained
a property value set to a list containing constant values (e.g., <tt>p
= [1]</tt>). This has been corrected.
(<a href="http://bugdb.tads.org/view.php?id=0000106">bugdb.tads.org #0000106</a>)
</ul>
<!------------------------------------------------------------------------>
<br><br><hr>
<h3><a name='tads2516'>Version 2.5.16</a></h3>
<i>Released on August 30, 2012</i>
<ul>
<li>A couple of bugs appeared in version 2.5.15 due to internal
changes in the file safety mechanism. In particular, stand-alone
executable games on Windows could sometimes crash on start-up, and
compiling a game that accessed files within its preinit function
sometimes failed due to a spurious file error. The second problem
affected games using the gameinfo.t module to create a GameInfo file
within preinit. These are now fixed.
</ul>
<!------------------------------------------------------------------------>
<br><br><hr>
<h3><a name='tads2515'>Version 2.5.15</a></h3>
<i>Released on December 21, 2011</i>
<ul>
<li>In past versions of the text-only interpreters, if an
<ABOUTBOX> section contained an <IMG> tag with an ALT
attribute, the ALT text was displayed. It shouldn't have been,
because the text-only systems aren't supposed to display
<i>anything</i> that's within an <ABOUTBOX> section. This has
been corrected.
(<a href="http://bugdb.tads.org/view.php?id=0000063">bugdb.tads.org #0000063</a>)
<li>The text-only interpreters now parse and translate HTML
entity markups ("&" sequences) within <TITLE> tags when
setting the window title. (In past versions, the text-only
interpreters simply displayed the literal text of the &
sequences. The HTML interpreters didn't have this problem,
so this change doesn't affect them.)
(<a href="http://bugdb.tads.org/view.php?id=0000062">bugdb.tads.org #0000062</a>)
<li>Some older games (specifically, compiled with a version before
TADS 2.3.0, from 1999) use an old version of the file dialog functions
that wasn't able to specify the file type. For modern GUI operating
systems, the file type is fairly important, because the file selection
dialog usually uses this to filter the file list, and to set default
file types or extensions for new files. The interpreter now tries to
infer when the interpreter is asking for the name of a transcript
file, by looking at the prompt string. If it sees the word "script"
or "transcript" the prompt string, the interpreter now assumes that
it's asking for a transcript file, and sets the appropriate default
file type in the dialog.
<li>The interpreter core engine is now more careful at game
termination to release allocated memory. This generally won't make
any difference to players, as the operating system usually frees this
memory anyway at program exit, but it should improve stability in
interpreters that can run multiple games in series.
<li>In the past, it was possible for a game to crash the interpreter
by returning a fairly long (around 200-character) message from
parseError or parseErrorParam. This has been corrected. (<a
href="http://bugdb.tads.org/view.php?id=100">bugdb.tads.org
#0000100</a>)
<li>Some internal changes in the code address problems related to
memory management on 64-bit processors.
(<a href="http://bugdb.tads.org/view.php?id=0000084">bugdb.tads.org #0000084</a>)
</ul>
<!------------------------------------------------------------------------>
<br><br><hr>
<h3><a name='tads2514'>Version 2.5.14</a></h3>
<i>Released on May 5, 2009</i>
<ul>
<li>Objects created with 'new' during the preinit phase are now marked
as ordinary objects in the .gam file, as though they'd been defined
statically in the source code. The same thing applies to the
vocabulary words they use. This change means that objects created
dynamically during preinit are effectively permanent: they persist
through RESTART, RESTORE, UNDO, and the like, and they can't be
deleted with the 'delete' operator.
(<a href="http://bugdb.tads.org/view.php?id=0000055">bugdb.tads.org #0000055</a>)
</ul>
<!------------------------------------------------------------------------>
<br><br><hr>
<h3><a name='tads2513'>Version 2.5.13</a></h3>
<i>Released on April 28, 2009</i>
<ul>
<li>The new systemInfo() codes __SYSINFO_AUDIO_FADE and
__SYSINFO_AUDIO_CROSSFADE let you determine if the interpreter
supports audio fades and audio cross-fades, respectively. (Audio
fades are accessed through the HTML TADS <SOUND> tag.) These
codes return nil or 0 if fades/cross-fades aren't supported at all, or
an integer giving a combination of bit-flags indicating which audio
formats support fades/cross-fades. The bit flags are
__SYSINFO_AUDIOFADE_WAV, __SYSINFO_AUDIOFADE_MPEG,
__SYSINFO_AUDIOFADE_OGG, and __SYSINFO_AUDIOFADE_MIDI (for WAV, MP3,
Ogg Vorbis, and MIDI files, respectively). For example, if
systemInfo(__SYSINFO_AUDIO_FADE) returns (__SYSINFO_AUDIOFADE_WAV |
__SYSINFO_AUDIOFADE_OGG), it means that WAV and Ogg Vorbis files
support fades, but other audio formats don't.
<li>A bug in the compiler sometimes made the debugger show the wrong
source location when single-stepping within a single-line expression
property. (That is, a property with an executable expression, but no
curly braces, with the whole definition on a single line of text.)
This bug was mostly cosmetic, but in rare cases triggered a separate
bug in the debugger that could crash the debugger. When a single-line
expression property was immediately followed by a single-line method
(with braces), and execution stopped in the method due to
single-stepping or due to a run-time error, the debugger was unable to
show the execution location, and sometimes even crashed. Both of
these bugs are now fixed.
</ul>
<!------------------------------------------------------------------------>
<br><br><hr>
<h3><a name='tads2512'>Version 2.5.12</a></h3>
<i>Released on September 28, 2008</i>
<ul>
<li>The cvtnum() built-in function returned the wrong result for
negative values on occasion. The problem was dependent on chance
arrangements of the run-time string/list heap, so it occurred
essentially at random. This has been corrected - cvtnum() now
correctly stops at the end of the string. (<b>Workaround for
older versions:</b> append a non-digit character to the cvtnum()
argument - e.g., <tt>cvtnum(str + ';')</tt>. The problem was that
cvtnum() didn't properly detect the end of the input string, so it
sometimes scanned into random bytes in memory following the string
<i>if</i> those bytes happened to look like ASCII digits. However,
the function did always correctly stop upon reaching any non-digit
character, so explicitly appending a non-digit was enough to make the
function stop scanning, ensuring that it wouldn't stray past the end
of the string. This workaround isn't necessary with 2.5.12 and later,
since the underlying problem in cvtnum() is now fixed, but you can use
the workaround if you want to ensure compatibility with older
interpreter versions that some players might still be using.)
<li>In the past, run-time error messages (e.g., "[TADS-1010: object
value required]") were omitted from the transcript. This was
particularly inconvenient for beta testing, since any errors
encountered by testers were invisible in their session logs. These
messages are now included in the transcript.
(<a href="http://bugdb.tads.org/view.php?id=0000032">bugdb.tads.org #0000032</a>)
</ul>
<!------------------------------------------------------------------------>
<br><br><hr>
<h3><a name='tads2511'>Version 2.5.11</a></h3>
<i>Released on August 9, 2008</i>
<ul>
<li>The parser now leaves the antecedent of "it" intact when a command
involves a number or string. That is, "it" will simply refer to the
noun phrase from the second-most-recent command when the most recent
command involves a number or string as its noun phrase: "x box; note
5; x it" will now treat the "it" in the last command as referring to
the box. In the past, the parser simply forgot any antecedent in this
type of situation. That was intentional, to avoid any confusion over
whether "it" should refer to the number or string, but in practice
players don't seem to find this confusing at all and expect "it" to
continue referring to the last real object.
(<a href="http://bugdb.tads.org/view.php?id=0000014">bugdb.tads.org #0000014</a>)
<li>The parser showed a somewhat confusing parser error message for
player commands of the form "verb x OF y" in some cases. If x and y
were valid nouns or adjectives, but the combination "x OF y" didn't
match any object's vocabulary (e.g., there's a BOX and some PAPER, but
there's no such object as BOX OF PAPER), the parser treated this
command as though it were a <i>two-object</i> verb, such as PUT IN or
LOCK WITH - that is, the OF was treated as a verb-phrase preposition,
and x and y were treated as (respectively) the direct and indirect
objects. This often resulted in the parser error "I don't recognize
that sentence," since OF is a rare preposition in verb phrases. For
example, EXAMINE BOX OF PAPER would be treated as an EXAMINE OF
command, which most games don't defined as a valid verb phrase. In
such cases, the parser now checks to see if it <i>could</i> have
formed a syntactically valid noun phrase from the whole "x OF y"
phrase, and if so, shows the more sensible error "I don't see any x of
y here."
(<a href="http://bugdb.tads.org/view.php?id=0000010">bugdb.tads.org #0000010</a>)
<li>If the game executed parserReplaceCommand() from within certain of
the "parser hook" functions, the interpreter displayed the run-time
error "TADS-1024: 'abort' statement executed". This happened because
of the way parserReplaceCommand() works internally, but it obviously
shouldn't result in an error message. This is now fixed.
(<a href="http://bugdb.tads.org/view.php?id=0000011">bugdb.tads.org #0000011</a>)
<li>The compiler's -p option (to make the compiler pause before
terminating, to give you a chance to read the output) didn't work
in some cases where an error occurred during compilation. This
has been fixed.
(<a href="http://bugdb.tads.org/view.php?id=0000015">bugdb.tads.org #0000015</a>)
</ul>
<!------------------------------------------------------------------------>
<br><br><hr>
<h3><a name='tads2510'>Version 2.5.10</a></h3>
<i>Released on August 17, 2006</i>
<ul>
<li>The INVENTORY TALL command now respects "quiet" containers and
surfaces (that is, the contents of these objects will not be listed in
the inventory). In the past, the default INVENTORY WIDE mode
respected the "quiet" flags, but TALL mode didn't. INVENTORY TALL
also now properly takes into account the "contentsVisible" settings of
the objects listed. These changes ensure that WIDE and TALL modes
yield the same information.
<li>In adv.t, the default message for TELL <i>thing</i> ABOUT
<i>topic</i> now properly takes into account the number (singular or
plural) of the thing, so the message will now change to "...are
interested" when the thing has a plural name. In the past, the text
always said "is interested," which was ungrammatical when the thing
had a plural name.
<li>A bug in the interpreter caused unpredictable behavior, sometimes
crashing the interpreter, when starting certain games, including
recent release <i>Finding Martin</i>. The problem was triggered by
a very large number of objects (more than about 150) in a single
location, so it didn't affect most games, and it appeared somewhat
sporadically even for games that did trigger it. The bug has now
been fixed.
<li>An interpreter bug caused delword() to occasionally and
unpredictably delete extra words beyond what it was actually
asked to delete. This has been corrected.
<li>In the past, if the player's answer to a disambiguation question
had certain kinds of syntax errors, the parser responded with a
suitable error message, but incorrectly showed that message twice in a
row. This was due to an interpreter bug, which has now been corrected.
<li>In adv.t, the messages for "the key doesn't fit" in
doorway.doLockWith and doorway.doUnlockWith were phrased incorrectly
in some cases (in particular, the subject and verb didn't always
agree). This has been corrected.
</ul>
<!------------------------------------------------------------------------>
<br><br><hr>
<h3><a name='tads259'>Version 2.5.9</a></h3>
<i>Released on September 12, 2004</i>
<ul>
<li>The "file safety" levels have changed slightly to provide better
security against malicious game programs. First, level 2, which
formerly provided global read access but no write access, now instead
provides read/write access to the current working directory only (the
game isn't allowed any access to files outside of the working
directory). Second, the default safety level is now level 2. In the
past, level 1 (read from any file/write to current directory only) was
the default, which left open the possibility that a game could access
data outside of the working directory. A malicious game could
conceivably have exploited this by, for example, secretly copying
sensitive data to the game directory for later use by a coordinating
network worm, or by encoding the data in a hyperlink (displayed in an
HTML-enabled game) that takes the player to a spyware site when
clicked. The new default setting should effectively eliminate these
risks by barring access to any files outside of the working directory.
<li>A bug in the compiler sometimes caused crashes when the "preinit"
function called certain built-in functions, particularly for file
manipulation. The problem was somewhat random, and tended to show up
on some machines and not others, because it depended on memory
conditions left over from other programs. The problem showed up for
several people when they included the "gameinfo.t" module in their
games, because that module writes a text file during preinit. The bug
has now been fixed.
<li>An interpreter bug was capable of corrupting list values during
game execution under very rare conditions. The bug only showed up
when assigning a value to an indexed element of a list (either
directly or via the "+=" or "-=" operators) at just the right moment
to trigger garbage collection, and only then when the list happened to
be situated in memory in just the right way. The bug was more likely
to occur with small "heap" memory settings (the "-mh" option); with
the large default heap of most current interpreters, the bug almost
never showed up. The bug was also quite unlikely to occur except in
games that perform unusually heavy list processing. The bug
manifested itself in unpredictable ways, ranging from spurious
run-time errors to interpreter crashes. This has now been fixed.
Note that most games that were likely to trigger the bug in the past
will now instead cause a "heap overflow" error; this error is valid,
and indicates that the game exhausted the available memory for
processing list and string values. If a heap overflow does occur
while running a game, try increasing the heap size using the "-mh"
command-line option when you run the game.
<li>An inconsistency in the command parser has been fixed. In the
past, the parser didn't properly take into account whether responses
to missing object prompts were singular or plural. This caused some
subtle differences between typing a full command and piecing a command
together with missing object prompts. In particular, the parser
didn't announce the object names for a plural response, and didn't
check rejectMultiDobj. This has been fixed, so the parser's behavior
is now consistent for missing object responses.
<li>In the past, the parser incorrectly treated THEM as plural even
when it referred to only one object, so it checked with
rejectMultiDobj in these cases. This is undesirable in some cases,
especially when the single object being referred to is an object whose
name has plural usage. The parser now treats THEM as singular when it
refers to just one object.
</ul>
<!------------------------------------------------------------------------>
<br><br><hr>
<h3><a name='tads258'>Version 2.5.8</a></h3>
<i>Released on June 12, 2004</i>
<ul>
<li>In adv.t, THROW AT now uses a new method, throwHitDest, to
determine where the thrown object lands. This method is called for
the actor's current location; by default, it simply returns 'self', so
a thrown object simply lands in the actor's current location. This is
the same behavior as in the past. However, the special 'theFloor'
object overrides this to return the current room. This corrects a
problem that occurred when the player sat on the floor and then threw
something: because the object formerly ended up in the actor's
location, the object landed in the 'theFloor' object, at which point
the object became inaccessible. This change ensures that a thrown
object will never be moved into 'theFloor', but will always land in
the actor's actual room location. As a side benefit, the new method
also makes it possible to customize the location where objects land
when thrown from within a nested room.
<li>When running in HTML mode, the default parser error message 1 ("I
don't understand the punctuation %c") now includes an "\H-" sequence
before the message to ensure that the unrecognized character is
displayed literally if it's an HTML markup-significant character
(such as '<' or '&'). It also shows an "\H+" sequence after
the message to restore HTML mode. In the past, if the player entered
a markup-significant character while the interpreter was in HTML
mode, the HTML parser could become momentarily confused, leading to
strange output.
<li>The new parser hook parseDefaultExt() extends the parseDefault()
function. The new function takes two additional parameters, giving
the actor and deepverb object involved in the command; the new
parameter list is parseDefaultExt(actor, verb, obj, prp). If the game
defines parseDefaultExt(), then the interpreter ignores parseDefault()
and calls parseDefaultExt() instead. If the game does not define
parseDefaultExt(), but does define parseDefault(), the interpreter
uses parseDefault() as it used to, which ensures that existing games
will continue to run unchanged. You can use the new extended version
of the function if you need the actor and/or verb information in
displaying the default object message; this is useful in some
non-English languages where a default object name's noun phrase must
be inflected according to its usage in the command.
<li>The new parser hook preparseExt() allows the game to inspect and
optionally change text the player types in response to parser
questions: disambiguation queries, requests for missing direct or
indirect objects, and OOPS typo-correction opportunities. The new
function's parameter list is preparseExt(actor, verb, str, typ), where
'actor' is the actor performing the command, 'verb' is the deepverb
object, 'str' is a string containing the exact text the player typed
in, and 'typ' is an integer giving the type of query the player is
responding to. The meaning of 'typ' is the same as the that of the
type codes passed to commandPrompt() and commandAfterRead(). The
function can return a new string, which the parser will use to replace
the text the user typed; true, to proceed with the original text the
user typed; or nil, to treat the user's text as a brand new command,
bypassing the special interpretation as a response to the parser's
question. The game doesn't have to define the preparseExt() function;
it's purely optional, so existing games will not be affected.
<li>When the interpreter looks for external resource bundles (*.rsN files),
it now looks for the files using lower-case <i>and</i> upper-case suffixes
(in other words, it looks for both *.rs0 and *.RS0, and likewise for digits
1-9). Lower-case suffixes are tried first, then upper-case. This change
makes the naming system more flexible on systems with case-sensitive
file systems, such as Unix; for systems such as Windows and Macintosh that
have case-insensitive file systems, this change will have no effect.
<li>A bug in the parser made it impossible to use numeric adjectives
in certain phrasings. In particular, if a given word was defined in
a game as both a noun and an adjective, but the word was defined only as
a noun for a given object that takes a numeric adjective, then the
phrasing <i>noun</i> <i>number</i> didn't match the object. For example,
if the word "switch" was defined as a noun for a given numbered switch,
but "switch" was defined as an adjective for some other object, then
"switch 5" didn't match the switch even if "5 switch" did. This has
been corrected.
<li>The compiler now checks for missing symbols before running the
'preinit' function, and skips running preinit if any symbols are
undefined. In the past, the compiler called preinit even if some
symbols were undefined; if preinit itself called any undefined
functions or invoked methods of undefined objects, this sometimes
led to misleading error messages. The compiler will now simply
point out the missing symbols, and skip running preinit entirely.
<li>The compiler now allows filenames up to 255 characters to appear
in the source file names in debugging records. In the past, the limit
was 127 characters. <b>Important note:</b> due to a bug, older
interpreters cannot properly handle .gam files compiled with debugging
information with path names over 127 characters. Attempting to load
.gam files with debugging information containing long source file
names will cause unpredictable results. Since some users might still
have older interpreter versions, <b>we strongly advise against
releasing games compiled with debugging information</b>. That is, you
should never release a game that you compiled with the "-ds" or "-ds2"
options.
<li>In the past, if the game code called a function or method, using
the return value of another function or method as an argument, and the
other function or method didn't actually return any value for the
argument, the results were unpredictable; in some cases, this even
caused the interpreter to crash. The interpreter is now more careful
about checking for these cases; when they occur, the interpreter now
automatically adds 'nil' values for the missing arguments. This
should ensure that errant code won't crash the interpreter, without
breaking any existing code with "asymptomatic" instances of this
error.
<li>The default "file safety level" for the command-line interpreters
is now set to 1, which allows reading files from anywhere on the disk,
but allows writing files only to the current working directory. This
protects against malicious game authors attempting, for example, to
modify your operating system's files. You can manually override this
to use a more permissive or more protective level using the "-s" option.
<li>External functions are now obsolete and can no longer be used on
any platform. One of the nice things about running games with a
system like TADS is that you don't have to worry as much about
viruses and other malicious code when playing downloaded games, since
games run in the interpreter environment rather than as native code.
The external function feature made it possible for games to call out
to native code, though, so a malicious author could have used
external functions to do damage to a user's system. Removing this
feature eliminates this security loophole. External functions were
only supported on a few platforms to start with, and they never
caught on with authors, probably because they were difficult to use
and had serious drawbacks (such as complete unportability). Since no
one has ever had much use for this feature, and because of the
potential security vulnerability, we've decided that there's no
reason to keep it around.
<li>In the past, the compiler did not accept 'self' as an element in a
list, even in contexts where 'self' was otherwise valid. The compiler
now does accept 'self' as a list element in method contexts.
<li>A bug in the interpreter sometimes made the result of the
subtract-and-assign operator ("-=") incorrect under certain
circumstances: specifically, the problem occurred when the left-hand
side was a local variable, the local variable contained a list value,
and the list value did <i>not</i> contain the value on the right-hand
side of the operator. In some such cases, a run-time error occurred;
in some others, the wrong value was assigned to the local variable.
This has been corrected; when the value on the right side is not in
the list, the list value in the local is simply left unchanged.
<li>Due to a bug, the compiler sometimes crashed if you used a "break"
and "continue" statement in an invalid context (i.e., outside of a
"while", "for", "do", or, in the case of "break", a "switch"
statement). This has been corrected; the compiler now simply flags
these as errors, but shouldn't crash.
</ul>
<!------------------------------------------------------------------------>
<br><br><hr>
<h3><a name='tads257'>Version 2.5.7</a></h3>
<i>Released on September 22, 2002</i>
<ul>
<li>The new system information code __SYSINFO_INTERP_CLASS returns
information on the "class" of interpreter currently running. This
returns one of the following codes:
<ul>
<li>__SYSINFO_IC_TEXT: a text-only, character-mode interpreter,
such as an MS-DOS or Unix interpreter. These interpreters use
a single, fixed-pitch font, and support the text-only HTML subset.
<li>__SYSINFO_IC_TEXTGUI: a text-only interpreter on a graphical
platform, such as MacTADS or WinTADS. These interpreters behave
essentially identically to character-mode text-only interpreters,
so from the game program's perspective there is no practical
difference between this and character-mode interpreters.
<li>__SYSINFO_IC_HTML: a full HTML-enabled interpreter on a
graphical platform, such as HTML TADS on Windows or HyperTADS on
Macintosh. These interpreters can display text and graphics,
use multiple fonts, and interpret the full HTML TADS markup language.
</ul>
<li>The travel system in adv.t has been enhanced slightly to allow
rooms to differentiate their travel behavior for travel by the player
character vs. travel by non-player characters. The new properties
actorNorth, actorSouth, actorEast, actorWest, actorNE, actorNW,
actorSE, actorSW, actorUp, actorDown, actorIn, and actorOut are now
called when an NPC attempts travel; these properties correspond to the
traditional properties north, south, east, west, and so on, and the
only difference is that the new properties are called when NPC's
travel. The traditional properties are still called for all player
character travel. By default, each of the new actorXxx properties
simply returns the value of the corresponding traditional property: so
actorNorth by default simply returns the value of (self.north). This
means that if you don't want to differentiate NPC travel from PC
travel, you need do nothing at all; but if you want a particular
travel direction from a particular room to work differently for
an NPC than it does for the player character, you simply need to
override actorNorth (or whichever direction you want to customize)
in that location. Thanks to Tommy Nordgren for suggesting this
enhancement.
</ul>
<!------------------------------------------------------------------------>
<br><br><hr>
<h3><a name='tads256'>Version 2.5.6</a></h3>
<i>Released on June 1, 2002</i>
<ul>
<li>The new system information code __SYSINFO_TEXT_COLORS tests for
text color support. Currently, only the HTML interpreters support
text colors; the text-only interpreters have no text color support.
The return value indicates the level of support available:
<ul>
<li>0/nil - no text color support
<li>1 - parameterized color names only (TEXT, STATUSTEXT, etc.)
<li>2 - the eight ANSI colors (white, black, red, blue, green,
yellow, magenta, cyan) are supported for the text
foreground color, but the background color cannot be set
<li>3 - the eight ANSI colors are supported for text foreground
and background colors
<li>4 - full RGB colors are supported, foreground and background
(the HTML interpreters generally return this code)
</ul>
<li>The new system information code __SYSINFO_TEXT_HILITE tests for
text highlighting support. This returns 1 if the interpreter is
capable of rendering highlighted text (i.e., text within "\( \)"
sequences, or text in HTML <B> sequences) with a distinctive
appearance, 0 or nil if not. Most interpreters are capable of
showing highlighting, except when running in "plain" mode or when
using a terminal or display device that has no ability to show
different text colors or styles.
<li>The new system information code __SYSINFO_OGG tests for Ogg Vorbis
audio format support. systemInfo(__SYSINFO_OGG) returns 1 if the Ogg
Vorbis format is supported by the interpreter, 0 if not.
<li>The new system information codes __SYSINFO_MNG, __SYSINFO_MNG_TRANS,
and __SYSINFO_MNG_ALPHA test for basic MNG (animated image) suport,
MNG transparency support, and MNG alpha-channel support, respectively.
These are analogous in meaning to the PNG information codes.
<li>The interpreter now includes the name of the external resource
(.rsn) file in error messages that result from errors reading these
files. In the past, the interpreter did not indicate which specific
file was causing the problem, which made it difficult to track down
where the problem was. (The non-specific error message worked fine
in the days before external resource files, when everything was
always in the single .gam file, but the new, more specific diagnostic
information is important now that a game's resources can be put in
several separate files.)
<li>In adv.t, <tt>basicMe.moveInto(room)</tt> now calls a new method,
<tt>room.meIsMovingInto(self)</tt>, whenever the <tt>basicMe</tt> object being
moved is the current player character (i.e., <tt>self</tt> is the object that
<tt>parserGetMe()</tt> returns). A default implementation of
<tt>meIsMovingInto(meActor)</tt> has been added to <tt>room</tt>;
this default implementation does nothing. Finally, an overriding
implementation of <tt>meIsMovingInto(meActor)</tt> has been added
to <tt>theFloor</tt>; this implementation sets <tt>theFloor.sitloc</tt>
to the player character actor's previous location. The purpose of all
of this new mechanism is to ensure that <tt>theFloor.sitloc</tt> is
properly set to the player character's prior location whenever the
player character is explicitly moved into <tt>theFloor</tt>. In the
past, <tt>theFloor.sitloc</tt> was set whenever the player character
moved to <tt>theFloor</tt> via a "sit on the floor" command from the
player, but wasn't set when the object was moved to <tt>theFloor</tt>
through other means. The <tt>theFloor</tt> object uses the <tt>sitloc</tt>
property to remember the location that originally contained the actor
before sitting on the floor; this is needed because <tt>theFloor</tt>
is a floating item and thus doesn't have an actual location of its own.
<li>In adv.t, the various <tt>hider</tt> subclasses (<tt>underHider</tt>,
<tt>searchHider</tt>, <tt>behindHider</tt>) now check to see if they
were never hiding anything to start with, and issue an appropriate
message if so. In the past, if an object was defined using one of
the <tt>hider</tt> subclasses, but no other object was ever hidden
inside the <tt>hider</tt>, looking in/under/behind the object generated
an erroneous message, of the form "You find , which you take." Now,
when the list of hidden objects is initially empty, the generated
message is simply "You find nothing under (the object)."
<li>The <tt>parserDictLookup()</tt> function can now be called
from within <tt>init()</tt>. In the past, this function caused
a run-time error if called while <tt>init()</tt> was running; this
has been corrected.
<li>Fixed a problem in parserGetObj(PO_ACTOR) that caused the incorrect
actor to be reported between the time <tt>preinit</tt> was called and
the time <tt>preCommand</tt> was called. During this window, if a
command was the first command on a new command line, and the command
line didn't start with a target actor ("bob, ..."), then
parserGetObj(PO_ACTOR) incorrectly returned the actor from the
previous command. This no longer occurs; the function now correctly
returns the current "me" object in such cases.
<li>Fixed a problem in the output formatter that caused problems
with displaying a series of quoted spaces ('\ ' sequences) in some
situations, especially on platforms with proportionally-spaced
display fonts such as the Mac. This has been corrected.
<li>The compiler no longer treats any characters in the "extended"
character set (i.e., characters with character codes outside the
ASCII range 0 to 127) as whitespace. In the past, the compiler on
some platforms treated certain extended characters as spaces, which
sometimes caused problems for authors working in non-English
languages. The compiler has no knowledge of the attributes of any
localized character sets (the compiler's character set translation
mechanism does not provide attribute information, only set-to-set
mapping information), so it was incorrect of the compiler to assume
anything about which extended characters represented whitespace
characters. This problem manifested itself most apparently when
a string containing extended characters spanned several lines of
source; if the compiler mistook any of the leading characters on
continuation lines for whitespace, it would remove them, resulting
in incorrect text displayed at run-time. This has been corrected;
the compiler now treats all extended characters as non-whitespace
characters.
<li>Fixed a problem in the <tt>execCommand()</tt> built-in function
that caused various problems ranging from data value corruptions to
interpreter crashes. The problem appeared when <tt>execCommand</tt>
was used to execute a command that terminated with an <tt>exit</tt> or
<tt>abort</tt>, and then only when certain combinations of operations
on local variables followed. The problem has been corrected.
<li>Fixed a compiler bug that caused an infinite loop when parsing
certain nested <tt>switch</tt> statements. A <tt>switch</tt> containing
string constant <tt>case</tt> labels nested within another <tt>switch</tt>
with string constant <tt>case</tt> labels sporadically caused this
problem. This has been corrected.
<li>Fixed a problem in the compiler that caused the <tt>contents</tt>
lists of objects to be initialized improperly in certain cases. In
particular, if an object's <tt>contents</tt> list was used during
execution of the <tt>preinit</tt> function, any object that inherited
a <tt>location</tt> value equal to the given object was omitted from
the given object's <tt>contents</tt> list, when clearly the object
should have been included in the list. This only affected
<tt>preinit</tt>, and then only when a <tt>contents</tt> that should
have contained an object with an inherited location was referenced
from within the <tt>preinit</tt> function. This has been corrected;
inherited <tt>location</tt> values are now properly handled when
<tt>preinit</tt> is executing.
<li>The compiler and interpreter must sometimes create temporary
files for internal memory management purposes. On certain systems
(in particular, DOS, Windows, and Unix), TADS determines a suitable
directory location to store any needed temporary files by looking in
the environment for variables called TEMPDIR, TMPDIR, TEMP, and TMP
(in that order), and using the value of the first such variable it
finds as the temporary directory path. In past versions, if the path
found in this manner was invalid, the interpreter or compiler would
usually terminate with an error message that wasn't very helpful in
tracking down the problem. In most cases, the error message was
"unable to open swap file." This has been changed; now, if the
temporary path obtained from the environment variables is invalid,
TADS ignores the path and simply creates any necessary temporary
files in the current working directory.
<li>A number of messages in adv.t now use format strings ("%you%" and
the like) where they didn't before but should have, to facilitate
games written in styles other than second-person. Thanks go to
Bennett Standeven for catching these.
<li>Fixed a problem that caused interpreter crashes under rare
circumstances for interpreters that could play more than one game in
a single session (such as the HTML TADS interpreter). If the
interpreter loaded a game that used the "output filter function"
feature, and then that game was terminated and another game was
loaded into the same interpreter session, and the new game didn't use
its own output filter function, results were unpredictable, and
interpreter crashes sometimes occurred. This has been corrected.
(This problem did not affect most platforms, because most
interpreters terminate when the game being executed terminates.)
<li>Fixed an interpreter problem that caused the "<tt>new</tt>"
operator to generate a run-time error in some unusual situations.
In particular, if the constructor modified a property of the
object containing the method that invoked the <tt>new</tt>
operator (directly in its own code, or in any code it invoked),
then the error "TADS-5: attempting to reallocate a locked object"
appeared sporadically. This has been corrected.
</ul>
<!------------------------------------------------------------------------>
<br><br><hr>
<h3><a name='tads255'>Version 2.5.5</a></h3>
<i>Released on September 27, 2000</i>
<ul>
<li>In adv.t, a comment in listcontgen() has been fixed to reflect
that it's actually part of the "tall" listing rather than the "wide"
listing.
<li>In adv.t, in moveableActor.travelTo, if the actor's previous
location was nil, a run-time error occurred. This has been corrected.
<li>In adv.t, in thing.thatdesc, the plural form has been changed to
display "those" rather than "them"; this provides a better parallel to
the singular display ("that").
</ul>
<!------------------------------------------------------------------------>
<br><br><hr>
<h3><a name='tads254'>Version 2.5.4</a></h3>
<i>Released on June 17, 2000</i>
<h4>New systemInfo() flags for PNG transparency</h4>
<p>Two new systemInfo() flags have been added to test for support of
certain features of the PNG image format:
<ul>
<li>__SYSINFO_PNG_TRANS: tests for PNG transparency support. Some
newer versions of the HTML interpreter support PNG transparency,
which allows parts of a PNG image to be designated as transparent so
that the background shows through. systemInfo(__SYSINFO_PNG_TRANS)
returns true if transparency is supported when displaying PNG images,
nil if not. This will never return true under interpreters that don't
support PNG images at all. Note that this flag indicates only <i>simple</i>
transparency support, which allows pixels to be designated as fully
opaque or fully transparent, and does not imply support of full alpha
blending; some interpreters (such as the Windows
HTML interpreter 2.5.4) support only simple transparency but not
alpha blending.
<li>__SYSINFO_PNG_ALPHA: tests for PNG "alpha blending" support, which
allows individual pixels of a PNG image to be designated as partially
transparent. Currently, none of the interpreters support alpha blending
in PNG images; this flag has been added for possible future use.
</ul>
<h4>Bug Fixes</h4>
<ul>
<li>A bug in the compiler caused a crash under certain unusual conditions
when the program defined a symbol as an object, and the symbol
was already defined as a property or function. Most of the time, the
compiler reported an error ("redefining symbol as object"), but in some
cases the compiler crashed. This has been corrected.
</ul>
<br><br><hr>
<h3><a name='tads253'>Version 2.5.3</a></h3>
<i>Released on April 16, 2000</i>
<p>This version contains no changes to text-only versions of TADS; the
only changes are in HTML versions.
<br><br><hr>
<h3><a name='tads252'>Version 2.5.2</a></h3>
<i>Released on March 27, 2000</i>
<h4>Index of Changes</h4>
<ul>
<li><a href='#isThem'>Parser recognizes isThem</a>
<li><a href='#scoreFormat'>New scoreFormat() Function</a>
<li><a href='#sysinfo252'>New systemInfo() Capability Codes</a>
<li><a href='#bugs252'>Bugs Fixed</a>
</ul>
<a name='isThem'></a>
<h4>Parser recognizes isThem</h4>
<p>
The parser now recognizes the <tt>isThem</tt> property for the purposes
of deciding on the pronoun to display when prompting for an indirect
object. In the past, the parser only recognized the <tt>isHim</tt>
and <tt>isHer</tt> properties, and used the pronoun "it" if neither of
these properties were consistently defined for the objects matching the
direct object. The parser now uses the pronoun "them" if the matching
objects all have <tt>isThem</tt> set to <tt>true</tt>.
<p>
For example:
<p><pre>
>throw pants
What do you want to throw them at?
</pre>
<a name='scoreFormat'></a>
<h4>New <tt>scoreFormat()</tt> Function</h4>
<p>
The way that adv.t displays the status line has been changed slightly
to simplify coding of special formats. A new function,
<tt>scoreFormat()</tt>, is now responsible for formatting the string
to display in the right half of the status line. <tt>scoreFormat()</tt>
takes the current score and the current turn counter as arguments, and
returns a string to display in the right half of the status line. The
default implementation in adv.t simply returns a string consisting of
the score, a slash ("/"), and the turn count, which provides the same
format that adv.t has traditionally used for the status line.
<p>