Category : BBS Programs+Doors
Archive   : VBBS61A2.ZIP

Output of file : VBBSDOOR.DOC contained in archive : VBBS61A2.ZIP


The Virtual BBS/NET
Version 6.10

(C) Roland De Graaf 1990, 1991, 1992, 1993

4246 Elisabeth Ave.
Holland, MI 49424

º VBBS Doors Documentation º
º Written By: Kevin Klunk, aka Lord Doomslayer 2@5081 VirtualNET º
º Edited By: Thom Harris, aka Da'Chief 1@6171 VirtualNET º
º Format By: Sam Fleming, aka O. F. 1@2056 VirtualNET º


(1) General Information
1.1 - Dropfiles
1.2 - FOSSIL Drivers

(2) Preparation, Installation, and Execution
2.1 - Game Files
2.2 - Batch Files
2.21 - Game Batch Files
2.22 - Maintenance Batch Files
2.3 - Interfacing with the BBS
2.31 - VBBS Door Configuration Menu
2.32 - Script Installation
2.33 - Function Block Installation

(3) Programs and Utilities
3.1 - DoorWay
3.2 - DoorMaster
3.3 - VReturn/WWIVDoor
3.4 - Virtual ToolKit

(4) Miscellaneous Information
4.1 - Enhancements
4.2 - Copyright Information & Distribution Sites
4.3 - Final Comments

NOTE: The words DOOR and GAME are used interchangeably throughout this

VBBS Doors Documentation -- 2


1.1 - Dropfiles

Dropfiles (DF) are the link between the BBS and the game
itself. A DF contains all of the required info for the game to
operate properly. This includes the user's "handle" (so he al-
ways uses the same slot in the game), the user's COM port & speed
(so the game knows where to send the data), and other miscellan-
eous info - the BBS name, sysop name, user's time remaining (on
the BBS), etc.

Here is a list of many of the common dropfile formats:

Types Original BBS format VBBS Supported?
----------------- ---------------------- ---------------
CALLINFO.BBS Wildcat! 2.x No
DOOR.SYS Wildcat! 3.x & Others Yes

At the present time VBBS supports the CHAIN.TXT,
DORINFOx.DEF and DOOR.SYS dropfiles. They are fairly simple to
use; the only one needing an extended explanation is the
DORINFOx.DEF. All the dropfiles are created in your \VBBS di-

The 'x' in DORINFOx.DEF is the node number that the user is
logged in on. On a single-line system this will always be a '1',
the normal local node would be a '0', and node 2 would be a '2'.
Many of the newer games that are coming out allow for multiple
players in the game at the same time, and some even allow inter-
action between the players. Almost all of these games require
the DORINFOx.DEF dropfile.

The DOOR.SYS dropfile is a fairly generic dropfile accessible to
many games and is VERY common. It requires no special work to
use with a game. The CHAIN.TXT dropfile is used predominantly by
WWIV-based doors, and most can be used with VBBS (see section 3.3
for more information.)

1.2 - FOSSIL Drivers

FOSSIL drivers are external TSR's that handle carrier de-
tection routines for programs that cannot do it themselves. You
do not HAVE to use a FOSSIL driver for all games, so you do not
have to load one at start-up (unless your modem configuration
requires one.) Sometimes they are required if you are using a
high-speed modem, but this DOES vary.

VBBS Doors Documentation -- 3

The two most commonly used FOSSIL drivers are BNU and X00. Both
allow installation before running a door and removal afterwards.
See section 4.2 for information or where you can get these pro-
grams. You will want to go through the documentation files on the
FOSSIL driver for specific installation information, as the setup
varies widely based on the hardware used.

º (2) Preparation, Installation, and Execution º

2.1 - Game Files

Installing the game onto your system is the first step to-
wards getting it to work. The first thing you should do when you
get a new game is unZIP/deARJ/unPAK/whatever the compressed file
is into its own directory. Then load up your favorite text edi-
tor/viewer and read the sysop documentation. Almost all ques-
tions can be answered with the docs included with the games.
While you are reading, take note of the following information:

