TOP v3.00wb1 Notes
------------------

    This file tells you everything you need to know about TOP v3.00wb1,
including what's new and how to upgrade.  Please read the entire file
thoroughly to ensure the new beta will work on your system.

    This file can be thought of as an addendum to TOP.DOC.  Although an updated
TOP.DOC has been included with this version of TOP, it does not cover
installation and describes new features as if they are working perfectly, which
they may not be.  Also, it does not cover some of the smaller new features
which need some attention.

    NOTE:  Wide betas of TOP are being distributed as upgrades from TOP v2.00
only.  If you wish to install TOP for the first time, please obtain a copy of
TOP v2.00 and follow its installation instructions before applying this
upgrade.

                                   ==========
                                   Disclaimer
                                   ==========

    This is a wide beta version of TOP.  It is being released because the
recent downsizing of the BBS community makes it too hard to find dedicated
testers.  I prefer private testing as it makes it easier to work closely with
testers, but this is reality.  So, I can only say that your feedback and
assistance (if needed) will help improve TOP.

    This wide beta comes with no guarantees, so be sure to make backups of your
current TOP configuration!  Should the beta fail to work properly, you will
need to be able to restore your existing setup.  I recommend archiving your
entire TOP directory (TOPPath) as well as your ANSI directory (TOPANSIPath).
If space does not permit this, backup all of the following:  *.CFG, *.ACT,
*.TOP, *.LNG, *.KEY.  Also, be sure to have the full TOP v2.00 distribution
archive backed up somewhere.

                                ===============
                                Revised Licence
                                ===============

    A revised LICENCE.DOC and REGISTER.DOC have been included with this archive
to reflect changes in both policy and author accessibility.  Essentially,
registration of TOP is now completely optional, and the author is only
available via Internet email.

    BTW, if you still wish to register TOP, prices have been slashed.  After
the final version of TOP (see "Future Plans") it will no longer be possible to
register, so if you are one of those amazing and commendable sysops who likes
to have everything on your system registered, now is the time.  Personally, I
do not care if you register or not, but because a significant number of people
have registered in the past, I am leaving the registration feature intact as a
courtesy.

                          ============================
                          Introduction to TOP v3.00wb1
                          ============================

    Now that the legal stuff is out of the way, welcome to TOP v3.00wb1!  I'm
sure you will enjoy the new version and all of its features.

    I apologize for the lack of user-friendliness for the upgrade procedure.
I've tried to make it as painless as possible.  However, it will still require
some heavy work on your part.  Follow the steps outlined below in order, and
take your time.

    I'd like to assure you that so far the beta has proven very solid.
In addition to working fine on my personal Maximus and Ezycom test beds, it has
been in private testing on several systems before the decision was made to take
the testing public.

    The rest of this file is broken down this way:  First the file covers the
steps for upgrading, then goes into detail about some of the new features and
how they can be used to your advantage.  At the end is contact information.

    Thanks for participating in the TOP beta program!

    -- Paul Sidorsky (paulsid@home.com)
       February 4th, 1999

                               =================
                               Upgrade Procedure
                               =================

    This section will tell you step-by-step how to upgrade from TOP v2.00 to
TOP v3.00wb1.  Follow each step carefully to insure proper operation.

    NOTE:  If you were previously betatesting TOP privately, ignore the steps
below and simply replace TOP.EXE.  Very little has changed since the private
beta.  However, make sure your TOP.CFG contains the ActionPreload setting,
which was the most recently added setting.  If it is not, you will need check
your configuration against the TOPCFG.3B1 file to see what settings are
missing.  Also, doublecheck your language file against LNG.3B1 to be sure that
all of the new items are present.  There will be a few that you need to add.

    1) Backup everything, as mentioned in the Disclaimer.

    2) Unpack the beta 1 upgrade archive TOPDU3B1.ZIP or TOPWU3B1.ZIP into the
