                            PFEDIT 1.0

                    Unregistered Documentation

TABLE OF CONTENTS

1.0  Introduction

2.0  Installation

     2.1  System Requirements
     2.2  Setup

          2.2.1  Contents
          2.2.2  The Database Index Files
          2.2.3  Database Directories
          2.2.4  The HARPOON2.INI File

3.0  Execution

     3.1  Running PFEDIT
     3.2  Backup Files
     3.3  Running Under Windows

4.0  Using PFEDIT

     4.1  PFEDIT Main Menu
     4.2  Editing the Harpoon2 Database

          4.2.1  Structure of the Harpoon2 Database
          4.2.2  Editing and Creating Platforms
          4.2.3  Edit Platform.DAT Menu
          4.2.4  Individual Platform Editing Menus
          4.2.5  Harpoon2 Scenario Editor Rebuild Functions

     4.3  Working With Platform Text Descriptions and Pictures

          4.3.1  Editing or Adding Text Descriptions
          4.3.2  Designating Text Description Attached to Platform
          4.3.3  Steps to Write a New Platform Text Description
          4.3.4  Setting Platform Picture Reference

     4.4  Playing Scenarios Created from a Custom Database

          4.4.1  Creating an SDB
          4.4.2  Playing a Scenario using an SDB
          4.4.3  Some General Guidelines

     4.5  Transferring Platforms Between Databases (and Users)

          4.5.1  Creating a TPF
          4.5.2  Receiving a TPF

5.0  Registration

                            PFEDIT 1.0

                    Unregistered Documentation


HarpoonII and Three-Sixtey are registered trademarks of Intracorp Inc.
BattleSet is a registered trademark of ACSI.
Harpoon is a registered trademark of GDW Inc.


1.0 INTRODUCTION

PFEDIT is a share-ware tool designed to work with the Harpoon2 database.  PFEDIT
allows you to edit the parameters that define the various platforms in the game. 
PFEDIT also allows you to create completely new platforms of all types.  From
sensors and communications units to ships, submarines, aircraft, and weapons,
PFEDIT allows you to modify the existing platforms or create entirely new ones. 
In addition to editing and creating platforms, PFEDIT provides the means to
transfer platform data from user to user.  Users can share modified and new
platforms with the entire Harpoon2 community.  PFEDIT also provides the means to
play scenarios designed by others that employ modified or new platforms.

PFEDIT provides the following specific capabilities:

1. Change any attribute of existing platforms
2. Add new platforms of any type
3. Print an Index of platforms in the database
4. Print a detailed report on any platforms of the major types
5. Transfer/receive any platform to/from another user
6. Transfer/receive data to play scenarios employing custom platforms
7. Modify/add text descriptions of major platform types
8. Edit the country and date restrictions used by the Harpoon2 Scenario Editor

This document provides a basic outline of the options available in PFEDIT. 
Detailed instructions on the use of PFEDIT are available by registering as a
user. These instructions include topics such as choosing and calculating input
for parameters, explanations of the complex interactions between parameters,
construction of several specific types of platforms, and Harpoon2 game effects
of various settings.  See section 5.0, Registration, for more information.  The
author, Tom Wenck, will entertain all manner of questions, comments, and requests
at E-Mail address, twenck@clark.net, and monitors the Harpoon Mailing List on a
regular basis.

ACKNOWLEDGEMENTS

     360 published the excellent Harpoon2 and Harpoon2 Scenario Editor, and
     made PFEDIT possible and necessary.

     The following individuals have provided significant assistance by helping
     to decipher the database, testing PFEDIT, or providing programming advice:

                              Norm Lunde
                              Rodney Harper
                              Steve LeBlanc
                              Chris McKenney
                              Chris Hutto

     Special thanks goes to Saul Jacobs for providing plenty of advice and
     feedback, and a good dose of much needed encouragement.


2.0 INSTALLATION


2.1 SYSTEM REQUIREMENTS

PFEDIT will run under DOS (verified version 5.0 or greater), Windows3.x, or
Windows95.  Full usage requires 600k of free low memory.  No expanded or extended
memory is required.  The PFEDIT package will use 1.2Mb of hard drive space when
unzipped.  Maximum hard drive space required depends on the number of database sets and
the total number of platforms created.  Each copy of the original 360 database
will use approximately 563k.  Maximum power and flexibility is achieved if PFEDIT
is run under either version of Windows.


2.2 SETUP

2.2.1 Contents:

PFEDIT can be run from any desired directory.  The following files are
included with this release package:

     PFEDIT.EXE     platform editing program
     PFDOCS.TXT     this document
     ARK.SCN        scenario by Saul Jacobs
     ARK.SDB        scenario database for ARK.SCN
     F18E.TPF       sample TPF
     SV22.TPF       sample TPF
     FGR2.TPF       sample TPF
     ESSEX.TPF      sample TPF
     ARK.TPF        sample TPF
     SHIP.IND       index to SHIP.DAT 
     SUB.IND        index to SUB.DAT 
     PLANE.IND      index to PLANE.DAT 
     INSTALLA.IND   index to INSTALLA.DAT 
     FACILITY.IND   index to FACILITY.DAT 
     AIRFACIL.IND   index to AIRFACIL.DAT 
     PROPULS.IND    index to PROPULS.DAT 
     FUEL.IND       index to FUEL.DAT 
     SENSOR.IND     index to SENSOR.DAT 
     COMM.IND       index to COMM.DAT 
     LOADOUT.IND    index to LOADOUT.DAT 
     MOUNT.IND      index to MOUNT.DAT 
     MAGAZINE.IND   index to MAGAZINE.DAT 
     WEAPREC.IND    index to WEAPREC.DAT
     WEAPON.IND     index to WEAPON.DAT 
     WARHEAD.IND    index to WARHEAD.DAT 
     COUNTRY.IND    index to COUNTRY.DAT 


2.2.2 The Database Index Files:

This version of PFEDIT has no provision for platform selection displays. To use
PFEDIT you will need to know the database ID numbers of various objects.  The 17
*.IND files included contain an index for each of the DAT files as originally
published by 360.  The index files have been sorted by name and type.

The index files can be used in two ways.  If using PFEDIT in a Windows
environment, you can simply view the *.IND files in a separate window, using a
text editor or word processor.  You can then scroll through the list or search
for key names to find the ID number needed.