Installation - does this program self-install?
- does this program need to be in a special
directory to run?
- does this program have a configuration file
that needs to be made / altered?
- how do you initialize the game files?
Dropfiles - does it use one of the 3 supported by VBBS
or does it require a special dropfile?
FOSSIL Driver- Is one needed for this program to run?
Command Line - Quite often there are MANY switches that
can be used on the command line. Make SURE
that you note ALL the possible switches.
- Major switches to look for are:
Dropfile Type Dropfile Path
FOSSIL (Y/N) Node Number Info.
Configuration Filename Local Play Mode

Before you continue, make sure the game will support one
of the three dropfiles that VBBS supports (either DOOR.SYS,
DORINFOx.DEF, or CHAIN.TXT.) If it does not then there are two
other ways you can get the game to run with your BBS.

1> Get a Door Converter program - these programs allow you to
take a dropfile that you already have (ie DOOR.SYS) and run
it through the converter to produce a different dropfile for-
mat (see section 3.2 for more detailed information).

2> Some games allow you to create your own dropfile for use with
the game. If it is possible to do so then all you need to do
is write down the information that has to appear in the file
and the order it must appear. You can then either write up a
script or a batch file to create the new dropfile for the game.

VBBS Doors Documentation -- 4

If neither of these options are available then place the game on
a floppy for storage and check to see if any local (or network)
sysops can give you a hand. The most important rule when setting
up a game is 'Ask Lots Of Questions.' If you cannot find the an-
swers in the docs, then you NEED to ask someone else. Do not give
up on the game if it does not seem to work when it is first in-
stalled, many games require a bit of fine-tuning to match your
specific system setup.

At this point run any installation program (if supplied)
and fill in the required information. Remember to write down any
information that the program gives you during the installation.

Most doors require you to modify a configuration file. You can
do this with your favorite text editor and make any changes re-
quired. Note: Make a back-up copy of this file before you make
the changes! These changes normally entail inserting your BBS's
name, the sysop's name, any file paths that don't match the de-
faults, etc. If the program allows multi-line use and requires a
separate file for the configuration of each line, then make sure
to make as many copies as you need (changing the filename) and
then edit in the information that needs to be different between
each configuration file.

Once the program is installed, you should perform initial-
ization of the game files (if that is required) before continuing
on to the next step. This will allow you to immediately go into
the game to see if you have everything set up properly. If the
game has a 'LOCAL' mode, try to run it at this point. This will
allow you to test for any bugs in the configuration as far as the
game files are concerned. After the 'local' bugs are taken care
of you will then want to move on to the next section. It is re-
commended that you do not make the door open to all your users
until you have had a friend (or fellow sysop) call from remote
to test the modem end of it.

2.2 - Batch Files

The single most important part of getting a door to run is
having the correct batch file setup. Not all games require a
batch file to run, but we strongly recommend that you do use them
for every door. It makes it easier to find problems, and allows
far more versatility. You may also be required to create batch
files for running the nightly maintenance for the game. Both
files are covered here.

2.21 - Game Batch Files

This is where the information you took down on the command
line comes in handy. You need to determine what switches will be
required, and you will also have to discern if you need more than
one batch file.

VBBS Doors Documentation -- 5

Here is an example batch file (most will be similar in format):


Line 1-> @echo off
Line 2-> c:
Line 3-> cd c:\vbbs\games\dumbgame
Line 4-> dumbgame /pc:\vbbs\ dumbgm1.cfg
Line 5-> cd c:\vbbs

Line 1 -> Not required, turns off screen output of the batch
file. Note: If you are not using DOS 5.0 you cannot
use the @ symbol (so the line would read 'echo off')

Line 2/3->Just a precaution to make absolutely SURE you are on
the correct drive and in the right directory. Not
required, but a GOOD thing to do in ALL batch files.