same directory as TOP.EXE.  Answer (Y)ES when asked to overwrite TOP.EXE
itself, as well as TOPMAINT.EXE and TOPMAINT.DOC.  There should be no other
name conflicts if you are upgrading from TOP v2.00.  If there are, rename the
new files until you can check if the old files need to be backed up.

    NOTE:  If you are upgrading to the Win95 version, the file name of the main
program is TOPW.EXE and thus it will not overwrite your old TOP.EXE.

    3) When performing step 2 you will notice several files with the extension
of .3B1.  These files are all used during the upgrade process described below.

    4) The next step is to upgrade your TOP.CFG file to include the new
settings for the beta.  You can do this in one of two ways.  If your text
editor supports it, you can load TOP.CFG into the text editor, jump to the very
end, and then insert the file TOPCFG.3B1 at that point.  This will append the
new settings.  The other way do do this is to use DOS as follows:

COPY TOP.CFG + TOPCFG.3B1 TOP.CFG

    Following this, you need to edit TOP.CFG and add an extra preference to the
DefaultPrefs setting.  Simply add a Y or N to the end of the line, after
setting K (which of course makes this one L).  This is the default preference
for the "No AFK Cancel" setting.  The recommended default is N.  See the
section below on "New Features" under "AFK Command" for more details.

    You can change the new settings right away if you like, but I recommend you
leave them as they are until you are sure the beta is working properly.

    5) Next, upgrade your NODES.CFG.  First, append the description of the new
setting following the technique in step 4.  The file with the description is
NODECFG.3B1.  After doing this, you need to add the following line to _EACH_
node's definition in the new NODES.CFG:

InputLog            INPUT.LOG

    I recommend adding this setting just below the LogFile setting for each
node.  This will suffice until the upgrade is working.  Once it is, you can
consult the "New Features" section of this file under "Input Logging" for more
details.

    6) Now you have to upgrade your language file.  Once again, use the
appending technique described in step 4.  This time, you need to append the
file LNG.3B1 to your language file (eg. PUB.LNG, STTNG.LNG, etc.).  After doing
this, you can edit the new items to your liking if you wish, though once again
I suggest you wait until the upgrade is working using the default items.  If
you are not using the default Neighbourhood Pub theme, leaving the items
unedited will make them more conspicuous while testing new features, making it
easier to detect problems with these features.

    7) The next step is to upgrade the external files inside your TOPANSIPath.
Change to this path and unpack ANSI3B1.ZIP (which is included in the beta
archive).  There will be some name conflicts with existing files, and when this
occurs you have two options.  If you haven't changed your original external
files or if you don't mind overwriting them from now and restoring the backups
later, answer (Y)ES to overwrite the files.  If you wish to keep your existing
files, answer (N)O.  Note that if you answer (N)O you will need to edit the
files later and add the new commands, using the new files as a guide.  For this
I recommend you make a temporary directory and unpack the entire contents of
ANSI3B1.ZIP into it, then you will have the new files available to guide you.

    8) Lastly, change back to your TOP directory.  You will need to run the new
version of TOPMaint twice using the following two commands:

TOPMAINT PACK CDSET=1000
TOPMAINT PACK CLEARSTATUS

    The first command will set each of your user's CyberDollar total to the
specified value.  I recommend 1000 for now as it works well with the fixed bet
value of the SLOTS program.  You can always rerun this command when new ECPs
dictate it.  The second command will clear the Status field in the user file,
which is stored where the old Description field was.  This is particularly
important if you have run TOP v2.00g1 or any version of RAP in the past,
because the user status is stored where the old user description was stored.
However, even if you haven't run a version before v2.00, it should be run as
garbage may be present in that field.  I try to keep the memory clean when
saving data but things always crop up unexpectedly.  :-)

    9) If you are upgrading to the Win95 version, you will need to change your
batch files and/or BBS menus to run TOPW.EXE instead of TOP.EXE.  After doing
this, follow TOPWIN95.DOC for additional setup instructions.

    10) At this point, the upgrade is complete and the beta can now be run!