Alternatively you can load each *.IND file into a word processor and print the
file.  You can then manually look up the index numbers as needed.  It is
recommended that you use as small a font as possible and format the files into
2 newspaper columns.  This will produce the fewest number of pages.  This can be
reduced by half again by double-sided printing or photocopying.

The index files were created using the I. option from the EDIT Platform.dat Menu. 
Section 4.2.3, Edit Platform.dat Menu, contains instructions for creating updated
index files after platforms have been added to the database.


2.2.3 Database Directories:

PFEDIT can work with any number of database directories using any directory name. 
It is recommended that a full copy of the database be placed in each of the
following directories:

     HARPOON2\MDB   Master Database:  Your custom database containing the
                    final version of all platforms.  This is the database
                    you would likely use to create non-experimental
                    scenarios for public release.

     HARPOON2\WDB   Working Database:  A database for making frequent
                    changes for testing and experimentation.  This is the
                    default database for PFEDIT and is required.  It is the
                    recommended database for the initial design of new
                    platforms or receiving platforms from other designers. 
                    The MDB should frequently be copied to the WDB to keep
                    it up to date.

     HARPOON2\SDB   Scenario Database:  A directory to hold custom database
                    files that are specific to a particular scenario (or
                    group of scenarios).  This is the directory in which a
                    custom database will be created from an SDB file.

     HARPOON2\ODB   Original Database:  A directory to hold the latest 
                    version of the database published by 360.  This database
                    may be frequently referenced or used to reset a data
                    file to its original form. This is the least needed
                    directory, as the original database can be archived on
                    disk or accessed on the MM CDROM.


2.2.4 The HARPOON2.INI File:

For Harpoon2 to use any of the above database directories, it must know where
they are located.  The default configuration for Harpoon2 is stored in a file
named HARPOON2.INI in the HARPOON2 directory.  This is a text file that
determines such settings as the staff functions and map display defaults.  The
file is well self-documented.  Each parameter is labeled and has listed the
options available.  One of the settings in this file tells Harpoon2 what
directory contains the database.  This section of HARPOON2.INI looks like this:


; ============================================
; Directory where annex data is stored        
; ============================================

AnnexDir             G:\HARPOON2\database



To have Harpoon2 and the Harpoon2 Scenario Editor use the various databases (MDB,
SDB, etc.) it will be necessary to frequently change the pointer to your
database.  It is recommended that you modify HARPOON2.INI as shown below by
adding the suggested lines.  This can be done with any text editor or word
processor.  Remember to save the modified file in text format.



; ============================================
; Directory where annex data is stored        
; ============================================

;AnnexDir             G:\HARPOON2\mdb
;AnnexDir             G:\HARPOON2\sdb
;AnnexDir             G:\HARPOON2\odb
AnnexDir             G:\HARPOON2\wdb



A line proceeded by a ; is considered a comment line and has no effect on the
Harpoon2 game engine.  You can change the database directory that Harpoon2 and
the Harpoon2 Scenario Editor will use by removing and adding the ; from the
beginning of these lines.  The line without a ; in front will be the active line
and determine which database is used.



3.0 EXECUTION


3.1 RUNNING PFEDIT

PFEDIT can be run from any directory.  The program will except the drive/path to
Harpoon2 as an optional command line parameter.  PFEDIT can be run from the
HARPOON2 directory with no path given on the command line.

An example with command line parameter:  pfedit g:\games\harpoon2


3.2 BACKUP FILES

PFEDIT automatically creates a backup file any time a file on disk will be
replaced.  The backup file will always be named *.bak. This will occur when
replacing a DAT or RES (text descriptions) file. If a file named *.bak already
exists it will be overwritten.


3.3 RUNNING UNDER WINDOWS

Running the programs in a windows (3.x or 95) environment is especially
efficient.  PFEDIT can be run multiple times with the windows arranged to view
them all at once.  This allows one, for example, to view the data on a mount and
the data on the weapons used by that mount at the same time.  One can also view
several mounts at once, or the same mount from more than one database set.

The menu for editing each platform type contains an option to refresh the
database records.  This will cause the data for the platform type being edited
to be reread from disk.  This would be used if multiple instances of PFEDIT are
being run and a data change in one window has been saved to disk.

For example:  A ship is being edited with the ship's sensors displayed in one
window.  In another window the data for one of those sensors is being displayed. 
If the name of the sensor were modified in the Edit Sensor window, the change
would not show up in the Edit Ship window until the refresh option were selected.



4.0 USING PFEDIT

PFEDIT will allow you to edit the parameters of any existing platform or create
a completely new platform from scratch.  PFEDIT will allow you to transfer a
platform from one database set to another, or to another PFEDIT user.  Similarly,
PFEDIT provides the ability to incorporate a platform from another user into any
of your database sets.  PFEDIT also allows for the transfer of all the data
necessary to play any scenario to or from another user.

4.1 PFEDIT Main Menu

When PFEDIT is run, the main menu appears with the following options:

1. Edit H2 Database
2. Edit Text Descriptions
3. Edit Country and Date Restrictions
4. Receive TPF
5. Scan Scenario and Make SDB
6. Receive SDB
C. Change Database <current = \WDB>
Q. Quit

Options 1 - 6 will be discussed in the sections below.  Option C., Change
Database, allows you to tell PFEDIT which database directory to use.  Options are
provided for MDB, WDB, SDB, ODB, and other as specified.  PFEDIT defaults to the
WDB.



4.2 EDITING THE HARPOON2 DATABASE

4.2.1 Structure of the Harpoon2 Database:

Each platform in the Harpoon2 Database is stored as a record in one of the *.DAT
files.  This record contains data describing the platform and references to other
records that are attached to the platform.  Editing or creating a platform
consists of inputting data into the *.DAT record and designating other records
to be attached to the platform.  The attachments are made by record ID number and
are structured as follows:

ships: air facilities, engines, fuel, sensors, comms, mounts, and magazines

subs: engines, fuel, sensors, comms, mounts, and magazines

planes: engines, fuel, sensors, comms, mounts, and loadouts

installations: facilities

facilities: fuel, sensors, comms, mounts, and magazines

loadouts: weapon records