Line 4 -> Actual game command line. This game requires the
program name followed by a '/p' and the path to your
dropfile (which is ALWAYS the \VBBS directory.) and
then the name of the configuration file it is going
to use (if this game was run on node 2 the config file
would be dumbgm2.cfg)

Line 5 -> This is just another 'make sure' line to restore the
system to the right directory. If you do NOT return to
the \VBBS directory after running an external program
you will have empty files and CONTROL.DAT files popping
up all over your hard drive. These files are harmless
and can be deleted, but they are a pain.

While most batch files will contain more 'meat' they will usually
follow the same basic structure. Again, refer to your sysop docs
that came with the game for more detailed information.

A final note on batch files. If a door requires a differ-
ent command line when being run off of different nodes (hence
multiple batch files) you should give the batch file a name of 1
to 7 characters followed by the number of the node that the batch
file is for. The command to run the game would then be the file-
name followed by a %1. For example, the command line


would run the files as follows:

User on Node 0 --- Filename: DUMBGM0.BAT
User on Node 1 --- Filename: DUMBGM1.BAT
User on Node 4 --- Filename: DUMBGM4.BAT

Some games that require you to use a FOSSIL driver and have a
'local' switch will require a different batch file for remote and
local play. If a game does require a separate file for local
play (and it does NOT use a dropfile to do so) you may NOT be

VBBS Doors Documentation -- 6

able to do a og-in Local from the WFC screen because the pro-
gram will not detect a carrier and then exit. That style of game
will require you to use the local node (Node 0) to play.

2.22 - Maintenance Batch Files

Some games require that you run a special program at the
end of each day. These programs do things like updating high
score files, maintenance on the game universe, and sometimes
making backups of the data files. Any game that requires such
maintenance will list the command line information in their re-
spective doc files. All you need to do is create a batch file
resembling your game batch file, except that it will contain the
maintenance command line. At this point you have two ways to
implement the nightly maintenance: either set it up as an indi-
vidual nightly event or make a master batch file that runs all of
your nightly maintenance at one time.

No matter which way you choose to do it, you must first
create the maintenance file. All you have to do is create a
batch file following the same structure as your game batch, but
using the command line that the game docs require for the main-
tenance portion. If you are going to run each individually then
you are done with file work at this point.

If you wish to run all of your maintenance at once, then you
should take all of your maintenance batch files and place them
all into one BIG batch file.

At this point you need to go to your \VBBS directory and run the
VCONFIG program. Select option '8. Events Configuration' and you
will be shown a screen like this:

## Time Last Run Command line

A)dd Event E)dit Event Esc) Quit

Select [A]dd Event and the cursor will be placed under the Time
section of the first blank line. Enter the time that you wish to
run the batch file and remember it is in Military Time (00:01 to
23:59.) The last run section should be left blank by just hit-
ting [Enter] at this point. The command line is where you type
the complete path and filename to the batch file you wish to run.
If you are running each file individually you will need to add
one new event for each file, although it is best to only use one
large file for maintenance because each time it runs an event it
has to reload the BBS and initialize the modem, which is just
extra work for the system to do. If you have any questions on
events then just see VBBS560.DOC - EVENTS Configuration for more

VBBS Doors Documentation -- 7

2.3 - Interfacing with the BBS

And now we get to the fun part -- actually installing the
games into your BBS. There are 3 different ways you can load a
door; from the VBBS door config, from a script, or from a func-
tion block. Each has its own merits and each will be covered in

2.31 - VBBS Door Configuration Menu

VBBS comes complete with a built-in door handling area.
The door area places all the games in one section, allows you to
place certain restrictions on access, and gives the option for
using a credit system. It also offers the easiest setup of the
three methods:

Load up VCONFIG.EXE from the \VBBS directory.
Enter the VCONFIG section 'A. Doors Configuration.'
Select [F1] to add a 'New Game' line to the menu.
Move the highlight bar over the 'New Game' line and hit

You will now see the following screen:

