OS/2 Professional/OS2PRO194.ISO/os2/com/bbs/czarwars/czar_doc.txt

Text File | 1989-12-29 | 39.9 KB | 764 lines

          Sysop Documentation for OS/2 Czarwars Game System 3.58
        (C) Copyright 1987-1989  Ray Yeargin.  All rights reserved.

 OS/2 Adaptation,  (C) Copyright 1989  Troy Carroll.  All rights reserved.


A. System Requirements:
   Minimum Configuration:
      IBM personal computer or compatible with 2MB RAM (4MB preferable)
      OS/2 1.1 SE or greater
      Hard disk drive with 1 megabyte of free space
      Hayes compatible modem usable through COM1 or COM2

   Recommended:
      Real-time, battery backed clock/calendar
      Good quality surge suppressor


The following instructions in Item B are for a fast setup of the system
   using default settings.  Once the quick setup is completed you will be
   able (at your option) to read the Configuration section of this manual
   and customize your board to your individual preferences.  If you are not
   already familiar with Czarwars you should read the CZAR_HLP.TXT file
   prior to doing the quick setup.  You should also make back up copies of
   the distribution disks.

B. Quick Setup for standalone mode:
   NOTE:  If you intend to run this software as a door under other software
          using command line parameters, read section G below before
          continuing here.

   Hardware:

   1. Ensure that your modem is set to NOT auto answer the phone.

   Software:

   1. Create a Czarwars directory on your hard disk and copy all the files
      on the distribution disks into the directory.
      All included files should be in the Czarwars directory for the
      system to operate properly except for the following:

      README
      HISTORY.TXT
      LICENSE.TXT
      CZAR_DOC.TXT

   2. Run CZAR_UTL.

      The CZAR_UTL program will check for missing files in the Czarwars
      directory and will generate new copies of the data files and
      bulletins, if necessary.

      You will be asked a couple of questions concerning the location and
      speed of your modem.  If you do not already have a map file
      (CZAR_MAP.DAT) in the Czarwars directory, you will also be asked
      questions about the size and type of galaxies to install in the map
      file that will be generated.

      You will then be asked for a name and password for the Sysop.  You
      should enter your name or simply 'SYSOP' at the name prompt.  Both
      the Sysop's name and password must be entered in UPPER CASE.  This
      will be the name and password you enter when you log into Czarwars.

      When the automatic configuration of Czarwars is completed you will
      see the Czarwars utility program main menu on your screen.  You may
      select option 1 (Configure the System Parameters) at this point to
      further customize your installation of Czarwars.

      Some items you may consider changing at this time are:

      a. Select item 15 (Enable programmatic upgrades to 'A')
         If you intend to ask for donations to help support your BBS then
         you will probably want to leave this set to '0'.  If you don't
         plan to solicit donations, enter a '1' so players can upgrade
         their own ships to class 'A'.  (a '0' here would enable you to
         give class 'A' ships to contributors only - or give them to no
         one, if you prefer)

      b. Select item 13 (Initialize the map).  If you start with the
         advanced map file you may want to 'freshen' the inventory levels
         of the ports and planets.  To do this enter a number from 1 to 10
         to set the initial inventory levels (2 to 4 recommended).
         NOTE:  If you have the advanced map file and you do not run this
         routine, the inventory levels will be very high when the game
         first starts.  As a result, the first few players to log on will
         encounter planets and ports with the maximum quantitys and prices,
         therefore gaining an early advantage.

   3. You should now be able to run CZAR_PGM and move around on the board
      as a regular player.  You can buy and sell things, leave signs, and
      even leave mail.

      You can now bring up the BBS by entering CZAR_PGM /M.  Using the /M
      switch causes the program to look to the modem for incoming calls
      rather than going straight to the console as before.  If your modem
      is on and attached to the COM: port that you selected during the
      automatic installation then you should see a 'waiting for a call'
      screen on your display (which can appear in any of 8 different spots
      on the screen).

      If the phone rings now, the system will answer it and attempt to
      detect a carrier tone.

   You're online!  If you were actually bringing up the system you would
      now turn off your monitor to save electricity and to prevent burn-in.
      Of course, you also may press the escape key and bring down the
      system at any time.