mounts: directors (sensors) and weapon records

magazines: weapon records

weapon records: a specific weapon

weapons: engines, fuel, sensors, comms, warheads, and directors (sensors)



4.2.2 Editing and Creating Platforms:

PFEDIT Main Menu option 1., Edit H2 Database, is used both to edit existing
platforms and to create new platforms.  A new platform is created by choosing an
existing platform that is similar to the one being created, and change the
necessary data to reflect the characteristics of the new platform.  The edited
platform is then saved with a new ID number while the data on the existing
platform remains unchanged.  Changes made to platform data are made in computer
memory and do not take effect until the platform type *.DAT file is saved to
disk.

The process of editing an existing platform is outlined as follows:

1. Choose PFEDIT Main Menu item 1., Edit H2 Database

2. Select platform type

3. Select option E., Edit platform, from the EDIT *.DAT menu

4. Enter the ID number of the platform to be edited

5. Change platform data as desired using the EDIT PLATFORM menu

6. Exit the EDIT PLATFORM menu

7. Select option S., SAVE *.DAT File, from the EDIT *.DAT menu


The process of adding a new platform to the database is outlined as follows:

1. Choose PFEDIT Main Menu item 1., Edit H2 Database

2. Select platform type to edit

3. Select option E., Edit platform, from the EDIT *.DAT menu

4. Enter the ID number of a platform similar to the one to be added

5. Change platform data to reflect the platform being added

6. Select option S., Save as a new platform ID

7. Exit the EDIT PLATFORM menu

8. Select option S., SAVE *.DAT File, from the EDIT *.DAT menu

Note of Caution:  When you make a change to a record that is attached to another
platform, you may be affecting more than one platform.  Many platforms may
reference the same record.  You may find, for example, that a particular aircraft
does not have enough fuel attached.  If you modify the amount of fuel in the
fuel.dat record used by that aircraft, you may be inadvertently adding fuel to
another aircraft that refers to the same fuel record.  In this case, it would be
better to create a new fuel record with the correct amount of fuel and attach it
to the aircraft.  On the other hand, you may discover that a sensor that should
have air search ability, does not have it.  Adding that capability to the
existing sensor.dat record would be appropriate.  All platforms with that sensor
attached would now have air search ability as they should.  As a general rule,
modifications to a record should be made by creating a new record unless you are
sure you want the modification to be generic to all platforms that might employ
it.


4.2.3 Edit Platform.dat Menu:

After selecting option 1, Edit H2 Database, on the PFEDIT main menu, you will be
prompted with a list of platform types that can be edited.  When a type is
selected, the data for those platforms will be read from disk and an Edit
Platform.dat menu will appear.  This menu has 6 options:

     E. Edit Platform:  After selecting Edit Platform, a prompt to enter the ID
     number of the platform to be edited will appear.  Once a valid platform
     has been selected for editing, a menu listing the parameters available for
     editing will be displayed.  This menu is different for each of the 16
     platform  types.  Each will be described separately below.

     D. Delete Platform:  After entering the ID number of the platform to be
     deleted, the platform name will be displayed and a prompt given to confirm
     that the platform should be deleted from the database.  If confirmation is
     given by typing the y key, the data for that platform will be deleted from
     the database in computer memory.  The data will not be permanently deleted
     until the modified *.DAT file is saved to disk.  Whenever a *.DAT file is
     written to disk, a backup copy of the original *.DAT file is created with
     the extension BAK.  All changes, including the deletion of platforms, can
     be undone by deleting the modified *.DAT file and renaming the *.BAK file
     to *.DAT.

     I. Index *.DAT Records:  Selecting this option will cause an index of the
     current *.DAT file to be written to the current directory and named *.IND. 
     The index will be structured similar to those that were included in the
     PFEDIT zip file, but will not be sorted.  Rather, the records will be
     listed in ID number order.  The index can be sorted in a spread sheet, and
     saved as a text file for printing or viewing in a word processor/text
     editor.  This option will be needed to print updated indexes as PFEDIT is
     used to modify existing records and to add new platforms.

     R. Refresh *.DAT Records:  This option will cause PFEDIT to clear the
     current *.DAT data from memory and read the database again from disk. 
     This action will cause the loss of any changes/additions that have been
     made since the last SAVE option was performed.  Refresh Records is used to
     "update" the data in memory if the data on disk has been changed via
     another window with PFEDIT running in windows.

     S. Save *.DAT File:  Selecting this item will cause PFEDIT to write to
     disk a copy of the *.DAT data currently in memory.  The original *.DAT
     file will be backed up as *.BAK.

     Q. Quit: End the editing session for the current *.DAT file and return to
     the platform type selection menu.  Note, the *.DAT file is not saved and
     any editing done since the last Save is lost.


4.2.4 Individual Platform Editing Menus:

4.2.4.1 Options Generic to All Platform Editing Menus

Undo

Most menus have an undo option.  Hitting the U key will restore all data
accessible by that menu to the original values.  There is also an undo option on
the main menu for editing the selected platform.  Hitting the U key on that menu
will restore all data for the entire platform to its original values.  The
ability to restore data to its original value is lost at the time the *.DAT file
is saved to disk.


Save As New Platform ID

This option will cause PFEDIT to save a copy of the current platform, with any
data changes, as a new platform with a new ID number.  The data for the current
platform will be restored to the original values.  This is how new platforms are
added to the database.


Print Report

The major platform types ships, subs, planes, installations, facilities, and
weapons have an option to print a detailed report.  The report will be printed
to a file named platform.rpt in the current database directory.  The report
displays all the data on the currently selected platform including the name and
ID number of any attached objects.  If the platform.rpt file already exists, the
data on the current platform will be appended to this file.  This allows reports
to be generated on more than one platform of the same type in one session.  If
the file is to be saved, its name should be changed to prevent PFEDIT from
appending data the next time a report is generated.


Exit

Selecting exit returns to the Edit Platform.dat menu.  The changes made to the
platform will be made permanent when the *.DAT file is saved to disk.



4.2.4.2 Edit Ship.dat Menu

1. Name, Class, Type, or Type Code:  Name, Class, and Type are identifiers used
as labels on the Harpoon2 display.  The Class is usually the hull number of the
first ship of the class.  The Nimitz, for example has "Nimitz" as the name, "CVN
68" as the class, and "CVN" as the type.  The type code is chosen from a menu of
limited options.

