OS/2 Shareware BBS: 2 BBS

home *** CD-ROM | disk | FTP | other *** search

/ OS/2 Shareware BBS: 2 BBS / 02-BBS.zip / va210.zip / BBS.DOC < prev next >

Wrap

Text File | 1997-02-05 | 71KB | 1,687 lines

Virtual Advanced Installation ═════════════════════════════ If you've already installed the software, you can skip to the next section of the documentation titled "Virtual Advanced Command Line" below. Otherwise, to start the installation process, first UNZIP the archive you downloaded or received on disk to an empty directory on your hard drive. If you're reading this document, then chances are you've already gotten this far. Next, execute the INSTALL.EXE and follow the prompts. INSTALL will create a few directories and copy default configuration files, executables, etc to the proper places. When INSTALL is complete, you are ready to run the program for the first time -- however -- it is a good idea to first run VCONFIG.EXE and set-up the proper COM Port and other parameters for your computer. If you intend to run a single-line BBS, you need only to set-up the comm parameters for channel 1. If you intend to run a multi-line BBS, you may elect to set-up all of your channels right away, or just set-up the comm parameters for channel 1, until you get more familiar with the software. Virtual Advanced Command Line ═════════════════════════════ When running VA, a RAM-resident BBS.EXE controls the program. It should be used as the ONLY means of starting Virtual Advanced, as it transfers needed information into the program. The basic syntax for bringing Virtual Advanced online is: BBS <channel number> where <channel number> is a number from 0 to the multi-user limit of the version of VA you are running. For example, the 2-user version can run channels "BBS 0" (local console), "BBS 1" (remote channel 1), and "BBS 2" (remote channel 2). The 8-user version can run channels "BBS 0" thru "BBS 8", and so on. Note that ALL single-node installations use the command line: BBS 1 and that the command line: BBS 0 specifies LOCAL MODE (SysOp) operation only, using the console keyboard and bypassing WFC initialization. Command line options include: /AC Use this option when running VADV as a door, or from a matrix logon. It has VADV maintain separate user data (etc.) and maintains the doored VADV as an independent system. /H Used with the /AC option, forces VADV to hang up when the user logs off. /Bxxxxx Used with the /AC option, passes the speed (bps rate) of the modem-to-modem connection to VADV. First-Time Start-Up ═══════════════════ Before you do your first login to VADV, there are a few final checks you need to make: 1) Make sure the following files are available to VADV via a PATH= statement in your AUTOEXEC.BAT file: For VA for DOS: (PKZ204G.EXE) PKZIP.EXE (PKware) PKUNZIP.EXE (PKware) For VA for OS2: (ZIP201X2.ZIP, UNZ512X2.EXE) ZIP.EXE (INFOZIP) UNZIP.EXE (INFOZIP) For example, you might have these files in a directory on your hard drive called BBSUTIL; the PATH= statement might read: PATH=C:\DOS;C:\BBSUTIL For more information on the PATH= statement, please refer to your DOS documentation. 2) Make sure the device driver ANSI.SYS is loaded with the ap- propriate statement in your CONFIG.SYS file: DEVICE=ANSI.SYS This enables your computer to handle the ANSI displays VADV uses and generates. For more information on the DEVICE= statement, please refer to your DOS documentation. There are many alternative drivers available - particularly ZANSI.SYS -- that handle ANSI graphics MUCH faster than DOS default ANSI.SYS. These programs are available on BBSes all over. By executing the statement: BBS 1 on a single-node installation, you will bring up VADV in the WFC (Waiting For Call) mode. This is the online control panel for VADV, and when you see this screen, the BBS is said to be in a "waiting for call" state. From the WFC screen, press "F" for "Fast Login" to login to your VADV board for the first time. Other Programs ══════════════ Every bulletin board system has the need to work with file archives. The most popular archive format is ZIP, and your BBS should support at least ZIP. Whether you decide to support other formats is up to you. To handle ZIP archives you will need the PKZIP/PKUNZIP files mentioned earlier. To obtain these and other utilities useful to sysops, you may call Virtual ComTech International, Inc. BBS at 616-399-4818 or 616-399-8791. These files are also available via the Internet at http://virtualc.com. Shareware Notice ════════════════ Virtual Advanced BBS Software, all included utilities, documents, and default configuration files are copyrighted shareware. You may freely distribute the UNREGISTERED version, and you may use the software in its UNREGISTERED state for an evaluation period not to exceed 60 days. After that period of time, you must either REGISTER the software, or discontinue its use. For more details, see LICENSE.DOC. Program Limitations When UNREGISTERED: "Nag" at login 50 user accounts maximum VNET limited to VirtualNET & Localnet VUUCP limited to one remote connection in dial-list VFIDO limited to one remote connection in dial-list IRC Internet Relay Chat disabled SLIP/CSLIP/PPP Internet Pass-Thru limited to 5 minutes/call Registered SysOps will receive an unlocking key when they purchase the program. This unlocking key will remove the opening "nag" screen, and open up all of the functions of the software. For details on ordering, see ORDER.FRM or CONTACT.DOC. Configuring with VCONFIG ════════════════════════ VCONFIG.EXE is the main configuration utility supplied with the Virtual Advanced Bulletin Board Software Package. VCONFIG was designed to be easy-to-use, yet powerful enough to satisfy even the most demanding system operator. Of course, the evolution of VCONFIG is closely tied to the evolution of the entire software package, so improvement and change is always in the works. For the details on using VCONFIG and the configuration data that cn be manipulated with VCONFIG, please see the document file pertaining to VCONFIG. This file also includes detailed information on set-up of doors and other facets of the software that are closely tied to VCONFIG. Configuring with VSTRING, RIP Graphics, and VWC Graphics ════════════════════════════════════════════════════════ Every text string displayed to the user by Virtual Advanced is sysop-definable. In fact, you can take it a step further and define several different external string files, and allow your callers to select the external string file they want to use during their login session. In this manner you can set-up different languages, dialects, and/or styles to your BBS since you completely control the text strings and prompts being used by your BBS. VSTRING & External String Files ═══════════════════════════════ The standard VADV system comes with one external string file set called DEFAULT. There are two components to this set: DEFAULT.S The source file to the set DEFAULT.STR The compiled representation of DEFAULT.S DEFAULT.S and DEFAULT.STR should be installed to your VADV Text Directory (\VADV\TXT). The program used to quickly and easily edit and compile the .S files is called VSTRING.EXE, and it is included with your Virtual Advanced software. VSTRING.EXE should be executed from your Main VADV Directory (\VADV). The program is very user-friendly with on-screen instructions. Special Character Sequences ═══════════════════════════ There are several special string sequences you can use in your extenal strings: %b User's Base Color %p User's Prompt Color %l User's Line Color %h User's Header Color %handle User's Handle %tl User's Time Limit %topic Current Topic Group %subtopic Current Sub Topic %ftopic Current Topic Group (formatted to 32 characters) %fsubtopic Current Sub Topic (formatted to 32 characters) %fb Current Function Block You may also embed heart code color within your strings. Press Ctrl-C for a heart code character when in the VSTRING editor. Creating New External String Files & Setting Up Multiple Languages ══════════════════════════════════════════════════════════════════ It is highly recommended that you follow this procedure when attempting to create new string files. This example will show how to create a new external string set called SILLY: copy \vadv\txt\default.s \vadv\txt\silly.s It is very important that you start out with a copy of DEFAULT.S from the version of Virtual Advanced that you are using, as .S and .STR files from previous versions may not be compatible. Line 1 of the .S file should be a descriptive name for the string file, and should be edited with a text editor: edit \vadv\txt\silly.s The last step is to make VADV aware of the new string file set. To set-up multiple languages, use a text editor to create an ASCII text file called LANGUAGE.CFG in your Main VADV Directory (\VADV). Type in the names of your external string sets, one entry per line as shown in this example: SILLY Note that no extension is given, and that DEFAULT should NOT be listed in the LANGUAGE.CFG file. External Strings & RIP ══════════════════════ There are over 400 external strings defined in the DEFAULT.S file. For RIP callers, each string can be replaced by a RIP file. VADV comes with a set of R*.RIP (RIP replacement) files. Here is the sequence taken by VADV for RIP users: 1. Compute external string from the string file 2. Check for a R*.RIP file in the VADV Text Directory (\VADV\TXT) * = External String Number 3. If the desired R*.RIP file exists, it is displayed to the remote caller. Any occurences of %%text%% found in the RIP file will be replaced with the external string computed in step 1. If you examine some of the included "R" files, you'll notice that some of them begin with a "*" character. This is a special signal to VADV to execute a wait-for-keypress sequence after displaying the RIP file. This is useful when displaying a DIALOG BOX (typically with an "OK" button) that is followed by a screen clear. The included RIP files may be edited using any RIP- compatible graphics editor. You may, however, need to remove the "*" before editing, and put it back afterwards. External Strings & VWC ══════════════════════ As with the RIP supprort, for VWC callers, each string can be replaced by a VWC file. VADV comes with a set of R*.VWC (VWC replacement) files. Here is the sequence taken by VADV for VWC users: 1. Compute external string from the string file 2. Check for a R*.VWC file in the VADV Text Directory (\VADV\TXT) * = External String Number 3. If the desired R*.VWC file exists, it is displayed to the remote caller. Any occurences of %%text%% found in the RIP file will be replaced with the external string computed in step 1. The included VWC files can be edited using any text editor. Configuring Your Menus ══════════════════════ Editing and customizing the text string displayed to callers of your BBS is great, but what about the menus? The configurability of VADV can not be overstated. Because of the way VADV is structured, it's possible to reconfigure the program to create your own design. Redesign of your board's menu structure and supported commands is quick and easy with VADV. You can even create new commands as needed for custom applications. There are always two components to every menu: (1) The FB File - This is a CONTROL File that defines the commands on the menu and the keys (on the keyboard) that activate the commands. (2) The MNU File - This is a DISPLAY File that is displayed to the users of your BBS. This file may contain text and "heart code" color codes. Additionally, there may be: (3) The RIP File - This is a DISPLAY File that is displayed to RIP users, containing a series of RIPterm commands. (4) The VWC File - This is a DISPLAY File that is displayed to VWC users, containing a series of VWC term commands. Function Blocks ═══════════════ Despite the fancy name, a function block is really nothing more than an ASCII text file which defines one MENU of commands for your users to choose from. There is no limit to how many function blocks (menus) you can have installed on your system. As written, function blocks are ASCII text files, and may be created with any simple text editor such as DOS EDIT or the like. Your favorite word processor will also do nicely so long as the document is saved as plain ASCII text. FBs must reside in your VADV \VADV\V directory. Anatomy Of A Function Block File ════════════════════════════════ A function block file specifies THREE things: 1. Name of Menu File to be Displayed for this Function Block (NO EXTENSION!) 2. Active (Available) Database Groups (if any) (DON'T FORGET TO EDIT THIS LINE WHEN ADDING NEW TOPIC GROUPS!) 3. One or more BBS Commands which can be used by the SysOp and/or Caller Heres a small example, which will be useful for this discussion: (1) MAIN (2) ABC (3) P 001 1 post /WHO 001 1 who G 001 1 logoffyn X 100 2 extend Y 255 3 dir.bat Z 200 4 door.bat M 001 5 message (1) In the above example, the first line, "MAIN," specifies the name of the Menu Display File which goes with this function block. Notice that no file extension is given. VADV will automatically look to your VADV Text Directory (\VADV\TXT) for the Menu file, and determine the extension using the following steps: 1. If the caller is using RIP, a menu file with the .RIP extension is looked for. (Example: MAIN.RIP) If found, then it is transmitted to the caller, and menu display is complete. If the caller is using VWC, a menu file with the .VWC extension is looked for. (Example: MAIN.VWC) If found, then it is transmitted to the caller, and menu display is complete. 2. If the caller is not using RIPor VWC, a menu file with the .MNU extension is looked for. (Example: MAIN.MNU) If found, then this file is transmitted to the caller, and menu display is complete. If a .MNU file cannot be found, VADV will check further for a .ANS or .ASC file depending on whether the user has their ANSI turned on or not. (2) The second line of the function block file indicates which database groups, if any, are enabled at this prompt. In our example, groups A, B, and C are enabled. A common mistake in setting up VADV is adding New Topics (Database groups) in VCONFIG, but then forgetting to update line 2 of the .FB file(s) where you want the new topics enabled. If you intention is to not have any groups enabled, then leave line 2 blank. (3) Lines 3 onward are for configuration of the actual commands themselves. You may have up to 40 commands in each function block. There are 4 parts to each entry, and each part needs to be separated from the other parts by at least one space. Let's look at an example: /WHO 001 1 who "/WHO" is the keystrokes the user will have to type to activate the given command. "001" is the security level (SL) required to be able to use the command. "1" is an identifier that tells VADV it is about to execute an internal command. The possible identifiers for this field are: 1=internal command, 2=run a script, 3=run a executable, 4=run an executable with shrinking out, and 5=go to another function block. "who" is the internal script command to be executed. Other Examples: X 100 2 extend The above example uses the keystroke "X" to activate it. A SL of 100 or greater is required to use this command. The "2" indicates that we are to run a script, and "extend" is the name of the script. Notice that no file extension is given. Y 255 3 dir.bat The above example uses the keystroke "Y" to activate it. A SL of 255 or greater is required to use this command. The command is to run a batch file "dir.bat" without shrinking out. Z 200 4 door.bat The above example uses the keystroke "Z" to activate it. A SL of 200 or greater is required to use this command. The command is to run a batch file "door.bat" with shrinking out. M 001 5 message The above example uses the keystroke "M" to activate it. A SL of 1 or greater is required to use this command. The command is to go to another function block - message.FB. Notice that the extension is omitted. A summary of the command types: 1 Internal command (like SENDEMAIL) 2 Virtual Advanced Script (.V file) 3 DOS function (don't shrink VADV out of memory) 4 DOS function (shrink VADV out of memory) 5 Transfer control to a different function block (.FB file) "DOS function" means basically any valid DOS (or OS2) command line: execute a DOS command, .BAT (or .CMD) file, .COM file, or .EXE file, with or without parameters. Note the differences between command types 3 and 4; for Virtual Advanced for DOS, type 4 will give your DOS function more conventional memory to execute in. A sample function block to handle E-mail might look something like this (without the parts inside angle-brackets): EMAIL <name of menu file> <no database enabled> e 001 1 sendemail m 001 1 reademailto f 001 1 feedback s 001 1 reademailsent q 000 5 main <on quitting, return to MAIN.FB> If you would like to study further function block examples, feel free to view and modify the standard set that is shipped with the Virtual Advanced software. Heart Codes & ANSI ══════════════════ One term often heard in BBSing is ANSI (American National Standards Institute), and it refers to the ability of the BBS software to control screen position and color on the remote user's terminal. This allows the BBS full use of color and cursor positioning for fancy text screen displays. Be sure you have an ANSI.SYS (or equivalent) display driver installed on your system. This will typically take the form of a line such as following in your CONFIG.SYS file: DEVICE=C:\DOS\ANSI.SYS This will allow your system to properly display these color codes locally, so that you will see exactly what the caller is seeing. Menu Display Files ══════════════════ There are two ways of putting ANSI color in your menu files. They both have different advantages and disadvantages. Another thing to also consider is the fact that your board will most likely have both ANSI and non-ANSI callers. Therefore, your BBS must be able to send the ANSI version of the menu only to those who have their ANSI compatibility turned on, and send a plain text version of the menu for users who do not have their ANSI enabled. 1. You can use an ANSI drawing program, like TheDraw, to put true ANSI color, and optionally, animation, into your menus. This has the advantage in that you can use any valid ANSI foreground/background color combination, or for that matter, any valid ANSI command sequence, in your menu files. This disadvantage to this is that you'll have to make two files for each menu -- one for your ANSI users (.ANS) and one for your non-ANSI users (.ASC). 2. You can use the built-in VADV "heart code" system. This system has the advantage that you need only make one menu display file (.MNU) for both ANSI and non-ANSI users. VADV automatically determines whether or not to send ANSI command sequences, so the caller will see the ANSI colorized version of the menu if they have their ANSI enabled, and they will see a plain text version of the same menu file if not. The heart code system can control both foreground and background colors, however this system has the disadvantage that the number of foreground and background color combinations is more limited than with true ANSI. The supported background/foreground color combinations were chosen based on appearance. Editing Menu Display Files ══════════════════════════ To edit true ANSI menu display files, an editing program like TheDraw (or equivalent) is recommended. Many utilities for creating and manipulating ANSI file are available through bulletin boards, online services, and the Internet. To edit VADV heart code menu display files, one can use built-in Full Screen Editor (FSE). Several utilities, also, are available to help in modifying VADV heart code files. Menus are a great way to customize the look and feel of your Virtual Advanced system, and you should try to make your callers as comfortable as possible with your system. VADV And The Waiting-For-Call Screen ════════════════════════════════════ When not servicing a user or a network caller, a channel is said to be "waiting for call." During this time, the sysop can access the bulletin board, shut the system down for routine maintenance, and do other things as needed with the system. VADV uses a highly-informational WFC screen. This screen not only provides system statistics, the time, available drive space, system status and the BBS name. Note that if your drive space on a given drive drops below a certain percentage of its capacity, that line will change color to let you know that you need to free up some space on that drive. The WFC screen is capable of showing you the user and/or activity on each node (or channel) of your system at a glance. The system automatically tailors the size of the display to fit the size of your BBS. While at WFC, keyboard keys [F1] through [F10] can be configured to execute any standard operating system command, or external EXE, COM, or BAT file. The WFC screen is set up so that most of the sysop's routine chores may be handled without ever logging on to the BBS. This, coupled with configuration of the [F1] through [F10] keys, can be a real time-saver. Note that the [Alt], [Shift], and [Ctrl] Keys expands the [F1] thru [F10] range to a maximum of 40 sysop-configured command keys. Commands available from the WFC screen: [L] Login [U] User Editor [W] Who [F] Fast Login [M] Read Email [C] Callers [E] Send Email [V] VCONFIG [N] Net Call [T] Micro-Term [X] VSTRING [S] DOS Shell [A] SysOp Available [Y] VMB [*] Down All Channels [Q] Validate [Z] VDOC [Esc] Down Channel The functions should be relatively self-explanatory, with the following special notes: 1. [F] Fast Login This logs you into the BBS on the sysop account without requiring you to actually type in your user number, password, etc. 2. [T] Micro-Term Use for modem setup and diagnostic purposes only. 3. [A] SysOp Avail VA for DOS also uses the "Scroll Lock" key (and light) to determine sysop chat availability. You could think of the scroll lock key and the [A] key as having an OR relationship; if either is turned on the sysop is available. If both are turned off, then the sysop is NOT available. Keys Available While A User is Online ═════════════════════════════════════ When a user is online, the [F1] through [F10] keys function differently from the way they do at the WFC screen. The list of functions available when a user is online is given below: [F1] and [Shift-F1] Pressing [F1] puts the sysop and on-line user in normal chat mode. (Press [F1] to exit normal chat mode.) Pressing [Shift-F1] puts the sysop and on-line user in split-screen ANSI chat mode. (Press [Esc] to exit split-screen chat mode.) [F2] Call up user editor; user sees a <Wait> prompt on his or her screen. By exiting the [F2] user editor as another user, the sysop can "change into" that user. [F3] and [Shift-F3] Pressing [F3] adds 1 minute to the user's session. Pressing [Shift-F3] subtracts 1 minute from the user's session. [F4] and [Shift-F4] Pressing [F4] increases the user's SL by 5. Pressing [Shift-F4] decreases user's SL by 5. [F5] Drop to DOS (VA stays in memory). [Shift-F5] Drop to DOS (VA shrinks out as per a door program.) [F9] Invoke the "Download Any File" convenience feature. [F10] Boot user off the system, "cold". [Ctrl-F10] Display external string #396 and boot the user off the system. [Shift-F10] Spurt some simulated "line noise" at the user, and boot him or her off the system. Makes the user think a bad connection terminated the session. New User Processing ═══════════════════ When a user logs on as NEW on your system, he or she is first presented with the NEWUSER.TXT file (which you definitely should create/edit before opening your BBS to the public) stored in the \VADV\TXT directory defined in your PATHS Configuration. The NEWUSER.TXT file should provide enough information to get new users started; it may also include anything else you wish. If you configured a "New User Password" in VCONFIG, the new user will be asked to provide the password before the system allows him or her to continue. At the end of the NEWUSER.TXT screen, the new user is prompted to provide some basic information about himself or her- self. Depending on whether or not your system allows "aliases" or "handles", the user will be prompted to provide a "handle" or real name to use on the board. VADV checks what the user types in against other entries in the USERFILE.DAT to make sure that duplicate names are not used. If there are handles or names that you would prefer not to allow on your system, you may include them in a text file called TRASHCAN.TXT in your \VADV\TXT directory. This file is created using an ASCII text editor and has one handle/name/word per line. Most sysops use this to pre- vent users from having profanities as handles. As the signup continues, the user is prompted for his ad- dress, voice and data phone numbers, birthdate, password, and other information pertaining to default settings used on the BBS. The information provided goes into the USERFILE.DAT file. If you have chosen to allow auto-validation of visiting sysops, VADV will asked the user if he or she is a sysop. If the user answers "yes", he or she will be prompted for informa- tion concerning his or her BBS and will then be given the SL and time you have defined for visiting sysops in VCONFIG. Again, there have been instances in which a user has given false information in order to gain sysop access to a BBS; use caution when allowing auto-validation. If you have configured "yes" for automatic call-back verification, VADV will prompt the user (according to the area code and prefix criteria you have established) to prepare to receive an incoming call from your board, at which point VADV hangs up, calls the data phone number left by the user, and confirms its authenticity by prompting the user answering the callback to provide the password for the new account. New users are assigned the SL and time allowed on the system according to what you have set up in VCONFIG. New User Feedback and Validation ════════════════════════════════ Generally, you do not want to give a new user too high an access level to your system until you are sure the informa- tion provided you is accurate. It is often desirable to have a new user leave a short introduction of himself or herself in addition to the information given in the basic signup process. To have the system prompt for such "new-user feedback", turn the appropriate option in VCONFIG on. Upon completion of the new user signup process, the new user is given the opportunity to change their account defaults. These settings allow the user to select a video terminal mode, customize display colors, and so on. Account defaults may be changed at any time thereafter by pressing [A] on the stock VADV main menu when logged into the BBS. User-selectable account defaults: 1) Video Mode The user may choose ASCII, ANSI, Enhanced ANSI (which enables pull-down menus) or RIP as the default. 2) Expert Toggle Expert mode disables the menu-at-every-prompt mode, and allows your more experienced users to more quickly navigate the BBS. 3) Page Breaks Number of lines per page. A setting of 0 produces continuous screen scrolling; 24 is default. 4) Password Change password, if desired. 5) Autoposts Toggles Autopost display at login. 6) Ctrl-A User Macro 7) Ctrl-B User Macro User may create up to 2 macros, each containing up to 79 characters (including ANSI control characters). 8) ANSI Color Setup User may customize screen colors to suit personal tastes. 9) Full Screen Editor Toggles between the ANSI full-screen editor (FSE) and a non-ANSI line editor. A) Mailbox Forward E-mail to another user or network system, if desired. B) Security Displays a list of things the user has a high enough SL to do. C) Long Distance Cost Allows user to keep track of LD usage and billing by defining cost per minute and knowing the billing cycle. D) Sort File Lists Toggles between alphabetically- and numerically-sorted file listings. E) User Time Bank User may deposit unused time for later withdrawal. Maximum time is set in VCONFIG. F) File List Display Toggles between single-line, double-line, and double-line with extended descriptions file listing. Q) Quit Saves changes and quits to Main Menu. The sysop should encourage new users to take time to set their defaults early on; ANSI users should be encouraged to use the full-screen editor for its superior cursor control and editing features. The User Editor ═══════════════ The user editor allows the sysop to view and edit users' information, validate and/or delete users. The user information is divided into several fields, each of which is described below. a) User Handle User's handle. Same as user's real name when handles are not allowed on the BBS. b) User Real Name User's real name. c) Address d) City e) State f) Zip User's mailing information. g) Security Level User's SL; acceptable values are 1-255 (255 is sysop access); the default SL given to a new user is set in VCONFIG. h) Access Flags Access flags A-Z for implementing "group" type access control to databases and on-line doors. For example, all users with an "A" in this field could access databases and doors requiring the "A" access flag. (Note: Users with a SL of 255 or higher override access flag restrictions.) i) Flags General flags used outside of databases/doors, given as a letter A-Z. VADV currently uses five flags "out of the package": F - Full Screen Editor X - Expert Mode (Menus Skipped) N - User Has Been Sent New-User Email I - Enable Internet Pass-Thru Access U - Enable UUCP Access The remaining unused flags can be used to govern network email access via optional configuration of the NETWORKS.LST file. Flags may be set or reset manually in the user editor, or via scripts. See SCRIPT.DOC for more information. j) Password User's password. k) Phone 1 User's voice phone number. l) Phone 2 User's data phone number. m) MaxTime Maximum time allowed on per day. n) Credits User's credit total. o) Verify Birthday User's birthday. If toggled, will ask user to re-enter birthday at next login. p) Ratio Exempt? Allows you to exempt the user from upload/download ratio (if any). q) U/L Files/kilobytes uploaded. r) D/L Files/kilobytes downloaded. s) Unforward Mail Turns off mail forwarding. Ex1 - Ex8 User's $extra variables 1 through 8. Manipulated with VSCRIPT SETEXTRA command. Page User's default page length (screen size). Vid User's default video mode. Calls Number of calls user has made to your BBS. Time Total time the user has spent on your BBS. Last The date the user last called your BBS. Posts Number of public posts the user has left. Email Number of E-mails the user has sent. You may edit the information in fields a) through r) and Ex1 through Ex8; the rest is pretty much "read-only" user-selected defaults or record-keeping information. There are several commands to help the sysop get around in the user editor: [/] Prompts for a user number, handle, or real name and searches on the information given. In case of duplicate information (e.g., two users with the first name "Mike"), it will ask if the user shown is the correct one. [Enter] Move to next record. [-] Move to previous record. [!] Delete user's account. Sets SL to 0 and opens the account number for reassignment. If you open several slots, a new user will be given the lowest-numbered slot available; the user list is NOT "packed" (renumbered) after deletions. [Esc] Exit the user editor. The user editor is a powerful tool for managing your user base -- spotting bogus accounts, changing users' access to various areas of the BBS, verifying information, and so on. There are several utilities available that make use of the information stored in USERFILE.DAT. UPLDSCAN.EXE ════════════ UPLDSCAN.EXE is the new upload scanner included with Virtual Advanced Ver 2.00 and higher. It's small size and efficient design result in the maximum of amount of free conventional memory space to run today's large virus scanner programs, such as MacAfee's latest series. OS2 platforms running Virtual Advanced for OS2 don't have to worry about conventional memory space, but DOS platforms running any kind of software do. Configuration of UPLDSCAN.EXE is accomplished by use of VCONFIG.EXE. If you desire to use a scanner other than MacAfee's you'll also need a text editor. See VCONFIG.DOC for details. ADVAUX.EXE ══════════ Virtual Advanced is huge program with a large built-in command set, and an infinite number of commands and configuration possibilities that can be added to the stock set-up. To keep the sizes of the executables in reason, some of the more "door-like" functions of the BBS are located in their own executable -- ADVAUX.EXE. ADVAUX.EXE is cut from the same cloth as VADV.EXE, and behaves exactly like it in terms of serial port usage, user file usage, etc. ADVAUX uses the following command line syntax: ADVAUX.EXE <ch> <COMMAND> <ch> VADV Channel Number <COMMAND> Which Part of ADVAUX To Execute Possible <COMMAND>'s Are: TEXTFILES This command takes the user to the "Text Bulletins" section of your BBS, where they can view lists and texts you have set-up previously. Also used by the sysop to set-up texts. Configuration of this part of ADVAUX is handled by VCONFIG. LISTUSERS SECURITY These commands both list user information. LISTUSERS lists all users on the system; SECURITY lists only those with an SL of 250 or higher. CHECKVOTE VOTE These two are related. VOTE takes them to the Voting Booth unconditionally, while CHECKVOTE takes them to the Voting Booth only if there are unaswered polls for this user. Configuration of this part of ADVAUX is handled by VCONFIG. LISTNET List network information. TELECON Multi-User Teleconference. Users can chat with each other in real-time. Supports the VLIVE Interface for multiple linking of several Virtual Advanced bulletin boards. See VL.DOC for more details on VLIVE. The standard Virtual Advanced teleconference module supports 99 different "rooms" in which your users may congregate. At the most basic level, anyone in a room hears what is said in that room, and can speak to others in the room. Optionally, the SysOp may affix permanent "names" to these rooms, and may also specify a "fixed" moderator for the room. Naming rooms makes them topical, and further allows you to customize your BBS. Moderators help to keep the teleconference room on track and on-topic if necessary. As an example, here is how one would configure ROOM 1: 1. Create File ROOM1.CFG In Your VADV Main Dir copy con ROOM1.CFG 2. Type In One Line Of Text In The Following Format: *MAIN*,1 3. Press <Enter>, then Press Ctrl-Z. You have now successfully named ROOM 1 as *MAIN*, and made yourself the only moderator. If the line had read: *MAIN*,0 The name would still be *MAIN*, but anyone could make themselves the moderator of ROOM 1. The TELECON module also supports Internet IRC in conjunction with VAIRC.EXE, a module that is part of the VISK package. The version of VISK required is 1.30 or higher. Please also see the instructions for VAIRC.EXE contained in the VISK 1.30 (or higher) package for more details on its use. VAIRC.EXE must be up and running as per its instructions before the ADVAUX TELECON module can access Internet Relay Chat. While in IRC mode, the user is no longer in the "regular" teleconference. This draws a distinction between the "Local Teleconference" that's happening right on your BBS, with "IRC Teleconference" where you are chatting with people from all over the world. Additionally, VA's IRC capability allows for each user on your BBS to customize his or her IRC experience, and have those customizations remembered for future use; these include configurable "Quit" messages, and the messages generated by Bots. VA also features a togglable IRC Profanity Filter to keep your users from cussing and possibly getting you into trouble. A typical use of the IRC function is described as follows: 1) User types /I 2) BBS shows a list of IRC servers and allows user to choose one 3) IRC session started with selected IRC server 4) Upon end of IRC session, the user is returned to the regular teleconference The list of IRC servers the user can choose from is configured by the sysop. The text file IRC-S.CFG should be created in the main VA directory, one entry per line, max 100 entries, in the format: <system name or IP address> <port #> <flags> <system name or IP address> The system name or IP address of the IRC server <port #> The port number (This is usually in the range 6665-6674) <flags> The flags let the SysOp control his users' behaviour on the IRC, and this is a bit-mapped field: Bit 0 - 1=Disable Profanity Filter Bit 1 - 1=Enable Busy-Bot Bit 2 - 1=Enable Welcome-Bot Bit 3 - 1=Enable AutoOp-Bot Possible values for the <flag> field: 0 - Prof Filt Enabled, All Bots Disabled 1 - Prof Filt Disabled, All Bots Disabled 2 - Prof Filt Enabled, Busy-Bot Enabled 3 - Prof Filt Disabled, Busy-Bot Enabled 4 - Prof Filt Enabled, Welcome-Bot Enabled 5 - Prof Filt Disabled, Welcome-Bot Enabled 6 - Prof Filt Enabled, Busy-Bot & Welcome-Bot Enabled 7 - Prof Filt Disabled, Busy-Bot & Welcome-Bot Enabled 8 - Prof Filt Enabled, Auto-Op-Bot Enabled 9 - Prof Filt Disabled, Auto-Op-Bot Enabled 10 - Prof Filt Enabled, Busy-Bot & Auto-Op-Bot Enabled 11 - Prof Filt Disabled, Busy-Bot & Auto-Op-Bot Enabled 12 - Prof Filt Enabled, Welcome-Bot & Auto-Op-Bot Enabled 13 - Prof Filt Disabled, Welcome-Bot & Auto-Op-Bot Enabled 14 - Prof Filt Enabled, All Bots Enabled 15 - Prof Filt Disabled, All Bots Enabled A "Bot" is a kind of automated response to some type of stimulus (input). All Bots are inactive at the start of any new IRC session. Bots are not accessible if you "flag" them as being disabled. The Bots built-in are designed to be non-intrusive, non-destructive bots, however, read this anyway: MOST IRC SERVERS DESPISE BOTS AND WILL KICK YOU OFF IF THEY CATCH YOU USING THEM. USE AT YOUR OWN RISK. The Busy-Bot flashes a user-configured "away from my keyboard" style message once per minute to let others in IRC know you'll be right back. The Welcome-Bot flashes a user-configured "welcome" style message when someone new enters the IRC channel. %s and %c can be used as replacable parameters to mean "name" and "channel name" respectively. The Auto-Op-Bot is a Bot you'd use if you were an IRC Channel Operator (ChanOp), and you wanted to automatically Op/ReOp your friends as they come into the channel. If you are familiar with IRC, then you know what this option is for. If not, contact me on IRC, and I'll be happy to explain it you. Need help finding an IRC server? Email irc@virtualc.com for a list of possible servers and port numbers. Note that a sample IRC-S.CFG (listing only a few possible servers) is included with this package to help start out. Tip: Not only can VAIRC.EXE connect your users to people all over the world, but you could use also use it to link up with the BBS down the street, so long as you are both connected to the Internet, and you are both are using the same IRC server. WHO Displays Who's Online. Not needed by VADV - supplied for your creative usage. HELP x Enter the HyperText HELP System (Default Help Files Not Included). x indicates the number of the main help file -- from 0 to 999 -- allowing you to have multiple hypertext systems. SYSOPCMD Additional SysOp Functions Avaiable Here. Accessing ADVAUX From A Function Block ══════════════════════════════════════ If you've ever looked in the default .FB files that are included with Virtual Advanced, then you may have seen references to the ADVAUX module that look like this: B 001 4 advaux %1 TEXTFILES U 001 4 advaux %1 LISTUSERS V 001 4 advaux %1 VOTE N 001 4 advaux %1 LISTNET /CHAT 001 4 advaux %1 TELECON The %1 is replaced at run-time with the proper channel number. Accessing ADVAUX From A Script ══════════════════════════════ Running ADVAUX from a script is easy: door "advaux %1 TEXTFILES" The %1 is replaced at run-time with the proper channel number. VME.EXE ═══════ VME.EXE is the Virtual Multi-Network Engine, and its job is to direct mail and coordinate the functioning of the BBS, VNET.EXE, VUUCP.EXE, and VFIDO.EXE, as they all work together to provide a unified mail system. In a sense, VME.EXE directs the traffic so that everything functions smoothly in a multi-user environment. It also allows for gateways between networks. One of the best things about VME.EXE is that there is virtually no set-up involved; when you set-up a network interface program such as VNET, VUUCP, or VFIDO, as per its docs VNET.DOC, VUUCP.DOC, or VFIDO.DOC, you have given VME all the critical configuration information it needs. Another great thing about VME.EXE is that VADV.EXE executes it automatically, as needed. There are no tricky .BAT files to set-up or configure for most installations; the only time one might want to call upon VME.EXE manually is under very special circumstances, such as: 1) running VADV under a matrix login 2) running VADV as a door under another BBS 3) importing mail from exotic sources There is one optional, advanced feature about VME.EXE that does require some additional configuration if you want to use this feature. This feature is the AUTO-RESPONDER, which you can use to make it possible to send "form letters" to people who send email to a certain "userid" on your system. For example, Virtual ComTech has one set up at "virtualc.com" called "help". If you send email to help@virtualc.com, you'll receive back an automated reply of the latest Tech Help instructions. The text file you need to create in the VADV main directory is called AUTORESP.CFG. This file should contain one entry per line, and may contain as many lines as you wish. Each entry must be in one of two formats: Format 1, No Attached File: <handle>,<pathname of text reply file> Format 2, Include Attached File: <handle>,<pathname of text reply file>,<pathname of attached file> Examples: info,c:\robot\info.txt help,c:\robot\help.txt file,c:\robot\file.txt,c:\sysop\file.zip Of course, you'll also need to create the text reply file. Here is an example of a text reply file. Note that lines 1, 2, and 3 have special meaning, with the remainder of the file constituting the body of the text which is sent: Help <-- Line 1 = Desired Subject AutoResponder <-- Line 2 = Desired From: Handle 2 <-- Line 3 = User # From: Thank you for using the HELP auto-responder at Virtual ComTech Int'l Inc. -=- Virtual ComTech Int'l Web Site -=- http://virtualc.com -=- Virtual ComTech 24-hour BBS -=- 616-399-4818 616-399-8791 -=- Virtual Advanced/VISK Author -=- rdegraaf@virtualc.com -=- Documents Available By Email Request -=- Document Send Email To ------------------- ---------------------------------------------------- Help (This DOC) help@virtualc.com Order Form orderform@virtualc.com -=- Official Support Internet "Mail Lists" -=- 1. VADV-R Virtual Advanced News/Announcements READ-ONLY To subscribe, send Internet Email to LISTSERV@virtualc.com and put in the BODY of the message: subscribe VADV-R To unsubscribe, send Internet Email to LISTSERV@virtualc.com and put in the BODY of the message: signoff VADV-R 2. VADV-L Virtual Advanced Technical Support READ/WRITE To subscribe, send Internet Email to LISTSERV@virtualc.com and put in the BODY of the message: subscribe VADV-L To unsubscribe, send Internet Email to LISTSERV@virtualc.com and put in the BODY of the message: signoff VADV-L To post a message to the mail list, email your post to VADV-L@virtualc.com, and your post will be redistributed to all list members. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- PAK.EXE ═══════ PAK.EXE is a single-file compression/decompression utility program. It operates on a command line basis: PAK c <infile> <outfile> Compress the contents of <infile>, yielding <outfile>. PAK d <infile> <outfile> Decompress the contents of <infile>, yielding <outfile>. PAK.EXE does not make any assumptions about filename extensions, so make sure you include extensions. PAK was mainly designed to be used in conjunction with VWC, as it yields excellent compression ratios with .BMPs and .WAVs -- two items that VWC can work with, although there are bound to be other uses. SLIP/CSLIP/PPP Pass-Thru ════════════════════════ The Internet Pass-Thru feature allows your BBS to serve double-duty as both a BBS, and a possible access point for real, direct Internet access for your callers. Simply put, this mechanism allows you to share an Internet SLIP, CSLIP, and/or PPP account with others, under controlled conditions, while "metering" and/or restricting the amount of time used by the caller. There are just a few parameters to set-up for this function; they are described in VCONFIG.DOC. Basically, it works like this: (1) The caller (who desires to use Internet) calls your BBS using their normal SLIP, CSLIP, or PPP software .. ie.. Trumpet Winsock, Win95 Dial-Up Networking, or any other equivalent. The caller DOES NOT call in using a term program such as Telix, Procomm, etc. (2) Their dial-up script is programmed to log them into your BBS, using their normal user account. The dial-up script should given their normal login handle, with a special suffix added to indicate that they wish to access the Internet in one manner or another: .SLIP Wants a SLIP connection .CSLIP Wants a CSLIP connection .PPP Wants a PPP connection Their password should be sent unaltered. Here is a simple example of a caller-side script for Win95 Dial-Up Networking, which logs the caller into the BBS for PPP access: proc main waitfor "ogin:" until 30 transmit "Roland De Graaf.PPP^M" waitfor "word:" until 30 transmit "password^M" delay 40 endproc Here is a simple example of a caller-side script for Win95 Dial-Up Networking, which logs the caller into the BBS for SLIP access: proc main waitfor "ogin:" until 30 transmit "Roland De Graaf.SLIP^M" waitfor "word:" until 30 transmit "password^M" delay 40 endproc Here is a simple example of a caller-side script for Win95 Dial-Up Networking, which logs the caller into the BBS for PPP access, when the caller is SysOp and has to negotiate one more prompt: the system password: proc main waitfor "ogin:" until 30 transmit "Roland De Graaf.PPP^M" waitfor "word:" until 30 transmit "password^M" waitfor "word:" until 30 transmit "systempw^M" delay 40 endproc Note the "delay 40" line that is in each of the scripts. It takes a small amount of time for the your end to dial the ISP and login. This "delay" statement prevents Win95 Dial-Up Networking from trying to negotiate PPP too soon. The actual time delay required may vary; you may find that callers can lower the delay to 30, or you may find that they need to increase it to 50 or more. (3) Recognizing that this is a request for Internet access, the BBS will: (4) Check the user's flags. The I flag MUST be set for access to be granted. (If the I flag is not set, the login will continue like a regular user login.) (5) If (4) is OK, then the BBS executes ADVAUX to handle the rest of the session. (6) When ADVAUX loads, a check is made to see that the monthly time used is not past the limit set by the sysop. If it is, the caller is given a brief text message and disconnected. (7) Next, ADVAUX looks for an open channel on your BBS. If none are available, the caller is given a brief text explanation and disconnected. (8) The open channel is commanded to initiate a dialout to your ISP as configured in VCONFIG SLIP/CSLIP/PPP Pass-Thru. (9) Once connected to your ISP, the Internet Pass-Thru dialer uses a script you create to login to your Internet Provider: SLIP.SCR For SLIP Sessions CSLIP.SCR For CSLIP Sessions PPP.SCR For PPP Sessions You may set-up one, two, or all three of these files. You must set-up at least ONE or these. Which of the three connect modes (SLIP, CSLIP, PPP) you'll be able to offer depends entirely on which ones are supported by your chosen ISP. NOTE: THE ISP YOU CHOOSE MUST SUPPORT THE STANDARD TEXT-STYLE login: / password: SEQUENCE AS THE MEANS FOR LOGGING IN TO THE INTERNET AND MUST NOT REQUIRE PAP (Password Authentication Protocol) OR CHAP (Challenge Handshake Authentication Protocol). If the caller requests a connect mode you don't have configured, they are given a brief explanation and disconnected. The appropriate script is executed, and once logged into your ISP, the connection to the remote caller and the connection to the ISP are virtually tied together forming a tight communications link. ---------- --------------------- | Caller | -> | BBS Channel | ---------- |- - - - - - - - - -| ---------- | - - - - - - - - - | | ISP | <- | BBS Channel | ---------- --------------------- Put in simpler terms, what comes in one modem is transmitted out the other, and vice-versa. The link is maintained as long as both sides have CARRIER DETECT, and the user's time limit has not run out. Once the user and the Internet are bridged together, the user can run any standard Internet application, ie web browser, ftp, telnet -- you name it. Due to the connect as needed and disconnect when done nature of this utility, the Internet Pass-Thru is best used with a non-dedicated Internet connection. One of those "unlimited access" type non-dedicated accounts may be best. If the type of connection you already have now is dedicated, then you may consider getting another, cheaper non-dedicated account for Internet Pass-Thru use. Programming the script you will use to login to your ISP should be fairly easy. You must create SLIP.SCR and/or CSLIP.SCR and/or PPP.SCR in your main VADV directory, using almost any text editor. The IP Dialer script langauge is rather simple: transmit Transmits Text With Character Translation (ie ^M = carriage return) transmitraw Transmits Text Without Character Translation delay Pause The Script For A Number Of Seconds Here is a simple example, showing how to do a PPP login with an actual provider (WinNet): delay 4 transmit ^M transmit p_virtual^M delay 2 transmit password^M delay 1 Here is a simple example, showing how to do a SLIP login with the same provider: delay 4 transmit ^M transmit s_virtual^M delay 2 transmit password^M delay 1 Notice the little trick used by that provider to determine whether SLIP or PPP is being requested? A recap of what needs to be set-up by the sysop: VCONFIG Internet Pass-Thru At least one of the three files: SLIP.SCR, CSLIP.SCR, PPP.SCR to log the system into the Internet Service Provider NOTE: Internet Pass-Thru uses the directory defined in VCONFIG "CONTROL.DAT Directory" for temporary data storage. For maximum performance, set your CONTROL.DAT Directory setting to a RAMDRIVE, or if that's not possible, at least use a cached hard-drive. When choosing a size for the RAMDRIVE, think in terms of 8k to 16k per active channel on your BBS. User's account needs to have the "I" user flag set A recap of what needs to be set-up by the BBS caller: TCPIP Software that supports PPP or SLIP Some type of Login Script appropriate to their TCPIP software that will log them into the BBS DNS Servers - Since they will be using your provider, they should set their DNS servers to the same ones you use when you use your provider. Without DNS, they won't be able to resolve domain names to IP addresses. SLIP/CSLIP/PPP Pass-Thru And "Family" PPP Accounts ══════════════════════════════════════════════════ Many ISPs offer "family type" PPP access where you get two login IDs (each with a different password) with one login ID being full, regular Internet access, and the second ID being filtered access -- for the kids. If you have such an account, and you wish to use it with the Internet Pass-Thru, then you should configure PPP.SCR to use the REGULAR account, and PPP2.SCR to use the FILTERED account. To indicate that a BBS caller should be directed to the filtered access, set their "Y" User Flag. Access Type Login File User Flags ------------ -------------------------------- ---------- Regular (Full) SLIP.SCR, CSLIP.SCR or PPP.SCR I Filered SLIP2.SCR, CSLIP2.SCR or PPP2.SCR I & Y Note: If you are using a "simple" Internet account with a single Login ID/password, you DO NOT need to configure SLIP2.SCR, CSLIP2.SCR, or PPP2.SCR.