home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Monster Media 1994 #1
/
monster.zip
/
monster
/
BBS_UTIL
/
BFE3100P.ZIP
/
BFE3100P.EXE
/
DOCS
/
BFEREF.DOC
< prev
next >
Wrap
Text File
|
1994-03-12
|
45KB
|
1,008 lines
▒▒▒▒▒▄ ▒▒▒▒▒▒▄ ▒▒▒▒▒▒▄
▒▒█▀▒▒█ ▒▒█▀▀▀▀ ▒▒█▀▀▀▀
▒▒▒▒▒█▀ ▒▒▒▒▒▄ ▒▒▒▒▒▄
▒▒█ ▒▒▄ ▒▒█▀▀▀ ▒▒█▀▀▀
▒▒▒▒▒█▀ ▒▒█ ▒▒▒▒▒▒▄
▀▀▀▀▀ ▀▀ ▀▀▀▀▀▀
▒▒▒▒▒▒▄ ▒▒▒▒▒▒▄ ▒▒▒▒▒▒▄ ▒▒▒▒▒▒▄ ▒▒▒▒▒▒▄ ▒▒▒▒▒▒▄ ▒▒▒▄▄ ▒▒▄ ▒▒▒▒▒▒▄ ▒▒▒▒▒▒▄
▒▒█▀▒▒█ ▒▒█▀▀▀▀ ▒▒█▀▀▀▀ ▒▒█▀▀▀▀ ▒▒█▀▒▒█ ▒▒█▀▀▀▀ ▒▒█▒▒█▒▒█ ▒▒█▀▀▀▀ ▒▒█▀▀▀▀
▒▒▒▒▒█▀ ▒▒▒▒▒▄ ▒▒▒▒▒▄ ▒▒▒▒▒▄ ▒▒▒▒▒█▀ ▒▒▒▒▒▄ ▒▒█ ▀▒▒▒█ ▒▒█ ▒▒▒▒▒▄
▒▒█▀▒▒▄ ▒▒█▀▀▀ ▒▒█▀▀▀ ▒▒█▀▀▀ ▒▒█▀▒▒▄ ▒▒█▀▀▀ ▒▒█ ▒▒█ ▒▒█ ▒▒█▀▀▀
▒▒█ ▒▒█ ▒▒▒▒▒▒▄ ▒▒█ ▒▒▒▒▒▒▄ ▒▒█ ▒▒█ ▒▒▒▒▒▒▄ ▒▒█ ▒▒█ ▒▒▒▒▒▒▄ ▒▒▒▒▒▒▄
▀▀ ▀▀ ▀▀▀▀▀▀ ▀▀ ▀▀▀▀▀▀ ▀▀ ▀▀ ▀▀▀▀▀▀ ▀▀ ▀▀ ▀▀▀▀▀▀ ▀▀▀▀▀▀
▒▒▒▒▒▒▄ ▒▒▄ ▒▒▄ ▒▒▄ ▒▒▒▒▒▄ ▒▒▒▒▒▒▄
▒▒█▀▀▀▀ ▒▒█ ▒▒█ ▒▒█ ▒▒█▀▒▒█ ▒▒█▀▀▀▀
▒▒█▒▒▒▄ ▒▒█ ▒▒█ ▒▒█ ▒▒█ ▒▒█ ▒▒▒▒▒▄
▒▒█ ▒▒█ ▒▒█ ▒▒█ ▒▒█ ▒▒█ ▒▒█ ▒▒█▀▀▀
▒▒▒▒▒▒█ ▒▒▒▒▒▒█ ▒▒█ ▒▒▒▒▒█▀ ▒▒▒▒▒▒▄
▀▀▀▀▀▀ ▀▀▀▀▀▀ ▀▀ ▀▀▀▀▀ ▀▀▀▀▀▀
┌──────────────────────────────────────┐
▓███│ v3.10.0 Release Date 12 Mar 1994 │▓███
└──────────────────────────────────────┘
(C)opyright 1992-1994 Southeastern DataLINK, All Rights Reserved
7088 Stoneybrook Drive, Columbus, Georgia 31909
─────────────────────────────────────────────────────────────────────────────
█▌▐█ █▀▀ ▐█▌▐▌ █ █ ▀█▀ █ █ █▀█ █▀▀ █▀▀ █ █ █ █▀▄ █▀▀
█▐▌█ ██ ▐▌▌▐▌ █ █ █ █ █▀▀ ██ █ ▄▄ █ █ █ █ █ ██
█ █▌ █▄▄ ▐▌███ █▄█▌ █▌ █▌ █▌ █▄▄ █▄▄▌ █▄█▌ █▌ █▄█▌ █▄▄
─────────────────────────────────────────────────────────────────────────────
TYPE: E
DESC: Errorlevel Exit (Lower DTR)
SCRIPT: ErrorLevelLow();
SECONDARY CONTAINS: Valid numeric DOS errorlevel (5-255)
Specifying an "E" as the type will cause BFE to exit back to the calling
batch file with an errorlevel. This is perhaps one of the more powerful
types, as it provides virtually unlimited possibilities. Simply place the
errorlevel you wish to exit with in the SECONDARY FIELD. As an example, you
could call one BBS with an errorlevel of 100, and another one with an
errorlevel of 101, etc. Basically, as long as you trap the errorlevel in
your calling batch file, you could do practically anything! This menu type
will lower the DTR of the modem, and hang up on the current user.
─────────────────────────────────────────────────────────────────────────────
TYPE: 2
DESC: Errorlevel Exit/DTR HIGH/LU
SCRIPT: ErrorLevelHi();
SECONDARY CONTAINS: Valid numeric DOS errorlevel (0-255)
This menu type is similar to the menu type "E" above, with one exception: The
DTR of the modem will remain high. This comes in handy when running BFE as a
normal door, allowing the user to exit BFE, but return to your BBS or host
software. This menu type will also generate a LASTUSER.nnn file in the IPC
directory.
─────────────────────────────────────────────────────────────────────────────
TYPE: 6
DESC: Errorlevel Exit (DTR High/no LU)
SCRIPT: ErrorLevelHiNOLU();
SECONDARY CONTAINS: Valid numeric DOS errorlevel (0-255)
This menu type is similar to the menu type "2" above, with one exception:
no LASTUSER.nnn file is generated in the IPC directory.
─────────────────────────────────────────────────────────────────────────────
TYPE: R
DESC: Run an External Process
SCRIPT: RunExternal();
SECONDARY CONTAINS: Path/filename of external program or batch file
Specifying an "R" as the type will cause BFE to execute (run) an external
process. This is also an incredibly powerful option, in very much the same
way as the "E" type. The benefit of using "R" over "E" is simple: You don't
have to fiddle with the calling batch file and trapping the errorlevels. In
addition, if the PASSPARMS (described later) option is enabled, BFE will pass
the communication parameters on the command line for you. This feature is
unavailable in an "E" type errorlevel exit! BFE will attempt to swap itself
out to memory or disk first, to ensure that you have as much memory as
possible to call your task. If you wish to run a program that requires
command line parameters or switches, you can do this in one
of two ways. You can place all of the switches in a batch file, and have BFE
call the batch file, or you can make use of the PROCESS field, and its
macros. Your call!
Simply place the name of the external process in the SECONDARY FIELD. You
may specify the full path, or just the filename if it resides in your path or
the BFE directory.
** NOTES: We cannot stop expressing the sheer power of this type! You can
use this to call bulletin doors, message entry doors, Doorway, etc. BFE
works especially well with RegPRO, our full screen online entry form system!
:-) It is possible to call a program such as Marshall Dudley's Doorway(tm).
In fact, this has been tested and confirmed by several BFE corporate beta
sites. Since BFE passes the port and baud rate to any external processes, it
is a cinch.
If you experience problems running certain programs via this option, your
command line parameters may not be coming across as you think they are. We
have included a small program called CMDLINE.EXE, which allows you to "test"
your command lines from BFE. Simply run this program instead of the program
in question, and the command line parameters passed to the program will be
displayed on your screen.
─────────────────────────────────────────────────────────────────────────────
TYPE: P
DESC: Page Sysop
SCRIPT: Page();
SECONDARY CONTAINS: N/A
When the user selects a menu option which has been labeled as a type "P", BFE
initiates the sequence of events leading to a chat session with the sysop or
current operator. BFE first checks the paging hours as configured in
BFE/Setup (Global Options), and if valid, will prompt the user for a "reason
to chat". If the user simply hits ENTER, then the page attempt is aborted.
If the user enters a reason, BFE will begin to page the sysop. You can break
in to chat by pressing CTRL-C at any time. The reason for chat is also
placed into the BFE log file if logging has been enabled.
If the user has ANSI or AVATAR graphics mode enabled, BFE will utilize the
internal full screen chat mode. The screen will be split into two
partitions, with the user's comments appearing in the top window, and the
sysop's comments appearing in the bottom window, each in the respective color
as reflected in BFE/Setup. If the user is using vanilla ASCII/TTY mode, the
old line chat mode will be initiated.
While in the full screen chat mode, pressing ESC twice on the sysop end will
return the user to BFE.
─────────────────────────────────────────────────────────────────────────────
TYPE: N
DESC: Page Sysop (NOW!)
SCRIPT: PageNow();
SECONDARY CONTAINS: N/A
This menu item type functions the same as the type "P" above, with one
exception: No time checks are performed against the configured paging hours
from BFE/Setup. This menu type will *always* initiate a page.
─────────────────────────────────────────────────────────────────────────────
TYPE: P
DESC: Play ANSI Music String (Remote Only!)
SCRIPT: PlayMusic()
SECONDARY CONTAINS: ANSI music string
For those who are interested in implementing ANSI music / sounds in their
frontend setups, this function is for you. This menu type will play ANSI
music / sounds on the remote system, and not echo the music on the local
speaker. This is usually alright, as most often the sysop would not want
their computer emitting beeps and playing music at all hours of the day.
Future additions for supporting the local speaker may be in order. It can be
called with a string of 1 to 250 characters. The characters of the string
define what sounds should be played:
A - G Musical Notes
# or + Following A-G note means sharp
- Following A-G note means flat
< Move down one octave
> Move up one octave
. Period acts as dotted note (extend note duration by 3/2)
MF Music Foreground (pause until finished playing music)
MB Music Background (continue while music plays)
MN Music note duration Normal (7/8 of interval between notes)
MS Music note duration Staccato
ML Music note duration Legato
Ln Length of note (n=1-64, 1=whole note, 4=quarter note, etc)
Pn Pause length (same n values as Ln above)
Tn Tempo, n=notes/minute (n=32-255, default n=120)
On Octave number (n=0-6, default n=4)
As an example of using this menu type/function, consider the following:
PlayMusic("MBT120L4MFMNO4C8C8DCFE2C8C8DCGF2C8C8O5CO4AFED2T90B-8B- 8AFGF2");
PlayMusic("00m");
Which plays the tune "Happy Birthday". :-) Look for a collection of these
tunes coming soon!
─────────────────────────────────────────────────────────────────────────────
TYPE: A
DESC: Toggle ANSI Graphics
SCRIPT: ToggleANSI();
SECONDARY CONTAINS: N/A
This menu type merely allows the current user to switch BFE in and out of
ANSI graphics mode. This option can also be toggled from BFE/Script, via the
TOGGLEANSI() function.
─────────────────────────────────────────────────────────────────────────────
TYPE: 3
DESC: Toggle RIP Graphics
SCRIPT: ToggleRIP();
SECONDARY CONTAINS: N/A
This menu type merely allows the current user to switch BFE in and out of RIP
graphics mode. This option can also be toggled from BFE/Script, via the
TOGGLERIP() function.
─────────────────────────────────────────────────────────────────────────────
TYPE: 4
DESC: Toggle MORE Graphics
SCRIPT: ToggleMORE();
SECONDARY CONTAINS: N/A
This menu type merely allows the current user to switch BFE in and out of
MORE prompting mode. When BFE displays a file longer than the screen
length, a "more" system of prompting is utilized. This is great if the user
is browsing through some informative text file, but not too hot if you are
trying to show ANSI animations, or RIP scenes, which may be quite a big
larger. This option can also be toggled in BFE/Script, via the ToggleMore()
function.
─────────────────────────────────────────────────────────────────────────────
TYPE: O
DESC: Shell to Operating System
SCRIPT: OS_Shell();
SECONDARY CONTAINS: N/A
For those of you wish to drop to DOS from remote, this is the one! Simply
place an O as the type. BFE will make use of the COMSPEC enviroment variable
to locate your command processor (COMMAND.COM, 4DOS.COM, etc). To return to
BFE, simply type exit at your command prompt.
One note is in order here. You may run any program you desire from remote,
once you are in the OS shell. However, keep in mind that unless the program
supports DOS routing, then you will not see any output on your screen. Most
command line utilities will work just fine, as well as the internal DOS
commands, however, things like Windows, PC-Tools, etc will not function
properly, and will more than likely lock your system. If you enable your
fossil watchdog, you should be fine in the event you get hung up. Check your
fossil documentation for more information on the watchdog services.
With the inherent power that arrives by shelling to your OS from remote, you
should always password protect this option!
─────────────────────────────────────────────────────────────────────────────
TYPE: D
DESC: Display a File (ANSI/ASCII/AVATAR/RIP)
SCRIPT: DisplayFile();
SECONDARY CONTAINS: Path/filename of file (extension optional)
This nifty type will allow you to display an ANSI, ASCII, AVATAR, or RIP file
to the user. To use this option, simply place the filename of the file to be
displayed in the SECONDARY FIELD. If you do not specify an extension, then
BFE will look for the filename which corresponds to the user's graphic
settings. For example, you could create four different screens for your
WELCOME screen:
WELCOME.ASC
WELCOME.ANS
WELCOME.AVT
WELCOME.RIP
In the above example, simply using the filename alone, with no extension, BFE
would display the appropriate file. BFE will "drop down" one level, and
attempt to display *something*. For instance, if the user was RIP capable,
and BFE could not locate a RIP version of your file, he will attempt to
display the .AVT (AVATAR) version, then the .ANS (ANSI) version, and so on.
You may also specify the extension, if you only want one file to be used,
such as MYFILE.TXT. You may specify a full path, or just the filename if the
file is in the BFE directory.
By default, BFE will automatically engage "more prompting" when displaying
screens that are over 1 screen in length, except for when in RIP mode. This
setting is toggable via the ToggleMore() function in BFE/Script (More later).
** NOTE: BFE "interprets" the file as it is being displayed to the COM port.
It is capable of interpretting embedded system codes used by RemoteAccess.
For more information on these codes, please refer to your RA documentation.
More embedded code schemes, such as WildCat! and PCBoard will be added in
future releases.
─────────────────────────────────────────────────────────────────────────────
TYPE: 5
DESC: FlashFile
SCRIPT: FlashFile();
SECONDARY CONTAINS: Path/filename of file to be displayed
Functions the same as the type "D" above, but with no page pausing.
─────────────────────────────────────────────────────────────────────────────
TYPE: F
DESC: Download a File
SCRIPT: DownloadFile();
SECONDARY CONTAINS: Path/filename of file to be downloaded
This type will allow the user to download a file (ratio free) from BFE,
without having to log onto your BBS first. This is particularly handy,
especially if you are a shareware author, as you can offer the latest
versions of your products up front. Trust me when I say that your long
distance users will admire you for this! Simply place the filename to be
downloaded in the SECONDARY FIELD. You may specify a full path, or just the
filename if the file is in the BFE directory.
When the user selects this option, BFE will present a list of available
protocols (configured via the PROTOCOL EDITOR in BFE/Setup).
─────────────────────────────────────────────────────────────────────────────
TYPE: U
DESC: Upload a File
SCRIPT: UploadFile();
SECONDARY CONTAINS: N/A
This menu type is very similar to the type "F" above, only it allows your
users to upload files to your system rather than downloading them. In
addition, if the protocol in which the user has selected has been setup to
"Prompt for Filename", then BFE will prompt for this information, and pass it
to the protocol dispatcher (once again, configured in the PROTOCOL EDITOR in
BFE/Setup).
─────────────────────────────────────────────────────────────────────────────
TYPE: M
DESC: Download file from a list
SCRIPT: DownloadList();
SECONDARY CONTAINS: Path of FILES.BBS to use for listing
This type is very similar to the "F" type, with one exception. Instead of
downloading a specific file, the user will be presented with a list of the
available files, from which he/she may choose the file to be downloaded. In
order to use this type, a "files list" must be created, and the full path to
the list must be placed in the SECONDARY FIELD.
This list should be in the following format:
---------------------------[ CUT HERE! ]---------------------------------
Southeastern DataLINK Free File List
D:\FILES\AVLAB100.ZIP AVLab v1.0 - Antiviral Researcher's Toolkit!
D:\FILES\RCS10A.LZH Netmail Robot Construction Set v1.0a
D:\FILES\RP_260.LZH RegPRO v2.60 - The Premier Questionnaire Door!
D:\FILES\TBM_250.LZH Turbo Bulletin Manager Door v2.50
D:\FILES\VID201.ZIP VID v1.10 - Virus Information Door
D:\FILES\VP0793.ZIP Updated VID Virus Database - as of March 1993
D:\BETA\RP_300B.LZH Beta version of the upcoming RegPRO 3.0 release!
---------------------------[ CUT HERE! ]---------------------------------
As you can see, this is a modified version of the standard FILES.BBS, with
the only difference being that the full path to each file needs to be
present. This provides a nifty way of pulling files from all over your system
to a single file download menu. In this way, you need not use any of the
FILES.BBS files that your BBS uses, you can create a custom one and place it
in another directory, such as the BFE directory. Any line which does not
start in column one is considered a comment line, and will be displayed in
the appropriate attribute (as configured in BFE/Setup).
All that is needed in the secondary field is the PATH to the FILES.BBS, not
the entire path/filename. The name FILES.BBS is assumed.
Once again, the user will be presented with a list of available protocols
which are defined in the PROTOCOL EDITOR.
─────────────────────────────────────────────────────────────────────────────
TYPE: J
DESC: Jump to another menu (.CTL file)
SCRIPT: N/A
SECONDARY CONTAINS: Path and filename of new .CTL file
Through the use of the "J" type, you can have BFE call a completely different
.CTL file! This is handy when you need to group several options together:
For example:
Top Menu (MAIN.CTL)
- -
- -
Sysop Menu (SYS.CTL)<--- ----> Product Info (PROD.CTL)
Menus can be nested up to 10 levels. If you try to go beyond this, BFE will
simply post a warning message and re-display the current active menu.
Although we feel that 10 levels of menu nesting is quite adequate for a BBS
front end, this will more than likely become limited only by available memory
in the future.
─────────────────────────────────────────────────────────────────────────────
TYPE: X
DESC: Return from a jump
SCRIPT: N/A
SECONDARY CONTAINS: N/A
Use this option to provide a method of returning from a subordinate .CTL file
menu back to the .CTL file menu that called it.
─────────────────────────────────────────────────────────────────────────────
TYPE: T
DESC: Return to main menu
SCRIPT: N/A
SECONDARY CONTAINS: N/A
This menu type simply provides a hook from returning to the original .CTL
file menu (i.e. the one that BFE started with initially), from any level of
nesting. A short cut, if you will.
─────────────────────────────────────────────────────────────────────────────
TYPE: S
DESC: Run a BFE Script Program
SCRIPT: N/A
SECONDARY CONTAINS: Path and filename of script to execute
BFE has an internal script processor called BFE/Script. You can create
scripts to do just about anything! An overview of the BFE/Script system
appears later in this manual.
─────────────────────────────────────────────────────────────────────────────
TYPE: L
DESC: Enter a Message (*.MSG format)
SCRIPT: LeaveMsgSDM();
SECONDARY CONTAINS: Number of message area to use
BFE contains an internal line editor called BFE/Edit. You may configure any
of your menu options to have the user enter a message through the use of the
internal editor. The secondary field should contain the "number" of the
message area to use. This number corresponds directly to the list of message
areas which appears by selecting MESSAGE BASES from the main menu of
BFE/Setup.
─────────────────────────────────────────────────────────────────────────────
TYPE: B
DESC: Enter a Message (Squish format)
SCRIPT: LeaveMsgSQ();
SECONDARY CONTAINS: Number of message area to use
Functions identically to the type "L" menu type (above), but uses Squish
compatible echomail areas.
─────────────────────────────────────────────────────────────────────────────
TYPE: 1
DESC: Show Available SlashCommands
SCRIPT: N/A
SECONDARY CONTAINS: N/A
When activated, this will display a brief listing of all SlashCommands that
area available to the current user, based on security level. For each
SlashCommand shown, the description of the SlashCommand will also be
displayed.
─────────────────────────────────────────────────────────────────────────────
TYPE: 7
DESC: Passive Transmit to Gateway
SCRIPT: Transmit2Gateway(command, 0);
SECONDARY CONTAINS: Remote command line
Once a BFE/gateway connection has been established by calling the script
function gateway(), individual "client" commands may be programmed into
standard BFE menus through the use of this menu type. The contents of
the SECONDARY FIELD will be sent through the gateway port, presumably to
a UNIX server running through a NULL modem cable (see GATEWAY.DOC for more
detailed information on setting up a UNIX gateway through BFE). The
PROCESS field may also be used to obtain command line arguments, and will
be appended to the contents of the SECONDARY FIELD. This is the PASSIVE
version of the Transmit2Gateway() function. After the command is sent to
the server, control is immediately passed back to BFE.
─────────────────────────────────────────────────────────────────────────────
TYPE: 8
DESC: Active Transmit to Gateway
SCRIPT: Transmit2Gateway(command, 1);
SECONDARY CONTAINS: Remote command line
This is functionally equivalent to the above command, but the user will not
be returned to BFE, until the RETURN2BFE string is sent by the server to
BFE.
─────────────────────────────────────────────────────────────────────────────
TYPE: 9
DESC: Dummy Line Separator
SCRIPT: N/A
SECONDARY CONTAINS: N/A
This menu type functions as simply a menu line separator in the default
BFE menus. This allows you to place "divider" lines between the various
menu items. Keep in mind that in order for any BFE menu item to be on
the "active" list of menu items, it must have a description. This menu
type does not make use of the description field at all, but for readability,
we suggest you put a few dashes ("----") in the description field for your
line separators.
─────────────────────────────────────────────────────────────────────────────
TYPE: G
DESC: Goodbye (Log off)
SCRIPT: Goodbye();
SECONDARY CONTAINS: N/A
This type is fairly straightforward! It hangs up on the user, and returns an
errorlevel of 255 to the calling batch file.
─────────────────────────────────────────────────────────────────────────────
█▀█ █▀▀ █▀▀ █ █ █▀▀ █▀▀ █▀█ █▀▀ █ █ █▀▀ ▀█▀ █▀▀ █▌▐█
█▀█ █▀ ██ █ █ ▀▀█ ██ █▀▌ ▀▀█ █ ▀▀█ █ ██ █▐▌█
█▄█▌ █▌ █▄▄ █▄█▌ █▄█▌ █▄▄ █ █ █▄█▌ █▌ █▄█▌ █▌ █▄▄ █ █▌
─────────────────────────────────────────────────────────────────────────────
Although BFE is an extremely powerful software package, initial releases
lacked the ability to adequately inform the sysop of the exactly *who* the
online user was, if BFE was being run in front end mode (i.e. without a BBS
dropfile). Once again, we listened and implemented a very powerful solution!
As of v2.00, BFE now includes an optional user system. This system allows
BFE to effectively keep track of all of your system's users. When enabled,
BFE will perform any enabled graphics detection schemes, and will proceed to
place the user into the logon screen. There, the user will enter his/her
name, followed by their password.
BFE maintains a file called USER.BFE in the BFE directory. This file
contains the user information for all users in the system. The format of
this user file can be found in the BFE developer's kit, which should be
contained within the distribution archive.
If a user's name is not found in the user file, they will be prompted to
enter their location and a password to use in subsequent logins to BFE.
Their initial access level is set to zero (0).
The BFE User System also has the ability to support multiple users who share
the same name.
You may set the user system to function in one of three modes: FULL, PARTIAL,
and NONE. The FULL mode will prompt the user for the name and password, and
will maintain the users in the USER.BFE file. The PARTIAL mode will only
prompt the user for their name, and will continue, without maintaining a user
file at all. The NONE mode will disable the user system completely. To run
in FULL mode, place an "F" in the USER SYSTEM field in BFE/Setup. To run in
PARTIAL mode, use a "P". Use a "N" to disable the user system.
Keep in mind that if you enable the user system in either FULL or PARTIAL
modes, this overrides BFE's ability to look for a dropfile upon entry! In
other words, this feature was designed to be used when BFE is being utilized
as a true front end, not a door!
There are two files which also relate directly to the BFE User System. The
first, the Logon File, is shown to BFE callers right before they are asked
for their name. The second file, the Newuser File, is displayed to new users
after BFE gets their name and location, but right before they are prompted
for a password to use. Both of these files can be configured via BFE/Setup
under GLOBAL OPTIONS | PATH/SWAPPING INFORMATION.
A few notes on access levels are in order. The first is a carry over from
Maximus CBCS, but a nifty feature all the same. If a user has an access
level of -2, BFE will simply hang up on the user as soon as they enter their
name! This is similar to the "twit" user level in Maximus, thus, this
feature is dubbed the "twitted" logon.
Also, BFE does not have a "userbase" editor of any type. The userfile which
is used is generated by third party userfile conversion utilities. We have
provided a MAX2BFE.EXE program which will convert the Maximus CBCS userbase
into the USER.BFE format used by BFE. A program called SF2BFE.EXE which will
convert Spitfire BBS user bases is also enclosed.
Userbase conversion programs should be run nightly, or after new callers hang
up, so that BFE will always have the latest copy of your userbase. Since the
user will be going through the newuser loops once he or she hits the BBS,
there is no reason to have yet another user editor for BFE. We feel that
this concept is more than efficient for practical use. Information necessary
for the development of third party userfile conversions can be found in the
BFE Developer's Kit, included with the distribution archive. If you put
together a convertor for your brand of BBS, send it on to us for possible
inclusion in later releases. If you have the necessary information, and are
willing to provide a sample userbase with record layouts, we will optionally
write the convertor for you.
─────────────────────────────────────────────────────────────────────────────
█▀▀ █ █▀█ █▀█ █▀█ █ █▀█ █▀▀▌ █▀▀▌ █▀▀ █▀▀ █▀▀
█ ▄▄ █ █ █ █▀█ █▄█ █ █▄█ █ █ ██ ▀▀█ ▀▀█
█▄▄▌ █▄▄▌ █▄█▌ █▄█▌ █ █▌ █▄▄▌ █ █▌ █▄▄▌ █▄▄▌ █▄▄ █▄█▌ █▄█▌
─────────────────────────────────────────────────────────────────────────────
There will be times when you will want to offer certains options from *all*
of your BFE menus (i.e. Sysop pager, goodbye, etc). Through the use of the
GlobalAccess(tm) system, this is now possible in BFE. To enable this
feature, simply create a new menu .CTL file called GLOBAL.CTL. Place all of
your global options in this menu and save it. When BFE is executed, this
file is read in automatically, and all of the options contained in it are
"appended" to the contents of your regular menus. Voila! This is a great
place to put global SlashCommands (see next section).
─────────────────────────────────────────────────────────────────────────────
█▀▀ █ █▀█ █▀▀ █ █ █▀▀▌ █▀█ █▌▐█ █▌▐█ █▀█ ▐█▌▐▌ █▀▄ █▀▀
▀▀█ █ █▄█ ▀▀█ █▀█ █ █ █ █▐▌█ █▐▌█ █▄█ ▐▌▌▐▌ █ █ ▀▀█
█▄█▌ █▄▄▌ █ █▌ █▄█▌ █ █▌ █▄▄▌ █▄█▌ █ █▌ █ █▌ █ █▌ ▐▌███ █▄█▌ █▄█▌
─────────────────────────────────────────────────────────────────────────────
BFE not only supports hotkey menuing, but also SlashCommands. Any menu item
can become a SlashCommand by simply entering the name of the slash command in
the DESCRIPTION field, separated from the actual description by a pipe sign
(|).
For example, to get a SlashCommand called "/MYBBS", the description field
in BFE/Setup would look something like:
MYBBS|This option takes you to my BBS
─────────────────────────────────────────────────────────────────────────────
█▀▀ █▀█ █▀▀ █▀▀▌ █ █▀█ █ █▀▀ █▀▀▌ █▀█ █ █▀█ ▀█▀ █▀▀
▀▀█ █▀▀ ██ █ █ █▄█ █ ▀▀█ █ █▀▌ █ █▀▀ █ ▀▀█
█▄█▌ █▌ █▄▄ █▄▄▌ █▌ █ █▌ █▄▄▌ █▄█▌ █▄▄▌ █ █ █▌ █▌ █▌ █▄█▌
─────────────────────────────────────────────────────────────────────────────
In addition to running BFE scripts from BFE menus, there are four special
scripts available. They are:
1) Startup script: The startup script is executed after BFE displays the
WELCOME screen (if any), but before the user hits the first BFE menu.
This script name is configurable in BFE/Setup under GLOBAL OPTIONS, then
STARTUP OPTIONS.
2) Exit Script: The exit script is executed if the user logs off through
BFE through the "goodbye" command. This script name is also configurable
in BFE/Setup, under GLOBAL OPTIONS, then STARTUP OPTIONS.
3) Re-entry Script: This script is executed in lieu of the normal startup
script if BFE is started up in "re-entry" mode. This script name is also
configured in BFE/Setup, under GLOBAL OPTIONS, then STARTUP OPTIONS.
4) Auto Script: BFE has the ability to execute a script, and then exit,
without ever hitting a BFE menu. This is called the "auto" scripting
feature. To specify an "auto" script, use the -a command line switch.
Through the use of this feature, it is possible to create little "doors"
of your own, without having to place them underneath BFE menus. This is
also great for setting up custom BFE/Gateway menus to be called from your
BBS program.
─────────────────────────────────────────────────────────────────────────────
█ █▀█ ▐█▌▐▌ █▀▀ █ █ █▀█ █▀▀ █▀▀ █▀▀ █ █ █▀▀
█ █▄█ ▐▌▌▐▌ █ ▄▄ █ █ █▄█ █ ▄▄ ██ █▀ █ █ ██
█▄▄▌ █ █▌ ▐▌███ █▄▄▌ █▄█▌ █ █▌ █▄▄▌ █▄▄ █▌ █▌ █▄▄▌ █▄▄
─────────────────────────────────────────────────────────────────────────────
In order to further allow the user to customize the operation of BFE, an
external "language" file has been implemented. This file is a simple text
file, which contains a series of keywords and text fields.
Quite a bit of BFE's internal text messages can be customized! Upon startup,
BFE looks for a file called BFE.LNG (The BFE Language File). The format of
this file is relatively simple:
KEYWORD <Language Text>
All lines starting with a semicolon (;) are treated as comments and are
ignored. Each line should be no longer than 80 characters (including the
keyword!).
Macro keys available: ~ = carriage return/linefeed pair
_ = Blank (space)
The following language keywords are available to you:
BEFORECHAT
Shown if the sysop initiates a chat session
AFTERCHAT
Shown when the sysop closes a chat session
BEFORESHELL
Shown when the sysop shells to DOS locally
AFTERSHELL
Shown when the sysop returns from a local DOS shell
CHATREASON
Displayed when BFE is asking for a reason to page
CONTINUE
General continuation message (i.e. Continue [Y/N/=])
TIMEOUT
Shown when the user has an inactivity timeout
NOTAVAIL
Shown when the user pages the sysop, and you are not in!
NORESPONSE
Shown after an unsuccessful paging attempt
OUTTATIME
Shown when the user has reached his timelimit in BFE
OFFLINE
Shown when browsing FILES.BBS for files that are offline
PAGINGMSG
Shown while BFE is paging the sysop
PRESSKEY
General "press ENTER to continue" message
PROMPT
Menu selection prompt
DEFUSERNAME
Default name to use when BFE doesn't know who the user is
DEFUSERLOC
Default location to use when BFE doesn't know who the user is
ENTERMSGTXT
Shown at the top of the BFE/Editor screen
SLASHCMDTXT
Prompt used when a user initiates a slash command
HANGONMSG
Shown when BFE is exiting on an errorlevel
ROCKHEADTXT
Logged when a user botches the BFE login procedure
BADPASSWORD
Logged when a user fails at a BFE menu password
TWITLOGON
Logged when a "twitted" user tries to log in
LOGINPROMPT
Default "login" prompt
Additional textual customization features will be added to this .LNG file as
the product grows. Currently, this feature is only enabled in registered
versions of BFE. See the BFE.LNG file which came packed in the BFE archive
for starter examples.
─────────────────────────────────────────────────────────────────────────────
█ █ █▀▀ █ ▐█▌▐▌ █▀▀ █▀▄ █▀█ █▀█ █▀█ █▀▀ █ █ █▀▀ █▀▀
█ █ ▀▀█ █ ▐▌▌▐▌ █ ▄▄ █ █ █▀▌ █ █ █▀▀ █▀ █ █ ██ ▀▀█
█▄█▌ █▄█▌ █▌ ▐▌███ █▄▄▌ █▄█▌ █ █ █▄█▌ █▌ █▌ █▌ █▄▄▌ █▄▄ █▄█▌
─────────────────────────────────────────────────────────────────────────────
If BFE locates an enabled Dropfile path in your global options, it will
attempt to make use of a BBS dropfile, effectively ignoring any relevant
command line communication arguments. If you wish to run BFE as a normal
door from your BBS, you will need to specify a valid path for this option in
BFE/Setup. If you are running BFE as a front-end to your system (i.e. called
from a mailer), do *not* put a path in the dropfile directory field!
It appears that the BBS world simply cannot agree on a standard dropfile
format. For a while, it appeared as if the DORINFOx.DEF, or perhaps the
DOOR.SYS format would prevail. However, with the release of RemoteAccess
v2.0+, that myth has apparently been shattered, as the RA author decided to
introduce yet another dropfile format. We will continue to add and support
all of the popular dropfile formats, regardless of how hairy it gets... :-)
BFE by default does not look for a BBS dropfile, since it was originally
designed to be run as a frontend (i.e. *BEFORE* the user had actually logged
on to the BBS).
As of v1.22 of BFE, a "smart" method of dropfile detection has been employed.
BFE first looks in the current directory for the dropfile. If it is not
there, it looks in the DOS path. If the dropfile mode is enabled, and BFE
can not locate a dropfile, it will not run!
1.) First, if there was a custom door information file format
defined in the CUSTOM.BFE file, BFE will begin by looking for
this file. BFE searches for the custom information file in the
following order:
A.) The path defined by the BBS Directory option
B.) The directory which was the current default dir at
startup time
C.) If any of the following environment variables exist,
BFE will then search for the file in the directories
pointed to by these variables, in the following order:
RA
QUICK
PCB
BBS
2.) If no custom door information file was found / defined, BFE will
then search for door information files corresponding to one of
the built in formats. It will search for these files in the same
directories, and same order, as it does for the custom door
information file (A - C). Within each directory, it will
search for files with the following filenames:
CHAIN.TXT
SFDOORS.DAT
DOOR.SYS
CALLINFO.BBS
DORINFO1.DEF
DORINFOx.DEF, where x is the node number (0-Z)
As soon as it finds a directory containing one of these filenames, BFE will
stop it's door information file search phase. It then begins to decide what
to do with what it has found. If more than one of the above filenames was
found in the directory in question, BFE will read the file with the most
recent date and time stamp. This is intended to overcome abiguities that can
arise when a door information file conversion program is being used, and a
number of different door information files may still exist in the directory.
In such a case, it is assumed that the most recently created file is the one
that should be used. If more than one file exist with an identical date and
time, BFE will use the file that is closer to the beginning of the above
list. (ie they are listed in their order of priority)
Once BFE has decided which file it is going to use, it may have still more
decision-making to do. In the case of door information file names that
correspond to more than one format (such as DOOR.SYS), BFE will examine the
file to determine which format it actually is. If a DORINFO?.DEF file is
found, BFE will then also attempt a search for an EXITINFO.BBS file. Again,
if an EXITINFO.BBS file is found, BFE must determine which of the many
EXITINFO.BBS formats it is actually dealing with.
This may all sound rather complicated, but it is a well thought-out strategy
that is intended to asure that the correct door information file will be
located and used in the vast majority of cases. (and to think - it does all
this in the blink of an eye!)
As of v1.22, BFE recognizes the following dropfile formats:
DORINFOx.DEF (Standard DORINFOx.DEF Drop file (Default))
EXITINFO.BBS (RA v.01 - v.04)
EXITINFO.BBS (Extended (RA v1.0+))
EXITINFO.BBS (RemoteAccess 2.0+ style)
CHAIN.TXT (WWIV)
SFDOORS.DAT (SpitFire BBS)
CALLINFO.BBS (WildCat!)
DOOR.SYS (GAP/PC-Board)
DOOR.SYS (Doorway version)
QBBS 2.75+ (EXITINFO.BBS)
DOOR.SYS (WildCat! style)
Custom (See the next section!)
─────────────────────────────────────────────────────────────────────────────
█▀▀▌ █ █ █▀▀ ▀█▀ █▀█ █▌▐█ █▀▄ █▀█ █▀█ █▀█ █▀▀ █ █ █▀▀ █▀▀
█ █ █ ▀▀█ █ █ █ █▐▌█ █ █ █▀▌ █ █ █▀▀ █▀ █ █ ██ ▀▀█
█▄▄▌ █▄█▌ █▄█▌ █▌ █▄█▌ █ █▌ █▄█▌ █ █ █▄█▌ █▌ █▌ █▌ █▄▄▌ █▄▄ █▄█▌
─────────────────────────────────────────────────────────────────────────────
BFE automatically recognizes most door information file (drop file) formats,
including DORINFO?.DEF, EXITINFO.BBS, DOOR.SYS, SFDOORS.DAT, CALLINFO.BBS and
CHAIN.TXT. However, to permit BFE to operate on BBS systems that produce a
different format file, you may define a custom door information file format.
A custom door information file format is defined using the "CustomFileName"
command, followed by one or more lines beginning with the "CustomFileLine"
command. This file *must* be called CUSTOM.BFE!
The "CustomFileName" option specifies the filename used to distinguish this
file format from other file formats. This filename should not include a path.
To specify the path where the door information file is located, use the
BBSDir setting, near the beginning of this file. If the filename of the
custom format is the same as that of one of the built-in formats, the custom
format will override the built-in format.
The actual format of the custom file is specified using a number of lines
that begin with the keyword "CustomFileLine". Each of these lines will
correspond to a single line in the door information file, with the option
following the "CustomFileLine" keyword specifying the information that can be
found on that line. This can be one of the following keywords:
Ignore - Causes the next line in the door information file to be
ignored. Use on lines for which none of the options below
apply.
ComPort - COM? port the modem is connected to (0 indicates local mode)
FossilPort - Fossil port number the modem is connected to
ModemBPS - BPS rate at which to communicate with modem (0 or non-
numerical value indicates local mode)
LocalMode - 1, T or Y if door is operating in local mode
UserName - Full name of the user
UserFirstName - First name(s) of the user
UserLastName - Last name of the user
Alias - The user's psuedonym / handle
HoursLeft - Hours user has left online
MinutesLeft - Minutes user has left online, or time left online in
format hh:mm
SecondsLeft - Seconds user has left online, or time left online in
format hh:mm:ss or format mm:ss (If more than one of the
above time options are used, the user time left is taken
to be the total of all of these values.)
ANSI - 1, T, Y or G for ANSI graphics mode
AVATAR - 1, T or Y for AVATAR graphics mode
PagePausing - 1, T or Y if user wishes a pause at end of screen
ScreenLength - Number of lines on user's screen
ScreenClearing - 1, T or Y if screen clearing mode is on
Security - The user's security level / access level
City - City the user is calling from
Node - Node number user is connected to
SysopName - Full name of the sysop
SysopFirstName - The sysop's first name(s)
SysopLastName - The sysop's last name
SystemName - Name of the BBS
A sample CUSTOM.BFE is outlined below. This example designs a custom
dropfile template which emulates the standard DORINFO?.DEF file.
CustomFileName EXAMPLE.DEF ; File name to look for!
CustomFileLine SystemName
CustomFileLine SysopFirstName
CustomFileLine SysopLastName
CustomFileLine ComPort
CustomFileLine ModemBPS
CustomFileLine Ignore
CustomFileLine UserFirstName
CustomFileLine UserLastName
CustomFileLine City
CustomFileLine ANSI
CustomFileLine Security
CustomFileLine MinutesLeft
─────────────────────────────────────────────────────────────────────────────
▐█▌▐▌ █▀▀ ▀█▀ █ █ █▀█ █▀█ █ █ █ ▐█▌▐▌ █▀▀
▐▌▌▐▌ ██ █ █▐▌█ █ █ █▀▌ █▀▄ █ ▐▌▌▐▌ █ ▄▄
▐▌███ █▄▄ █▌ █▌▐█▌ █▄█▌ █ █ █ █▌ █▌ ▐▌███ █▄▄▌
─────────────────────────────────────────────────────────────────────────────
BFE has special support for FrontDoor(tm) style semaphore files. These files
are generated in the IPC subdirectory, underneath your main BFE directory.
The files contain one line, which holds the name of the current user (or
the name of the default user configured in the language file, if you are
not running the BFE user system).
These files can be checked against in your own programs or batch
files, to determine what nodes are active, and what each user is doing.
Whenever BFE is started up in non-reentrant mode (no -r switch), the IPC
directory is cleared of semaphores for the current node.
The following semaphores are available (nnn = node number of current node):
ACTIVE.nnn - User active in BFE menus
EXTERN.nnn - User running an external process
ERRLVL.nnn - User exiting on an errorlevel
SCRIPT.nnn - User executing a BFE script file
GATEWAY.nnn - User active in a BFE/Gateway session
More than one of these IPC files may be present at any given time. For
example, if the user was active on node 2, and was in a custom BFE/Gateway
script file, you would have ACTIVE.002, SCRIPT.002, and GATEWAY.002 sitting
in your IPC directory.
Note that the ERRLVL.nnn semaphore may remain active if your BBS program
does not return control to BFE (i.e. you are not running "round trip"
options from BFE). To keep the IPC directory current, you can simply
delete the ERRLVL.nnn file after exiting your BBS, although this will not
affect BFE in any way. All semaphore files are there for your information
only, although this may change in a future release.
One additional semaphore is also supported in the IPC directory. This file
is called LASTUSER.nnn, and is generated whenever BFE exits on an errorlevel.
This file is the only semaphore which does not contain simply the user's name.
Rather, it contains a complete image of BFE internal's at the time the user
exited BFE on the errorlevel. If BFE is subsequently started in re-entry
mode, this file is read back in, and the user is automatically placed at
the exact point where he/she originally exited BFE. The time remaining
within the system (BFE) is also updated based upon the time which was stored
in the LASTUSER.nnn file. This is helpful if you run multiple BBS systems,
but only wish to grant a set amount of time per day across the system.
Note that when BFE is started in re-entry mode, the "-c" switch which
specified the .CTL file is no longer used, as this information is taken
straight from the LASTUSER.nnn file.