C. Configuring and Customizing Czarwars:

   The CZAR_UTL program option <1> (Configure the System Parameters) allows
   you to customize Czarwars into a unique game.  When you select option
   <1> you will be presented with a menu of numbered options.  Lets take
   them one by one in order.

   1. Game Cycle in days = 8
      The 'Game Cycle' controls the maximum inventories of goods at the
      various ports and planets.  For example,  a port with a daily ore
      productivity level of 20 will produce 20 cargo holds of ore per day.
      If no one ports there to purchase ore for (say) several weeks then
      the inventory of ore would just keep growing indefinitely - if not
      for the limits imposed by the Game Cycle.  If the Game Cycle is set
      to 10 then the port will accumulate no more than 10 times the daily
      production.  10 x 20 = 200.  Therefore, if no one buys the ore to
      keep the levels of inventory down, production will stop when 200
      holds of ore accumulate there.  When someone buys some ore thereby
      causing the inventory to drop below the limit of 200 then production
      of ore will resume at the 20 hold-per-day level.  Commodities
      produced on planets and the quantities of goods that ports attempt to
      purchase are controlled in the same way.
      I recommend starting with this number in the range of 6 to 12.

   2. Logon Delay in 5 minute periods = 30
      The Logon Delay is measured in 5 minute periods (5 minutes=1
      'Starday') and controls how long a player must wait between LOGONS.
      Note that the duration of the session has no bearing on when a person
      is eligible to log on again.

   3. Daily antimatter per player (grams) = 80000
      Antimatter is fuel.  The more you issue, the more a player can move
      around, trade, and gamble.  Class 'A' ships are given an additional
      bonus above the number you enter here if the second parameter from
      item #16 below is set above zero.  This enables you to give (for
      example) class 'A' ships a 10-100%+ antimatter bonus.  The reasoning
      here is that if you are soliciting donations, the extra antimatter is
      an additional incentive to give.  50000-100000 grams is a good range
      to stay in until you've had the board up for a while.

   4. Start Holds in new ship = 25
      This controls how many cargo holds are included with a new ship.

   5. Start Cash issued with new ship = 5000
      The number of credits ($) issued to a player getting a new ship.

   6. Max Holds for A & B class ships = 125     75
      The maximum number of cargo holds that class 'A' and class 'B' ships
      can contain.

   7. Price of a Star Base = 10000
      The amount of credits a player must pay to build a type 1 Starbase.
      For simplicity, this parameter is actually entered as a 'price per
      fighter strength'.  Since a fighter costs 100 you can easily set the
      Starbase price to, say, half of the equivalent fighters price... in
      this case, 50 credits per 'fighter strength'.

   8. Time limit parameter in minutes = 30
      This parameter is used along with antimatter quantity to determine
      the time limit for a session.  A session time limit is based on 2
      things.  First of all, each session automatically gets 5 minutes
      regardless of antimatter quantities and the setting of the time limit
      parameter.  Second, in addition to the default 5 minutes, extra time
      is issued based on the quantity of antimatter the person possesses
      AND this parameter.  For example, if a person has a full daily issue
      of antimatter and this parameter is set to 20 they would get the 5
      minute minimum and an additional 15 minutes (because of the full load
      of antimatter).  If the they have 10% more than the daily issue of
      antimatter, then a setting of 25 would get them 27 minutes (5 + 1.1 *
      20), etc.  If, however, they have used half of today's issue of
      antimatter in an earlier call, then a setting of 35 would yield them
      only a 20 minute time limit (5 + 30/2).  A setting of about 7 minutes
      per 10000 grams of antimatter usually gives plenty of time.  If your
      system has mostly experienced players, use a smaller number.

   9. Bell on time (don't ring before) = 9
      This controls the bell when a person uses the <!> summon the sysop
      function.  Enter the hour that you want the bell enabled.  For
      example, if you get up at 9 am, set the parameter to 9.  (use 24 hour

      format).  To disable the bell, set this and the 'Bell off time' to
      the same number.

   10.Bell off time (don't ring after) = 20
      Like the 'bell on time', this controls the bell.  Enter the hour in
      24 hour format that you want the bell disabled.  To have the bell
      disabled at 8 pm, set the parameter to 20.

   11.Price of player strength calculations  = 1000
      This is the price in credits that players will be charged to do "net
      worth calculations" on other players.

   12.Operating through Com: port 1 or 2 = 1
      This switch tells the system which COM: port your modem is attached
      to.  If your modem is attached to COM2: then set this switch to 2.

   13.Start Fighters with new ship = 25
      This number controls the quantity of fighters issued to new players
      and to players getting a new ship after losing their old one.

   14.Remote Validation Password = none
      This will be the secret password that you would use to validate
      someone at validation level 1 (class B) remotely.  It can consist of
      upper case letters, numbers, and special characters.  For example,
      to validate JOE BLOW (a new, registered but not yet validated player)
      you can call the board and enter JOE BLOW at the name prompt and then
      this secret code at the password prompt.  Of course, if you are at
      your computer you can use CZAR_UTL to set a validation level to any
      valid setting.
      NOTE:  Entering a password in lowercase here will disable this
      feature.

   15.Enable programmatic upgrades to 'A' = 0
      This switch controls upgrades to class 'A' ships.  If set to 1
      players will be able to purchase class 'A' ships (and raise their
      validation level to 2) at any class 4 port.  If set to 0 they will
      not be able to upgrade - you will have to do any upgrading with
      CZAR_UTL.  You might want to disable programmatic upgrades if you
      solicit donations to your system.  As an additional incentive for
      your users to contribute you can then give Class 'A' ships only to
      those users that do.

   16.Cost of class 'A' / Antimatter bonus = 100000,     25
      The first parameter (Cost of class 'A') represents the cost in
      credits of an upgrade to validation level 2 (class 'A').  This is the
      price a player would have to pay at a class 4 port to upgrade his
      ship.  Of course, this parameter is meaningless unless programmatic
      upgrades (parameter #15) is enabled by setting it to 1.

      The second parameter (Antimatter bonus) has an effect regardless of
      the setting of parameter #15.  It controls the awarding of extra
      antimatter to class 'A' ships.  The number represents the percentage
      over the standard antimatter issue to be given to class 'A' ships.
      If it is set to '50' then class 'A' ships will be given 50 percent
      more antimatter than class 'B' ships.  If you have programmatic
      upgrades enabled, keep this one small.  If, however, you set
      programmatic upgrades to manual and charge your users for class 'A'
      ships, you can use this to make contributions much more attractive by
      setting it to give contributors an extra 10-100% (or more)
      antimatter.

   17.Lock out 300 baud access  = 0
      Setting this parameter to a '1' causes 300 baud callers to get this
      message; "300 baud in not supported".  Setting it to 0 enables 300
      baud callers to connect.  This parameter applies only in stand-alone

      BBS mode [CZAR_PGM/M].

   18.Modem Setup & modem options  = ATS12=20S10=99S7=40E0X1V1M0
      This is the setup string that is sent to initialize the modem each
      time the system goes to wait for a call.  It is set up for a Hayes
      compatible modem but can be changed to any string up to 40 characters
      long.

      Other options here include :

      modem reset string
      modem answer string
      modem hangup string

      Each of these three options can be disabled by entering "NONE" (in
      uppercase as shown) rather than a modem string.

      In the case of the modem reset string, entering NONE will prevent
      resetting the modem prior to sending the setup string each time the
      program goes to wait on a caller.

      Disabling the modem answer string by entering NONE will prevent a
      string from being sent to the modem when the phone rings.  If you do
      this you will have to set your modem to autoanswer either by a
      hardware switch or by putting S0=1 (or appropriate instruction) in
      the setup string.

      In the case of the hangup string, entering NONE will cause the system
      to hangup by the 'DTR drop' method.  This will be faster than using a
      hangup string but may not work with all modems.

   19.Modem type (1=300, 2=1200, 3=2400, 4=9600) = 2
      This parameter tells the software what speed modem you have.  As
      indicated, enter a '1' for a 300 bps modem, '2' for 1200 bps, '3' for
      2400 bps, and '4' for 9600 bps.

   20.Map size (1, 2, 4, or 8) = 4
      This parameter tells the program how much of the map to use.  If you
      set this option to 1, then players will only be able to get to the
      first 500 sectors of the map.  Using a 2 opens 1000 sectors and a 4
      opens up the entire map of 2000 sectors.  You may want to start out
      with a 500 sector map and only raise it as you get additional users
      (to keep it lively).  I recommend setting it at 500 until you get
      about 15 active players, then raising it to 1000 and raising it again
      when you add 15 more players.

      NOTE:  Although all new maps are only 2000 sectors in size, you can
      now set this option to 8.  A setting of 8 will cause the CZAR_UTL
      program to build a mirror image of the first 2000 sectors starting in
      sector 2001.  The end result will be a 4000 sector universe with all
      the galaxies, planets, and ports duplicated - only reversed in
      position.  For example, sector 1 would be duplicated in sector 4000,
      sector 2 in 3999, etc.  Do not do this until your game has become
      quite active.  I would suggest you leave it at 2000 sectors until you
      get about 40 active players.

      NOTE:  If you do decide to expand the map, you can use option 17
      under the CZAR_UTL main menu to reorganize the galaxies in the upper
      2000 sectors (using manual galaxy selection).  Please note that you
      can not use this option to reorganize an area in an ongoing game that
      has previously been available to players - use it only on the upper
      2000 BEFORE allowing players access to it.

   21.Public mail fixed and char cost = 5000     10
      These parameters control the cost to post public mail.  The first one
      (fixed cost) is a fee for posting a public message, regardless of
      length.  The second number (character cost) is an additional charge
      for each character typed into the message.  For example, a 100
      character message would cost 6000 credits using the above prices
      (5000  +  100 * 10).

   22.Price of a sector sign = 3000
      This price controls three things:

      1) the price to post a sector sign
      2) the refund when you remove a sign of your own
      3) the fee to remove someone else's sign

      If this parameter is set to 3000, then it would cost a player 3000
      credits to post a sector sign.  He would then be given a refund of
      90% of the original price when he removed it (2700).  If, however, he
      attempted to remove someone else's sign, it would cost 50% above the
      sign cost (4500 credits).

