From: ghudson@athena.mit.edu (Gregory B Hudson)
Subject: VT 2.14 beta release
Followup-To: poster
X-Date: 12 Oct 1992 09:01:50 GMT
Organization: Massachusetts Institute of Technology
Date: Sun, 8 Nov 1992 07:25:27 GMT

Release notice for VT 2.14 beta, 10/12/92
-----------------------------------------

VT 2.14 beta is available for anonymous ftp on ftp.math.okstate.edu as
 /pub/muds/clients/vt/vt.2.14.beta.tar.Z.

The latest program release was VT 2.13 alpha 4 on July 9; the latest
distribution VTC code release was on July 20.  VT 2.14 beta contains
only minor and mostly user-invisible changes since these releases.

I am satisifed with the current state of the client, although I might
develop a help system at some point.  I'm essentially planning to
allow VT to go latent with the exception of bugfixes and an eventual
VT 2.14 release.

The 2.13 alpha releases came with little documentation.  For VT 2.14,
I have revised and supplemented the VT 2.12 documentation.  I have
developed a better set of examples, including a simple Scheme
interpreter written in VTC as an example of a large-scale application
(albeit a useless one).

I am releasing an updated version of the July 14 'extras' archive in
the VT 2.14 distribution.


Description
-----------

VT (Vaportalk) is a client program written to be easily extendible by
the author and by users.  VT is vaguely reminiscent of TF, but was
never intended to be backward-compatible with TF.  VT provides a
windowing system (TF users can envision the /visual mode with multiple
output windows) and an extension language, called VTC, which is
similar in syntax to C.

As an example of VT's extensibility, one of the 'extras' files in the
2.14 release is an interface to TinyMUSH systems.  One feature of this
interface is to autoescape lines beginning with ':' and '"' so that
they are not affected by the mush evaluator.  This feature is tailored
closely to a particular server's features.  On the flip side, I can be
connected to a Mush and another type of server at the same time and
only the Mush is affected by the interface.  Also, if the evaluator
for Mush ever changes, or if Mush becomes obsolete, users can simply
modify or discard mush.vtc.  The VT program itself does not have muds
in mind; the distribution code has only the barest idea of a generic
mud.


Liabilities and requirements
----------------------------

VT's biggest drawback, to most users, is size and runtime space
requirements.  Users of machines which are prone to thrashing because
of user load may find VT intolerably slow because of swapping.
Likewise, VT is slower than other clients because of the
interpretation that goes on, so users of slow machines may find VT
unuseable.

VT requires a terminal type that can use the cs (set scroll area)
capability.  This usually means a VT-102 emulator.

Some users complain about the rigidity of the VT interface.  It does
not have mode analagous to TF's "non-visual" mode, nor does it have
any options like /cleardone and /hn and so forth.  There is an input
window, and the input cursor sits at the bottom line of the screen at
all times, period.  I've found that catering to each user's separate
idea of the perfect interface is not worth the code bloat it created
in TF.  It can't be that big of a deal.


Author
------

VT was written and documented by Greg Hudson, who can be reached at
ghudson@athena.mit.edu.


---
Greg Hudson
Explorer_Bob@Space, etc.
ghudson@athena.mit.edu


--
rec.games.mud.announce submissions: rgm-announce@glia.biostr.washington.edu
other stuff related to that group:  rgm-announce-request@glia...
mudlist-related mail:		    mudlist@glia.biostr.washington.edu
other mail of a personal nature:    scott@glia... or scg@mentor.cc.purdue.edu
Newsgroups: rec.games.mud.announce