
                               Galaxy 5 
                                Help With Doors


     
      This file explains how to setup a door, and the use of fossil
      drivers, and related topics. It is primarily for those who are not
      yet familiar with the setup of doors on their BBS (new SysOps). If
      you already know how to setup doors, then you do not need to read
      this file. It starts from the basics of door setup.
     
      Please keep in mind that I run a Wildcat! 4 system, and will be
      giving many examples using the Wildcat! doors setup. If you are
      running BBS software other than Wildcat!, then setup points
      referred to in this file, may differ slightly, or greatly.
     


                                  DOOR SETUP
     
      When you first install a door, you should read any documentation
      on the setup of that particular door. Most doors are similiar in
      setup, but alot have their own requirements on setting up.
      Sometimes door authors will include a SYSOP.DOC file with their
      door. This file usually contains everything you need to know on
      how to setup the door. If there is no SYSOP.DOC file, look for
      one or more of these files,
                                 SYSOP.TXT
                                 README.TXT
                                 READ1ST.TXT
                                 README.1ST
                                 INSTALL.TXT
                                 INSTALL.DOC
                                 SETUP.DOC
                                 SETUP.TXT
      If you see any of these files (especially the README files), you
      should refer to them immediately before attempting to install the
      door. If none of the above files are included, then look for a
      .DOC or .TXT file with the same name as the door. Such as
      GALAXY5.DOC for Galaxy 5.
     
      First, if necessary, run the setup program that comes with the
      door (or any install programs needed, or both if necessary). If
      you need to edit a .CFG file, then do that also. In some setup
      programs, and/or .CFG files, you will be asked where the door can
      find your BBS drop file. Drop files have different names for
      different BBS platforms, and some use the same drop files. Here is
      a list of a few of them,
                              DOOR.SYS
                              DORINFO*.DEF
                              CALLINFO.BBS
                              PCBOARD.SYS
                              SFDOORS.DAT
      Among many others. Many new SysOps ask the common question, "I
      don't have a DOOR.SYS file! Where is mine?" Or whatever drop file
      your BBS uses. The answer is simple, there isn't one! These files
      are temporary files created when a user uses a door on your BBS.
      The door then reads this drop file to gather caller information
      such as name, security level, time left on BBS, COM port info,
      etc. After the door exits, and your BBS returns, the drop file is
      erased. So you will not see a door drop file at any given time,
      unless you are in another "window" in a multi-tasking environment,
      looking in the drop file directory while a caller is using a door.
     
      Sometimes the door configuration will ask for your drop file type.
      This is where you either use the file name of the drop file your
      BBS creates, or a special abbreviation or other code the door uses
      for each different type of drop file (the config file or setup
      program will usually inform you of the code to use if any). Then
      you may be asked for the directory where to find this drop file. A
      Wildcat! single node system would use the C:\WILDCAT\WCWORK\NODE1
      directory (replacing C:\WILDCAT with your home Wildcat!
      directory). And sometimes the door configuration will ask for the
      full path and file name of the drop file. A Wildcat! single node
      system would use, C:\WILDCAT\WCWORK\NODE1\DOOR.SYS (again
      replacing the C:\WILDCAT with your home Wildcat! directory).
     


                         SETTING UP THE BATCH FILE(S)
     
      The most important thing you probably need to look for, in the
      documentation, is how to set up the batch file(s) for the door.
      The batch file(s) to run the door, are ran from your BBS software.
      In a Wildcat! 4 setup, these batch files have the .BAT extension,
      and are placed in the WILDCAT\BATCH subdirectory. Here is a basic
      example of a batch file used to run a door when the BBS is setup
      to "shell" to doors instead of terminating (the recommended
      setting),
               @ECHO OFF
               D:
               CD\DOORS\DOORNAME
               DOORNAME FILENAME.CFG

       Here are explanations of each command
      ---------------------------------------
      @ECHO OFF - This turns of echoing these commands to your screen.
                  It is not really a necessary command, but is used by
                  many SysOps (including myself!).

      D:        - This is only needed if your doors are located on a
                  different drive than your BBS software. It will change
                  to that drive before executing the door.

      CD\DOORS\DOORNAME - Changes to the directory containing the door
                          about to be executed. Most of the time, this
                          is necessary for the door program to be able
                          to find its program files. If you use a
                          command like,
                          D:\DOORS\DOORNAME\DOORNAME.EXE FILENAME.CFG,
                          then if the door needs to use any external
                          program files, it will not be able to find
                          them, because you are actually running the
                          door from your drop file directory this way,
                          instead of the doors own directory.

      DOORNAME FILENAME.CFG - Executes the door using the configuration
                              file as the command line (if needed). Here
                              is where door batch files usually get
                              tricky. Many doors use many different
                              command line parameters (the command line
                              parameter in this case is the FILENAME.CFG
                              command) to initiate the door. You will
                              have to find out what command line
                              parameters you need to use to execute each
                              door from your BBS batch file, in one of
                              the documentation files explained earlier.
                              Most doors need the name of the config
                              file as the only parameter, but this is
                              not always the case, so you really should
                              look at the docs to find out what
                              parameters you need to use.
     
      Case is not important in your batch file(s). Upper or lower case
      can be used anywhere in the above commands.
     
      Sometimes you will need to change back to your drop file directory
      after the door is run (if required by your BBS software). If so,
      then you will have to add the "CD" command again to the end of the
      batch file. If you changed to another drive letter at the
      beginning of the batch file, then you will need to first change
      back to your BBS drive before changing back to your drop file
      directory. Here is an entire batch file example, with Wildcat!
      being on the C: drive, and the doors being on the D: drive, and
      changing back to the drop file directory after the door is run,

      @ECHO OFF
      D:
      CD\DOORS\DOORNAME
      DOORNAME FILENAME.CFG
      C:
      CD\WILDCAT\WCWORK\NODE1

      As far as I know, Wildcat! does not require you to do this, but I
      do it myself anyway. I know from experience that it WILL work
      properly without changing back to the drop file directory at the
      end of your batch file.
     


                        SETTING UP THE DOOR IN YOUR BBS
     
      Now you will need to tell your BBS software about the door. I
      honestly have no idea how to do this in any other BBS software
      besides Wildcat! So I will explain how to do it in Wildcat!, and
      maybe you can relate the info to your BBS software if you run any
      other than Wildcat! Note that this is Wildcat! 4 setup, and that I
      plum forgot how to do it in Wildcat! 3, since its been so long! ;>

      1) Run MakeWild, and choose the "Doors" main menu option.
      2) Move your highlight bar to the very last door (which is empty),
         and press ENTER (or double click on the empty one).
      3) It will ask you something like, "Clear door access for this
         door?" Select Yes.
      4) You are then editing the doors info. The first box asks for the
         door description. Enter the name of the door here (this can be
         worded however you wish). Next is the door batch file. Enter
         here whatever you named the batch file for this door (usually
         named to match the door it is for). You should have already
         placed this batch file in your WILDCAT\BATCH subdirectory. In
         the next box you enter the display file you want shown to users
         upon choosing to enter the door (I do not currently use this
         feature myself, it is optional if you wish to use it). The next
         one is the "Door Multi User?" flag. If the door allows more
         than one caller to use the door at the same time, then change
         it to Y, otherwise, leave it at N. The next one, "Small
         DOOR.SYS," I have never had to answer Y to this one yet, so
         unless the door you are installing needs a small DOOR.SYS,
         leave this one at N. "Use Alias Name" This one is up to you. If
         you set it to Yes, then the real name of the caller will not be
         passed to the door in the DOOR.SYS file, only his/her alias. I
         have so far, always left this at No. "Terminate On Door." This
         one if set to yes, Wildcat! will terminate, and then execute
         the door instead of "shelling" out to it. I have not explained
         the use of terminating on doors instead of shelling. So if you
         wish to continue using this file as your guide for now, leave
         this at N. I do not terminate on my doors, as I have not had
         the need to.
      5) After filling in all of the fields, press F3 (or double click
         on it), and select all security levels who are allowed access
         to the door. Then press F4 (or double click on it), and select
         all of the conferences this door is available in. I always
         select all conferences for every door, but this is up to you,
         and how you want to set up your doors on your system.
      6) Press F10 to save it.
      7) Load WCdraw, and add the door to your DOORS.BBS display file.
     
      As I mentioned before, if you are not running a Wildcat! system,
      then you will have to set up your doors in your BBS however you
      are supposed to do so according to your particular software.
     


                               MULTI NODE SETUP
     
      If you are running more than one node on your BBS, and want to set
      up doors, it gets a little more complicated, but once you
      understand it, its really not that hard to comprehend (unless the
      door you are installing is not very multi node friendly). Most
      doors are set up for use by one caller at a time. If this is the
      case, then you can still set up the door on all of your nodes, but
      will have to "disallow" more than one person from using it at the
      same time. Most BBS platforms allow you to do this when setting
      the door up in your BBS configuration program. For instance,
      Wildcat! has a flag for each door in the door setup called "Door
      Multi User?" If the door cannot be used by more than one caller at
      a time, then you must set this to NO. On the other hand, if the
      door you are installing is multi node aware, and allows more than
      one player to use it at a time (such as Galaxy 5), then set this
      to YES for that/those particular door(s).
     
      I can explain multi node door setup to the best of my ability, as
      most doors must be set up differently for multi node use. What I
      can do, is explain the configuration file use for multi node
      doors. For example, a door that asks for the config file on the
      command line to run the door (DOORNAME FILENAME.CFG), you can
      create separate config files for each node that you have, using
      the setup particular to each node.
     
      Lets say we are setting up DOORNAME under two nodes, nodes 1 and
      2. First we create a configuration file (used by the door) named
      NODE1.CFG. In this config file, we show the door where to find the
      drop file for node one, and if asked for, the com port number for
      the modem on node 1, and/or the IRQ number for node 1 (if asked
      for), and anything else specific to node 1 that the config file
      asks for. So our Wildcat! setup under node one, would point the
      door to the drop file in the C:\WILDCAT\WCWORK\NODE1 directory
      (replacing C:\WILDCAT with your home Wildcat! directory). And if
      the modem that node 1 uses is on COM 4, then we would put 4 on the
      line that asks for the COM port number (if it asks for it), etc.
      We save the file, then copy it to NODE2.CFG (or start a new one),
      and edit this one to point the door to the C:\WILDCAT\WCWORK\NODE2
      directory (again replacing C:\WILDCAT with your home Wildcat!
      directory). And the COM port number the modem that node 2 uses is
      on (if asked for), etc. etc.
     
      Now comes the trickier part. Wildcat! systems (among others) can
      use a "Node ID" variable to determine the node number for each
      different node. In Wildcat!, this variable is WCNODEID and is set
      in the batch files that you start each node from like this,
      SET WCNODEID=1 for node 1, and SET WCNODEID=2 for node 2, etc. If
      you use (or are going to use) the Node ID variables, then you need
      only make one batch file to run the door with, and place it in
      your WILDCAT\BATCH subdirectory (or the batch file directory for
      your particular BBS software). Now in this batch file, you will
      need to call the appropriate config file for the node being ran.
      Here is an example batch file for a multi node door using the
      WCNODEID variable,

      @ECHO OFF
      D:
      CD\DOORS\DOORNAME
      DOORNAME NODE%WCNODEID%.CFG

      Notice the NODE%WCNODEID%.CFG in the above example. If node 1 was
      running the door, then this command would be passed to DOORNAME,
      DOORNAME NODE1.CFG. And if node 2 was running the door, then the
      above statement would be passed looking like this,
      DOORNAME NODE2.CFG. Anywhere you place %WCNODEID% (case is not
      important) in your batch file(s) for running doors, it will be
      replaced with the proper node number being ran, as long as you use
      the SET WCNODEID=? command in your batch files that start each of
      your BBS nodes replacing ? with the proper node number.
     
      If you are not using the Node ID variables, then for Wildcat!
      systems, you will need to use separate .RUN files instead of one
      .BAT file. These .RUN files are batch files with a .RUN extension,
      and must be placed in your NODE directories. Here is an example
      .RUN file for node 1,

      @ECHO OFF
      D:
      CD\DOORS\DOORNAME
      DOORNAME NODE1.CFG

      This file must be placed in the C:\WILDCAT\WCWORK\NODE1 directory,
      instead of the C:\WILDCAT\BATCH directory (replacing C:\WILDCAT
      with your home Wildcat! directory). Here is node 2's example,

      @ECHO OFF
      D:
      CD\DOORS\DOORNAME
      DOORNAME NODE2.CFG

      This file must be placed in the C:\WILDCAT\WCWORK\NODE2 directory,
      instead of the C:\WILDCAT\BATCH directory (replacing C:\WILDCAT
      with your home Wildcat! directory).
     
      Wildcat! always first looks for the .RUN version of your door
      batch files in the node directories when executing a door. If not
      found, then it uses the .BAT file in the BATCH directory.
     


                               LOCKED BAUD RATES
     
      It is recommended that you lock your baud rate for each node. How
      you ask? Anywhere in any setup pertaining to your BBS or doors
      that asks for the locked baud rate, enter a locked baud rate. If
      you have a 14400 modem or slower, first try locking it at 38400.
      If you have a 19.2 or higher, use 57600. Locking your baud rate
      increases the speed at which text is sent over the modem, and is
      much more effecient.
     
      To lock your baud rate, you must first do so in your BBS setup
      program. In Wildcat!, this is located under "Modem Settings" in
      the MakeWild program. Then, when setting up a door, if it asks
      anywhere for your locked baud rate, you must enter the same value
      there as you did in your BBS setup program. It is not wise to use
      a locked baud rate under one program and not the other! ;> This
      also applies to front end mailers if you use one (Front Door,
      D'Bridge, etc.).
     


                                FOSSIL DRIVERS
     
      Alot of doors can use a fossil driver if you are using one. Whats
      a fossil driver you ask? A fossil driver is a TSR that runs your
      COM ports for you. They are more effecient than regular COM
      routines, and are recommended, especially in a multi node
      environment. By far I have found the best fossil driver to be BNU
      by David Nugent. As far as I am aware the most current version is
      2.02. BNU works well under DESQview, and Windows as well as DOS (I
      am not sure about OS/2). I am currently running BNU v2.02 under
      Windows 95 with beyond satisfactory results.
     
      By far the easiest way to setup BNU (in my opinion), is to use the
      BNU.COM version, instead of the BNU.SYS (both are included in the
      archive when you obtain it). The BNU.COM version can be loaded via
      batch files, or directly from the command line. The BNU.SYS
      version must be loaded via your CONFIG.SYS file. The main reason I
      use the .COM version is because I like to unload the fossil driver
      when I take the BBS down. By using the BNU.SYS version, the fossil
      is always resident in memory until you reboot (to my knowledge
      anyway). Refer to BNU's documentation (if you decide to use it)
      for more complete informatin on the fossil driver.
     
      BNU can be used to control all of your COM ports. Be it one or
      four modems, maybe more, I'm not sure, as I said before, refer to
      BNU's documentation for full information on this. If you use the
      .COM version, I personally recommend creating a batch file called
      FOSSIL.BAT (or whatever you wanna name it), containing the full
      command line to load BNU for your system. This way, you can
      CALL FOSSIL.BAT from the batch file(s) that load your BBS (or
      front end mailer if you use one), instead of calling the entire
      command line that BNU must have.
     
      Another important factor when using a fossil driver, is telling
      your BBS software to use the fossil driver. For example, in a
      Wildcat! system, under "Modem Settings," there is a field that
      asks for "Type of Serial Port." If you are using a fossil driver,
      then you must use "Fossil Driver" in this field. Also, you must
      set the field "Determine Ringing Using" to "Ring Result." Then
      set the "Determine Baud Rate Using" field to "Result Code 2."
     
      Here are the basic settings to get you started using BNU.COM. If
      you are unfamiliar with BNU, try these settings first (replacing
      the appropriate info where necessary). Of course, in order to use
      BNU, you should first place the BNU.COM file somewhere in your
      path statement. The example used below, is for one modem (one
      node) where the modem is connected to COM port 1, and is equal to
      or faster than 14400. If these settings do not work for you, then
      tweak them as you need to.

      BNU /P:1 /L0:57600 /F+ /Z0 /M- /T:3072 /R:3072 /O

       Here is an explanation of the above switches used
      ---------------------------------------------------
      /P: = Tells BNU how many ports to enable. (/P:2 enables 2 ports).
      /L0 = Tells BNU what baud rate to lock the specified COM port at.
            The COM port specified in this case is 1. Notice that a 0 is
            used instead of 1. When refering to the actual COM port
            number in BNU, you must decrease the value by one. For
            example, COM 2 would be /L1, COM 3 would be /L2, etc.
      /F+ = Enables fast screen writes. To disable fast screen writes,
            use /F-.
      /Z0 = This is used if you have a 16550 FIFO buffer. I believe this
            is in your modem specifications. Most modems that are 14.4
            and faster, and do not require any software drivers to run,
            do have 16550 FIFO's. If you have problems with BNU, try
            either removing this command, or changing it to /Z5 which
            disables 16550 FIFO buffering.
      /M- = Disables the BNU initialization message. Normally BNU shows
            its loading stats to the screen, you can disable it with
            this switch, or enable it by removing this switch, or
            changing it to /M+.
      /T: = Sets the transmit buffer size. In this case the value is set
            to 3072. This shouldn't normally have to be changed. If you
            do need to reduce it however, change it to /T:2048.
      /R: = Sets the receive buffer size. This is also set to 3072. If
            you need to reduce it for some reason, change it to /R:2048.
      /O  = This switch is used to enable "compatible" operation of BNU
            in situations where either X00 or Opus!Com worked (other
            fossil drivers), but BNU didn't. It should be used by
            default at all times unless you can get away with omitting
            it.
     


                                   NOT ENUFF
     
      If the above information does not help you out enough, feel free
      to contact me with your question(s) regarding what it is you need
      help with. I am always glad to help, and will give you all the
      info I can to help you get started setting up doors on your
      system! ;>
     
      BBS      : The Last Call BBS! (313) 295-6284
      Fido     : 1:2410/903
      Internet : Thomas.Smith@wland.ack.mi.org
     
      I also frequent the following echos on FidoNet,
                                                     LORD
                                                     LORD_SYSOP
                                                     SHAREWRE
                                                     SHAREWARE_SUPPORT
                                                     DOORGAMES
                                                     ON_LINE_GAMES
     
                         Hope this helped! Good Luck!
     

                                 END OF FILE 