2. Damage Points, Armor Ratings, Length, Displacement, or Crew:  Damage points,
length, displacement, and crew are self-explanatory.  Length is in meters and
displacement in tons.  Each ship has 4 different armor ratings.  It is not yet
determined what structural aspect of the ship is covered by each field.  The
ratings are chosen from a menu with Special, Heavy, Medium, Light, and None as
the options.  Examine similar ships in the database to decide ratings for a new
ship.

3. Air Facilities:  The capability of a ship to carry, launch, and land aircraft
is determined by the Air Facilities that are attached to that ship.  This menu
allows Air Facilities to be added or deleted from a ship.  Air Facilities are
attached by ID number.  The characteristics of an Air Facility are set in the
EDIT AIRFACIL.DAT menu and can be read from the AIRFACIL index.  As a minimum,
a ship must have a hangar or open parking to carry aircraft and a pad or runway
to launch and land aircraft.

4. Engines or Fuel:  The speed of a ship at each throttle setting as well as its
fuel consumption is determined by the attached engines.  The range of the ship
will be determined by the attached fuel.  It is possible to attach more than one
engine to a ship although the effect is yet undetermined.  Several ships have
more than one fuel and type of fuel attached.  Engines and Fuel are attached by
ID number.  Their characteristics can be viewed/edited from the EDIT PROPULS.DAT
and EDIT FUEL.DAT menus respectively.  The Fuel index lists the fuel type and
amount for each record.

5. Sensors or Cross Section Data:  Sensors are attached to a ship by ID number. 
The characteristics of Sensors are viewed and edited from the EDIT SENSOR.DAT
menu.

The likelihood of a ship being detected by a given sensor is related to that
ship's cross section for that sensor type.  Each ship has 5 cross section
ratings: visible, infrared, radar, active sonar, and passive sonar.  Each rating
has values for the ships front, side, and rear yielding a total of 15 separate
ratings.  Higher numbers indicate a greater chance of detection while smaller
values (including values < 0) result in a lesser chance.

6. Mounts:  Mounts are attached to ships by ID number.  The characteristics of
a mount are viewed and edited from the EDIT MOUNT.DAT menu.

7. Magazines: The number of reloads a ship has available for its mounts is
determined by the attached magazines.  The ordinance in the attached magazines
also determines the type and number of loadouts embarked aircraft may use if the
aircraft logistics option is on.  Magazines are attached to ships by ID number. 
The ordinance available from each magazine may be viewed/edited from the EDIT
MAGAZINE.DAT menu.

8. Communications: The ability of a ship to form data links with various types
of units is determined by the attached comms.  Comms are attached to ships by ID
number and can be viewed/edited from the EDIT COMM.DAT menu.

9. Special/Replenishment/Misc. Codes or Picture/Text Reference:  Each ship has
3 sets of codes that describe various characteristics of the ship.  These codes
are all selected from a menu.  More than one option from each menu may be
selected.

Ship text descriptions and pictures are referenced by ID number.  Selecting Edit
Text or Picture will allow one to change the ID number of the text or picture
reference.  The text being referenced will be displayed.  This menu contains an
option to save the current description to a text file for editing.  Edited text
can be loaded into the text resource files from the PFEDIT main menu option 3.,
Edit Text Descriptions.

A. Cargo or Troop Capacity:  These options are self-explanatory.  Cargo is in
tons.  It appears this data is not used by the Harpoon2 game engine.

B. Unknowns:  There are 2 data fields in the ship.dat records that have not yet
been deciphered.  Generally, these should not be changed on existing ships. 
Values for new platforms should be selected by observing the values used in
similar ships already in the current database.


4.2.4.3 Edit Sub.dat Menu

The options for editing subs are nearly identical to those for ships.  There is
an option to set the maximum depth in meters the sub can dive.  Subs have no
armor ratings or air facilities.  Subs have no replenishment capability and have
unique options in the special codes section.


4.2.4.4 Edit Plane.dat Menu

The menu for editing planes is similar to that for ships.  Planes have  no air
facilities or magazines.  Instead, loadouts are attached to planes by ID number. 
The ordinance contained in various loadouts can be view/edited from the EDIT
LOADOUT.DAT menu.  Planes have no sonar cross sections.  Planes have a climb rate
specified in meters/second although initial tests indicate the planes do not obey
this climb rate in the Harpoon2 game engine.  There are many options for planes
under the special codes menu including the plane size, runway length required,
and a designation for carrier capable.  Each plane is rated for its
maneuverability vs. an incoming missile.  The rating, called Defensive Air-to-Air
rating (DATA), is a number ranging from 0.0 to 5.0 with 5.0 being the most
maneuverable (and therefore, the most difficult to hit).  Each aircraft has 2
DATA ratings, one for fully loaded and one for unloaded.


4.2.4.5 Edit Installa.dat Menu

Installations are composed of a collection of Facilities.  This menu allows one
to add or delete facilities to an installation.  Facilities are attached to the
installation by ID number.  The makeup of facilities can be viewed/edited from
the EDIT FACIL.DAT menu.  The Multi Media Deluxe version of the database
contained only one installation named Airfield.  The INSTALLA.DAT file from the
original Harpoon2 had many installations available.  This file can be used in
place of the MM Deluxe version by copying it to a desired database directory. 
If you have West Pac or Cold War, the INSTALLA.DAT files from these have even
more installations.


4.2.4.6 Edit Facil.dat Menu

Facilities are very similar to ships but without engines.  See the description
of the EDIT SHIP.DAT menu options.  As in the ship.dat section, there are 2 sets
of data fields that have not been deciphered.  Values should be copied from the
existing facility that most resembles a new facility.


4.2.4.7 Edit Airfacil.dat Menu

1. Facility Type: This option displays a menu to select a type of air facility. 
Only one option is allowed.

2. Aircraft Capacity: This is the number of maximum-sized aircraft the facility
can accommodate.  A larger number of smaller-than-maximum sized aircraft can be
handled.

3. Maximum Aircraft Size: This sets the maximum size of aircraft that can be
based or operated by the air facility.