First, try a test by yourself to see if things are working.  Run TOP from
within your BBS or from a LOCAL type node just to make sure it runs and works.
If it does, it should be safe for your users to use.  If you get any errors,
check to see that you have followed each step to the letter.  If you can't
resolve the problem, please contact me.

    11) Should you make a major error, need to try a different setup to get
around problems, or wish to start from scratch, I have included two archives.
FULLCFG.ZIP contains my own .CFG files (which have minor updates to the comment
documentation) and PUB.LNG file.  Simply change the paths and you are ready to
go!  (For NODES.CFG, you will need to do more detailed editing also.)
ALLANSI.ZIP contains my entire master TOPANSIPath and has obvious applications.

    NOTE:  When you are finished with the upgrade process, you can delete the
.3B1 files from your TOP directory as they are no longer needed.

                                  ============
                                  New Features
                                  ============

    This section covers in detail all new features in TOP v3.00wb1.  The main
purpose of this section is to let you know how the new features are _supposed_
to work, so you can let me know of any behaviour that doesn't seem to fit in.
I'll also mention any problems to watch out for, so please read this section
carefully.

    External Commands (Spawning)
    ----------------------------

    The biggest feature so far, and perhaps the biggest ever feature for TOP,
is the ability to spawn executable programs from inside TOP.  These programs
can interact with TOP to display text, send users messages, change settings,
etc.  This gives TOP the ability to run games, add-on commands, and even
regular doors.  Add-on games and commands are the primary objectives, so this
section will concentrate on those objectives.

    External Command Programs, or ECPs, are configured from the new
configuration file SPAWN.CFG.  This file is fully comment documented, and more
often than not ECP documentation will tell you exactly how to setup this file
so you won't need to worry about it too much.

    The way ECPs work is very simple.  When the proper command word is entered
by a user, TOP spawns the command program just like your BBS software spawns
doors.  The ECP does its thing, and then writes a response file before it
exits.  TOP then reads this response file and performs the actions requested by
the ECP.

    ECPs are spawned with speed in mind.  There is no swapping done (by
default), which reduces the amount of memory available but drastically improves
spawning time.  As most ECPs will be small this will not cause a problem.  All
information is passed on the command line (rather than from a drop file) to
save time.  The gist is that the program should spawn so quickly that a user
won't be able to tell the command they just entered is actually running from a
separate program.  Running TOP locally, on my system (a P133 with 32MB under
Win95), _I_ can't even tell that a program is running, so unless you have a
really old computer the process shouldn't bog down your system too much.

    NOTE:  If swapping doesn't seem to work and TOP simply appears to do
nothing when attempting to run an ECP, try enabling swapping as described in
your updated TOP.CFG and in SPAWN.CFG.  This will likely fix the problem.

    I've included two ECPs for testing.  The first one is DICE.  This is a
simple ECP that rolls virtual "dice" and shows the results to all users on the
same channel as the user that executed it.  You may have seen a similar feature
on MajorBBS/WorldGroup boards.  It's the first ECP I wrote for TOP and should
be very stable.  Read DICE.DOC to learn how it works and how to set it up.

    The second ECP, SLOTS, is a more complex ECP.  As its name suggests, it is
a slot machine game.  It has several subcommands and maintains its own
statistics file (SLOTSTAT.DAT).  However, it is younger than DICE and as such
is somewhat more primitive as far as development goes.  It doesn't have any
options (like min/max bets, payoffs, etc.) yet.  The purpose of SLOTS is to
test TOP's CyberCash feature, which is discussed below, as well as in the
comments for the UseCyberCash setting in your newly upgraded TOP.CFG.  The
default setup in SPAWN.CFG should work fine.  Read SLOTS.DOC for more
information and installation instructions.

    Although the SLOTS ECP is quite new, the code it is based on extends way
back to when TOP was known as the RA Pub.  I had built some games into TOP, but
they weren't entirely stable so I took them out.  I had also wanted them to be
external in some way, so that sysops that didn't want them didn't have to deal
with them and so I didn't have to have a bunch of game-related stuff in TOP.CFG
and in the language file.  Now, with spawning, I can make that happen.  BTW,
spawning itself was also first implemented during the RA Pub days, but the
first implementation had no command tokens (see SPAWN.CFG) and I had other
things to worry about at the time.

    If you are interested in writing your own ECPs for TOP, please check the