D. Routine system maintenance:
   In addition to configuring the system and validating users CZAR_UTL has
   15 other assorted maintenance functions.  They are explained below:

   <1> Configure the System Parameters
      (explained in section C above)

   <2> Validate/invalidate/change validation level
      The Sysop was entered initially during the automatic installation
      process with a validation level of '1'.  There are other validation
      levels you will need to become familiar with since you will need to
      use this option to validate players.

      The validation levels have the following definitions:

      ' ' (a space)  a new player, not yet validated
      '0' a player deliberately un-validated (has no access)
      '1' a player validated at class 'B' ship level
      '2' a player validated at class 'A' ship level.

      When you need to change someone's validation level (a new, recently
      verified player, for example) you can use this function.  Simply
      enter 2 to select this routine and then enter the name of the person
      to be validated (or invalidated, as the cas may be).  You will then
      be asked for a new validation level for the person.  Select one of
      the above options and press return.

   <3> List players to video or printer
      This option will list all players' validation levels, names, phone
      numbers, Stardate of last logon, and player number.  You will be
      prompted for whether you want the list to go to the video or to the
      printer.  This is frequently used to list new players (blank
      validation level) along with their phone numbers for validation
      purposes.  This routine also has an option to search by validation
      level.  For example, if you wanted to list only those players with a
      validation of 0 then you would enter a 0 at the validation level
      prompt.  Likewise, if you wanted only players with a space in the
      validation field (new players), then you would enter an "S" for
      Space.  You can also use the "N" option and search through the player
      file for names or name fragments.  For example, if you will looking
      for someone named "RAY" you would enter "RAY" as the text to search
      for.  You would then get a list of all players whose name contains
      the fragment "RAY", regardless of where it occurs in the name.

   <4> Delete players by name, date, or 0 validation
      This option allows the SYSOP to purge old and inactive players from
      the user file to make room for new players.  It also will purge any
      messages in the history file and the mail file that are addressed to
      a user being purged.  Any signs left by a person being deleted are
      automatically removed from the map file as well.  You will be
      prompted for whether you want to delete users based on date (period
      of inactivity), name (select a specific individual), or those with a
      validation level of 0 (people un-validated by the SYSOP).
      NOTE:  When deleting an individual by name you MUST enter the
      COMPLETE name in UPPER CASE characters.
      NOTE:  Deleting users by either date or validation 0  can be very
      time consuming if there are a lot of players affected.  Therefore, an
      option has been added to terminate purging prior to completion.
      Pressing the [Esc] key during these multiple user deletes will cause
      the purge to terminate immediately after removing the current user.
      (there may be a delay of 10 or 20 seconds before it actually quits)

   <5> Edit a player record.
      Be careful with this one!  It allows you to change a player's name,
      address, ship name, amount of fighters, amount of cash, etc.

   <6> Edit map file (change ports/planets/warps)
      Be very careful with this one!  It lset you to change warps, add,
      change,  and delete planets and ports, insert and delete signs etc.
      In general, it allows you to change any feature of any sector in the
      universe.  With it you can redesign the entire map, change
      productivity of ports and planets, add and delete Pulsars and Black
      Holes (and their warning signs!), create additional government
      controlled sectors, and accidentally make areas with no exit!!  So
      again, be careful.

   <7> Search map file for ships
      This option will search the entire map file and report all ships
      (along with the owners name) to the video.  It will also report and,
      at the same time, purge any 'ghost ships' (with an audible 'beep') in
      the universe.  A ghost ship is an image of a ship that appears in the
      wrong sector.  It should only happen when a player moves from one
      sector to another and the power goes down between the times that the
      map file and the player file are updated - causing them to get out of
      sync.  Though generally not serious, it does have two effects.  One,
      a ghost ship (invisible to other players) appears in one or more
      sectors.  And two, the persons ship disappears from the sector it is
      really in (meaning other players cannot see any evidence of the ship
      in ANY sector).  The players ship will reappear as soon as the they
      get back on and play out the rest of their turn.

   <8> System Statistics
      This item will tell you how many players there are in the player
      file, how many messages in the mail file, and how many entries in the
      history file.  In addition to those numbers, it will also tell you
      the percentage of each of the previous files that is filled - useful
      when determining if you need to purge some inactive players.  It will
      also give you a login count.  This count is the number of SUCCESSFUL
      connections received by all players CURRENTLY on the user file.
      Therefore, if you purge some players from the system, this number
      will decrease.

   <9> Scan the map for signs
      This routine will search the entire map file and list all signs in
      the entire universe to the screen.  It also shows the user number of
      the player who posted each sign (signs with a user number of 0 are
      government signs).  This option should be used now and then to make
      sure no obscene signs are being posted in remote sectors of the
      universe.  If such a sign is found, you can use option <5> (Edit a
      Player Record) to determine who posted it and then take appropriate
      action.  Also, you can easily remove any sign with option <6>  (Edit
      map...).  Don't forget to reset 'Sign Author' back to 0 if you remove
      a sign.

   <10> Scan the map for fighters
      This routine will search the entire map file and list all fleets of
      fighters (and Starbases) guarding sectors in the universe.  It will
      also list the owner of each fleet of fighters.

   <11> Reset a player's last logon date
      This option allows you to reset a player's last 'logon time' so that
      they may be able to log on and (optionally) issued the daily amount
      of antimatter.
      NOTE:  If you reset a player's time back past midnight, they will be
      issued the daily allowance of antimatter even if they have already
      played today!

   <12> Banish a player from the system for X days
      This option allows you to reset a player's last 'logon time' so that
      they will be locked out of the system for the number of days
      specified.

   <13> Initialize the map
      (explained in section B-2 above)

   <14> Initialize the game
      This option is used only if you run games with time limits or
      otherwise want to end a game and start a new one.  The advantage that
      it offers over repeating the installation process are:

      1)  All parameters are left as previously set.
      2)  All players registration information remains intact.
      3)  All players are notified that a new game has started.

      This routine will delete everyone's ship, remove all fighters and
      signs from the universe, and automatically do a map initialization
      (option 13).  The starting of a new game is an excellent time to
      change a few parameters to better suit your boards desired
      'personality'.

   <15> List the map file to printer or video
      This option allows you to list out sections of the map.  It will
      prompt you for beginning and ending sector numbers, ask whether you
      want to list the map to the video or to your printer, and then
      proceed to list out the section of the map you are interested in
      seeing.  It shows ports, warps, planets and signs.

   <16> List/Purge the message file
      This selection will allow you to browse through the message file,
      reading and purging messages.  It skips over blank messages and
      prints an "*".

   <17> Generate sector warps (use to reorganize galaxies in map file)
      This routine is used to modify warp connections within the existing
      map file.  When you first bring up Czarwars this routine will be
      automatically executed if needed.  Therefore, it won't be necessary
      to select it unless you specifically want to change around the
      galaxies in the map.
      NOTE:  Use this only when starting a new game - it will delete
      players' signs and Starbases!

      ===== A note to Sysops with a copy of the advanced map file =====
      If you have a copy of the advanced map you may still want to re-
      organize part of the map with this routine (for your first game or
      two, anyway).  Since this option can generate very simple maps
      including easily navigated 'toroidal' galaxies, new users may find it
      much simpler to move around and trade.  However, it will also be less
      interesting than the advanced map which has dead ends, one-way warps,
      easily defended areas, and mazes.  If you want a map that is half
      simple and half complex you can use this routine to re-organize the
      bottom 1000 sectors of the advanced map into simpler galaxies.  You
      may also use this routine to convert the dreaded one-way maze in
      sectors 1001-1350 to simpler galaxies since it is by far the most
      difficult area to navigate.

   [99] Exit to OS/2
      This option (the default) exits from CZAR_UTL and returns to OS/2.