4.2.4.8 Edit Propuls.dat Menu

1. Name, Type, or Co-Engine Type: The type is chosen from a menu of possible
designations.  Only one option may be selected.  The Co-Engine type is for
designating the type of the co-engine on dual engine ships such as CODOG.

2. The speed ratings:  Each engine is rated for speed at 4 different throttle
settings: loiter/slow, cruise, full, reheat/flank.  Each throttle setting may
have up to 4 different speed ratings that apply within different altitude bands. 
This menu option allows the setting of the low and high boundary of each altitude
band and the engine speed rating for that band at the chosen throttle setting.

3. Fuel Consumption Data: Each engine is rated for its cruise speed fuel
consumption rate in each of up to 4 altitude bands.  The units of the fuel
consumption rate depend on the type of platform powered by the engine and the
engine type as follows:

     Ship:     fuel units burned per 10 hours

     Sub:      Diesel Engine - fuel units burned per 10 hours
               Electric Engine - fuel units burned per second

     Plane:    fuel units burned per 100 seconds

     Weapon:   fuel units burned per second

Each engine also has a rating called the Full Burn Coefficient.  The rate the
engine consumes fuel at full throttle speed is equal to the cruise speed burn
rate multiplied by the Full Burn Coefficient.  There is a Full Burn Coefficient
for each altitude band.


4.2.4.9 Edit Fuel.dat Menu

Each fuel record consists of two parts, a type code and an amount of fuel.  The
type of fuel for the record is chosen from a menu.  Only one type may be chosen
for each record.  The units applicable to the amount of fuel is determined by the
platform to which the fuel is attached as follows:


               		Ship      Sub       Plane     Facility  Weapon (1)

Diesel Fuel    		tons      tons      N/A       tons      N/A

Gas Fuel       		tons      N/A       N/A       tons      N/A

Oil Fuel       		tons      N/A       N/A       tons      N/A

Battery        		N/A       sec (2)   N/A       N/A       sec

Air-Independent     	Not used in the current database

Rocket Fuel    		N/A       N/A       N/A       N/A       sec

Aviation Fuel  		tons      N/A       kg        tons      sec

Weapon Coast Time   	N/A       N/A       N/A       N/A       sec

Torpedo Fuel   		N/A       N/A       N/A       N/A       sec


note (1): All weapon engines have a fuel burn rate of 1 fuel unit per second. 
This effectively means that the fuel load gives the weapon flight time in
seconds, regardless of the actual units intended.  Seconds of flight time is used
as the "unit" for weapon fuel loads in PFEDIT.

note (2): The battery charge for subs is given as seconds of discharge at creep
speed.  Speeds above creep result in higher battery discharge rates and give a
lower actual endurance.  The submarine battery display in the Harpoon2 unit
window will always give the remaining discharge time at creep speed.  The
submarine fuel display will always give the endurance at the current speed.


4.2.4.10 Edit Sensor.dat Menu

Sensor performance is determined by input/output parameters.  Each sensor has 5
parameters that characterize the signal strength the sensor emits (if active) and
its sensitivity, or ability to recognize a return/an incoming signal.  The 5
parameters are search output power, search sensitivity, fire control output
power, fire control sensitivity, and passive sensitivity.  It is not yet
determined what the units are for these parameters and the names are generic to
represent the observed function.  Greater output power values and lower
sensitivity values result in improved detection/range performance.

The choices available in the sensor capabilities menu determine the types of
units the sensor can detect and the information the sensor can provide about a
contact.  More than one option may be selected for a sensor.  The range field is
used in the database text display and for limiting the display of the sensor
range ring.  The "real" range of the sensor is determined by the input/output
parameters.  The max number of intercepts determines the number of targets a fire
control sensor may track.  This places a limit on the number of targets a mount
may fire on simultaneously for weapons designated illuminate at launch or
terminal illumination.  The radar type designation appears to have no influence
on the sensor performance in the game.

There are 3 sensor.dat data fields (the largest number in PFEDIT) whose meaning
has not been determined.  Like the other unknowns, values for new sensors should
be copied from existing records that are most like the new sensor.


4.2.4.11 Edit Comm.dat Menu

1. Capabilities:  These options determine the types of communications links the
comm unit can maintain.  They also determine the comm units with which the unit
may establish a link.  Multiple options may be selected for the same comm unit.

2. Range:  Establishes the maximum range over which a comm unit may maintain a
link.

3. Channels:  Determines the maximum number of links a comm unit may maintain
simultaneously.


4.2.4.12 Edit Loadout.dat Menu

1. Target Types:  Determines the target types that will be legal for the plane
when carrying this loadout.  Loadout target types should be a composite of the
target types of all the weapons in the loadout.  The loadout target types specify
which target types a plane may be ordered to attack or intercept.  The individual
weapons' target types determine whether that weapon may be launched against a
target.

2. Weaprec References or Total Weapons Capacity:  The weapons available in a
loadout are specified by attaching one or more weaprecs to the loadout.  Each
weaprec refers to one weapon and gives a default and maximum number of that
weapon.  The maximum/default structure is really for use in magazines and mounts. 
For loadouts, the default is the number of weapons that will be available to a
plane carrying the loadout.  The maximum is ignored.  The total weapons capacity
appears to be for display only.  The maximum can be exceeded by the sum of the
weaprec default numbers.

3. Weapon Launch Period:  The launch period, in conjunction with the weapon
launch period given in each attached weaprec record, generally determines the
timing of multiple weapon launches.  These parameters determine the delay time
from attack order to the first weapon launch and the time that will pass between
each weapon launch.  The following describes the observed behavior that results
from entering various values in this field and the weaprec launch period field:


For both the loadout and weaprec weapon launch period fields, a value > 0
represents time in seconds.  A value < 0 gives the number of 30 second increments
(e.g. -10 gives 5 minutes.)

loadout value < 0:
     The weaprec launch period value is ignored.  The delay time from attack
     order to first launch is 0.  Loadout launch period gives the time between
     successive weapon launches in 30 second increments.

loadout value > 0:
     loadout launch period gives the launch delay in seconds
     weaprec launch period < -1 launch period = 1 second
     weaprec launch period = -1 launch period = 30 seconds
     weaprec launch period > 0  launch period = weaprec launch period in
     seconds.