TOP website (address below) for the latest version of the ECP Development Kit.
(At release time, a slightly older version is available which will work with
this wide beta, and will be updated as soon as possible.)  ECPs can be written
in any programming lanaguage by anybody who knows how to get information from
the command line and write to a text file.  It is even possible to use batch
files!  I encourage anybody with programming experience to get involved writing
ECPs.  I'd love to see a decent library of small ECPs on the TOP website.

    Users may list external commands using the COMMANDS2 command.  If you have
a better name for this command, please suggest it to me.  It should be to the
point but non-technical.  For now I think COMMANDS2 will suffice because it is
in effect a continuation of the COMMANDS command.  Of course, you can alias it
to whatever you want using the language file.

    Windows 95 Version
    ------------------

    The much promised Windows 95/98/NT version of TOP is now available.  It
functions identically to the DOS version.  You can change between the DOS and
Win95 versions at will by simply changing which executable (TOP.EXE or
TOPW.EXE) is run.

    From a technical standpoint, there are a few obvious benefits from
protected mode, the most useful being the removal of the 640K conventional
memory barrier.  This means a lack of memory will never be a problem with
TOP/95.  Another benefit is the increased stability of a protected mode
application, which means that situations which would cause TOP/DOS to lock up
your system will just cause TOP/95 to exit back to the BBS.  Another benefit is
the graphical interface available to sysops at the local console.

    There are of course some downsides to the Win95 version.  One drawback is
that spawning (described above) must be done in a separate session, which makes
it slower than DOS spawning.  I am only talking about a few tenths of a second,
which is noticable but not serious.  Another drawback is that the Win95 version
has not been tested as thoroughly as the DOS version.  A third drawback is the
awkwardness which the Win95 version interfaces with some BBSs.  Lastly, the
Win95 version has not yet been fully optimized, which may cause it to operate
slower than the DOS version at this time.

    If you are using the Win95 version, be sure to read TOPWIN95.DOC and
follow its instructions carefully.

    OS/2 Version Discontinued
    -------------------------

    Unfortunately, the OS/2 version of TOP has been discontinued.  It already
had several fairly important problems, and I couldn't get spawning to work
either.  OS/2 users should be able to use the DOS version of TOP successfully
as long as they are using the SIO drivers, but an explanation of how to do this
is beyond this document.

    Input Logging
    -------------

    By popular demand, TOP can now log all user input.  The uses for this are
obvious, so I'll just cover how it's supposed to work.

    Chat logging is turned on using the new LogAllInput setting in TOP.CFG.  If
turned on, TOP uses the InputLog setting for each node in NODES.CFG.  The
(included) comment descriptions for each of these settings covers how to set
logging up.

    Each node can log to a separate file, or you can have all nodes log to one
huge file.  (This is in contrast to the mail TOP log which must be different
for each node.)  TOP will log verbatim what each user types in regular chat,
including all commands, whispers, actions, and other text.  Private chats, as
well as personal action changes, bio changes, and other such information, are
NOT logged.

    As you might expect, on a busy system, the input log(s) can get very large
in a hurry.  Be sure you have lots of disk space.  I suggest deleting the
log(s) or archiving on a nightly or weekly basis.  Be sure only sysops and
trusted users can access them, as they may contain private conversations with
other users.

    Also, as a courtesy to your users, please tell them that all conversations
are logged or monitored.  Logging is your right of course, and many users
expect it anyhow, but it's just good PR and courtesy to tell people.

    Ezycom Support
    --------------

    TOP now supports Ezycom v1.20, and should work with v1.48g.  I have tested
v1.20 locally on my system without any problems, but that was initially true
for all other BBS types that TOP supports and they ended up having some pretty
big real-life problems.  :-)

    To set up Ezycom support, change the BBSType setting in TOP.CFG to "EZY12".