1. Program Name: New Game
2. Command Line:
3. Security Lvl: 255
4. Access Flag:
5. Single User: Yes
6. Credit Cost: 0

D)elete This Entry

[ESC] to quit

1. Program Name: -> This is what the user will see when he enters
your doors area.
2. Command Line: -> This is what you will use to run the game. If
you are using a batch file, all you need to
have is the COMPLETE path to the batch file
and the batch filename (no extension). If
the program has a different batch file for
each NODE on your BBS then the batch file
name would be listed like this:


The %1 tells VBBS to place the node # at the
end of the filename, thereby using the proper
batch file for each node.
3. Security Lvl: -> This is the minimum security level (SL) nee-
ded to play this game. It is set to 255 by
default. You should leave it at that until

VBBS Doors Documentation -- 8

you are ready to have it tried from remote.
See VBBS560.DOC for more info on security
4. Access Flag: -> This is the access flag required to play this
game. NOTE: Access flags (also called "H
flags") are the flags that are set in the
user editor by pressing the [H] key. They
are NOT the general flags. If this field
is blank then anyone with the proper SL (or
higher) can access this game. If this has a
letter in it (and it can use from A to Z)
then the user must ALSO have the flag ON
(listed in his Uedit screen). This is use-
ful for games that you only want certain
people to have access to, including game edi-
tors and such. See VBBS560.DOC for more info
on access flags.
5. Single User: -> Set to YES if only one person can be playing
at once, set to NO if it is a multi-player
game. Most multi-player games require that
DOS's SHARE is loaded into memory before they
can be run. If this is the case you will
need to add it to your AUTOEXEC.BAT file.
6. Credit Cost: -> This allows you to set an individual cost in
credits per game. See VBBS560.DOC and
VSCRIPT.DOC for more info on the credit sys-

2.32 - Script Installation

Script : Any program created using VBBS' script language.
All scripts have the .V extension, are located in the
script directory (see VBBS560.DOC - PATHS Configuration)
and are compiled with VCOM.EXE (see VSCRIPT.DOC for
more info.) Remember that any time you make changes
to a script, you MUST recompile it.

Installing in a script can be simple or complex, depending
on the type of setup you would like to have. Due to space con-
straints, only the actual running of a single door from within a
script will be covered.
For running more than one door, you would need a script
for each door.

*** Special Note ***

Before you attempt to create the script you SHOULD read through
the VSCRIPT.DOC to become familiar with the script commands.

When setting up a door from within a script you need to decide
how you would like to run, for lack of a better term, the 'loop
stop'. When you exit a door that was loaded from a script, the
system returns to the first line of the script, thereby creating
an endless loop. To avoid this, you have one of two options:

VBBS Doors Documentation -- 9

use either an $Extra variable or a $Flag. Both formats will be
covered here.

When using an $Extra variable:


test $extra2 = DumbGame exitgame <--- This line tests to
see if they just re-
turned from the game.
setextra 2 "DumbGame" <--- This sets the 'loop
$gametoplay = "c:\vbbs\batch\dumbgm%1" <-These lines run the ac-
tual door.
door $gametoplay <-Remember that the %1 is
the node number VBBS adds
to the command line. If
you do NOT need to have
multiple batch files,
then do not use the %1.
# exitgame <--- These last lines turn
$blnk = " " off the 'loop stop'
setextra 2 $blnk so the user can play
the game again.
exit start <--- This is the line that
sends the user back to
the function block
that he/she came from.

When using a $Flag

$q = $flags instr N <--- These two lines do the same
testval $q <> 0 exitgame thing that the 'test' line
above does.
setflags N on <--- This turns on the 'loop
$gametoplay = "c:\vbbs\batch\dumbgm%1" <--- as same commands above
door $gametoplay <---
# exitgame
setflags N off <--- Turns 'loop stop' off
exit start <--- as same command above

You will need to run VCOM to compile the scripts you have written
into code that VBBS can use. You compile by using the command