In the original 360 database, a very large majority of loadouts have a launch
period of 15.  Bomb loadouts occaisionally have a launch period of 1.  Loadout
weaprecs usually have a launch period of 1 for bombs, and 5 or 15 for missiles
and torpedos.  Many torpedos have a launch period of -4 or -10, but this appears
to be due to a mistake in which ship torpedo tube weaprecs were used for
loadouts.


4.2.4.13 Edit Mount.dat Menu

1. Mount Directors:  The ability to add and delete directors for a mount is a
hold over from the original release of Harpoon2.  Beginning with the West Pac
version of the database, the directors were removed from all but one mount.  Each
weapon has a list of applicable directors.  The effect in the current game engine
of designating a director for a mount has not been determined.

2. Weaprec References or Total Weapons Capacity:  The ability to fire particular
weapons is specified by adding one or more weapon records.  The weapon record
refers to one weapon and specifies a default and maximum load.  The mount will
initially contain the default number of weapons.  The maximum specifies the
maximum number of that specific weapon that can be loaded in the mount.  The
actual number of each weapon loaded in a mount can be changed using the logistics
button in the Harpoon2 Scenario Editor.  The total weapons capacity of the mount
will be enforced by the scenario editor.

3. Launch Period: The launch period generally determines the minimum time that
must pass between each weapon launch.  See 4.2.4.12, Edit Loadout.dat Menu, for
an explanation of the use of this parameter.  Unlike the loadouts, most mounts
will not show a delay between the order to attack and the first weapon launch. 
The values used for mount and mount-weaprec launch periods are much more variable
than the values for loadouts.  It is recommended you use values from existing
mounts and mount-weaprecs that are similar to the ones being created.


4.2.4.14 Edit Magazine.dat Menu

1. Weaprec References or Total Weapons Capacity: The scheme for adding weapons
to a magazine is identical to that for adding weapons to mounts.  Like a mount,
the magazine will contain the default number of each weapon unless changed using
the Harpoon2 Scenario Editor logistics button.  The total number of weapons in
the magazine will be limited to the specified total weapons capacity.

2.  Reload Time:  This parameter gives the amount of time it takes a mount to
reload ordinance from the magazine.  A positive value gives the reload time in
seconds.  A negative value gives the time in 30 second increments.


4.2.4.15 Edit Weaprec.dat Menu

1. Weapon Reference: Specifies the particular weapon referenced by the weaprec.

2. Default Load: Allows a change in the default number of weapons to be loaded
in the loadout, mount, or magazine.

3. Max Load: Allows a change in the maximum number of weapons the Harpoon2
Scenario Editor will allow in a mount or magazine.

4. Weapon Launch Period:  This parameter, in conjunction with mount or loadout
launch period, determines the amount of time that must pass between the launch
of each weapon.  See section 4.2.4.12, Edit Loadout.dat Menu, for an explanation
of the use of this parameter.


4.2.4.16 Edit Weapon.dat Menu

The structure of the data for a weapon most resembles that for a plane.  A weapon
has no mounts or loadouts but instead has warhead(s) and a list of applicable
directors (sensors on the firing platform that will be used in conjunction with
the weapon.)  A weapon also has a set of launch parameters that must be satisfied
by the launching platform before the weapon can be fired.

1. Directors:  Specifies a list of sensors, of which, at least one must maintain
detection with the weapon's target.  These sensors would be attached to the
firing platform.  The illuminate at launch or terminal illumination options in
the Special Codes menu determine precisely how the directors interact with the
weapon.

2. Launch Parameters:  These 6 parameters give a set of conditions which must be
satisfied by the launching platform before the weapon can be fired.  If the Max
Launch Speed is set to 0, no maximum applies.  Negative numbers for the Max and
Min Launch Altitude indicate sub-surface depths. (e.g. Max Launch Altitude -10
and Min Launch Altitude -100 indicate only a submarine between 10 and 100 meters
can launch the weapon.)

3. Warheads, Legal Targets, or %Hit:  Each weapon has a list of the warhead types
carried.  The actual number of warheads is set in the warhead record itself.  The
legal targets menu allows the designation of which target types a weapon may be
fired upon.  More than one option is allowed.  The target designations surface
vessel, submarine, runway, and aircraft are straight forward.  Missile refers to
a missile in flight (e.g. an incoming Tomahawk) not to a missile launcher
(mount.)  The radar target type is used for anti-radiation missiles (ARMs).  The
target for an ARM is a particular sensor emission, regardless of the type of
platform emitting.  The following gives a brief explanation of the land based
(i.e. facility) target types land structures, hardened structures, soft targets,
and hardened targets:

     1.   Facilities are always structures unless they contain mounts and no
          other attachments.

     2.   Facilities that contain mounts and no other attachments are targets.

     3.   The presence of Heavy Armor makes a facility a hardened structure or
          target.

     4.   The presence or absence of sensors and comms have no effect on
          facility target type.

A weapon with any target type other than aircraft and missile, will have a
surface %hit.  Two values are specified, the near and the far %hit.  It has not
been determined which applies to a particular attack.  A weapon with a target
type of aircraft or missile will have an air near and far %hit.  Note the
Harpoon2 game database display has a bug which will cause it to display the near
air %hit value as both the near and far %hit.  It is not known if the game engine
uses the correct value for the far case.  These %hit values are base chances for
the weapon to hit.  Many game circumstances affect the final %hit chance that
will apply.  These effects can be viewed by running Harpoon2.exe with the -W
command line parameter.

4. Special Codes:  This menu allows the designation of several codes that
determine the behavior of the weapon.


4.2.4.17 Edit Warhead.dat Menu

1. Warhead Type: This menu allows the selection of warhead type.  Note that more
than one type is allowed for a warhead (e.g. Armor-Piercing Gun up to 150mm.) 
Two types require further explanation.  The warhead type, weapon, indicates the
warhead is itself another weapon. A good example of this is the ASROC (Anti
Submarine Rocket.)  This missile delivers a torpedo to the target location.  The
torpedo is then detached and activates, seeking the submarine target.  To model
this in Harpoon2, the ASROC warhead type is weapon, and the ASROC warhead
references the torpedo weapon.  Similarly, warhead type sensor indicates a weapon
that delivers a sensor.  There are several warheads in the database for the decoy
weapons (chaff, flares, etc.) but they are unused.  The decoy weapons do not
reference these warheads.  It appears the Harpoon2 game engine gives them generic
characteristics.