Then set both the BBSPath and BBSIPCPath to point to your "Node Msg Path" as
you have set it up in CONFIG.

    Early reports indicated some display problems.  Please let me know if you
get any.  Also, for me Ezycom itself didn't seem to care about the Quiet flag
when sending messages (pages).  Let me know if this is true on your system.
        
    BBS Quiet Mode Acknowledgement
    ------------------------------

    TOP will now get the "quiet" or "do not disturb" (DND) flag setting from
the BBS on all systems except Maximus.  This means users who have quiet mode
turned on inside the BBS will not be able to be paged inside TOP.

    Maximus unfortunately always turns on quiet mode when shelling a door,
which means the only way I can get the true setting is to look at the Maximus
user file.  At the moment this isn't something I'm prepared to do, so TOP will
turn the quiet mode for each user _OFF_ so that they can be paged.

    On all systems (including Maximus), a user can change his/her DND status
with the CHANGE QUIET command.  The change only lasts while inside TOP for that
session.

    RA Credit Support Enhanced
    --------------------------

    If you are running under RA and using credits, TOP can now either subtract
the user's credits upon exiting from TOP, or leave them alone and let RA do it.
The reason for the two options is because I've had reports that RA does it both
ways, so I don't know how to set it up.  Very confusing.  :-)

    To have TOP deduct the credits itself upon exit, simply put a minus sign in
front of your UseCredits setting, so that the setting becomes a negative
number.  To have TOP do nothing and let RA deduct the credits, use a positive
number as has been done in the past.

    Censor Level 6
    --------------

    As suggested on the TOP web site, you can use censor level 6 to do some
creative replacing of non-offensive text, allowing things like macros, single
word aliases for multi-word commands, coloured punctuation, etc.

    If you have been doing this already you've probably changed or commented
out the CensorReplace language item, to prevent TOP showing a warning when
such creative replacing is used.  This is no longer needed, so you should
change this language item back to the way it was so it can be used with other
levels.  TOP will no longer send a replacement warning for level 6 text.

    Multitasker Detection
    ---------------------

    The multitasker detection in the door kit I use (OpenDoors) seems to be
flawed.  It wasn't picking up Windows, and may not have been picking up
DESQview in all cases.

    I've implemented my own routines that should work properly.  Please let me
know how TOP performs on your system.  If you have a CPU usage monitor, each
node of TOP should take anywhere from 0-5% while it is idling at the name
prompt.  If one node shoots the monitor up to 100%, TOP is not detecting your
multitasker and thus not timeslicing.

    If TOP won't detect your multitasker, you can force it to timeslice with
the new Multitasker setting in TOP.CFG.  Valid values are described in the
comments for the new setting.

    I ask that everybody try the AUTO setting at first to see if TOP detects
your multitasker properly.  If it does not, please contact me, reporting your
multitasker type and version.  If TOP still is slow and runs the CPU usage up
even with a forced setting, then we have a really big problem because it means
the built in timeslicing is not working.  :-)

    NOTE:  TOP only supports Windows, DESQview, and OS/2.

    CyberCash & CD... Commands
    --------------------------

    As mentioned in your newly upgraded TOP.CFG, TOP supports online currency
known as CyberCash.  It currently has no function other than to play ECP games,
but soon you will be able to do things like let users convert time, charge
users for actions or censor violations, etc.

    There are some new commands related to CyberDollars.  These commands are
only active if the UseCyberCash setting in TOP.CFG is turned ON.  Three of the
new commands apply to sysops:

SYSOP CDGIVE    Gives a user CyberDollars.
SYSOP CDTAKE    Takes CyberDollars from a user.
SYSOP CDSET     Sets a user's CyberDollar total.

    Like other sysop commands, these commands only work when a user is inside
TOP and in the same channel.  I will probably combine them into a single
command in the future since it's kind of silly to have three separate ones, but
the infrastructure was already there so I just used it.  (This goes back to
when I had games inside TOP.)

    Users get one command, CDTOTAL, that tells them their current CyberDollar