E. Information on running the system:

   1. Using the logfile  (CZAR_LOG.TXT):
      If you invoke CZAR_PGM.EXE with the /L switch, Czarwars will keep a
      log of all calls.  Contained in this log is information such as the
      time and date that the phone was answered, the baud rate of any
      successful connection, the name of the player who logged on, records
      of any errors (such as i/o errors), and other information.  The
      logfile also can contain messages to the SYSOP by non-validated
      users.  Whenever a new user registers on the system for the first
      time, a special entry is made in the logfile.  It will include the
      players phone number, name, any message that he might have left, as
      well as some eye-catching characters to make it stand out from the
      rest of the routine log entries.  You need to look at this file often
      (every day or two) so you will know when you need to validate new
      users, etc.  (If you run in stand-alone mode without the /L switch,
      you will need to list players in the CZAR_UTL program who have a
      space in their validation field).  It is also useful for determining
      when players are using "clone" ships - extra pseudonyms to gain an
      advantage.  If several players call every day, one after the other,
      using the same baud rate, for example, you might look carefully to
      ensure that they aren't just one player who had some friends register
      and give him their passwords.

   2. Terminating a user's session:
      If you have need to hang up on a player, just press the [Esc] key
      once.  The system will then hang waiting on confirmation from you
      (Really hang up on this user? [N]).  If you then press "Y" and
      <enter> the system will hang up and go on to wait for another call.

   3. Chatting with a user:
      Press the F10 function key to toggle chat mode on at any prompt.
      Press F10 again to turn off chat mode.

   4. Backing up the system:
      Periodically (preferably every day) you need to make back up copies
      of the Czarwars data files on a floppy disk.  There are, of course,
      many things that can happen to files on a hard disk - most of them
      bad.   With a day-old set of backup files you could simply reload the
      game and notify your users of what had happened - not a major
      inconvenience for anyone.  Without backups you would be forced to
      start a brand new game - which some users will no doubt find very
      annoying.  The only files that must be backed up are those that end
      with an extension of .DAT.  They are:

      CZAR_PLR.DAT  (the player file)
      CZAR_MAP.DAT  (the map of the universe)
      CZAR_HST.DAT  (the history file - events happening to fleets)
      CZAR_MAL.DAT  (the mail or message file)
      CZAR_PRM.DAT  (the parameter file)
      CZAR_NEW.DAT  (the news file)

      I suggest that you compress these files with an archive program and
      then freshen the archive daily.  The archive file will be a small
      fraction of the size of the full-blown data files and is easily
      backed up.  My backup archive is usually under 130K.
      The logfile (CZAR_LOG.TXT) may be backed up as well, if desired.  It
      is possible to continue a game if you have only the player and map
      files - but you will have to re-enter the configuration parameters
      and players will lose their mail and history information.  So, at an
      absolute minimum, back up the player and map files - they are
      necessary to continue the current game.

   5. The Bulletin, Pre-Logon Bulletin,  and Information/Rules files:
      These three files are necessary for the system to run.
      The bulletin file (CZAR_BUL.TXT) is an ordinary text file and can be
      modified by most any word processor (in non-document mode) as well as
      ASCII editors such as the OS/2 System Editor.  Here is where you make
      announcements and post bulletins.  You should keep this one SHORT since
      it lists for everyone who logs on.
      The Pre-logon file (CZAR_PRE.TXT), too, is an ordinary text file.  It
      is displayed PRIOR to a person being prompted to log in.  As a
      result, it is an excellent place to identify your system, list your
      hours, and possibly tell new users to use their real names.  You
      should also keep this one as short as possible.
      The Information/Rules file (CZAR_NFO.TXT) is where you would put your
      system rules and any other information about your system (such as:
      Send $5 and you will be issued a class 'A' ship (more hold capacity
      and 50% more antimatter)).

   6. The Help file:
      The help or 'instructions' file (CZAR_HLP.TXT) is required for the
      system to function.  It ordinarily doesn't require any modification.

   7. Connection information:
      Czarwars only supports 8 data bits, no parity, and 1 stop bit.  7
      data bits is NOT supported.  People who connect at 7 data bits will
      get strange results.

   8. Maps:
      Paper copies of the advanced map are not available.

   9. SYSOP mode:
      This option is only available to the sysop (player #1).  It enables
      the sysop to move directly to any sector in the universe without
      being attacked by fighters left on guard.  It also permits the sysop
      to send public mail and do player strenth calculations without
      paying.  In addition, it permits the sysop to list (and delete) the
      log file while logged in the game.  To activate it go to the
      <U>tilities menu and type SYSOP.  It will respond with "sysop mode
      on.".  To disable this mode repeat the process used to enable it.  It
      will respond with "sysop mode off." when disabled.

F. Performance considerations:
   The following information is for OPTIONAL speed/performance improvements
   to the system.

   To speed disk access to the system, load all Czarwars files together
   (in adjacent spots) on the disk (especially the map file and the player
   file - the ones used most).  Also, try to load them unfragmented.  Once
   loaded, they will not move around or become fragmented on their own -
   they will stay in the exact spots where you put them.  A program that
   reorganizes disk files and unfragments them will make this task simple
   (as well as improving the disk performance of other programs).  Another
   way to both improve disk performance while simplifying backups is to put
   the entire Czarwars system in its own 2 or 3 megabyte disk partition.
   Of course, optimizing the partition with a program like the one
   mentioned above will further improve performance.  With a very fast hard
   disk drive, these changes will make only a modest improvement.  However,
   if you have a slow 'average access time' drive, following these
   recommendations will make it seem VERY fast since the drive heads will
   have only a very short distance to travel in even the worst
   circumstances.

G. Doors / Running under BBSs:
   There are several things to consider in addition to the advice given
   above if you intend to run Czarwars as a DOOR under another BBS.

   First, to run Czarwars in doors mode you must invoke it as follows:

   CZAR_PGM !<port handle> <baud> <timelimit> <first name> <last name>

   As you can see, a ! is used followed immediately by a decimal number
   designating the handle of the communications port that Czar Wars is
   to use.  This is followed by a space and then a FOUR DIGIT baud
   rate.  Valid baud rates are  0300  1200  2400  4800  9600  1920  and
   LOCA for connections at the console.  If LOCA is specified, the port
   handle is ignored.  The baudrate is followed by a space and then the
   the user's time limit in minutes.  This is followed by a space and the
   user's name.  This name should usually consist of first and last name
   separated by 1 space.  It can be up to 20 characters in length.  Below
   is an example of what a command line might look like:

   CZAR_PGM !5 9600 60 JOHN SMITH

   NOTE:  Any other switches that you may want to use must be placed BEFORE
   the ! on the command line as follows:

   CZAR_PGM /L !0 LOCA 60 SYSOP

   Second, do NOT allow the parent BBS to monitor carrier.
   Czarwars will terminate on its own if the user drops carrier.  However,
   if the BBS terminates Czarwars immediately after carrier drop (and prior to
   Czarwars closing its files and terminating) some of the Czarwars files
   may not be updated.

   Third, since Czarwars doesn't support 7 data bits, you may want prevent
   connection at 7 data bits in your BBS.


H. Common (and some uncommon) errors codes that you may see:
   The most frequent error you will encounter is 'I/O error (57)'.  These
   will be common when there is noise on the phone line.  In addition, you
   will occasionally get one for no obvious reason.   Another common error
   is 'error code 24' (see next paragraph for more on error 24).  You will
   get this error whenever a user hangs up abnormally or otherwise drops
   carrier.  A much less likely (though still fairly common) error is
   'error code 69'.  This one occurs when there is a buffer overflow -
   usually caused by someone uploading a message at a rate faster than the
   BBS can accept it.  In some circumstances, it can be caused simply by
   holding the <Enter> key depressed continuously.  This error will be
   slightly more common with slower computers and when running the BBS in
   a multi-tasked environment.

Other error codes:

   64*  Possibly means you have configured the BBS to use a com port that
      doesn't exist.  This error is sometimes followed by error 52*.
      Also, error code 68* indicate possible problems with the
      communications port.

   53*  Possibly caused by the absence of one of the required BBS files or
      by too small a number of FILES declared in the config.sys file.

   61*  Probable cause: The disk drive containing the logfile is full.

   6   Overflow/underflow.  A number was used that exceeded the limits of a
      variable - this usually is a response to an invalid input by a
      player.

   * The preceding errors flagged with an asterisk are serious and will
      generally bring down the BBS.  Other listed errors (57, 69, 6) should
      cause no problem unless 12 or more are detected in a single session.
      In that case, the system will recycle, therefore bumping off the
      player who incurred the multiple errors.

   Most other errors can be found in a GW-BASIC or BASICA manual.

I. Support:  Registered users of OS/2 Czarwars are provided support via
   "The Parkway BBS" system.  The latest OS/2 version of Czarwars is
   available for examination through a door there.  You must be registered
   on the system before you can enter the Czarwars door, however.  This
   system is online 24 hours a day at 9600 Hayes/2400/1200/300 BPS at 8 data
   bits, no parity, and 1 stop bit.

   The Parkway BBS:  [phone] or
                     [phone]

   On your first call, leave any questions or remarks in a message to the
   Sysop.  Please read LICENSE.TXT for further information on registering
   your copy of Czarwars.

J. Upgrades:  Any registered OS/2 Czarwars Sysop can upgrade to the
   latest version of OS/2 Czarwars at any time.  This can be done in
   one of two ways.

   It is possible to remove the 'UNREGISTERED Copy!' line from new, publicly
   distributed copies of Czarwars.  Registered copies of Czarwars include
   a file named REGISTER.COD which will include a code and instructions for
   putting registration information into all future releases.

   If you do not wish to download updates of Czarwars, you may also upgrade
   by mail for a $10 handling fee.

   Send any upgrade requests and written correspondence to:

   Troy Carroll
   Rt. 16 Box 9022
   Tallahassee, FL. 32310-9710

K. Running Czarwars in stand-alone mode from a batch file:  Czarwars will
   automatically recycle when used in the /M mode.  If you want to have it
   exit to OS/2 after each call (and subsequently be invoked again by a
   batch file) use the /1 switch:

   CZAR_PGM /M /1