2. Number of Warheads: Gives the actual number of warheads present.  Weapons with
multiple warheads include ICBMs with MIRVs and cluster bombs.

3a. DP: Gives the number of damage points the weapon will inflict when it hits
a target.  Warheads of type sensor or weapon do not have DP.

3b. Sensor or Weapon Reference: For warheads of type sensor or weapon, this
option allows the specification of the sensor or weapon ID.


4.2.5  Harpoon2 Scenario Editor Rebuild Functions

In the course of building a scenario, it may occur that you make a change to a
platform using PFEDIT.  In most cases, that change will not be reflected in the
scenario.  Most platform data is copied from the database to the scenario file
at the time of scenario creation.  To have the changes reflected in the scenario,
the Harpoon2 Scenario Editor Rebuild functions must be used.  There are two
options under the Unit menu named Rebuild Unit and Rebuild All.  Selecting a unit
and choosing Rebuild Unit will cause the Harpoon2 Scenario Editor to update the
selected unit's data from the current database.  Selecting Rebuild All will cause
all units in the scenario (all sides) to be updated from the database.

     Note:  The current version of the Harpoon2 Scenario Editor has a bug in
     the rebuild routines that cause it to fail to update any data on ship,
     sub, or facility magazines.  Unfortunately, the magazines are one of the
     areas that need a good bit of work.  There is a work-around however.  If
     you make a change to a magazine and want it to be reflected in a scenario,
     you can use the following procedure.  Insert a new unit of the same type
     adjacent to the original unit.  Rename the new unit if necessary. 
     Duplicate any conditions of the old unit for the new unit (e.g. join it to
     a TF, assign it to a mission, etc.)  Finally, delete the old unit.  The
     new unit will have essentially replaced the old and will have the new
     magazine data available.

     Also note:  The rebuild functions do not at all for aircraft "in flight". 
     They must be "manually updated" as described above for magazines.  The
     rebuild functions do work for aircraft assigned to ships and facilities.




4.3 WORKING WITH PLATFORM TEXT DESCRIPTIONS AND PICTURES

The following platform types have text descriptions attached: ships, subs,
planes, facilities, sensors, and weapons.  These text descriptions are stored in
the files SHIPTEXT.RES, SUBTEXT.RES, PLANTEXT.RES, FACLTEXT.RES, SENSTEXT.RES,
and WEAPTEXT.RES.  Strangely enough, all but the facility text files are stored
in the DAT2 directory.  The facility text is stored in the RESOURCE directory.

There are two phases to editing platform text descriptions: (1) editing or adding
text descriptions, and (2) designating which text description is attached to a
platform.

4.3.1 Editing or Adding Text Descriptions:

On the PFEDIT main menu there is an option to edit text descriptions.  After
selecting this option a menu will be displayed listing the platform types that
support text descriptions.  Selecting a platform type will display the EDIT
PLATFORM TEXT DESCRIPTIONS menu.  At the top of the screen, the first text
description in the *.RES file will be displayed along with its reference number. 
The menu allows you to select any text description for display by entering its
reference number.  The menu option Save Text Description as a Text File, allows
you to "capture" a text description to a text file.  This file will be saved to
the same directory as the *.RES file.  This text file can then be edited with any
text editor (such as DOS EDIT.EXE) or word processor.  Remember when saving an
edited file, to save in  text format.  Similarly, a completely new text
description can be created and saved as  text.  There are two menu options to
load a text file into the *.RES file.  The LOAD INTO CURRENT ID option will
replace the description currently displayed on the screen with that in the text
file.  The LOAD INTO NEW ID option will add the text file as a new description
with the next available reference number.  The text files to be loaded must be
in the same directory as the *.RES file.  Any changes will not be permanent until
the *.RES file is saved using the SAVE *.RES FILE option.

4.3.2 Designating Which Text Description is Attached to a Platform:

On the EDIT PLATFORM menu there is an option to edit the text description
reference (for those platform types that support text descriptions).  After
selecting this option, the current text description will be displayed along with
the text description reference number.  There is an option to capture the text
description as explained above.  There is also an option to enter a new text
description reference.  Another option sets the text description reference to "No
Description Available".


4.3.3 Steps To Write a Text Description for a New Platform:

1.   Write the new description and save it as a text file.

2.   Copy the file to the DAT2 directory for facilities, or the RESOURCE
     directory for all others.)

3.   Choose EDIT TEXT DESCRIPTIONS from the PFEDIT main menu and select the
     appropriate platform type.

4.   Select the LOAD TEXT TO NEW ID option and enter the name of the text file. 
     The new reference number will be displayed.

5.   Save the *.RES file to disk.

6.   Return to the PFEDIT main menu, select EDIT H2 DATABASE, select platform
     type, choose EDIT, and enter the ID number for the new platform.

7.   Select the option to edit the text description reference and change the
     reference to the new reference number given in step 4 above.  Exit to the
     Edit Platform.dat menu and save the *.DAT file.


4.3.4 Setting Platform Picture Reference:

The picture attached to a platform can be changed similar to the way its text
description reference can be changed.  New pictures cannot be added to the *.RES
file.  It is recommended that you set picture references to either that for a
similar platform or the "No Picture Available" reference.



4.4 PLAYING SCENARIOS CREATED FROM A CUSTOM DATABASE

A Harpoon2 scenario file contains most of the data for the platforms used in that
scenario.  The database display for a specific unit in a scenario is also drawn
from this "internal" data.  The database display for a generic unit of the same
class, however, is drawn from the database.  It is desirable, and sometimes
necessary, to have the data in the scenario and that in the database match. 
These factors make it necessary to play a scenario using a database that is
identical (in data and ID number assignment) to the database used to create the
scenario.  To this end, PFEDIT includes options to create and receive Scenario
Database (SDB) files.  An SDB contains all the data for the platforms used in a
scenario.  This data can be loaded into the SDB directory and used for playing
the scenario.  This method allows you to play scenarios that were created with
custom platforms, without necessarily adding those custom platforms to your
Master Database.  These platforms can later be added to your MDB as you choose.