total.  This total also shows up on the TIME display when the UseCyberCash
setting is on, so if you have TIME aliased to $ or /$ or something similar you
can just leave it that way without confusing your users.

    Screen Pausing
    --------------

    NOTE:  I wrote the section below just before a MAJOR bug was found with
this feature.  As a result, I have disabled screen pausing in main chat.  It
should still be operational in list commands, however it does not seem to get
the screen length exactly right, likely due to internal counter resetting that
wouldn't happen if the entire thing was active.  I've left the description
below in these docs so you can be aware of this feature just in case what's
left of it causes problems.  I hope to fix this in time for the final version.

    TOP now counts how many lines have been sent since the last user input.  If
the total exceeds the user's screen length, TOP will display a More? prompt.
What this means is that if a large volume of chat text comes in at once and the
user has been idle through it, the user will get a More? prompt out of
courtesy.  It should allow users to keep up with the chat without having to
resort to scrollback buffers, which not everybody has or knows how to use.

    Listing commands like USERLIST and ACTION LIST have also been modified to
work with this feature.  This means that ACTION LIST ALL no longer pauses after
each list, no matter how small and that pauses for other list commands are not
hardcoded at 20 lines.  I'm sure this will make many people very happy.  :-)

    TOP gets the screen length from the drop file, if available.  Only
DORINFOx.DEF and the short version of DOOR.SYS don't have this information
available.  If it is not available, TOP will default the screen length to 23.
This is not configurable and there are no plans to make it such.  Just about
every BBS I know of can generate a drop file that has the screen length, so I'm
not going to bother keeping track of the screen length in the user file.

    Please note that this feature is relatively new and may be prone to some
minor problems (all cosmetic).  Most probably this will simply mean too many
more prompts.  Please let me know if you see this happening and where it
occurs.  It will likely happen in some seldom used feature or command that I've
forgotten to adapt to the new system.  All of the main areas of TOP seem to
work fine.

    User Status
    -----------

    Users can now configure a little message to be displayed on a WHO/SCAN
command listing when they are chatting normally.  This is done with the CHANGE
STATUS command.  You can enable or disable this feature with the
AllowChangeStatus setting and restrict it with the SecurityChangeStatus
setting.  See these settings in TOP.CFG for more details.

    AFK Command
    -----------

    The AFK command works like /AWAY on IRC.  It lets users mark themselves as
"Away From Keyboard", giving an optional reason which will show up in a
WHO/SCAN list.  (The reason feature is not enabled if user statuses are
disabled with the settings mentioned above.)

    AFK can be optionally cancelled when a user enters a command who's results
will be visible to at least one user, or types normal chat text.  This can be
controlled by the "No AFK Cancel" preference.  It is highly recommended that
you set the default for this preference to NO.  Users who aren't actually AFK
that maintain such a status can be confusing, so by default their AFK status
should cancel.

    When a user sends an action or message to another user who is AFK, the
sender will receive a warning stating that the user is AFK.  This is just a
notification, however - the message will still go through.

    Users that are AFK will have screen pausing (as described above) disabled,
so that incoming messages do not pile up behind a More? prompt.  Also, users
that are AFK will have their inactivity timeout (as configured by the
InactiveTimeout setting) doubled to allow them extra time to do whatever they
are AFK for.

    Action Preloading
    -----------------

    In the past, TOP has always loaded all of the actions fed to it into memory
when it starts up, to reduce demand on the file system and speed things up.
Unfortunately, however, this turned out to be a severe cap on the number of
actions as memory usage increased.  The number of actions was limited to
anywhere between 100 and 400 depending on the conventional memory in use on any
given system.

    To solve this problem, I have implemented the ActionPreLoad setting.  When
turned ON, TOP will preload all actions into memory.  This is how TOP has
always behaved in the past.

    Turning this setting OFF tells TOP to only preload the action verbs and
types, and instead load action text (which makes up the bulk of an action) on
demand.  As a result, TOP can handle many more actions!  The upper action limit
with ActionPreLoad turned OFF can range from 6500-8000!  This should be plenty
for any system.  The trade-off is of course a loss of speed when an action is
issued, but today's systems with faster access times and hardware caching will
probably counteract the effect.  On my Pentium 133, I can't tell the difference
between the two modes.

    NOTE:  TOP may not work properly with the ActionPreLoad setting turned ON,
