home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.wwiv.com
/
ftp.wwiv.com.zip
/
ftp.wwiv.com
/
pub
/
BBS
/
CEL138A.ZIP
/
CELERITY.DOC
< prev
next >
Wrap
Text File
|
1991-11-11
|
90KB
|
1,807 lines
C e l e r i t y
Version 1.38
Copyright 1990
The BBS of the Present - And Future
Written by Brendon Woirhaye and Dave Hicks
Celerity License Statement
This software and documentation are copyrighted products of Brendon Woirhaye
(herein referred to as "The Byter") and David Hicks (referred to as "Mobius"),
and are protected by the United States copyright law and International Treaty
provisions.
Copies of Celerity BBS may be freely given to other individuals for demon-
stration and distribution purposes only. Any sysop who wishes to run Celerity
BBS on their own system must receive a validation utility from the authors.
Archival copies of the Celerity validation utility may be made by the owner of
a Celerity license for his personal use and protection only. In no circum-
stances is a sysop to give a copy of his validation utility to someone else.
If the sysop does willingly release his validation utility, or it gets out of
his possession in any other way, he will lose all rights to support and future
updates of Celerity BBS.
Contents:
Section 1 What is Celerity?
1.1 General Description
1.2 List of major features
1.3 Distribution Policy
1.4 Required Extras
Section 2 Setting up Celerity Note: Must-Read!
2.1 Running the CONFIG program
2.1.1 Timed Events
2.1.2 Conferences
2.1.3 The Logon Shell
2.1.4 Validation Process
2.1.5 The Files section
2.1.6 Communications
2.1.7 Networking
2.1.8 CelerityNet
2.1.9 Color Setup
2.1.10 Prompt Configuration
2.1.11 Info-Forms
Section 3 Running the BBS
3.1 Setting up subs / gfiles / xfer sections
3.2 The waiting for call screen
3.3 Online commands
3.4 Online Editing Tools
Section 4 Strategies for running a good board
4.1 Policies
4.2 Access Levels
4.3 Conference Arrangement
4.4 Advertising
Appendix A Running CONVUSER - upgrading to new versions
Appendix B Running PROTEDIT - editing xfer protocols
Appendix C Running CONVFILE - Converting file areas
Appendix D Running CONFIG - setting up your system
Appendix E Configurable Status Screens - what they are, how to make them.
Appendix F CelerityNet conferencing - how to get it going.
Appendix G CelerityNet Conference ID Codes - what can I net with?
Appendix H Using a demonstration version of Celerity
Appendix I Multinode operation
Appendix J Sysop-definable text files
Appendix K CAE Mode
Appendix Z Celerity Credits and Acknowledgements
Section 1: What Is Celerity?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
General Description
~~~~~~~~~~~~~~~~~~~
Celerity is a Forum hack which attempts to take the best features of all the
other boards and combine them into one system. It is programmed by The Byter
and Mobius, and is a presentation of The Alternative. It draws heavily on
TCS and KauCom (a board for the Apple II which I wrote a number of years ago),
and I have also picked up a couple ideas from the other Forum hacks out there.
Other utilities for Celerity will soon be released by various people who have
been working on the Celerity project. As they are finished and declaired bug-
free, they will be released.
List of features:
~~~~~~~~~~~~~~~~~
-- Celerity is optimized for speed.
-- It takes advantage of 286 / 386 / 486 processors if present for quick
memory access.
-- It fully supports the 16550 buffered UART for greater efficiency
-- It was designed for use on the USRobotics HST, and has full support for
9600, 14400, and Dual Standard modems. No generic modem drivers here.
-- True high-speed 38400/19200 DTE rates. Get the maximum from your modem.
-- Complete support for v.42/v.42bis HST modems.
-- Support for v.32/v.32bis HST dual standards
-- Sustained ZIP transfer speeds as high as 1782 cps using Zmodem.
-- Extensive code rewriting for speed and efficiency has been done to
older code.
-- FAT file move for incredible file management speed.
-- Internal ANSI driver to end reliance on slow DOS ANSI drivers, which
other many other BBS programs use.
-- Celerity is designed to make the sysop's life easy.
-- New users can be "Quick Validated" with one keystroke. No need to edit
each access flag unless you desire to.
-- Fully automated new user voting section, to allow your users to decide
who gets access and who doesn't. The sysop has veto power, of course.
-- The new user newscan quickly locates all new users awaiting validation.
-- New user voting section can be completely automated, at the sysop's
descretion.
-- New users can be required to upload an example of their newest software,
for examination by sysop and new user voting committee.
-- Complete user editing available while the user is online.
-- "Suggested Point Value" to make file validation quick and easy. Sysop
definable, of course.
-- Automatic ZIP commenting if desired.
-- Auto-Validate allows the sysop to have all uploads automatically cleared
for downloading as soon as they are uploaded.
-- Easy-to-use Config program, unlike any other Forum-clone config.
-- A multitude of sysop-configurable options.
-- Complete control over infoform access, requirements, and text.
-- The most advanced and easy-to-use online sysop tools of any Forum
clone
-- Celerity has the features you want and need.
-- Full conferencing. Celerity supports up to five entirely independent
message bases and transfer sections, ideal for support of multiple
computer types. Celerity conferences are more than just an access flag.
If you don't desire conferencing, it is a simple matter to turn it off.
-- Fully configurable logon shell. Shell commands can be added and removed
as the sysop desires, and each command is fully configurable. The shell
can exist as either a conventional menu-type shell, a dos-simulator
shell, a UNIX-simulator, an interactive lightbar shell, or even an external
sysop-developed shell. The shells are optional, of course, and can be disabled.
-- Configurable prompts. Every Celerity system can have its own distinctive
prompt if the sysop desires.
-- Celerity will run on com ports 1-8, with fully configurable addresses,
inturrupts, and IRQ's. More flexibility than any other Forum clone.
-- Fully configurable file listings. Each user can choose what file list
information he or she desires.
-- File commission system. If the sysop desires, users will get file points
every time their upload is downloaded. You can even have it set up so
a user gets NO points for uploading, and only gets points when people
download his file. This way, users are not rewarded for uploading crap
that nobody wants, and users who upload good stuff are well rewarded for
their efforts.
-- CAE mode. Celerity once again brings a new revolution (or a very old
one, if you were familiar with the old AE's and Catfurs in the Apple
community years ago) to the PC modem world. See Appendix K for details.
-- Celerity supports TRUE NETWORKING, not lame "Net-Mail" like early Forum
clones have. CelerityNet was the net which inspired the networks of
LSD, Vision, Havok, Silicosis, and others.
-- ONE call per day from your system transfers data to and from the entire
net.
-- If you miss a day, the network will still send all your messages.
-- Average Net Call time is 2-3 minutes, so its cheap. Extenders are
available.
-- Networked subs and email are standard features.
-- Network-wide Oneliner database, BBS Listings, and Network News are
special features no other Network has.
-- Network Update service delivers recent Celerity updates to your system.
No need to call around and download them on your own time.
-- Many new and unique networking features to be added in the near future.
-- Dedicated network server. No longer do net BBS' have to contend
with regular BBS callers to make their net calls.
-- CelerityNet is supported by the greatest number of Forum-based
software, including the popular Silicosis, Cypher, Faq, ADI, and Havok
packages.
-- Celerity supports Multi-node operation.
-- Using network cards or a multitasking operating system, Celerity can
support up to eight seperate nodes, possibly more in the future.
-- Fully functional multinode chat to allow users to talk to each
other directly.
-- Celerity supports additional hardware for those who have it.
-- EGA/VGA card support. Celerity has full support for a 43 line (EGA) or
50 line (VGA) screen for the local display. Also works in the config.
-- SoundBlaster support. Celerity will ring out a digitized chat call for
sysops who own a SoundBlaster card. For those without SoundBlasters,
there is an option for digitized sound using the PC speaker, but it does
NOT sound too hot.
-- Mouse support. If you have a mouse, you may use it for easy access to
commands.
Celerity has most of the new features FIRST. It has led the pack of modern
Forum based clones such as LSD, Silicosis, Havok, Vision, Velocity, Magnum,
ACS, and many others which have copied and adapted features found in Celerity
first, and continues to bring new features for the others to copy.
Distribution Policy:
~~~~~~~~~~~~~~~~~~~~
Celerity is distributed via shareware, but requires a validation utility to
fully utilize the system. The validation utility can be acquired from the
authors directly. Please see the file called "CELERITY.APP" for information
on acquiring a validation utility and the current registration fees.
Required Extras
~~~~~~~~~~~~~~~
Celerity requires the use of a few other Shareware programs, or their
equivilent. These are listed below:
PKZIP and PKUNZIP archive utilities from PKWare. Most of Celerity's
archive manipulation is done in ZIP format because of its acceptance as
the standard archive format. These files can be obtained on most BBS'.
DSZ from Omen Technologies. DSZ is an external transfer protocol
program which supports a whole slew of transfer protocols, including
Xmodem, Ymodem, YmodemG, and Zmodem. Although other external protocols
can be used, DSZ is recommended as the standard. Feel free to add
additional DSZ-Log compatible protocols like TASY, SZModem, and Lynx.
Other archive programs like PAK, ARC, and LHARC are also supported (for
archive viewing) by Celerity if the sysop owns these utilities.
QEDIT is the external editor of choice for Celerity, although any
external text editor may be used with equal efficiency, such as DOS
5.0's EDIT, or even EDLIN.
For the ANSI editor, I recommend TheDraw, which is an excellent editor
for the editing and creation of nice ANSI screens.
Section 2: Setting Up Celerity
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sysops setting up Celerity for the first time should read this file IN ITS
ENTIRETY, and they will find a lot of their questions answered. As this is not
commercial software, I should not be responsible to hold your hand through each
step of the installation when the doc file gives you all the needed info. It
is important to read the appendices as well, as they contains a lot
of useful information relating to specific topics. The revision history
(REVISION.DOC) is also a must-read and will explain many features of the
BBS not covered here.
If you are moving up from another Forum clone, such as Emulex, LSD, ACS, USSR,
Havok, Vision, Velocity, etc., you will find the overall feel to be much the
same, and pick up the commands quite quickly. If you are moving from a WWIV
or Telegard, things will be little different from what you are used to.
If you have never run a BBS, I would recommend that you start with something
more simplistic, like Emulex or WWIV. Although Celerity is highly automated
and easy for an experienced sysop to run, it is NOT a simple piece of
software, and can cause great frustration to inexperienced sysops.
Initial Setup
~~~~~~~~~~~~~
Celerity versions are now shipped in a single ZIP file called CELver.ZIP,
where 'ver' is the version number (CEL137.ZIP is version 1.37, for example).
This file contains the following files:
INSTALL .BAT - Batch file to install a working demonstration of Celerity
CELverA .ZIP - New files for version upgrade
CELverB .ZIP - Support files for new Celerity systems
CELverC .ZIP - Support utilities for current version
CELverD .ZIP - Menu set #1 (Optical Illusion)
CELverE .ZIP - Menu set #2 (General Zennor)
CELverF .ZIP - Menu set #3 (Malignant Growth)
PACKING .LST - File containing information about other files in the zip.
When you are upgrading to a new version, it is recommended that you unzip the
CELverA and CELverC zips to your Celerity directory. If you are using one of
the pre-packaged menu sets, unpack the appropriate file to your menu
directory.
For new Celerity users, it is recommended that you run the INSTALL.BAT file,
which will unzip all files into their correct directories for you and set up
the demo. You can then proceed to modify the demo's setup to tailor it to
your own specifications.
There is one additional ZIP which is not contained in the CELver.ZIP file, and
that is CELverG.ZIP. This file contains the default digitized SoundBlaster
chat call files. You can add your own .VOC files to Celerity as well.
New and old users alike should read through the REVISION.DOC file to gain some
familiarity with the timeline of Celerity's development, and discover some
features which might not be covered in the manual. Upgrading users should
read the README.ver file which includes any changes from the previous version.
Everyone should be familiar with the documentation file.
The Config Program
~~~~~~~~~~~~~~~~~~
The CONFIG.EXE program is used to set up all the information about
your BBS that Celerity needs. It will allow you to enable or disable
features, adjust parameters, define your hardware, and more. Its basic
operation is explained in Appendix D. Some of the options may need
explaining, and are covered here.
[Timed Events]
There are three events which take place at a certain time. When the time for
one of these approaches, any online user will be kicked off so that the board
can execute its task. The three events are:
Batch Event: This can be anything the sysop desires. The time and name of
the batch event must be entered in the config, and the system
will execute the batch file at the proposed time. This can be
a utility which will scan your drive for viruses, an alarm,
a disk optimizer, a tape backup program, or whatever.
Auto-Backup: There is no excuse for a BBS to loose all its data -
especially a Celerity system. At the backup time, if the
sysop chooses to have one, the file BACKUP.BAT will be
executed. This file can be used to back up only essential
files - such as the userlist and the DATA subdirectory, or can
be comprehensive and back up everything.
Net Call: This last event is the time at which the CelerityNet call
will be made to the network host. It will not be executed if
the network is disabled.
[Pathnames]
Celerity will ask you for about ten pathnames to indicate where Celerity
should look for different sets of data. The first ten will be directories
where data is stored, and the last three will be specific file pathnames.
These paths will be given suggested values after Config examines your drive
setup, but you may change them according to these specifications:
Node Directory..Where the CELERITY.* and KAU.CFG files reside. Usually the
same as BBS Directory, except for multi-node operation.
Common Node Dir.A directory for multiple nodes to share. This works best if
it is a RAMdisk.
BBS Directory...This is where your main BBS files and data files will be
stored.
Xfer Directory..This is a TEMPORARY work directory for the transfer section.
All files in this directory will be deleted. Do not set it to any
currently-used directory, or you'll get mad at me when your files are
deleted.
Message Area....This directory will hold all of the message files.
Board Directory.This contains the index files for your subs, posts, file
areas, and files available for transfering.
Menu Directory..Your menus. The menus are and will continue to be kept
external to save memory. If you have lots of memory, put these in a
RAMdisk, and you will get the same speed as hardcoded menus.
Sysop-definable files (see Appendix J) are also stored here.
Network.........This is a work directory for the CelerityNet system's use.
Doors...........This is for door support
Sounds..........If you want the digitized chat call, this is the directory
where the sound files are stored.
Text Editor.....Give the pathname and file name of your text editor, like QEDIT.
ANSI Editor.....Pathname and filename of an ANSI editor, like TheDraw.
DSZ Log.........This should match your environment variable for DSZ log TO THE
LETTER. Make it uppercase.
[Conferences]
Conferencing is one of the central features of Celerity. It
allows one system to be organized into different interest areas,
each area having its own message base and xfer section. Thus, a
system can easily have a General section with general interest
information and downloads, an IBM section for IBM posts and
transfers, and sections for other computer types, and the users
will not have to share message and transfer sections with users
with different interests or access. A board could be divided
into a Public access conference, a private conference, an adult
conference, and a user's group support conference. Celerity
will support up to five conferences, or as few as one. Turning
the "Use Conferences" toggle off will limit the board to one
conference and function much like a conventional BBS does.
Otherwise, you can limit the number of conferences you want by
leaving unused conferences without names, and they will not be
accessible to users. Users can be given access to conferences
or denied access selectively, and transfer volumes and message
bases can be further restricted for complete control over
information flow. All other features of the board (email,
rumors, news, automessages, gfiles) are cross-conference. If
you have multiple conferences, but a user only has access to the
first (conference #1), they will not be aware of any additional
conferences (ie: you can set up conference #1 as general
interest with no illegal activities, so if the SPA or Feds call,
you can give them an account (restricted to the one conference)
with nothing to fear [note: the authors of Celerity do not
condone illegal activity in any respect with that remark]. File
volumes may be shared across conferences if desired.
[The Logon Shell]
When a user first connects to the board, they may be presented with a
logon shell or command menu, if you choose to use one. Many boards use these
today. Usage of a logon shell allows you to isolate the new user process
from the main board itself, and to protect the system from unwanted callers.
A user who enters the shell will be presented with a menu of choices, which
have static operations but can have their commands customized in the config
program. All of the following commands can be restricted by defining no
command in the config. In that case, the option will not be offered to the
user. There are currently three different types of logon shells which
can be used, but they all have basically the same commands.
The first command is always the command to enter the main BBS section. Once
entered, the user is prompted for his/her handle and password. This can be
password protected, but such a password is redundant and is NOT required.
The second and third commands can be used to link entirely different and
separate BBS programs (or additional copies of Celerity) by executing batch
files by the names SYS2.BAT and SYS3.BAT. These, too, can be password
protected, but no password is required if the sysop does not desire it.
Options here could possibly be a sister system for local callers only, a
support board for a company, or an online game.
The fourth command is what a new user must enter to apply for access to the
main system. A user will have to give a new user pass if it is required, and
fill out any information forms the sysop has defined.
The fifth command allows a new user to check on the status of his or her
application. If the user has been validated, he or she will be given the
password to system 1, and be allowed to enter. If the new user voting system
is enabled, the user will be informed as to the up-to-the-minute results of the
voting.
The sixth and seventh commands allow a user to request a chat or to leave
feedback from the shell. Again, if you do not wish users to use either of
these options, leave them blank.
The eighth command logs a user off the system.
The prompt line for the logon shell (type 1 only) can also be defined, to add
an additional flair of originality to the BBS. Common prompt lines include
"[Command/?]" and "Login:".
As mentioned, there are different logon shell types which can be
selected. If you don't wish to use a logon shell, enter "0" for the
shell type. Other types include:
1: Menu shell
2: DOS shell
3: Interactive shell
The menu shell gives the configurable command line. Hitting a '?' will
provide the user with a list of supported commands. If you wish to have
a custom shell menu, you can make a file called SHELL.1 in your menu
directory that will be displayed when the '?' is hit. Be sure that it
has all the commands the user may select.
The DOS simulator shell will place the caller into a DOS simulator,
where they will run seperate "programs" corresponding to the shell
commands. The shell commands (defined for the menu shell) will be converted
to DOS filenames (ie: if you choose "Login" as the command to enter the
main BBS, the DOS name will be "LOGIN.EXE"). If the user types DIR,
they will be presented with a "directory" listing of the commands, or
else the optional SHELL.2 file from the menu directory.
The interactive shell is like the menu shell, but the user will be
provided with a lightbar menu to select the desired option. The user
must have ANSI, VT100, or Avatar emulation to use this. If the caller
does not have one of these terminal emulations, he will get the menu shell.
As the shell is fully configurable, you can make Celerity look like some other
type of system. Have it mimic a mainframe or mini if you want to conceal the
fact that it is a private bulletin board system. Using the connect string, the
SHELL.1 help screen, and the definable shell commands, you can make the
shell look like anything you like.
[The Validation Process]
There are several options relating to the validation process. These are
outlined below.
Quick Validate:
The entries in the config program for quick validate scores allow the sysop to
enter the default values given to a new user when the sysop hits the quick
validate key. The Basic Access entries are useful for giving access to
conferences by default, in case the user is not quick validated.
New User Voting:
The purpose of the New User Voting section is to allow the users of a system
have a say in who gets access and who doesn't to the system. There are five
data options in the config relating to the New User Voting.
Use New User Voting...Turn it on if you want the New User Voting to be active.
Turn it off if you don't. Default is off.
Automated NUV.........If On, users will be automatically validated or deleted
(given level -5 access) when they reach the threshold of
YES or NO votes.
Yes Votes Needed......The number of YES votes a user needs to be accepted to
the system.
No Votes Needed.......The number of NO votes which are needed to deny access
to the system.
NUV Access............The access level needed to vote in the NUV Section.
NUV Force Vote Level..Users above this access level will be forced to vote for
new users.
The process works like this. When a new user logs on, they will enter all
their normal information, plus Infoform #5, which is reserved for the New User
Voting section. They will be given 0 Yes and 0 No votes, and be logged off.
When other users call, they may enter the New User Voting section and view the
existing new users awaiting a decision. They may also scan for users they
have not voted on, and be given the option to view the fifth infoform, and
make a judgement (yes, no, or abstain) on the new user. Users may change
their vote at any time before the Yea or Nay threshhold has been
reached. Voting users may also enter a 50-character comment regarding the
user.
When the new user attempts to log on again, he or she will be given an up-to-
date status report on how the voting is going. If enough YES votes are cast
(sysop definable between 1 and 20), the new user will be auto-validated (as
per the quick validate parameters set by the sysop). If enough NO votes are
cast (also definable), the user will be given an access level of -5, which
will give the user a message saying "Your application has been denied by the
user voting panel", and deleted when he/she logs on again. The text file
"DENIED.BBS" will be displayed to users who have been turned down. If the
automated NUV option is turned off, the sysop will have to manually decide on
each of the users before any action is taken.
Some new users will never call back, and in this case, the sysop can simply
scan for users with -5 access who have not called in a week or so and delete
them.
[File Transfer Section]
The file section can operate on a few credit systems. Options pertaining to
these systems are detailed below.
U/D Ratio.......Uploads divided by downloads will be calculated, and if the
user falls below a certain point, they will not be allowed to
download further. This value may be independently changed
for each user through the user editing commands.
FPS.............File Point System. All files are assigned a point cost, and
a user must have enough points to download the file if they
want it. The sysop (or system, if auto-validate is on) grants
points to users for their uploads.
FP Loan.........A sub-option of the FPS, a user over a certain sysop-defined
level may take a file point "loan" to download a file which he
does not quite have enough points for. This allows users some
freedom to get something they need and "pay back later", and
frees the sysop from having to give the user unwarranted file
points or doing book-keeping. The maximum loan limit can also
be defined by the sysop.
Commission......The Commission system also works with the FPS. When it is
enabled, users will get a certain number of points every time
someone downloads the user's upload. The commission value is
the denominator of the file's cost which will be awarded to the
user who uploaded the file. A commission value of 0 results in
no commission being granted. If the value is 10, the uploader
will get 1/10th of the points spent on the download. If the
value is 2, the uploader gets 1/2 of the point cost. A value
of 1 will give ALL the points used to download the file to the
user who uploaded it. The purpose of the commission system is
to reward users who upload popular programs which many people
download, and discourage the uploading of old crap which nobody
wants.
Point Value.....One last modifier to the FPS is the point value. This is the
number of Kbytes that one point will generally download. Often
this is 1 (250k file costs 250 points), 50 (250k file costs 5
points), or 100 (250k file costs 2 points). When this figure
is used, the value will be "suggested" to the sysop when he
validates new files.
Auto-Validate...When the Point Value is used, newly uploaded files can be
immediately and automatically validated by the system without
sysop intervention. This eliminates a lengthy turnaround
regarding new files which must be spread quickly, and is a must
for sysops who do not check up on their boards daily.
Zip Comment.....If the Zip comment option is turned on, Celerity will execute
a batch file called COMMENT.BAT with two parameters: The path
of the file and the extension. COMMENT.BAT can simply add a
zip comment, strip ads and -AV ads, or it can even unpack the
archive, do a virus scan, and re-pack it. The options are
unlimited.
The Upload/Download Ratio system, the File Point System, or a combination of
both may be used. Options on the FPS can be turned on or off, but remember
that the Auto-Validate function requires the Point Value function to work.
[Communications]
Celerity supports a high-speed, high-efficiency modem driver
capable of speeds from 1200 to 115,000 baud. The sysop should
enter the DTE rate that his/her modem can support (generally
1200 or 2400 for slow modems, 19200 for an older HST, or
38400 for a new USRobotics HST, Dual Standard, or V.32) and the
individual baud rates that the board will allow calls at.
Celerity will support calls on any one of four COM ports, COM1
through COM4. Most bulletin boards only allow COM1 or COM2, but
we know the value of allowing you to exploit the full features
of your computer. In addition, your COM ports may be fully
configured by providing Celerity with the inturrupt, the IRQ,
and the Base Address of the port. Few other BBS programs offer
such versitility.
Celerity has a toggle for the 16550 buffered UART chip, which
can lead to higher transfer speeds and more reliable transfers
when Celerity is run in the background of a multitasking
machine, and decent transfer speeds on slow (XT) computers.
For your modem setup, Celerity asks for the type of HST you happen to have.
The codes are listed below:
0: No HST.
1: HST 960/964 (old 9600 HST)
2: HST 1440/1441 (new 14.4k HST)
3: HST Dual Standard
4: HST 14.4k w/v.42bis
5: HST Dual Standard w/v.42bis
Celerity will fully support the v.32 mode of the Dual Standard
HST, but is not designed to work with the USRobotics v32
(non-HST) modem. In addition, Celerity allows you to customize
your modem setup and hangup strings, so you can choose "No HST"
and set your modem string appropriately.
Celerity will automatically send its own suggested answer
command to your modem if you have an HST and have your HST type
set correctly. If you do not wish to have the optimum setup for
the best performance, you may enter an additional setup string
which will be sent AFTER the default string.
The DIP switch settings I use for my 1441 HST are:
Quad: Up 1,2,4,6,7,9,10:Up 3,5,8:Down
The switch settings my dual standard uses are similar.
[Networking]
Celerity will support a complete network of Celerity, Havok,
Silicosis, ADI, Velocity, Vision-X, and Faq systems around the
world. The ability of system users to send email to
any other user on any other board in the network is fully
supported, of course, as are a host of networked sub boards,
which share contributions from all users with all the other
systems. CelerityNet uses its own proprietary networking
system, and is not compatible with FIDO, PCBoard, or WWIV
networking methods. Two other software packages currently
support the CelerityNet format, these being Havok and Silicosis.
The network will operate quite efficiently, only requiring a
node board to make ONE phone call per day, as opposed to a
number of calls which some of the other networks require.
Only Celerity has a 24-hour dedicated network server to process
the network calls. On other nets, you have to fight with other
users to connect to a popular BBS to make your net calls.
The network is now open to all systems which desire to
receive the net, but we are asking a $30 setup charge to
help defray the costs of our dedicated network server.
Options relating to the network are found at the bottom of the
configuration list. As features to CelerityNet become
available, they will be described here. Note: Please turn off
ALL unused features, as they may cause problems.
Feature Group A: Networked sub-boards. These appear to be normal
sub-boards to users, but all messages posted on such subs
will be echoed across the whole network, and all messages posted
on other systems will be sent to your board. See Appendix F and
G for details.
Feature Group D: A global Bulletin Board listing, which works very much like
the Network BBS list does. This has been disabled with version 1.36
and as of this writing is not reconnected.
Feature Group E: A network-wide database of oneliners is supported. Oneliners
added on a Celerity board which supports this option will be posted on
every board in the net the following day.
Feature Group F: The NetNews feature of Celerity brings a network-wide news
broadcast to each and every CelerityNet BBS to give up-to-date
information about the status of the network, Celerity improvements,
new boards running Celerity, and assorted BBS community news.
Organizations who wish to have news dispensed over the net news can
contact The Byter on The Lexicon.
Feature Group H: The Stork is a special feature of CelerityNet which will
deliver to your hard drive the most recent updates of Celerity. A
file called UPDATES.ZIP will be delivered every night that there is
a new update available.
Color Setup The color setup in the config is divided into two parts. The
first set of colors is for your preference as a sysop running
Celerity, and decides the colors for various displays the sysop
will see while the board is in operation.
The second part is the user default colors. You can choose
what the eight Celerity colors a new user will be given as a
default, so you can make your board a bit more individual and
unique. Colors 1-7 are normal colors, color #8 should be an
inverse color (ie: background other than black).
[Prompt Configuration]
Celerity allows sysops to design their own prompt format for their system. The
special codes which allow the prompt to manipulate data include:
|1 to |8 - switch to that user's defined color.
|9 - send a carriage return.
@ - give the prompt location name.
$ - give the time the user has left.
An example prompt format of: [@]|9[$/Left] would appear as [Main Menu]
[22/Left].
Indicating that the user is at the main menu and has 22 minutes left. Color
commands are recommended to give life to the prompts.
[Information Forms]
Also called Scripts and Questionaires, Information forms are
forms a sysop can design to have users provide information about
themselves. Celerity features smart info-form management.
There are five slots for info-forms, and the sysop can define
each one with the following parameters in the config program:
1: Infoform Name Describes what the form is used for
2: Force Info-form Require users to fill out form
3: Minimum Level Users under this level cannot access form
4: Maximum Level Users over this level cannot access the form
In addition, two disk files are associated with each form, where
'x' is a number from 1 to 5 referring to the corresponding form:
INFOTEXT.x A text message explaining how to fill out the form
INFOFORM.x The form itself
Infoform #5 is special. New users can have their infoform #5
viewed by other users if you use a new user voting system, so
don't ask classified data here. Make sure that you indicate to
users filling out infoform #5, through the infotext.5 file or on
the form itself, that information here can be viewed by other
users.
To make an infoform, create a text file. Place all of your
questions in the file, and an asterisk (*) wherever you want to
user to respond with data. If you wish to use an ANSI full
screen infoform, use your ANSI editor, such as TheDraw, to draw
the form and everything you want on it, but do NOT put any
asterisks on yet. When you have the form looking exactly how
you would like
it, go into animation mode and place asterisks where you would
like data to appear.
Infoforms can be used to capture a wide range of information
about a user, but they don't have to be mandatory. You may have
some special service on your BBS which users may apply for, but
are not forced to. Making a non-mandatory form can be quite
helpful in cases such as this one.
Suggestions for infoforms include:
Sysop Data Some personal data about the user
New User Application Infoform #5 for the new user voters to look at
Private Access Have users answer questions before giving a
user access to a private section.
Group Application If your board is affiliated with a group, you
may have an application for a courier or
distribution site.
Infoforms can be used for whatever the sysop desires.
Section 3: Running the BBS itself
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When you first put up the board, there will be a couple of things you will need
to do after configuring to get everything ready for callers. Go ahead and log
on locally with the F10 key. I suggest you set the "Sysop Auto-Login" prompt
in the CONFIG to OFF for the duration, so you can get used to the Celerity
shell and how it operates. Log on to system 1 and enter '1' when prompted
for a user #. Your password is HST. You will probably be asked to fill out
your infoform, so go ahead and do that or skip it. When you get to the main
menu, press '+' to change your password. Come up with something you don't use
elsewhere, as it is imperative that you do not allow anyone else to enter the
BBS using your password, as that can be very destructive. After changing your
password, hit 'K' to go to the user configuration section. Set the board up as
you would like it for your account.
After you've finished playing with the defaults and password, you'll need to
set up the file areas, message bases, and gfiles section. Press 'M' from the
main menu to get to the message bases. You'll be asked for the conference to
join, go ahead and say '1'. Celerity will tell you that it can't find a message
base, and would like to create one. Go ahead and provide the information it
wants. You will set up your first sub here.
When setting up a sub-board, you will be asked for a bunch of data:
Board Name/Number: This is what a user must type to enter the sub. Usually
you will use a number to access the sub, although you may
decide to use a short name like TALK, SALE, or SOFTWARE in
some cases.
Board Name : This is the subs real name, such as "CelerityNet Talk", or
"For Sale" or "General Access".
Sponsor : The cosysop for the individual sub may be entered here.
Usually the sysop himself will take this role, although you
may appoint others to run a sub if you desire.
Access Level : Users must be of this level or above to access the sub. If
you change their personal access flag, this may be circum-
vented for special cases.
Autodelete After : This value is the total number of posts allowed on the sub.
When this number is exceeded, the 2nd post on the sub will
be removed to make room for new posts.
CelerityNet ID : This is used for the CelerityNet network. See Appendix G
for details. Enter a 0 for a local (non-networked) sub.
FidoNet Path : This will be used for FidoNet compatibility in the future.
Note that Celerity does not currently support FIDO.
Anonymous Posts : Set this to YES if you would like to allow users to post
without leaving their handle. Be careful with this.
Dataname Path : To be used in the future.
The sub will then build all of its files and return you to the sub menu.
When you've finished with the first sub, say "A2" or "ASale" or whatever to go
to the next sub you want in this conference. Provide the information about
each sub you wish to add.
When you have entered all the subs for conference #1, go on to the rest of the
conferences (if any) and follow the above steps.
The second task is to set up your xfer section. Enter the xfers, and you will
be prompted to create the first area of the conference. A bit of information
will be requested:
Area Name What do you want the area to be called? Uploads? Doors?
Access Level What xfer level do users need to enter the volume
Sponsor Usually the sysop, but this can be used to allow a regular
user sysop access for the individual section.
Upload Should users be allowed to upload to this area?
Download Should users be allowed to download from this area?
Path The pathname of the directory where uploaded files are to
be stored
Data File This is the pathname of the data file. It is suggested that
you give it the full pathname of your data directory, plus a
filename which will allow it to be easily recognized. The
automatic selection makes a filename called AREAn.x, where n
is the area number, and x is the conference number. This
method can cause problems if you move areas around.
Slow Drive If the area is to be on an optical drive, network drive, or
some other slow media, turning this toggle on will speed up
use of the volume.
Go through and add all of the sections for each conference.
Once you have done that, run any conversion programs (see Appendix C below)
if you are converting from other software.
The next task is to set up your gfiles section. Go in and create it, and use
the % command to get into the Gfiles sysop area if you want to delete areas or
sort them or whatever. There is only one gfiles section, which spans all of
the conferences, so you won't have a seperate section for each conference like
you do with the xfers and message bases. You can add additional sections in
the same manner as in the xfer section, by logging the non-existant area. The
Gfiles section is otherwise identical to a transfer conference.
Waiting Screen: When the BBS is waiting for a call, you will get a complete
display of various statistics and the like. At the top left
you will see the version number of Celerity, followed by your
board's name, followed by your personal serial number. The
serial number is there because I don't want Celerity widely
distributed (ie: distributed out of my control) and so if copies
do circulate without my permission, I can find out who did it.
What a tightass, eh?
The box below that holds various system statistics, which are
pretty self-explanatory, so I won't insult your intelligence and
describe them. Every few seconds, the information box
will scroll to display additional info.
On the left below the statistics box is a box which shows the
last caller to the BBS and the number of megs the board has
free on all drives, followed by a percentage (this is the
percentage of space free, not used).
In the centre of the screen is a glowing "thermometer" bar,
which is an indication of space used on the drive. If it is
small, your drive(s) are nearly empty. If it is near the top,
then you may want to clean out some older files. This permits
the sysop to determine how much space is free at a glace, which
can be quite helpful for sysops who don't log onto their board
every day, or those with small hard drives.
On the right side of the screen is the main command box, which
simply shows you which commands you can use in the "waiting for
call" mode.
F1 will force a network call if you are on the CelerityNet
network. Be sure to have The Byter set you up with a node #
and node password before attempting to net.
Alt-F1 will process any posts in the network directory, and can
be helpful if something goes wrong in the net.
F2 exits from the BBS. Simple.
F3 will force the modem to send a carrier. It is suggested that
you let people connect by calling in, but if you need to send
a carrier, this is how you can do it.
F4 allows you to read any feedback which may be waiting, if you
don't have the time to log on with your sysop account.
F5 will enter the Online Editing Tools. See section 3.4 for
more information regarding these.
F6 will run a user-defined external program. This program is
set up as a batch file called DEFINE.BAT, although you can
change this to anything you want. Look in the MAIN.BAT file
which manages the BBS under the label :userdefine for the text
to change. Put your hacker or word processor or whatever you
want here.
F7 will run the user-defined terminal program. Similiar to F6
above, this must be set up in the MAIN.BAT file under the label
:terminal.
F8 will take the phone off hook so users calling will get a busy
signal. This resets after a few minutes.
F9 displays the system log without requiring the sysop to log
on to the system.
F10 logs on locally. If you've got the "Auto-login" option set
in CONFIG, then account #1 will automatically log on. If not,
you will be thrown into the shell or main menu, depending on
whether or not you have a shell.
Alt-F10 will automatically log the sysop in.
Alt-A will toggle the sysop availability status.
Alt-H will reset the modem (ie: hang up).
Alt-D will drop into DOS. Typing EXIT returns to the WFC.
On the left side below the last caller/free storage box is the
system messages box. The top three lines here are countdown
timers until the three timed events - the user defined event,
the auto-backup, and the CelerityNet call.
If you are using CelerityNet, the status of your daily call will
be presented on the fourth line, indicating whether or not the
network call has been made.
Further down in this box is the name of the sysop the copy of
Celerity is registered to. Again, to keep people from giving
copies of this to everyone they know.
Occasionally a message will appear in this box explaining some
problem or marginal situation which may need your attention.
Other messages which may appear include the detection of a
mouse, a warning to upgrade to a new version of Celerity, or
indication that you are running a beta version of the program.
At the bottom of the call waiting screen are three more boxes.
The one on the left is a multi-purpose clock/calendar (sorry,
no alarm). Next to that is the modem status box, which will
explain what the modem is up to. The third box is the sysop
availability indicator. If it says yes, then users can call for
a chat. If it says no, then they can't.
While at the WFC (waiting for call) screen, you may use your
mouse to click on any of the commands listed above to operate
that function.
Online Commands:There are a number of keys which can be used when a user is
online. These are outlined below.
F1: Enter split-screen chat mode.
F2: <No function>
F3: Hang up on user. No text sent, just lost carrier.
F4: Enter line chat mode.
F5: Online sysop editing tools.
F7: Set board to let sysop on next.
F8: Locks time so it stops counting down.
F9: Locks all incoming modem data (ie: user can't type).
F10: Locks all outgoing modem data (ie: user can't see).
Alt-A: Toggles sysop availability.
Alt-B: Refresh bottom of screen data display.
Alt-D: Drop to DOS.
Alt-H: Get a help screen.
Alt-K: Take all time away from user.
Alt-T: Give the user temporary sysop status.
Alt-V: Display quick user status.
Left Arrow : Remove 1 minute of time.
Right Arrow: Grant 1 minute of time.
Up Arrow : Give one file point.
Down Arrow : Remove one file point.
Insert : Add one access level.
Delete : Remove one access level.
Page Up : Add one Xfer level.
Page Down : Remove one xfer level.
Alt-PgDown : Turns off local display of text while user online
Online Editing Tools
The Online Editing Tools provide the sysop with a powerful set
of utilities which may be used when a user or sysop is online,
or from the WFC screen. When you press F5, the menu will
appear. You may select options from this menu in three ways:
Moving the light bar with the cursor control keys and pressing
[Enter] on the desired option, moving the light bar with your
mouse and clicking on the desired option, or by pressing the
highlighted key for the desired option. Options currently
available include the following:
User Editor: Allows you to edit most of the statistics and
access for the online user. Move from option to option
with the cursor keys or Enter key.
Delete User: Provides for deletion of the online user if they
turn out to be a real jerk or for whatever reason.
Hang Up: Log the currently online user off.
Run Config: Links the CONFIG program to allow you to change
functions of your system's setup. Note: You will have
to exit and re-run the BBS for these changes to become
apparent.
Text Editor: Links your external text editor, as set up in the
config. A good example is Qedit.
ANSI Editor: Links another external editor, usually for the
editing of ANSI files such as menus. TheDraw is a good
example of an ANSI editor.
Load another User: Loads in a user and allows the sysop to edit
his/her statistics. This command will bring up a pick
list of all the available users, sorted alphabetically
by name. You can enter the user's name or number, or
use the scroll bar to select.
Exit: Return to the point you were before calling the tools.
Strategies for Running a Good Board Section 4
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Running a BBS is not an easy job, and running a high quality board which
commands respect is downright difficult. Here are a couple of suggestions to
help you run a quality system.
[Policies]
Sit down and determine the policies your board will have. If you have concrete
policies that the users can be aware of, they will be much more cooperative and
your system will appear to be much more stable and well run. Some policies
which you should consider:
1: Local callers.
Local callers have often been called the bane of a quality
BBS because of the assumption that "good users will call long distance for
good boards. Local callers will take whatever they can find". In many
cases, this has been proven to be true. In general, users who call long
distance are of a higher quality than those who only call local systems.
However, there may be high quality local users you will miss out on if you
flat out refuse all locals.
Different policies you may take would be:
a. Acceptance of all users, local or not.
b. Acceptance of local users providing they call out-of-state boards
c. Acceptance of only a few local users. Use of the LUL (Local User
Lockout) feature of Celerity will allow you to set a percentage of
local users who are allowed on the system.
d. Flat out refusal of all locals.
e. Acceptance of local users if they have a password found only on out-
of-state systems.
Decide what your policy is going to be, and stick to it. Do not change it
every day, and let your users know when you are changing it.
2: Slow callers.
Nobody can argue that 300 bps users should be permitted to have full access
to any bulletin board system, but in recent years, with the advent of high
speed modems, these restrictions have been extended to 1200 and 2400 users
as well. In general, a 1200 or 2400 bps user can contribute just as much
to sub-board activity as a 9600 or 14.4k user can, but will not be able to
transfer nearly as much data in the transfer sections.
9600/14400-Only systems: When I put up my IBM board for the first time, in
late 1989, there were NO 9600 only boards in the United States, and many
users said I was crazy to have such strict requirements of my callers. I
stuck with the 9600/14.4k only policy, and my board has become quite
successful and currently has over 200 quality HST users, and many hundreds
of HST users who had been denied access. These days, more and more boards
are following Lexicon's lead (although many don't realize it) and
establishing an HST-only policy. My CAE system only allows 14.4k calls.
Some policies you might consider would include:
a. Accepting all 1200/2400 users.
b. Accepting only the highest quality slow users.
c. Accepting only slow users who are in pirate groups
d. Accepting only out-of-state slow users.
e. Accepting only a small percentage of slow users.
f. Accepting slow users if they give a donation.
g. Accepting slow users, but deny transfer privileges.
h. Turning down all slow users, regardless of qualifications.
i. Accepting slow users for only a certain period of time, such as when
the board first opens.
Selecting your low speed policy can be difficult. If it is too restrictive
if can hinder early development of the system. If it is too liberal, it
can make your system far too busy to get the attention of high speed users
and reduce the amount of new programs uploaded.
3: Access requirements.
Many boards will accept anyone who calls. Others are more selective as to
whom they validate. This policy can be a key factor in determining the
quality of your system. Some factors many systems consider when deciding
to accept or deny a user include the following:
a. Speed and location factors, as determined by the above policies.
b. How soon does the user get new programs. You may make a distinction
between games and utilities/applications users.
c. Is the user willing to donate funds/hardware for the upkeep and the
improvement of the BBS?
d. Will the user bring a certain amount of respect to the system (ie: is
the user a major figure in the BBS community)
e. Is the user on other quality systems around the nation?
f. Does the user have good references?
One highly effective way of keeping poor users off your system is to get a
group of highly selective individuals as your new user voting panel (ie:
users with a high enough level to vote), and have them determine whether or
not to accept a user. When you have a number of users voting, the chances
of some of them knowing a user you may not know are improved greatly.
4: Conduct.
Rules of conduct are usually very important in determining the quality of
a BBS. Do you want to allow "rag wares" on your system? They will appeal
to a younger audience, but will turn off your more mature users. Do you
care if users post on the wrong subs? How old can a program be and still
be a wanted upload? Do you accept non-game uploads?
There are a number of small aspects you will want to define and usually
post so users are aware of them. If you enforce them, your good users will
abide by them and help enforce them themselves.
5: Voice Validation.
If you are going to voice validate users, you should let them know that you
may do so. Many sysops will ask, in an info-form, whether a user will
accept a collect phone call, and the best time to call. Voice-validating
is a good way to know that you have SOME accurate information about a user,
and he/she can be contacted if necessary.
[Access Levels]
Be consistant with your access granting. Grant new users a certain level, and
upgrade their access when they prove to be good users. Be very careful when
making a cosysop, and be sure you know that user well. Many boards have gone
down because of sabotage done by a cosysop, and many MANY boards have had their
security compromised when a cosysop downloads the userlist and passwords.
Do not give rediculous access levels. Celerity supports access levels of -5 to
100. A negative access level will delete the user the next time they call.
-1 Deletes the user.
-2 Gives the user the system 2 password and deletes him.
-3 Gives the user the system 3 password and deletes him.
-4 Tells the user he was deleted under "special circumstances" and displays
the "SPECCIRC.BBS" file in the menu directory.
-5 Tells the user what the results of the new user voting on him were, and
deletes the user.
Level 100 is sysop level. Do not make levels over 100.
[Conference Arrangement]
As you may have read, Celerity supports up to five entirely seperate
conferences, each one is much like a BBS to itself, possessing an individual
transfer section and set of sub boards. Sysops may use conferences for
different reasons, but most often they are used to restrict access on a very
general level. Some setups I have seen include:
1: One conference is for general access. All non-computer-specific data,
such as subs on entertainment, music, politics, literature, and the like
stay here. The second conference is for IBM users, and contains all IBM-
specific subs and transfers. The third conference is for some other
computer type.
2: The first conference is general access and public domain transfers. The
second conference is for pirate activity. This will allow you to let
anyone on without compromising your security. The feds can look your
system over and find nothing wrong with it.
3: One conference is for pirate activity, one is for phreaking, and one is
for carding.
4: The first conference is general subs and transfers. The second is for
out-of-state users, the third is for locals.
5: Add seperate conferences for certain groups your board may be a home for.
The possibilities are endless. Experiment and decide what you
want and need. The authors of Celeriity do not condone piracy
and other illegal activities through the suggestions outlined
above, but only provide them as examples of setups we have seen
Celerity used for.
[Advertising]
Advertising is a sticky subject. A couple points to remember are:
1: Advertise to your proposed audience. If you don't want any locals, don't
post ads on local boards, and advertise only on out of state systems. The
locals who may be quality users will eventually find out by calling those
other systems. If you don't want slow users, don't post on boards which
cater to them. Posting only on 9600 only boards is quite feasible in this
day and age. Post only on boards which have users of the quality you would
like.
2: Do not over-advertise. Nobody will call a board which makes them sick with
too many ads. Don't always use the same ad either, but vary the ads and
use new ones from time to time. Users will abort any ad they recognize.
3: Never, NEVER, send mass-mail advertising your system. Doing so will most
likely piss off the sysop of the board you are on, and in addition, no
decent user will call a board he has gotten a mass mail invitation to. If
there are a few users you would like, you can try sending them each a peice
of individual mail, but mass mail is sure trouble.
4: Make a nice looking ANSI ad. There are a few ANSI specialist groups, such
as ACiD and A.A.A. who will design ads for people (like myself) who have
absolutely no ANSI talent. When you post it on a forum clone system, be
sure that you have it saved in 79-column mode, not unlimited length.
5: Dumb BBS ads in ZIPs. Don't do it. The proliferation of these ads has
gotten way out of hand, and nobody looks at them anymore anyway. They
have also been known to lead investigators to pirate boards in the past.
Appendix A: Running CONVUSER
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CONVUSER.EXE is a small program which will convert userlists from one format
to another. In its current form, it will only convert the previous version
of the Celerity userlist to the new one when there is a format change. There
are now specialized user conversion programs:
CONVUSER.EXE --- Upgrade Celerity
TCS2CELR.EXE --- TCS Version 1.50
MON2CELR.EXE --- Monarch/2 and TCS/2 - All versions
EMU2CELR.EXE --- Emulex 1.65+
HAV2CELR.EXE --- Havok - All versions
VIS2CELR.EXE --- Vision .82
LSD2CELR.EXE --- LSD version 1.28
TG2CELR .EXE --- Telegard 2.5
Note that the TCS, Monarch/2-TCS/2, Emulex, and Havok converters are not
packaged. If there is need for them, contact the sysop on the support board
and one will be made. If you have a software package which is NOT supported
by one of the above files, contact us and we will consider creating a
converter. To make a converter, we MUST have the record format for the
software you are currently using.
Appendix B: Running PROTEDIT
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PROTEDIT.EXE is a program which allows you to set up your protocol files in a
format that the BBS can read. You will be prompted for the letter to use the
protocol, the protocol's file name (ie: dsz.com), a description of the protocol,
and a command line. The command line can use four switches which are passed
from Celerity, which are as follows:
%1 - COM port number
%2 - COM speed value (note: low-speed callers will still have data sent at the
fixed DTE rate when using an HST)
%3 - The filename to be sent. Precede with an AT sign (@) for batch
%4 - The average/estimated CPS, for time estimates
If you get a "Permission Denied" error when trying to download, that is a
result of a conflict between DSZ and DOS' SHARE command. Don't bother loading
SHARE unless you have a network without any protection going.
I don't pretend to be an expert on protocol setup, so if anyone comes up with
better strings, please post them on Lexicon's Celerity Sysop sub. Of course,
substitute your own logfile name for what I use on the Puma files above, and
MAKE SURE it corresponds to the logfile parameter you set up in your config.
If someone wants to do strings for Ymodem, Xmodem, Super8k, Jmodem, Cmodem,
Whatevermodem, feel free to post them on the Celerity Sysop sub.
There are a couple of protocol editors written by other folks which can be found
up on The Lexicon.
Appendix C: Running CONVFILE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CONV????.EXE will convert file areas, and is covered under the heading
of CONVFILE.EXE (the name for the Celerity->Celerity file converter).
???2CELR.EXE is the name of the user converter for other BBS packages, which
is covered under the CONVUSER.EXE header below (for the Celerity->Celerity
userlist converter).
Be warned that none of these are polished programs. They are ugly,
inefficient, slow, poorly documented, have an attrocious interface, and are
dangerous. The up side is that they (usually) work. MAKE BACKUPS before you
attempt to do any conversions.
It is best to have a complete copy of Celerity set up before you do
any conversions. Set up your board as you wish it to be (at least initially)
with all conferences and transfer areas set up (without files of course).
When you convert data areas, do them in a seperate temporary directory and
then copy them to the Celerity directory over the existing files. User files
are easy to convert, file areas are not. For file areas, you will have to
manually run the CONV????.EXE for each file area.
There are two types of CONVFILE programs. One is to upgrade to a more recent
version of Celerity (such as Celerity 1.20 to 1.23), the other is to convert
file areas from another BBS program to Celerity.
CONVFILE.EXE --- Upgrade Celerity (needed for 1.19 to 1.20, and 1.20 to 1.23)
CONVTCS .EXE --- Convert from TCS 1.41/1.51
CONVLSD .EXE --- Convert from LSD (1.28 to 1.35 tested)
CONVHAV .EXE --- Convert from Havok, all versions
CONVEMU .EXE --- Convert from Emulex 1.65/2.x
CONVVIS .EXE --- Convert from Vision .82 (identical to LSD). .83 untested.
CONVTG .EXE --- Convert from Telegard 2.5
CONVFILE.EXE is the version to upgrade to new Celerity versions. Simply go
to your DATA directory, make a backup of the files, and run the CONVFILE
program. It will update all your file areas and file records to the new format.
CONVxxx.EXE for TCS, LSD, Emulex, Havok, and Vision accepts two parameters:
the source file, and the target file. You may use complete pathnames here if
you desire. The file records for Celerity are stored in the DATA subdirectory
and always have a ".DIR" extension. The individual names are defined when you
create the transfer areas from the xfer menu. The source files from the above
software are usually named "AREA1", "AREA1.1", or something similar.
CONVTG.EXE accepts three parameters. The first is the source file (the
Telegard .DIR file), the second is the target file (the Celerity .DIR file),
and the third is the full pathname of where the files are stored (ie:
C:\xfers\uploads\). The file records for Celerity are stored in the DATA
subdirectory, and always have a ".DIR" extension. The individual names are
defined when you create the transfer areas from the xfer menu.
Appendix D: Running Config
~~~~~~~~~~~~~~~~~~~~~~~~~~~
CONFIG is the program which sets up Celerity the way you wish to run it.
To use it, simply type CONFIG. If you have EGA or VGA and wish to use 43/50
lines, type CONFIG /5.
The config options will be listed in the top box, with an inverse bar showing
the current selection. A description of what the option is for is shown in the
bottom bar. Hitting the up or down arrows will move the list down one item,
and hitting page up or page down will jump an entire page. There are many
types of data you can edit, and each one is handled a little differently:
Text: Data such as your BBS name, sysop name, chat appearance string, etc. are
all text data. When you select a text option to edit, the cursor will
be placed in the data string. Arrow keys go back and forth over text,
HOME jumps to the beginning, END to the end of the string, etc. Hitting
the INSERT key will toggle the insert mode (cursor becomes a block).
DELETE deletes the character the cursor is on top of, BACKSPACE deletes
the previous character. Hit ENTER when you are done editing.
Time: Time data types are self-explanatory, but must be entered in a certain
way. First, enter the hour digits. If the time is less than 10 hours,
be sure to enter a 0 as the first digits. After hours, enter minutes,
and lastly, AM or PM. Example: 6:45 in the evening would be entered as:
06 45 pm
YesNo: Some variables can be toggled between a YES or a NO, to enable or
disable a feature. Hitting ENTER when the inverse bar is on the option
will toggle it.
User : The daily time a user has allocated will pop up a window on the screen
Time indicating how many minutes a user of various levels will have. There
are options for levels 1-9, 10-30, 31-60, 61-90, and 91-100. To change
the amount of time, select the access level using the arrow keys, and
press + or - to add/subtract 10 minutes.
Color When selecting colors - either colors for the sysop displays or when you
choose the default color scheme for your new users, you will get a box
showing a list of colors and two cursors. To the left is a sample text
message to show you how it will look. Pressing the left/right arrows
will change the foreground color, and pressing up/down arrows changes
the background. For flashing colors, choose a background in the right
half of the color options. Press ENTER when you are done selecting your
colors.
Baud The last type of data is the baud rate selection. Pressing enter when
you are on a baud rate data type will give you a pop-up window with the
available baud rates listed. Press up/down arrows to choose the bps
rate you want to select or deselect, and press space or left/right to
toggle it.
When you have finished configuring your system, press F2 to save the data. The
ESCAPE key will exit the program. If you try to exit and have changed data,
you will be asked if you wish to discard the changes.
Much thanks go out to Mobius for his dilligent work on Config, and I really
hope you guys enjoy it as much as I do.
Appendix E: Configurable Status Screens
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ok. A new feature Celerity has with 1.19 is the ability for the sysop to make
his or her own status screens, rather than use the ones hardcoded into
Celerity.
Three such screens can exist, and should be saved in the following files:
LOGNSTAT. : This will be the stat screen displayed when the user first logs
in to the system.
YOURSTAT. : This replaces the main "Your Status" screen from the main menu.
XFERSTAT. : This replaces the Xfer status screen and xfer policy box.
USERSTAT. : This replaces the user status screen in the sysop's user edit
section.
Make sure the files do not have a suffix. If you wish to make different files
for different emulations, do so, but you MUST have one file with no suffix.
You can add .ANS and .ASC files if you desire.
Now, how the hell do you make a screen? Easy. You need to get into TheDraw or
whatever ANSI editor you use, and design your screen. When you've got every-
thing designed the way you like it, jump into animation mode, and place the
display commands at the location you wish the data to appear. The display
commands come in two types, @ commands and ` commands.
Here are the valid commands:
@A - Sysop Available / Sysop not available
@H - User's handle
@R - User's Real name
@P - User's phone number
@N - User note
@p - Password
@T - Total time spent online
@t - Time left today
@# - Total number of calls
@1..@5 - displays the conference name IF the user has access to the conf.
@L - Date of last call
@l - Time of last call
@h - Hack attempts
@S - Sysop availability
@c - Last caller
@B - User's BBS level
@G - User's Gfile level
@X - User's Xfer level
@Q - Quality rating
`X - Number of uploads
`x - number of downloads
`K - K uploaded (includes a 'k' at the end of the value)
`k - K downloaded (also includes a 'k' at the end)
`R - Upload/Download ratio (includes a '%' at the end)
`r - Upload K/Download K ratio (includes '%')
`F - File points
`C - Commission points earned (since last call)
`V - Validtion points earned (since last call)
`U - New uploads
`G - New Gfiles
`P - New posts
`M - Mail waiting
`D - New databases
`c - Average CPS rate user gets downloading
`p - Number of posts made
`% - Post/Call ratio
`u - gfiles uploaded
`d - Gfiles downloaded
`$ - Gfile u/d ratio
Feel free to design some screens and upload them to The Lexicon for other sysops
to use if they desire. This is yet another feature to make your Celerity system
look more distinctive and to your liking.
Appendix F: CelerityNet Conferencing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CelerityNet now supports networked conferences with version 1.19. These are
essentially local sub-boards which echo messages to all other systems in the
Net which support the sub identification code. Set one up as follows:
1: Toggle CelerityNet Feature A (in Config) to ON.
2: Add a new sub, just like you normally do. The sub name may be whatever
you desire (ie: no restrictions just because it is a net sub).
3: Insert a number of the CelerityNet conference when asked for the Net ID
number. Refer to the list below for valid codes.
4: Post a message on the board. This is the root message, and when the system
asks "Post this locally?" say YES. The first message must ALWAYS be local.
5: Additional messages may be posted as desired.
6: When the net call is made, your newly posted messages will be sent to the
host, and all new messages will be downloaded.
7: Please do not post "Is the net working???" posts on all the subs. Use
net sub #99 for test posts. It works like all other subs do.
Recent versions of Havok and Silicosis software also support CelerityNet.
Sysops are responsible for posts originating from their system. If they do not
keep the boards free of ragging and other immature posts, they may be locked
out of the network.
Appendix G: CelerityNet Conferences
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The current CelerityNet conferences can be found by running the NetSubs
file included with versions of Celerity.
More conferences will be added in the future as they are needed. Let me know
if there is one you wish to see.
Appendix H: A Celerity Demonstration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Periodically, demonstration versions of Celerity will be distributed. These
are identical to the actual versions run by Celerity systems (Celerity sysops
actually use the demo versions), but are not validated in the demo version.
All features of the board are usable, but the sysop must be named
"Abdul Clamwacker" and there is a limit of 10 users. The purpose of the demo
version is to allow potential sysops to look the system over and get a feel
for the sysop-side features. Versions 1.23, 1.24, and 1.28 have been cracked,
although I know not by whom, and may or may not be reliable.
Versions after 1.33 will be set up to allow a sysop to run a
small "private" BBS with a maximum number of 15 users. There is
a $15 shareware fee for this version, but you do not need the
validate file to get it running. If a registered sysop wishes
to upgrade to the full (500 users maximum) version, he or she
may send the $35 upgrade fee.
Appendix I: Multi-node Operation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
With version 1.20 comes the basis for multinodal operation for Celerity. Each
node runs as a seperate task under a multitasking operating environment such
as DesqView, Windows, PC-MOS, VM/386, or OS/2 2.0's DOS compatibility box.
You may also use a local area network (LAN) and use a seperate computer for each
node.
To add an additional node to a system set up for one node, you must make as many
additional node directories as you require, one for each additional node. In
this directory, you must copy the following files:
CELERITY.EXE CELERITY.OVR CONFIG.EXE CONFIG.OVR KAU.CFG
MAIN.BAT
Switch to this directory and run config. Use the same setup as you had for the
first (main) node, but change the node directory to the current directory you
are in. Change the BBS node number as well.
When you put the system up, switch to the node directory and run the MAIN.BAT
file (which may need some modification if you are using pathnames in it). Go
to each additional node (in seperate tasks) and run the main.bat files for each
node. The system should now be up and running in a multinodal environment.
As of 1.36, the multi-node chat has come to its own and works quite well.
Appendix J: Sysop-definable Files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There are certain files which reside in the MENU directory which the sysop can
(and is encouraged to) modify to meet the needs of his or her own system.
Some of these files are:
Assorted Message Files: These have no extension.
Donation -- Displayed to a user with the $ command. Usually contains the
board's donation policy.
Goodbye -- Displayed to all users when they log off. Often a list of
other BBS' the system recognizes.
Newuser -- When new users log on, this file is displayed. It usually
tells a bit about the system and the requirements for access.
Nicetry -- If a user messes up on a password three times, they will be
logged off and displayed the file. It usually contains a
message to the effect of "If you were a new user, you aren't
wanted here. If you're a hacker, fuck off". Not that a
nasty message will stop a hacker.
Nuke -- Displayed when the sysop deletes an online user. Often a
nasty message is appropriate here.
RaiseReq -- This file is displayed to a user who is requesting an
access raise. The format is as follows: A number of lines
of text, unlimited in length, followed by additional notes
depending on the user's current level. To add additional
notes, enter a period on a blank line, and the level range
on the next line (ie: 0-9, 10-50, etc.), followed by the
text for that level. As many entries as there are levels
are permitted.
Summon -- Text displayed to the sysop when chat call is activated.
Often something short and one-line is sufficient.
Timesup -- Text displayed to user when they run out of time while logged
on.
.BBS Files. You may include *.ASC versions without color,
and .TXT files for users without IBM ASCII.
validud.bbs -- validation upload text
Prematrx.bbs -- A file which is displayed before the shell is entered
Othersys.bbs -- A message which is displayed when the user is kicked off the
normal system and given the password to system 2 or 3.
Denied.bbs -- A message displayed to a user who has been denied access in
the new user voting section.
Feedback.BBS -- Message a new user gets indicating them to leave feedback to
the sysop after applying for access.
Prelogon.BBS -- Text displayed after a user has given the command to enter
system 1 from the shell.
Changes.BBS -- Quick "news brief" displayed AFTER prelogon.BBS, and before
the user enters his/her handle/password etc. This should
not be more than one line, and may be ommitted altogether if
there is no special news (appropriate news would be "Please
fill out the first infoform. Skip the rest.". Inappropriate
news would be "Hard disk crash. Userlist lost. Log on new."
Because of Celerity's Auto-backup feature, there is NEVER any
excuse for loosing a userlist.
Ad.BBS -- This is displayed when a user hits & from the main menu.
This can be an ad for the software, or can be changed to some
other text.
Blacklst.BBS -- Displayed when a user tries to log on new, and has been
blacklisted from your system. See BLACKLST. Below.
Prot_S.BBS -- A menu of the available (non-batch) download protocols
Prot_R.BBS -- A menu of the available (non-batch) upload protocols
Prot_D.BBS -- A menu of the available batch download protocols
Prot_U.BBS -- A menu of the available batch upload protocols
Other Files: See notes with each individual file.
Xfernews.* -- Xfernews.confnum is displayed when a user enters the xfer
section of conference #confnum.
Blacklst. -- This file has NO extension. It contains a list of handles
which you do not want admitted to your system. If a user
is listed here, they will be displayed the Blacklst.BBS file
when they log on new.
Welcome.* -- ANSI welcome screens have a suffix of a numerical value from
one to 9 (you may have 9 ANSI logon screens, displayed at
random when a user has entered his/her password). You may
also have one WELCOME.ASC file and one WELCOME.TXT file for
non-ANSI users. Enter the number of ANSI screens you have in
the config program to ensure proper randomization.
Lognstat.* -- }
Userstat.* -- } See Appendix F on "Sysop configurable Status Screens"
Xferstat.* -- }
Yourstat.* -- }
Menus: There are three types of menu files, ending with an
.ANS suffix for ANSI, .ASC for IBM ASCII, and .(nothing) for
conventional ASCII. Menus may all be edited at the sysop's
convenience.
Appendix K: CAE Mode
~~~~~~~~~~~~~~~~~~~~~
The CAE is a return to the ideal of the "no pass AE" or "Password AE"
of the Golden Age. The CAE asks for a user's handle, group affiliation, and
area code upon login. This information is kept only in the system logs, and
Celerity saves no user account information. Once this information is
established, the user is given complete access to the transfer areas with a
blessing to download whatever he or she pleases with no obligation to upload.
This sounds like a leeches' dream - and a sysop's nightmare! Why would
users ever upload anything if they didn't have to? Ware distribution is the
incentive. Our modern-day couriers find the CAE an invaluable tool in the
quick distribution of their latest wares. One casually uploaded new ware may
get downloaded over sixty times in the three day period following its release,
which can provide it with a much larger distribution than a courier - or a
dozen couriers - could achieve with so little effort.
By flipping the option in Config, you can set up a CAE system
yourself. We ask for a non-mandatory registration fee of $10 for a registered
copy, and that $10 can be put towards a future standard Celerity purchase.
Standard Celerity registration permits CAE use. The only difference between a
registered and non registered CAE system is that sysops must hit Alt-T on the
local keyboard to get sysop access with the non-registered copy.
Appendix Z: Credits and Acknowledgements
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Celerity is written by The Byter, with considerable contributions by Mobius.
Others who have contributed to the Celerity project in the area of beta testing
and suggestions include:
Lord Icon, sysop of The Genisis Division
Earl Weaver, sysop of the former Instant Replay
Malignant Growth, ex-sysop of Fungus Land
Dr. Crunch, sysop of the former The Proving Grounds
Phantom, sysop of the former XTC
Basket Case, sysop of The Hall of Illusions
General Zennor, sysop of The Cassandra Complex
The JokeR, sysop of The Arkham Asylum
The Punisher, sysop of The Crack in Time BBS/CAE
The WardeN, sysop of Maximum Security BBS/CAE
Thanks also to those who have written menus, status screens, and info-forms for
other Celerity sysops to use:
Lord Icon Phantom Basket Case Trooper X Grim Reaper
Wild Gunman General Zennor Optical Illusion Cemetery Shift
Even more thanks go to those sysops who have chosen Celerity as their BBS of
choice.
And to those whom I've forgotten to mention.
Thanks also go to The Shocker, for implementing CelerityNet into his BBS
software, expanding the network to more than one software package.
Additional thanks go to Skeeve, author of Silicosis, for making his software
the third BBS package to support CelerityNet.
Special thanks to The Slavelord, my colleague in writing a modern Forum clone,
for the help, suggestions, and ideas we have shared back and forth.
Acknowledgements
MS-DOS is a trademark of Microsoft Corporation.
DSZ is a trademark of Omen Technologies, Inc.
Turbo Pascal is a trademark of Borland International, Inc.
Forum is a trademark of Kenneth Duda.
PKZIP, ZIP, and PKUNZIP are trademarks of PKWare, Inc.