4.4.1 Creating an SDB:

Creating an SDB is a simple process.  Select Scan Scenario and Make SDB from the
PFEDIT main menu and enter the path and name of the scenario.  Scenarios must be
located in a subdirectory of the HARPOON2\BATTLSET directory.

     IMPORTANT NOTE: The currently selected database must be the one that was
     used to create the scenario.  Unpredictable results will occur if an SDB
     is created using a database different from the one used when creating the
     scenario.

PFEDIT will scan the scenario to determine the platforms used.  It will then
create an SDB file in the same directory as the scenario.  The SDB will have the
same name as the scenario and a .SDB extension.  This file will contain the data
for all platforms used or referenced in the scenario.  Any time the scenario is
given to another user, the SDB should also be transferred to allow the scenario
to be played.


4.4.2 Playing a Custom Scenario Using an SDB:

When you obtain a scenario that employs custom platforms you should also receive
an SDB.  The scenario and the SDB should be placed into a subdirectory of the
HARPOON2\BATTLSET directory.  Select the RECEIVE SDB option from the PFEDIT main
menu.  Enter the path and name of the SDB file.  PFEDIT will create a new
database in the SDB directory containing all the data used by the scenario.  The
platform ID numbers will match those used in the scenario file.  Before the
scenario can be played, the HARPOON2.INI file must be modified to point to the
SDB directory as the active database.  See section 2.2.4, The HARPOON2.INI File.

Malvinas Part II, a scenario created by Saul Jacobs, is included in the PFEDIT
package.  This scenario employs several new platforms and modifications to
existing platforms.  To play the scenario, copy the files ARK.SCN and ARK.SDB to
a directory under the HARPOON2\BATTLSET directory.  Use PFEDIT to recreate the
scenario database in the SDB directory.  Don't forget to point Harpoon2 to the
SDB directory by modifying the HARPOON2.INI file.


4.4.3 Some General Guidelines:

With the release of PFEDIT and/or 360's platform editor, our databases will be
undergoing continuous change.  No two users will have identical databases.  An
SDB essentially captures a snapshot of the database as it existed when the
scenario was created.  With this situation in mind the following recommendations
are made:

     1.   Whenever a scenario is created, immediately create a matching SDB
          for that scenario.  This should be done regardless whether you
          "think" you have used custom or new platforms.

     2.   Any time a scenario is to be modified, first recreate that
          scenario's database using its SDB.  Use this database while
          modifying the scenario (by pointing HARPOON2.INI to the SDB.)  After
          modifications are complete, recreate the scenario's SDB.

     3.   To modify platforms used in the scenario, recreate the scenario
          database using the SDB.  Use PFEDIT, TPFs, and the Scenario Editor
          rebuild unit/all functions as necessary.  Recreate the scenario SDB
          file.

     4.   Document the major modifications to platforms used in a scenario. 
          This can be done in a section of the scenario description or in a
          separate text file that is kept with the scenario and the SDB.

     5.   Keep the SDB and any documenting text files in the same directory
          with the scenario.  Always include them with the scenario and be
          sure to designate the scenario as one that employs a PFEDIT SDB.



4.5 TRANSFERRING PLATFORMS BETWEEN DATABASES (AND USERS)

PFEDIT provides a method to transfer individual platforms from one database to
another.  This method uses a file called a Transferrable Platform File (TPF). 
The TPF contains the data for the platform and all objects attached to the
platform.  By using an intermediate file for the transfer, this method can be
used to copy a platform between databases on the same computer (e.g. SDB to MDB),
or from user to user via disk or E-Mail.  A TPF can be created for any object in
the database from a fuel record or comm unit up to a ship or even an entire
installation.


4.5.1 Creating a TPF:

The Edit Platform.dat menu has an option T. Create TPF.  This option will prompt
you to enter an ID number, display the name of the object, and ask you to confirm
that this is the correct object.  You will then be prompted to enter a file name. 
Do not enter a file extension.  TPF will be appended as the file extension. 
PFEDIT will then create the file in the database directory.  This file will
contain the platform data, as well as the data for all objects attached to that
platform.


4.5.2 Receiving a TPF:

Place a copy of the TPF into the database directory which will incorporate the
platform.  From the PFEDIT main menu, change the database directory to the one
in which you will receive the TPF, and select RECEIVE TPF.  You will be prompted
for the TPF name.  Include the TPF extension.  PFEDIT will scan the database to
check whether each of the incoming objects already exists.  If an object already
exists in the database, PFEDIT will not duplicate it.  If an incoming object is
not already in the database, PFEDIT will assign it the next available ID number,
add it to the database, and change any references to that object to reflect the
new ID number.  A report will be written in the database directory that lists the
name and new ID number of each object added.  The report is a text file with the
same name as the TPF and the extension RPT.

Several sample TPFs have been included in the PFEDIT package.  It is suggested
you load these into your WDB and examine them to see how the TPF scheme works. 
You may find you want to keep these and load them into your MDB!  These 5 ship
and aircraft TPFs were created by Saul Jacobs while testing beta versions of
PFEDIT.



5.0 REGISTRATION

PFEDIT is a share-ware program.  As such, you have received the full,
unrestricted program with all functions and capabilities intact.  The
documentation you have received is a short outline explaining the function of
PFEDIT and is the minimum necessary to begin editing and creating platforms.

For a registration fee of $15 US, users will receive full documentation on the
use of PFEDIT.  This documentation provides a detailed description of the
possible inputs for platform data.  Platform capability codes are explained along
with their effects in the Harpoon2 game.  Methods are provided to calculate many
of the required numerical inputs.  Complete instructions for creating many
specific platform types are given.  The full documentation also covers editing
of the COUNTRY.DAT file, used by the Harpoon2 Scenario Editor to implement the
country and date restrictions on platforms.

Registered users will also receive any future patches and upgrades directly as
well as expanded documentation as available.  Future upgrades planned are an
improved interface and the ability to play all custom scenarios from one
permanent database.

To register send your name, mailing address, E-MAIL address, and a check or money
order for $15 US to:

     Tom Wenck
     6937 Fox Chase Rd
     New Market, MD 21774

All E-MAIL inquiries should be sent to Tom Wenck at twenck@clark.net.