which is weird because this is the way TOP always operated before.  The problem
is that garbage shows up when an action is sent.  It should not hurt to try the
ON setting if you wish to use it, just be prepared to switch to the OFF setting
if garbage shows up.  There are no known problems with the OFF setting at this
time.  (You may need to do this with TOP/95 even though TOP.CFG says to leave
this setting ON all the time.)

    Birthday Support
    ----------------

    TOP now stores the user's birthday in the user file.  It gets it from the
drop file if possible, either RA's EXITINFO.BBS or the biggest form of
DOOR.SYS.  If not, the user will be prompted to enter his or her birthday the
next time he/she enters TOP.

    This is the extent of birthday support inside TOP right now.  In the future
it will be used for age-control of actions, channels, etc. so if you are able
to use a drop file to give TOP the user's birthday, it is highly recommended
that you do set this up before using this version.

    Bug Fixes and Changes
    ---------------------

    A full list of bug fixes and changes can be found in WHATSNEW.DOC.

                           ==========================
                           Replacement Language Items
                           ==========================

    At the bottom of your newly upgraded language file are some replacement
language items.  These will be used in favour of any existing items of the same
name that occur earlier in the file, thanks to a revised scanning technique now
used by TOP.

    It is recommended that you search through your language file and remove the
old items (or at least comment them out), to avoid confusion in the future.
The names of the replacement items are listed below for your convenience.  Use
your text editor's search feature to find these names and remove the lines they
appear on.

SBBSRecvPageHdr     ProfMainKeys        ProfEdPrefActions   ProfEdPrefKeys

                                  ============
                                  TOP Web Site
                                  ============

    Unfortunately, the Internet is the only way for me to provide a public
access resource for TOP.  The BBS community where I live has been virtually
obliterated, and I don't have the money or time to keep a BBS working.  Without
the Internet, TOP would not be alive today.

    Fortunately, I have set up a comprehensive TOP web site to keep sysops in
touch.  The web site includes basic information, downloads, and even a
development log that details modifications to TOP as they are implemented.  You
can access it at the following URL:

http://members.home.net/paulsid/ismware/top/

                                   =========
                                   TOP Forum
                                   =========

    One of TOP's private betatesters, Mike Cattle, has been kind enough to
provide me with an online Web forum for discussion of TOP.  I invite and
encourage all sysops to read the forum and post if you feel the need.  Beta
discussion is of course permitted in the forum but please don't limit the
conversation to that.  Feel free to share your insights into feature
suggestions, changes, and even criticisms of TOP.

    To access the forum, go to the following URL:

http://members.home.net/rask/calgarybbs/

    It should work with any relatively new browser.

                                  ============
                                  Future Plans
                                  ============

    This is the first and hopefully only test version of what will definitely
be the final version of TOP.  Put much more simply, this is the second last
version of TOP, barring any major problems which force an interim release.

    The final version of TOP will be released this summer.  Some of the planned
features still to be added include:

    - BBS support using ECPs.  This would allow TOP to support any BBS from the
past, present, or future!

    - ChatNotes(tm), a small messaging system specially designed for the
chatroom environment.

    - A central data registry, which would allow TOP to do things like remember
which users a user has forgotten and remember more information about different
channels, as well as much more.

    - Full age and security support in all areas.

    - Other features which I don't want to promise in case I run out of time.

    I intend to work on this list from the top down, and with luck there will
be time to implement all of the above and more!  However, if I run into
problems (either with TOP itself or with life in general) I may cut the list
short.  Keep an eye on the TOP web site for updates.

                              ===================
                              Contact Information
                              ===================

    To contact me, use Internet email or the TOP Forum.  My address is:

paulsid@home.com

    Please DO NOT contact me by phone without prior authorization.

    That's it!  Have fun with the new version, and please send all comments my
way!
