UFO for VPA

Author: (c) Peter Ratschitzky

---

IMPORTANT
==========
This program has nothing to do with the host add-on ‘UFO4DOS’. UFO4DOS has to be run by the host and gives UFO/minefield information to players who do not have a registered WinPlan copy.

UFO4VPA is a player utility and can’t do anything for those players.

****************************************************************************
YOU MUST HAVE A REGISTERED WINPLAN COPY !!!
****************************************************************************

This is not to encourage you to pay more money to Tim Wisseman. The reason is that UFO4VPA uses a special file that only players with a registered WinPlan copy will get from the host. This special file (‘KOREx.DAT’) is absolutely necessary because it holds all data concerning UFOs, ‘true’ minefields or 50+ targets.

This utility doesn’t support PHOST or other 3rd party host versions other than TimHost.

UFO4VPA now supports Host999 (it’s not tested – have fun 🙂
But you should mind that the actual officially supported version of VPA (v3.51e) does NOT support Host999. There are some newer versions of VPA floating around in the net. These versions are NOT officially supported by the author and have many bugs. Please keep in mind that these versions are NOT SUPPORTED by UFO4VPA.

VERY IMPORTANT
===============
You can alter the template definitions in ‘UFO4VPA.ADD’, ‘UFO4VPA.MSG’, ‘UFO4VPA.REM’ or ‘UFO4VPA.HAZ’. But do it at your own risk. Wrong entries can cause unexpected results and/or loss of important information. Don’t play around with entries concerning configuration, minefield or ion storm processing. You do not want to overlook this Robotic mega huge minefield, do you ?

UFO4VPA may even hang after playing around with sensitive template definitions.

If you really want to alter something you should read ‘TEMPLATE.DOC’ for more details.

 

T A B L E O F C O N T E N T S
========================
I. D i s c l a i m e r

II. H i s t o r y Updated!

III. I n t r o d u c t i o n

IV. F e a t u r e s

V. S y s t e m R e q u i r e m e n t s

VI. P a c k a g e

VII. I n s t a l l a t i o n

VIII. U s a g e

A. Quick start

1. Introduction
2. Normal mode
3. Enhanced mode

B. Command line parameters
IX. D e t a i l s

A. Host settings

B. 50+ target support

C. Minefield processing

1. Overview
2. Mine explosions Updated!
3. Exact values (I)
4. Minefield activity
5. Scan range & ion storms
6. Exact values (II)
7. Ship IDs
8. Sweeping enemy ships
9. Mine laying enemy/ally ships
10. Moving Mines/Webs
11. Alliances
12. Summary of command line switches

D. Removing of futile host messages

E. Ion storm processing

1. Overview
2. Ion forecast messages
3. Special ion advisory messages
4. Heavy ion storms & mine sweeping

F. Add-on message processing

G. UFO data processing

1. Overview
2. Asteroid moving bug
3. Summary of command line switches

H. Alliances

1. Auto-config
2. Explore Map

J. Fleet analysis

1. Overview
2. Accuracy
3. Alliances
4. Warp Signature Messages
5. Summary of command line switches

K. Score processing

1. Overview
2. Basic VGAP score
3. PTSCORE

L. Enhanced mode

1. Overview
2. Minefield processing
3. Ship processing
4. Planet processing
5. Marker processing
X. C o m m e n t s

XI. T h a n k s

 

I. Disclaimer of Warranties
=====================
The program is delivered to you as is. Although copyrighted, the programmer shall not be liable for any damage whatsoever arising out of your use of this program, either in it’s original form or any altered form, even if you have been advised of the possibility of such damages.

Although distributed freely, this is copyrighted material. You are hereby granted the rights to use the program for your personal use. You may (re)distribute this program, PROVIDED you distribute the complete set of all files and you distribute them without charging any money or any other form of compensation.

 

II. History – Updated!
=================
05/07/99 v1.00 beta 1st public release

05/18/99 v1.01 beta
– some minor bug fixes
– 50+ target support in fleet analysis
– static data files are now searched in game AND planets directory

05/20/99 v1.10 beta
– full 50+ target support
– multiple RST support

06/07/99 v1.11 beta
– some minor bug fixes
– added some templates

06/23/99 v1.12 beta
– UFO4VPA now recognizes when run for a second time in the same turn
– sequence of first two parameters has changed old sequence still supported

09/02/99 v1.20
– UFO4VPA leaves beta status !
– UFO4VPA now writes additional way-point messages for UFOs with WARP > 0
– UFO4VPA now writes special ‘Ion Advisory’ messages for ships in heavy ion storms
– Fleet analysis now supports engine tech level
– Fleet analysis now supports ‘Remote ID’ feature (Gryphon/Jupiter add-on)
– Fixed: too many mine sweep messages had been removed
– Fixed: Known hull percentages over 100%
– some minor changes & bug fixes

12/14/99 v1.30
– completely rewritten minefield analysis
– mine laying & seeping activities are now displayed for every minefield
– calculation of beam types for sweeping enemy ships
– calculation of correct heading for Asteroids (fix for ‘Asteroid moving bug’)
– change of PBPs is displayed (useful for blank score games)
– Fixed: ships influenced by two or more heavy ion storms caused corruption of message base
– some minor changes & bug fixes

02/08/00 v1.31
– UFO4VPA now writes score messages (basic & PTSCORE)
– stupid bug in fleet analysis FIXED
– more accurate mine/web decay calculation
– some minor changes & bug fixes

06/24/00 v1.35
– UFO4VPA now remembers all minefields out of scan range
– added background aging for all minefields out of scan range
– more detailed minefield messages
– more detailed information about enemy/ally mine laying activities
– calculation of possible torp types for mine laying enemy/ally ships
– UFO4VPA now tries to extract the engine type of enemy ships from VCRs if E-S bonus is enabled
– again, more accurate mine/web decay calculation 😉
– as usual: some minor changes & bug fixes

07/04/00 v1.35a – severe memory allocation bug FIXED

03/22/01 v2.00
– ENHANCED MODE introduced
– Host999 support (not tested)
– general objects supported
– UFO4VPA database format completely changed, ALL older turns are now saved & remembered
– enhanced minefield activity messages
– a lot of new add-on features supported
– VPA can now draw ‘real’ UFO objects with correct radius and direction (enhanced only)
– old minefields (out of scan range, covered by ion storms) are now displayed (enhanced only)
– VPA now displays minefield type always correctly (enhanced only)
– VPA can now display engine and armament type of enemy/ally ships (enhanced only)
– allied planetary data from EchoView supported (enhanced only)
– number of messages are now recognized correctly by VPA, VPA /M switch no longer necessary
– ion storm forecasts introduced
– energy vortexes partially supported
– EchoView compatibility mode introduced (necessary for mine explosions)
– quiet mode introduced
– Fixed: engine type calculated from from E-S bonus erased armament data
– Fixed: own web mines that were not scanned by ships caused corruption of message base
– this time: MANY minor changes & bug fixes

05/31/01 v2.10
– Fleet analysis now supports crew, damage and ammunition of starships
– ‘Warp Signature’ messages introduced
– ‘Moving mines/webs’ supported (Gryphon/Jupiter add-on)
– Fixed: some ion joining messages corrupted message base
– Fixed: only first general object treated correctly
– Fixed: old messages from missed turn(s) corrupted message base
– as usual: some minor changes & bug fixes

08/01/01 v2.15
– improved crew experience accuracy
– Fixed: ship names could interfere with VPA data base identification strings which caused enhanced mode to fail
– Fixed: allied minefields sometimes marked as old when completely swept – now allied mine field information is always 100% accurate
– as usual: some minor changes & bug fixes

06/28/02 v2.20
– improved ship name recognition routine (important for minefield activity messages)
– one-way alliances supported
– ‘FFx’ alliances supported
– ‘NTP’ is now treated correctly
– crew experience points are no longer deleted if a ship has been destroyed
– some performance tuning
– Fixed: web mines from ally caused error in second run of enhanced mode
– Fixed: allied dummy ‘KOREx.DAT’ files are no longer used
– as usual: some minor changes & bug fixes

07/18/02 v2.21
– Fixed: some ion storm joining messages corrupted message base
– some minor changes (better EV and PCC compatibility)

 

III. Introduction
============
The purpose of this program is to enhance the abilities of the player client VPA. Many good players use this client to make better and faster turns. But VPA has some disadvantages/bugs and therefore players have to use WinPlan and other 3rd party utilities (like ‘EchoView’) to get the information VPA can’t give them.

Well known disadvantages of VPA are:

– no UFO information
– unreliable minefield information
– no 50+ target support with WinPlan RSTs

UFO4VPA can fix these problems and, additionally, gives many other useful information that WinPlan can’t give you. WinPlan only users can use this program, too. But to get most out of the information you should use VPA instead.

UFO4VPA analyses many binary files that are extracted from your RST. It then rewrites your ‘MDATAx.DAT’ file. You can read these new messages with WinPlan or VPA but the real purpose is to provide this information to the VPA message parser. VPA will then draw many new markers on the map screen.

UFO4VPA will remember all enemy ships (hulls) you can see on the map. It will also extract engine type (if possible) and armament data of surviving enemy ships from the VCRs. This should give you an overview about enemy fleet/ship strength.

 

IV. Features
==========
UFO4VPA …

– writes a message for every UFO object which VPA can display on the map
– calculates corrected waypoints for Asteroids
– writes additional messages for UFO waypoints (non-enhanced)
– allows VPA to draw circles and waypoint vectors for UFOs on the map (enhanced only)
– analyses all minefield scan messages and the starchart minefield data
– remembers and ages all minefields that are out of scan range
– remembers and ages all minefields that are covered by ion storms
– deletes needless minefield scan messages
– analyses mine explosion messages
– rewrites a corrected minefield message for every minefield (‘true’ minefields)
– writes additional minefield messages including all mine laying and sweeping activities
– helps you to find out the beam type of sweeping enemy ships
– helps you to find out the torp type of mine laying enemy/ally ships
– allows VPA to display minefields out of scan range or covered by ion storms with the correct (aged) size (enhanced only)
– writes ‘Warp Signature’ messages for enemy ships destroyed by mine hits and allows VPA to draw tracers on the map (enhanced only)
– supports ‘moving mines/webs’ (Gryphon/Jupiter add-on) and allows VPA to draw tracers on the map (enhanced only)
– writes messages for ion storms which normally can’t be seen in VPA and allows VPA to display them (‘true’ ion storms)
– writes ion storm forecast messages
– writes additional messages for joining ion storms
– allows VPA to display ion storm forecast information on the map (enhanced only)
– writes very detailed ‘Ion Advisory’ messages for ships threatened by ion storms
– writes special ‘Ion Advisory’ messages for alternative waypoints in heavy ion storms
– rewrites third party add-on messages so that VPA can paint a marker on the map
– deletes futile host messages (terraforming, fighter building, …)
– analyses and remembers all scanned enemy/ally ships
– analyses distress messages and VCR data
– writes enemy fleet/ship messages
– allows VPA to display remembered crew, damage, engine tech and armament information on the screen (enhanced only)
– writes score messages (basic & PTSCORE) for you and your allies
– writes ‘TARGETx.EXT’ file and allows VPA to support more than 50 targets
– imports allied planetary data from messages generated by EchoView (enhanced only)
– analyses data from allied RSTs
– supports and merges allied maps (generated by Explore Map) and allows any client to display all planets examined by your allies
– supports Host999

 

V. System Requirements
====================
– 386 (286 with co-proc) processor or higher (program is SLOW, Pentium system recommended)
– some (*) hard disk space (lazy write cache recommended)
– MS-DOS compatible system (program works with OS/2)
– REGISTERED WinPlan copy
– VPA 3.51e (to get out most of this program)

(*) NEW in v2.xx: The new database holds information from ALL previous turns. But that means that hard disk space consumption increases with every new turn. You can calculate with 40 kBytes for a single turn. This would result in 4 MBytes for a game with 100 turns. Shouldn’t be a too big problem. But if you are playing in lots of games with hundreds of turns you might get into trouble, especially if you have an older system with low capacity hard drives.

 

VI. Package
==========
contains the following files:

readme.1st – introduction
ufo4vpa.doc – documentation (which you are reading at the moment)
template.doc – documentation of message template definitions
database.doc – documentation of the database structures
ufo4vpa.exe – the executable
ufo4vpa.haz – templates for fleet analysis
ufo4vpa.msg – templates for configuration and add-on message parsing
ufo4vpa.rem – templates for minefield & ion storm parsing and
for removing of ‘needless’ messages
ufo4vpa.add – additional templates and definitions
vpa.msg – altered templates for VPA

 

VII. Installation
============
– Move the following files into your main planets directory:

ufo4vpa.add
ufo4vpa.exe
ufo4vpa.haz
ufo4vpa.msg
ufo4vpa.rem

Be sure that all these files are from the same UFO4VPA package.

– Replace the old vpa.msg file by the new one included in this package (save the old one before !).
Again, use the file from the same package. Otherwise you may loose important information when using VPA.
Be careful when using own modifications to the original vpa.msg file.

 

VIII. Usage
=========
A. Quick start
————–

1. Introduction:

You can run UFO4VPA in two different modes: the normal mode and the enhanced mode. The normal mode is the mode you are already familiar with if you have used versions of UFO4VPA prior to v2.00. This mode can also be useful for WinPlan only users.

With v2.00 the enhanced mode has been introduced. This mode is only useful
if you are using VPA v3.51e (and only THIS version), it doesn’t work for WinPlan only users.
1. Normal mode (enhanced mode disabled):

– Unpack your new turn with WinPlan.

– DO NOT execute VPA !!!

– Switch to your main planets directory and run:

ufo4vpa <race number> <game directory>

– Run WinPlan or VPA to make the turn.
Example: ufo4vpa 6 vpwork4
vpa 6 vpwork4
Important: You have to execute UFO4VPA only once per turn. You should do that immediately after unpacking a new turn and BEFORE running VPA.
You CAN run UFO4VPA every time before you run VPA. That’s for players who are using simplified batch files. UFO4VPA decides for itself whether it has to do anything or not. But that’s not true for versions prior to 1.12 beta. With versions prior to 1.12 beta you MUST NOT run UFO4VPA twice in a particular turn. Otherwise your message data could be corrupted.
2. Enhanced mode:

– Unpack your new turn with WinPlan.

– DO NOT execute VPA !!!

– Switch to your main planets directory and run this batch:

ufo4vpa <race number> <game directory> /E
vpa <race number> <game directory> /B
ufo4vpa <race number> <game directory>

– Run VPA to make the turn.
Batch file example: @echo off
ufo4vpa 6 vpwork4 /E
vpa 6 vpwork4 /B
ufo4vpa 6 vpwork4
vpa 6 vpwork4
You can use this batch for a single turn as often as you want. No further user input is necessary. That’s because UFO4VPA decides for itself what to do and whether it has to do anything at all or not. And executing VPA with the /B switch repeatedly is just a little bit overhead. But of course, after executing this batch for the first time the only necessary line is the last one when VPA is run to make/continue your turn.

If you are not familiar with batch files you can just copy the 5 lines from the example above and paste it into a new file. The file could be named to something like ‘UFO.BAT’. Important is the file name extension ‘BAT’. Of course you have to adjust race number and working directory. Then, if you want to run VPA, you just have to execute ‘UFO.BAT’.
B. Command line parameters
————————–

Usage: ufo4vpa <race number> <game directory>
[/MD:<mine decay rate>] [/WD:<web decay rate>]
[/MS:<mine sweep rate>] [/WS:<web sweep rate>]
[/SR:<mine scan range>] [/ES:<engine shield bonus>]
[/MDW] [-FCB] [-SHM] [-GRW]
[-m] [-b] [-t] [-e] [/k] [/K] [+V]
[-I] [-i] [-r] [-U] [-u] [-c] [-p]
[/F] [-F] [-f] [-S] [-s] [-w]
[/E] [/W] [/O] [-M] [-a] [/q]
<race number> 1, 2, …, 9, 10, 11
<game directory> where your RST file is unpacked

/MD:<mine decay rate> mine decay rate in percent
/WD:<web decay rate> web decay rate in percent
/MS:<mine sweep rate> mine sweep rate in units
/WS:<web sweep rate> web sweep rate in units
/SR:<mine scan range> mine scan range in LYs
/ES:<engine shield bonus> Engine Shield Bonus in percent
/MDW enable ‘Mines destroy webs’
-FCB disable Fed Crew Bonus
(and has nothing to with FC Bayern Muenchen 🙂
-SHM disable ‘Ion Storms hide mines’
-GRW disable Gravity Wells

-m no minefield activity messages
-b no calculation of possible beam types
-t no calculation of possible torp types
-e EchoView compatibility mode
(EchoView compatibility mode)
/k keep lay/sweep/scoop messages (minefield action)
/K keep ALL minefield messages (for hard-liners only)
+V correct mine units for VPA

-I don’t write ion forecast messages
-i don’t write special ion storm messages
-r don’t rewrite add-on messages
-U don’t write UFO messages
-u don’t write UFO waypoint messages
-c don’t correct UFO waypoints
-p don’t write score messages

/F fleet analysis only (-M -i -r -U -a)
-F disable fleet analysis
-f no fleet messages
-S neither enemy nor allied ship messages
-s no allied ship messages
-w don’t write Warp Signature messages

/E enable Enhanced mode (read documentation carefully !)
/W enable WinPlan mode (-e /K -r -U -a, for masochists)
/O don’t use allied RSTs (-A is also possible)
-M disable message analysis (and do not remove anything)
-a don’t change VPACLRx.INI
/q enable quiet mode
Examples: ufo4vpa 6 vpwork4 /M:5 /W:4
ufo4vpa 11 vpwork5 /E /q
ufo4vpa 2 vpwork1 /F -s
ufo4vpa 4 vpwork2 /W /F
***************************************************************************
***************** NEW (v2.00) ****************
***************************************************************************

V2.xx support a quiet mode. Use the /q switch and UFO4VPA won’t write detailed information on the screen.

The -V switch is no longer supported because it’s default now. Use the +V switch the emulate behaviour of versions prior to v2.00. Read the exact values (I) section for further details.

The -e switch has been introduced to allow full compatibility with EchoView. Read the mine explosion section for further details.
***************************************************************************
***************** NEW (v1.35) – For WinPlan users ! ****************
***************************************************************************

A new switch had been introduced, the /W switch. This switch is meant for WinPlan users who do NOT use VPA (which is a really silly decision).

When using this switch UFO4VPA …

– is fully compatible with EchoView (-e)
– keeps all minefield messages (/K)
– does not rewrite any add-on messages (-r)
– does not write any UFO messages (-U)
– does not change VPACLRx.INI (-a)

Of course, you can always set these switches manually at the command line.

 

IX. DETAILS
===========
A. Host settings
—————-

Most important for UFO4VPA to run properly are 10 host settings: decay rates and sweep rates for d.s. and web mines, the mine scan range (one value for both minefield types), the percentage of the engine shield bonus (if enabled) and 4 switches. The first one specifies whether the feature ‘mines destroy webs’ is enabled. The second one does the same for the Fed crew bonus, the third one for ‘Ion Storms hide mines’ and the last one determines whether gravity wells are enabled or not.

If you give the wrong information to UFO4VPA it can’t calculate the expected number of mine units and will give you wrong information about the IDs of mine laying and sweeping ships. And you will get wrong information about the engine types of enemy ships that have survived a battle.

Many hosts will send you information about these settings as configuration messages every turn. UFO4VPA will analyze these messages and extract 6 values and 4 switches. They are then saved to disk (‘UFO4VPA.SAV’). UFO4VPA remembers this information for the whole game.

But some hosts send config information only with the first turn. When running UFO4VPA for the first time and it is not turn 1 you are playing and your host doesn’t give you the config information, these settings will be set to default values. You should then force the host to provide config information with the planet FC ‘con’.

There could be situations (maybe) where UFO4VPA can’t extract the right information. Then you have the possibility to provide this information manually with the /MD:, /WD:, /MS:, /WS:, /SR:, /ES:, /MDW, -FCB, -SHM and -GRW switches. This information isn’t saved to disk. You have to use the switches every time you run the program. Additionally, the switches will override the information stored in ‘UFO4VPA.SAV’ and in the config messages.

Examples: /MD:3 mine decay rate at 3 percent
/WD:6 web mine decay rate at 6 percent
/MD:100 impossible, negative numbers and percentages over 90 for decay rates will be ignored
/WS:2 web sweep rate of 2 units per TeraWatt (good for the X-tals)
/MS:0 impossible, you must have a chance to sweep mines
/SR:150 you must be in a range of 150 LYs from the edge of a minefield in order to scan it
/ES:40 enables E-S bonus and sets percentage to 40
/ES:0 disables E-S bonus (default)
/MDW no value, if used the feature is enabled
-FCB no value, disables Fed crew bonus
-SHM no value, disables ‘Ion Storms hide mines’
-GRW no value, disables Gravity Wells

I have to say that normally these values are set to default in most games. The ‘mines destroy webs’ thing is disabled in most games, Fed crew bonus, ‘Ion Storms hide mines’ and Gravity Wells are normally enabled. The E-S bonus is also disabled in many games. The host has two switches to configure the E-S bonus, one on/off switch and one setting for the value. UFO4VPA knows only one setting. If it is set to zero the feature is turned off.

If you do not have the config information and do not use the switches the default settings are assumed and used. If you are absolutely sure your host uses these default settings you can forget all these switches.

When you start UFO4VPA it will display a short copyright message. If the quiet mode isn’t used turn number, the race you are playing and all other races where unpacked RST data is available are displayed. If an allied RST is from a player who does not have a registered WinPlan copy you will be also informed that this RST can’t provide full information (‘partially used’). You will also see whether the enhanced mode is enabled or not and, if enabled, whether the first or second run is executed.

If quiet mode is disabled and at least one needed config value couldn’t be extracted from the host messages or at least one config value had been changed with a command line parameter all settings needed by UFO4VPA are displayed. These are the values for mine/web decay, mine/web sweep rates, the values for the scan range and the E-S bonus and the settings for ‘mines destroy webs’, Fed crew bonus, ‘Ion Storms hide mines’ and Gravity Wells. Also displayed are the sources the information comes from.

This can be:

(saved) from config message and then saved to disk
(restored) restored from disk (no config message found)
(default) no config message found and program started for the first time
(overridden) command line parameter (switch) used

To say it again (new in v2.10) if all settings could be extracted from host messages and no setting had been overridden (status ‘saved’) this information won’t be displayed (because it’s the normal case).
B. 50+ target support
———————

Without special tools VPA can’t display more than 50 enemy targets with full information on the map. These are the famous ‘unknown hull’ ships. The reason is that DosPlan can only handle 50 targets and VPA behaves like a DOS client. WinPlan stores additional targets in ‘KOREx.DAT’ which VPA doesn’t analyze.
But UFO4VPA analyses this file and looks for additional targets. If found any, it writes a special file (‘TARGETx.EXT’). This file is normally written by ‘VPUNPACK’ in combination with PHost RSTs. But VPA doesn’t care whether a RST is from TimHost or Phost and uses the file to display more than 50 enemy targets.
If there are additional RSTs available (from players who have a registered WinPlan copy) a ‘TARGETx.EXT’ file is created for every corresponding race.

If you are using UFO4VPA for all your turns (I hope so) then you won’t get any trouble with ‘TARGETx.EXT’. Old files are always deleted. But if you make a turn without using UFO4VPA (don’t know why) it is possible that you will see ‘ghost targets’. The reason is that an old ‘TARGETx.EXT’ file is still in your game directory. The WinPlan unpack routine doesn’t delete this file because it is not part of the RST.
C. Minefield processing
———————–

1. Overview:

A major disadvantage of VPA is the fact that it can’t analyze the starchart data of WinPlan stored in ‘KOREx.DAT’. This file holds the TRUE minefield data. Additionally, VPA doesn’t take care about the minefield decay which occurs AFTER mine laying and sweeping and NOT before.

VPA relies completely on message parsing. But if an enemy ship with a high ID sweeps your minefield VPA will get a wrong information. That means, when using VPA only, you do not know whether your minefields had been swept, whether enemy minefields had been swept or scooped and you will see the fields before mine decay. The result could be that you rely on own minefields that had been already swept by an enemy. And, hunting for enemy minefields that do not exist doesn’t make sense either.

UFO4VPA analyses both the information given in the messages AND the information included in the file ‘KOREx.DAT’. This file is responsible for the starchart information of WinPlan. Then a comparison between message data and starchart data is made. You may ask, why? The reason is that the starchart data can’t give you all information about minefields. For example as a Colonial player you do not see minefields that are covered by an ion storm. Yes, you can sweep them (with fighters) and you will get a message but you can’t see them with WinPlan (no circle drawn). And, additionally, you get no information whether a minefield had been swept or scooped by high ID ships. UFO4VPA gives you as much information as possible.

This additional information can be:

– minefield is covered/hidden by an ion storm
– minefield has become out of scan range
– minefield (own or enemy) had been laid/increased, swept/scooped or a mine explosion occurred
– possible IDs for sweeping enemy ships
– possible beam types for sweeping enemy ships
– possible tube types of mine laying enemy ships
– minefield had been completely swept/scooped (‘swept field’)
– minefield information comes from ally (no original message from TimHost)
– minefield is d.s. (= normal) or web (which is not included in original TimHost message)
– exact amount of remaining mine units is available or not
– probable minefield radius predicted for the next turn

Another disadvantage of VPA are these absolutely useless minefield messages that come from every mine sweeping ship. It’s not unusual for a long lasting game to get 250+ mine scan messages. Okay, you WANT see all the minefields but there is no reason to see them twice, five times or even ten times. When using UFO4VPA you will get rid of those annoying messages (like PHost). UFO4VPA writes ONE scan message for every field and deletes the original host messages. If you are using the /k switch you will keep the host messages dealing with mine laying, sweeping or scooping (minefield action). You will always keep host messages dealing with minefield action if the ship ID isn’t known for sure (see ID section). Then you have a chance to find out the ship ID for yourself. These messages are also kept if you have disabled minefield activity messages with the -m switch.

Host messages with scan information only are always removed. But you can disable even this feature with the /K switch at the command line. This switch is meant for hardliners who do not trust any program and who want to find out all enemy activity for themselves. I have to say that the minefield activity analysis of UFO4VPA works very well if you are using unique names for your ships (see later) and in my opinion there is normally no need to read hundreds of scan messages. But some people asked for that switch.

UFO4VPA (v1.35 and higher) tries to predict the probable minefield radius for the next turn. This can be an important information for players who want to send their ships to the edge of an enemy minefield in order to get a good and safe sweeping position. This is most important for sweeping web mines. The calculation is based on the mine/web decay rate. If the exact amount of mine units is unknown there are probably 2 possible values for the radius displayed.
Of course, this prediction only works if the minefield isn’t increased (units laid by enemy) or decreased (swept/scooped by enemy/ally, mine explosion(s)) in the next turn.

If you are using the enhanced mode (v2.xx) VPA will display ALL minefields where information is available – information from the actual turn and from previous turns. Now minefields covered by ion storms and minefields beyond scan range (if scanned in previous turns) can be seen. And of course with accurate decay calculation.
2. A word about mine explosions: Updated!

TimHost will send you only ONE message when two minefields are overlapping and exploding. UFO4VPA will kill this message and write two new messages instead. One message for each minefield. The problem is that only one minefield ID is included in that original message.
UFO4VPA (v1.30 and higher) tries to find out the second minefield ID. This is not always possible. Minefields that are out of scan range can’t be recognized.

Newer versions of EchoView can display these mine explosions, too. But this doesn’t work if the original explosion message has been split by UFO4VPA. If you rely more on EchoView than on UFO4VPA (shame on you!) then you can disable splitting explosion messages with the -e switch at the command line.

New in v2.21: the -e swicht also disables writing of PBP changes in the last message (PBP message).
3. A word about exact values (I):

Because of a rounding bug in VPA all values of mine units a rounded up by UFO4VPA to the square of the real mine radius. VPA calculates the radius (which is the most important information) from the number of mine units. But it uses the formula

radius = trunc(sqrt(mine units))

for its calculation. TimHost uses

radius = round(sqrt(mine units)).

Mine unit values that are above the square of the radius are not affected. With versions prior to v2.00 the amount of units had been rounded up by UFO4VPA in order to achieve the presentation of a correct value for the minefield radius. An additional line in the minefield message has been written where the exact value for the mine units was displayed. But this rounding bug only affects the value of the radius displayed when clicking on the minefield center. It does not affect the radius of the minefield circle drawn on the map which is the real important thing. V2.xx do no longer support the -V switch. This switch is default now.
You will see now the correct amount of mine units and possibly the wrong value for the radius displayed by VPA.
If you really want to see the accurate value of the radius displayed by VPA (default behavior for versions prior to v2.00) you can use the +V switch at the command line.
If you are using the /E switch (enhanced mode) together with the +V switch UFO4VPA adjusts the amount of mine units by accessing the VPA database directly. With the /E switch it is no longer necessary to ‘fool’ VPA by presenting an adjusted value for the amount of units in the minefield message. Therefore, you won’t see the additional line with the ‘exact value’ thing.

Minefields where information comes from allies, your own minefields that are not scanned by your own ships and minefields that had been swept/scooped by enemies after your last scan with your highest ID ship have always ‘sqr(radius)’ mine units because there is only the starchart data available (there is no information about mine units). The same is true for minefields that have exploded and no ID is available from the explosion message (see above). An additional line is displayed that tells you that the exact amount of mine units is unknown.

For Colonial players only: if you are scanning or sweeping a minefield that is covered by an ion storm you will get the maximum number of mine units. There’s no way to find out whether this minefield had been swept or scooped by other players with high ID ships (ships that have a higher ID than your last scanning ship). And again the same thing with unattended mine explosions. The reason is you do not get any starchart information about those minefields (bug or feature ?). For the same reason you do not get information about the mine style. UFO4VPA tries to remember the mine style from previous turns but if there is no such information available UFO4VPA assumes that a hidden field is a web minefield if the owner is the Crystal and a deep space minefield if laid by all other races.

There is a hint in the message that this information is not reliable. Scanning/sweeping hidden minefields with fighters is the only situation where you don’t have ‘real’ minefield information.
4. Minefield activity:

UFO4VPA (v1.30 and newer) writes additional messages when a minefield has
changed in size. Of course, I do not mean mine decay. This thing is ignored
(not really ignored but not displayed). You will get information about your
own and enemy/ally mine sweeping/laying activities. Additionally, the IDs of
the responsible ships are displayed (if possible).

If something happened to an existing minefield or a new minefield has
appeared, UFO4VPA writes a second message after the ‘normal’ one. This second
message includes all activities for that minefield in the order of events
processed by the host. That means, first comes mine laying and then sweeping.
Last come mine explosions. Some add-ons are also supported. Most of them
are using auxhost1 for minefield actions and that means that these actions
(laying AND sweeping) happen before mine laying activities supported by the
host.
If your own ships are responsible for a particular activity the ID for that
ship is displayed and then the number of mine units that had been swept,
scooped or laid.
With v2.xx UFO4VPA draws a distinction between real minefield actions and
just changes of size. If UFO4VPA can assume that the change of size comes
from actions performed in the actual turn and there are scan messages
available it will display ‘laid’, ‘swept’ or ‘scooped’. If this is not the
case (unattended actions in previous turns or allied minefields out of scan
range) UFO4VPA will display ‘gained’ for size increase and ‘lost’ for
decrease.
If an enemy or allied ship performed this action, you won’t get the exact ID.
But UFO4VPA tries to find out the range of possible IDs. This information
is dependent of the number of ships with mission ‘sweep’. The more sweeping
ships you have the better is the chance to scan an enemy activity. You can
increase this chance when scanning with freighters. Of course, these ships
can’t sweep mines but they can scan the actual number of mine units.

V2.xx rely on a completely different database format. Minefield data from
previous turns (even if 10 or more turns ago) is remembered as well (and not
only 2 turns back as with versions prior to v2.00).
2 turns in raw are no longer a condition for displaying minefield activity
messages. If the last turn is not available UFO4VPA searches for the newest
(of course not the actual) turn that is stored in the database. If found
UFO4VPA uses this turn for calculating the minefield activity. UFO4VPA will
display the possible turn numbers for this unattended minefield activity
instead of ID numbers.

Example: actual turn: 20
previous turn: 17 (which means you missed 2 turns)

Output for 2000 units increase: ‘Turn>17 : 2000 units gained’

The same is true if you were out of scan range (or field was covered by ion
storm) for several turns. The output in the above example could also mean
that the field had been out of scan range for two turns.
IMPORTANT
=========
If you are running v2.xx for the first time you will get an activity message
for every minefield you are able to scan (own/allied and enemy). You will
then see in the first line something like ‘Turn=??? : xxxx units gained’.
This is not a bug, this is just because UFO4VPA has to initiate the minefield
entries in the database. And as I said at the beginning of this documentation
UFO4VPA can not withdraw minefield information from the database used by
versions prior to v2.00.
If you MUST rely on this information stored in the old database you should
not use v2.xx for this game.

Minefield activity messages can be disabled with the -m switch at the command
line.
5. Scan range & ion storms:

You laid a minefield and the next turn it is gone?
You laid a minefield and it never appeared on the map?

Not with UFO4VPA. You will get messages for EVERY minefield you own(ed) or
your ally owns/owned. The same is true for enemy minefields that are in scan
range. Minefields do not just disappear any longer – you will get a message
that the minefield had been completely swept, even if you didn’t have a chance
to scan it (swept by low ID enemy ship). VPA recognizes these messages as
swept minefields. You know what happened and you know who is responsible for
that.

With v2.00 enemy minefields that are out of scan range or covered by ion
storms are now FULLY supported and displayed (enhanced mode only).

UFO4VPA remembers these minefields and performs a decay every turn (aging).
If you come in scan range again (or ion storm has moved away) you should
not get any ‘new laid field’ messages which has been the case with versions
prior to v1.31.
Of course, whilst you are out of scan range, you don’t have information about
mine laying or sweeping activities performed by other races. When such a
minefield comes in scan range again you will get information that the field
has changed in size. But you won’t get exact information WHEN this change
has happened. An example:

Turn 30: you scan the enemy minefield
Turn 31: minefield is out of range, the enemy scoops some units
Turn 32: you are in scan range again

You will see how many units (approximately) had been swept/scooped and you
will get information about the period. In this case: Turn>30
This means there had been some sweeping/scooping activity during turn 31
and/or turn 32.

You should keep in mind that there is no detailed information about particular
minefield actions available. In the above example it could be possible that
your enemy laid some units in turn 31 and scooped a bit more units one turn
later.

Another thing you should consider: UFO4VPA ‘ages’ minefields that are out
of scan range. VPA doesn’t! And minefields covered by ion storms are not
displayed at all.
If you are using the /E switch UFO4VPA writes additional messages for ‘old’
minefields. ‘Old’ minefields are either minefields out of scan range or
minefields covered by ion storms (not for the Colonial). You will see when
you have scanned the field for the last time (‘xx turns ago’) and what the
reason for the ‘old’ status is (‘out of scan range’ or ‘hidden in ion
storm’).
With these messages VPA can draw minefield circles on the map. That means
minefields covered by ion storms are now visible!
Note, minefields out of scan range or hidden in ion storms are displayed
with their ACTUAL (estimated) size. If you do not use the /E switch mine-
fields out of scan range are displayed with the size that came from the last
scan (not ‘aged’).

The /E switch (enhanced mode) is necessary because UFO4VPA has to access
the VPA database directly to ‘tell’ VPA that these minefields are not
minefields scanned in the actual turn (the ‘xx turns ago’ thing).

The decision whether a minefield is in scan range or not is dependent of
the positions of sweeping ships before movement. It is possible that an
enemy minefield is recognized as a swept (scooped) field because the
position(s) of the scanning ship(s) is/are calculated wrong. The reason
for that can be an energy vortex that throws your scanning ship(s) into
deep space to a random position. Energy vortexes are only partially
supported. With v2.00 ships affected by Energy Vortexes get a ‘penalty’
value for its mine scan range in order to prevent UFO4VPA assuming that
a minefield out of scan range had been swept (see ion storm section for
further details).
But there are other possibilities for wrong positions if some add-ons are
used. There will be ‘penalties’ for ships using special add-on features
in a future release.
6. A word about exact values (II):

UFO4VPA tries to find out the exact value of swept or laid mine units. That
is not always possible. You won’t get exact values if an enemy ship swept
your field and you did not have a ship with a higher ID and mission ‘sweep’.
In that case (unattended sweeping activity) UFO4VPA uses the radius of the
field that is stored in the starchart data. But the radius can’t provide
exact values for the mine units.
The same is true for minefields you didn’t scan. If a new minefield appears
and this information is from one of your allies and none of your sweeping
ships are in scan range, you will get only information about the mine radius
which is displayed as the amount of units calculated from radius.
Third possibility: own minefields and no sweeping ships are in scan range.
You will always see your own minefields regardless whether you are scanning
them or not. Again, this information comes from the starchart data and no
exact values are available.
You will be informed if only starchart data is available. An additional
line is displayed that tells you that the exact amount of mine units is
unknown.

A special thing for mine explosions. Mine explosions happen AFTER mine
decay. That means, if you have laid a minefield with 1000 units and this
minefield had been completely destroyed by another overlapping enemy mine-
field, you will see the following line: Explosion: 950 units destroyed.
That’s of course for a decay of 5 percent. Don’t be confused, that’s not
a bug.
7. A word about ship IDs:

Unfortunately, the host messages do not include the ID of the ship that
performed the mine sweeping/laying action. Only the name of the ship is
provided. This makes things a little difficult. UFO4VPA uses two methods
to find out the corresponding ship ID:

First, UFO4VPA tries to attach the ship names to ship IDs. But that’s only
possible if the ships have their own unique names. Many players do not assign
special names to their newly built ships and that makes it impossible for
UFO4VPA to use ship names. I can only say that the players are responsible for
themselves to give their ships a more or less funny name. Even numbers should
do the job. Not too hard in my opinion.

****************************** Updated in v2.20 ******************************

With this version a new ship name recognition routine has been introduced.
If two or more ships have the same names only these ships are excluded from
ship name recognition. Or, in other words, if two or more ships have the same
names this doesn’t affect the ship name recognition of all other ships with
unique names. The mission of the ships is no longer important. If two ships
have the same name but different missions they are still excluded from name
recognition. That’s because of ships with erased missions (e.g. out of fuel).

Also new in this version is that names of destroyed ships are analyzed as
well. No longer these annoying question marks in minefield activity messages
after lots of battles or deadly mine hits.

******************************************************************************

There are some add-ons that require special ship names in order to perform
a special mission (ion control, moving (web) mines, …). These special ship
names often are attached to objects in the game (ion storms, minefields) and
cumulative actions referring to the same object require the same ship name.
Of course in this case this first method has to fail for the related ships.

If the first method fails UFO4VPA gives you a second chance:
UFO4VPA tries to attach the ships with mission ‘sweep’ or ‘lay’ to the
messages that come from the host. But very often this must fail because
ship missions can be erased if a ship runs out of fuel. It is not
guaranteed that a ship that performed a mine action successfully (and,
therefore, caused the host to write a message), will still have its
mission set after host run. Ships that performed mine actions can also be
destroyed in battle and the information about the ship mission is lost.
On the other hand, a ship that has mission ‘lay mines’ but does not have
any torps just doesn’t do anything and no message is written by the host.
But UFO4VPA assumes that this ship has laid some mines.
UFO4VPA checks whether the number of mine laying/sweeping ships is
matching the number of messages dealing with mine laying/sweeping and
if not, all information about ship IDs is dropped.
I have to say that there are possibilities where number of ships and
messages are matching but the information is still wrong. That’s the
case if one ship performs a mine action successfully and the mission is
lost (e.g. out of fuel) and another ship has a valid mission but didn’t
do anything (e.g. no torps in cargo space). There’s no solution for that.

If both methods failed the ID of the ship can’t be extracted. Then you will
see a ‘???’ instead of the ship ID.

IDs calculated from ship names have priority over IDs calculated with the
second method. Original host messages dealing with minefield action (lay,
sweep, scoop) are only removed if the ship ID is determined for sure by
ship names. This will guarantee that you have always a chance to find out
the ID of a ship that performed an important mission.
8. A word about sweeping enemy ships:

If your minefield has been swept by one or more enemy ships, UFO4VPA tries to
find out the beam type(s) of these ships. Of course, that’s only possible
if your minefield isn’t completely swept and you have a sweeping (scanning)
ship with a higher ID than the IDs of the sweeping enemy ships.
Additionally, the exact amount of mine units must be known from the previous
turn or from a lower ID scan in the actual turn. Only then it is guaranteed
that the exact amount of swept units is available. There is only support for
two different types of sweeping beams. That means if your field has been swept
by three or more ships with three or more different types of beams, you won’t
get this information. There are just too many combinations of beam types.
You should keep in mind that this information is only a suggestion. You
should NEVER completely rely on that information.
UFO4VPA first calculates possible solutions with one beam type only and then
solutions with combinations of two beam types. Solutions with one beam type
have priority over solutions with two beam types. The maximum number of
beams for a solution is 75. And only 50 possible solutions are allowed. If
the number of 50 possible solutions is exceeded or if there couldn’t be
found a solution with less than 75 beams, the calculation is cancelled.
UFO4VPA will then write a line that shows the beampower of the sweeping
enemy ships instead of presenting the possible solutions for the beam types.
The beampower is measured in TW = TeraWatts (Tim Wisseman: TetraWatts).
A beampower of 1 TW can sweep 4 d.s. (= normal) mines or 3 web mines
(default settings). 1 Laser has a beampower of 1 TW, 1 Heavy Phaser has
a beampower of 100 TW. This is for minesweeping only, it has nothing to do
with the energy that can damage hulls or kill crew.
If there are solutions found and the limits are not exceeded, the solutions
with one beam type are presented first (if any). Next come solutions with
two different beam types. But because of space limitations, not all
solutions for two beam types can be displayed. There is a rule that de-
termines which combinations have priority. Every beam type has a ‘weight’,
which is of course not the weight in KT. Beams that are used in ships very
often have a weight of 1. Rarely used beams have a higher weight. Look:

Weight of 1: Lasers, X-Rays, Disruptors, H. Blasters
Weight of 2: Blasters, H. Disruptors, H. Phasers
Weight of 3: Positrons, Phasers
Weight of 4: Plasmas

These settings are ok for me. Feel free to contact me if you have made
other experiences.

This weight is multiplied by the number of beams. Example:

Solution 1: 5xHP+10xD : combined beampower of 860 TW
5 H. Phasers & 10 Disruptors : 5 x 2 + 10 x 1 = 20

Solution 2: 17xHB+3xPB : combined beampower of 860 TW
17 H. Blasters & 3 Plasma Bolts : 17 x 1 + 3 x 4 = 29

Both solutions are matching the beampower of 860 TW, the power that can
destroy 3440 d.s. mines or 2580 web mines (default).
In this case solution 1 has priority over solution 2, because it is assumed
that the probability for enemy ships with 5 H. Phasers and 10 Disruptors
is higher than for enemy ships with 17 H. Blasters and 3 Plasmas.
Normally, solutions with less beams have a better chance to be displayed
than solutions with more beams. But it also depends on the beam types.

The more sweeping (scanning) ships you have the better is the chance to get
a solution for a single sweeping enemy ship. And the more sweeping ships
you have the smaller is the range of possible IDs for that enemy ship.
If you have enough sweeping ships you often have a good chance to find out
the armament (beamtype) of an enemy ship.

You can disable the calculation of possible beams with the -b switch at the
command line.
9. A word about mine laying enemy/ally ships:

If a new minefield is laid by your enemy/ally or an existing enemy/ally
minefield has gained mine units UFO4VPA tries to find out the torpedo type
of the mine laying ship(s).

But as usual, there are some restrictions:

Information about an existing minefield has to be up to date which means that
the knowledge about the amount of units has to come from a scan in the
previous turn. Existing minefields that had been out of range in the previous
turn(s) do not fulfill this condition. And, additionally, the last scan in the
previous turn as well as the first scan in the actual turn have to be real
scans. Information about the radius from the starchart data is not sufficient.

New minefields have to be new minefields for sure. UFO4VPA is testing that
by looking at the ship positions two turns ago and the ship missions set to
‘sweep’ one turn ago. If all ships with mission ‘sweep’ were not able to scan
the field in the previous turn it is assumed that it is a new field. In this
case scanning means scanning the center of the field – not the edge. The
center of the field must not be covered by an ion storm in the last turn if
you are not the Colonial. Only then you can make sure that it is really a new
field and not an updated field.
That means that many new minefields will be treated as updated minefields with
unknown size in the previous turn. I think it is more important to provide
reliable information. The information about the amount of units of the new
field has to come from a real scan. Information from the starchart data about
allied minefields is not sufficient. Your sweeping ships have to be in scan
range for themselves to get the exact information about the amount of units.
Additionally, you have to analyze your RSTs with UFO4VPA for at least 3 turns
in a raw. Otherwise it is not possible to access the ship positions from the
next to the last turn and, therefore, new minefields are always treated as
updated minefields.

Another thing – when updating to v1.35 or higher. You have to analyze your
RSTs with the new version for at least 2 turns in a raw when using v1.35
and for at least 3 turns in raw when using v2.xx. That’s because versions of
UFO4VPA prior to v1.35 do not save ship positions from the next to the last
turn. The database has to be initiated first.
That means after downloading v1.35 and analyzing your RST with this version
for the first time the ‘new field’ recognition routine doesn’t work. You have
to wait for another turn. When using v2.xx for the first time you have to
play another 2 turns before this routine will work.
Now you can say that it is a drawback when using v2.xx. Yes, maybe it is.
But the new database format makes things much more flexible, especially
for people who are testing a lot (in other words: me). And to find out the
torp type of an enemy ship is not that much important. I think you can easily
live without that feature for two turns.

If all conditions are fulfilled UFO4VPA tries to find out the possible
torpedo types of the mine laying ship(s). Combinations of two or more torp
types are not supported. There would be just too many combinations. Up to
999 torps are allowed for every torpedo type. Tech 1 torps are not taken in
account because these torps would always match the given amount of units.

Solutions (quantity x type) will be displayed in a special order. If there
is not enough space to display all solutions in a single line the solutions
with low priority levels are dropped.
Solutions with multiples of 10 torps (up to 100) have highest priority be-
cause most minefields are laid by ships with a FC of ‘mdx’ (x = 1, …, 9, 0).
The next priority level is the ranking of the torp type. Torps that will
make 100 mine units have priority over torps making 81 mine units and so on.

Example: new enemy minefield, 8100 mine units laid

solution 1: 100xM7P (highest priority level)
solution 2: 81xM8P (highest torp ranking)
solution 3: 225xM4P (Mark 6 & 5 Photons don’t match)
solution 4: 324xM3P
solution 5: 900xM2P (not displayed because not enough room)
solution 6: 2025xPt (same here and too many torps, max=999)
solution 7: 8100xM1P (not allowed because ranking is 1)
If you have read this chapter carefully you have noticed that there are a lot
of restrictions and a lot of conditions that have to be fulfilled.
And even if some solutions are calculated this information can be completely
wrong, for example if two or more ships with different torp types are
participating in mine laying to the same field. You should never rely on
that information.

You may ask now: is this feature useful? I don’t know – the reason why I had
implemented this feature is that some guys asked for it.

You can disable the calculation of possible torps with the -t switch at the
command line.
10. Moving Mines/Webs:

If your host is using the Gryphon (Jupiter) add-on Cyborg and Crystals have
the ability to move their already laid mines/webs. UFO4VPA (v2.10) supports
that feature. The new minefield coordinates are used to determine whether
your own moved fields are in scan range or not. If such a field had been
completely swept by your enemy and you didn’t get a chance to scan it with
a lower ID ship UFO4VPA can calculate the correct ID range for the possible
enemy ships (see section 5).
Additionally a tracer is drawn on the map (enhanced mode only) which reflects
the original position of the field.
11. Alliances:

If you have an alliance with another player you will see all his laid mine-
fields. But normally you can’t see the enemy minefields your ally can see if
you are not in scan range.
Many players share their RSTs with their allies in order too see what they
normally can’t see. UFO4VPA supports these multiple RSTs. You can see all
enemy minefields that are scanned by your ally/allies, even if you are at the
other end of the universe. Of course this is only possible if the players
you have the RST from have a registered WinPlan copy.
But only the starchart information of allied RSTs is analyzed. There is no
message parsing. That means that you do not get some additional information
described above. If your ally is the Colonial, you can’t see minefields that
are covered by an ion storm. And as a Colonial you can’t give information
about minefields hidden in ion storms to your allies. You should keep that
in mind.

V2.xx still do not support allied RSTs for minefield activities. And there
isn’t a good chance that this support will ever become reality. The reason
is that the minefield activity feature is a really complicate thing (I
never did so much bug fixing, you may even find many other unknown bugs).
And the fact that ship IDs can’t be extracted from messages for sure, makes
it even worse. There is just no way to find out which activity comes first
if messages from allied RSTs are taken in account. Maybe allied RSTs could
be used in a later release with some limitations.
The processing of data from unpacked allied RSTs can be disabled with the
/O switch. This will also affect UFO objects and fleet analysis (see later).

 

12. Command line switches:

Here again all command line switches affecting minefield processing:

-M disable message analysis (don’t remove anything)
/F fleet analysis only (-M -i -r -U -a)

The above switches COMPLETELY disable message analyzing. As a result ALL
information about ‘true’ minefields is lost. Keep that in mind.

/K keep ALL minefield messages
/W WinPlan mode (-e /K -r -U -a)

The /K switch is meant for players who want to analyze minefield action for
themselves which is, in my opinion, masochism.
Do not mix up -M and /K switches. The /K switch lets UFO4VPA keep all
original minefield messages but the new ‘true’ minefield messages are still
written and, therefore, no information is lost.

/k keep lay/sweep/scoop messages

Above switch forces behavior like in v1.30 & previous versions.

-m no minefield activity messages
-b no calculation of possible beams

See details in the special sections.

/O don’t use allied RSTs

Self explanatory, I think.
D. Removing of futile host messages
———————————–

Unlike WinPlan, VPA presents the messages unsorted ‘as they are’. These can
cause troubles when you have to scroll through hundreds of unimportant
‘terraforming’ or ‘fighter building’ messages to reach the important ones.
Like in minefield processing you have the possibility to get rid of those
messages you do not want to read. All messages that should be removed must be
defined in the message template file ‘UFO4VPA.REM’. You can alter this file
(be careful !) if you want to keep these messages (or kill additional ones).

The -M switch disables ALL message manipulation defined in ‘UFO4VPA.REM’ and
that means you do not have ‘real’ minefields or ion storms when using -M.
E. Ion storm processing
———————–

1. Overview:

With newer TimHost versions there are ion storms that only appear in the
starchart data. You don’t get a message. This will happen if the distance to
the ion storm is very large. VPA would miss that information. UFO4VPA analyses
the starchart data and rewrites all ion storm/disturbance messages. The old
ones are deleted.
Not deleted are host messages that deal with ion storms affecting ships
(hull/crew damage, ship destruction, course deviation or energy vortex).

With v2.00 a lot of new features have been introduced. UFO4VPA can now write
ion forecast messages. These messages inform you about position, size and
behavior of ion storms in the next turn. Joining storms are also (partially)
supported. When using the /E switch (enhanced mode) VPA will draw some new
circles on the map which makes it easier for you to predict ion storm movement.

Processing of minefield messages, ion storm messages, ion forecast messages
and removing of futile host messages can be COMPLETELY disabled with the -M
switch at the command line (special ion storm messages are still written).
2. Ion forecast messages:

V2.xx will write ion forecast messages. For every ion disturbance and for
every ion storm an additional message is written.
You will get information about possible ranges for the radius, voltage,
heading and speed of the disturbance/storm in the next turn. If the storm
is weakening you also see the values in case of pancaking. The probability
for that event is 3.33%.
The position can be predicted exactly if the storm moves with warp 6 or 8.
If the storm has a warp speed between 2 and 4 the most probable speed is
used for calculating the next turn position (which is warp 3).

If the /E switch is used VPA will draw circles for predicted ion storms
on the map. Radius and color of these circles are dependent of the ‘worst
case’ values for radius (maximum radius) and voltage (highest voltage).
The following colors are used:

actual storm forecast

(very) dangerous red light red
moderate/strong yellow white
harmless green light green

These colors are default colors and can be changed in ‘VPA.MSG’ and
‘UFO4VPA.ADD’. Read ‘TEMPLATE.DOC’ for further details.

If the warp speed of the storm can’t be exactly predicted VPA will draw
two additional circles (default color: dark grey) on the map which
reflect the two other possible positions for warp 2 and 4.
Circles for pancaking storms are not supported (that would be overkill).

If the /E switch isn’t used you will see a rhombe marker at the predicted
position instead of circles. Additional positions for warp 2 and 4 are
not supported.

UFO4VPA also calculates the possibility of joining. If two storms are
close enough they will join. The storm with the higher voltage will
completely absorb the storm with the lower voltage. The position of
the new storm will be on a line between the positions of the old storms
after movement but nearer to the position of the WEAKER storm.
If there is a possibility that two storms will join next turn another
message will be written for both storms which comes directly after the
forecast message. There you can see the probability for this event and
which storm will ‘survive’. If the surviving storm can’t be determined
for sure you will also see the probability of surviving.
Also displayed are position and the ranges for radius and voltage of the
new storm. Heading and warp speed are not displayed because they are
identical to heading and speed of the surviving storm. The position of
the new storm is only estimated because it is dependent of the voltages
of the old storms. And because there are only ranges for the voltages
available it is not possible to calculate exact values. If the speeds
of the old storms are not known (warp 2 – 4) a speed of warp 3 is
assumed. You should keep in mind that in that case the prediction of
the position of the new storm is not very accurate.

If the /E switch isn’t used a rhombe marker will be drawn at the predicted average position of the new storm.
If the /E switch is used VPA will draw 3 circles on the map. One circle for the average position with a special color and two circles in dark grey (default) for the possible extreme positions (dependent of voltage ranges). The special color of the first circle is the same as described for the ion forecasts. Additionally a dotted line (default) is drawn between the old position of the surviving storm and the predicted average position of the new one to reflect the shifting of position.
Default color is dark grey. If there is a possibility that both storms can survive dotted lines for both storms are drawn.
Again, read ‘TEMPLATE.DOC’ if you want to change default color and line
style settings for joining storms.

If the probability for joining is 100% the circles drawn for the original ion forecasts are removed. It just makes no sense to display these circles if the storms will never be there.

Calculating the possibility of ion storm joining underlies a major
restriction. The host first checks whether the first available storm
joins with the second available storm. If the first two storms are
joining it checks whether the new (joined) storm joins with the 3rd
available storm and so on. Theoretically all available storms can join
subsequently to one big new storm.
UFO4VPA can’t do that, there are just too many possibilities. As I said
before exact radius, voltage and especially exact position of the
new storm are unknown. UFO4VPA doesn’t calculate with average values
(some other utilities do) and that makes it impossible to take in
account more than two storms. That means UFO4VPA looks only for pairs
of ion storms. If two storms have joined these two storms and the new
one are removed from the list, the new storm can’t join with another
storm. But subsequent joining of more than 2 storms a really rare events
and even if that happens the consequences for your ships would be
unpredictable and therefore, that information would be useless.

All formulas used for ion forecasts and testing for joining storms
are based on investigation of ion storm physics by Stefan Reuther.
If you are interested in these formulas you should visit his page
dealing with ion storm physics at:

http://www.inf.tu-dresden.de/~sr21/ion.html

Please keep in mind that all this ion storm physics stuff is neither
officially documented nor supported. It’s just an experimental thing and
the only way to improve inaccurate or wrong formulas is to write bug
reports to the author.

Writing of ion forecast and join messages can be disabled with the -I
switch at the command line. Ion forecasts are still calculated for
special ion advisory messages, you just disable message writing and
markers (circles with /E).
3. Special ion advisory messages:

Since v1.20 special Ion Advisory messages are written for ships affected by
heavy (dangerous and above) ion storms in the next turn. V2.xx can give you
much more detailed information and foreign ships are also included in the
test routine.

The first type of special ion advisory messages are ship messages. If a ship
will be affected by an ion storm in the next turn a message will be written.
To determine whether a ship is affected UFO4VPA makes a full simulation for
all possible combinations of voltages, radii and warp speeds. If a ship is
inside of an ion storm and this storm has a voltage of 150 MeV or greater the
ship will be affected and a message is written. UFO4VPA supports up to 3 ion
storms that can drag a ship around. Why only 3 ion storms? That’s because
when a ship is affected the storm will drag the ship to a new position
depending of warp speed and heading. Sometimes you do not know the speed of
the storm but much more important is the fact that the host changes the
heading of the storm (+/- 10 degrees) after movement but BEFORE ship dragging.
UFO4VPA has to calculate with all possible positions when testing for the
second storm. With every additional storm affecting the ship this calculation
becomes more complex and calculation time increases rapidly.

With joining storms calculation becomes even more complicated. A full
calculation will be done if the joined storm is the first storm which is
affecting a ship. If it is the second or third storm a full calculation is
no longer possible because calculation time becomes too long. Then some kind
of approximation will be done. If the warp speeds of both storms before
joining were known then you have to live with some small inaccuracies as far
as probabilities for ship affecting concerns. But you won’t miss anything
important. A ship marked as possibly affected WILL be affected with a certain
probability (some small inaccuracies possible) and a ship not mentioned in a
message definitely WON’T be affected.
If at least on of the storms before joining has an unknown speed (warp 2 – 4)
this approximation may completely fail. That means a ship could be marked as
possibly affected but isn’t in danger at all. On the other hand a ship
not mentioned as a ship that could be affected might have a ‘good chance’ to
be affected and even destroyed. In that case you should have a look at the
ion forecast messages of both joining storms to find out whether the warp
speed is known for sure (warp 6 or 8) and if that is not the case you have
to live with the fact that the calculation is not reliable at all. Not
reliable especially for those ships that are located at the border of the
joined storm.

The message written by UFO4VPA gives you information about the probability
that the ship is affected by the storm. It will also tell you whether your
ship is heavy enough to survive the storm without damage. In that case the
‘overweight’ of the ship is also presented (for your own ships only).
If the ship is not heavy enough you will be informed about the damage and
crew casualties you have to reckon with (again, for your own ships only).
The prognosticated damage is the damage caused by a single ion storm. If your
ship will be affected by more than one ion storm or your ship is already
damaged you have to add all single values to get the expected total damage.

The value of the prognosticated damage is based on a worst case scenario for
the expected ion storm voltage and it is only valid if the ship has fuel
just before the host begins with ion storm calculation. If the ship doesn’t
have fuel you have to add another 50% damage (or subtract 50 KTs of ship
weight). Some add-on features consume a lot of fuel and are executed after
cargo transfers but before ion storm stuff (auxhost1). If such a feature
causes your ship running out of fuel an unexpected extra damage could be the
result or even the destruction of your ship. Be careful!

You should have in mind that increasing the ships weight (additional cargo
or fuel) doesn’t help anything for the next turn. That is because the host
calculates with the weight the ship has at the very beginning of the host
run (before any transfers occur). That is not logical because transfers
happen before ion storms can harm a ship (bug or feature?) but you just have
to live with it. That means increasing weight helps only for the next but
one turn. Of course that doesn’t help if the ship will be destroyed in the
next turn.

Crew experience points are taken in account, too. One crew experience point
makes your ship one KT heavier as far as ion storms concerns. Crew experience
is just an experimental thing at the moment because implementation is
incomplete. You should also know that if you update from versions prior to
v2.00 in mid game UFO4VPA can’t take in account crew experience points gained
in previous turns.

You will gain one experience point for every move with warp 6 or higher
(warp 4 or higher for gravitonic acc. ships) and one point for every 20 MeV
above 140 MeV if the ship survives an ion storm with such a voltage. There
are other possibilities to gain experience points (e.g. alchemy) but that is
not yet implemented.
UFO4VPA tries to do the same thing for foreign ships but it must be able to
see the ships to find out whether a ship has moved or not. No points are
granted to foreign ships for surviving an ion storm. You should always
have in mind that the values for crew experience points of foreign ships
are rather unreliable (and very often absolutely unusable).

With v2.15 UFO4VPA tries to adjust crew experience points if ships have been
affected by heavy ion storms. If a ship gets more damage than expected the
value for crew experience is decreased accordingly (ship must have fuel at
the end of the host run). If a ship is damaged less than expected (or no
damage at all) your crew experience points will be increased (with or without
fuel). This is only possible for your own ships and only if you didn’t miss
your previous turn.

In the last section of the message you will be told about the estimated course
deviation of the ship. It is assumed that the storm doesn’t change its heading.
If the warp speed of the storm is unknown (warp 2 – 4) the most probable
speed is assumed and the probability of this speed is given. Most probable
speed doesn’t mean warp 3 in this case because it is possible that a storm
which is moving with warp 3 can’t reach a ship but with warp 4 it can. Then
warp 4 would be the most probable speed for the storm when affecting this ship.

Of course, these course deviations don’t make sense for ships that are expected
to be destroyed by the ion storm. But the prognosticated damage is only an
assumption based on worst case ion storm voltages and more or less accurate
values for crew experience. Don’t give up a ship with an expected damage of
some points over 100%, especially ships you could capture from your enemy
(unknown crew experience). But of course, with prognosticated damages of 200%
or higher (e.g. terraformers) you can forget the thing.

If you are using the /E switch VPA will draw a vector for every probably
affected ship which reflects the average course deviation of the ship. If a
ship will be affected by more than one ion storm another vector is added at the
ending point of the previous one. For every ion storm one vector. The distance
between ship position and ending point of the last vector reflects the sum of
all course deviations. You can change color and line style of these vectors,
read ‘TEMPLATE.DOC’ for further details.
If you do not use the enhanced mode you will see yellow flags indicating that
a ship will be affected by an ion storm.
Additionally it is checked whether a particular ship can reach planets by
traveling its maximum distance (for your own ships only). If so, a message for
every reachable planet is written providing an alternative waypoint to its
orbit. This is the second type of special ion advisory messages. V2.xx also
support gravitonic accelerator and hyperspace ships.

There is only one message possible for every planet. Taken in account is only
the FIRST ion storm that influences the course of a ship. Multiple course
deviations for a single ship are not supported by alternative waypoints. If
there is more than one ship that can reach the orbit and these ships are
affected by two or more different ion storms only the course deviation caused
by the SLOWEST ion storm is used for calculation. If all these ion storms have
the same speed the ion storm affecting the ship with the highest ID has
priority.

The message will inform you about the ion storm the alternative waypoint is
calculated for. Only ships that are affected by THIS ion storm (and not by
another one) have a chance to reach the orbit when using this alternative
waypoint.

Following are the coordinates of the alternative waypoint.

The next information is the probability to reach the orbit when using the
suggested waypoint. The faster the ion storm moves the lower is the probability
to reach the orbit (that’s why slower storms have priority). The reason for
that is that the heading with which a ship is dragged is unknown. Maximum
change is 10 degrees and the higher the speed of the storm is the greater
is the possible extra deviation. If gravity wells are disabled the chance
to reach the orbit decreases dramatically and is near zero for storms moving
with warp 6 or 8.
You should keep in mind that the given probability is only valid for the warp
speed of the storm mentioned in the message. If the warp speed is unknown
the most probable speed is used to calculate the alternative waypoint and you
will be informed about the probability for this speed. To make things clearer
I will give you an example:

most probable speed: warp 4
probability for that speed: 60%
probability to reach the orbit: 50%

overall probability to reach the orbit: 60% * 50% = 30%

The reason for that is that you have absolutely no chance to reach the orbit
if the alternative waypoint is calculated for warp 4 but the storm moves with
warp 2 or 3 instead.
If you are using the /E switch VPA will draw vectors on the map for every
planet that can be reached by using an alternative waypoint. The ending
point of the vector represents the waypoint. Of course you can change the
default settings for color and line style of these vectors. Read ‘TEMPLATE.DOC’
for further details. Default settings are solid line for line style and
color of the planet for marker color.
If you do not use the /E switch you will see dark grey small circle markers
at the position of the alternative waypoint.

Writing of special ion advisory messages can be disabled with the -i switch
at the command line.
4. Heavy ion storms & mine sweeping:

With version 1.30 a new feature had been introduced. UFO4VPA calculates the new
position of a ship that is pulled by a heavy ion storm. This change of position
takes place after mine laying and BEFORE mine sweeping. This calculation is
necessary to determine whether a ship is in scan range of a minefield or not
(see minefield section). If a ship is damaged by this ion storm you will get
a marker at this new position. If the ship survives the damage and is moving,
this position is not the actual position of the ship. Don’t be confused. You
won’t see a marker if the ship hasn’t been damaged.
If you are playing in a game with the Nemesis (Jupiter) add-on you have the
possibility to use the ship FC ‘ANC’. A ship with this FC and warp 0 can’t be
pulled away – says the documentation. But that’s not true. The ship IS pulled
to a new position but is moved back to orbit afterwards. That’s why you can’t
repair these ships at a base. And, a ship with mission ‘mine sweep’ will scan
and sweep mines at the position where it had been pulled to by the ion storm
and NOT at the orbit of the planet.

Ion storms with a voltage of 400 MeV or higher can throw ships to a random
position on the map. These are so called ‘energy vortexes’. The effects of
ion storm pull and vortex throw are cumulative. That means you are first pulled
to a position determined by heading and warp speed of the ion storm and then
thrown to random position. The distance between these points is given in the
message you will get from the host. But, unfortunately, there is no direction.
And that made it impossible for versions prior to v2.00 to calculate the new
position of the ship if the ship was moving. This was important for ships with
mission ‘mine sweep’. UFO4VPA couldn’t find out whether these ships were in
scan range of a minefield or not.

V2.xx try to find out the position of a ship that had been thrown by an
energy vortex. As I said before that is not a problem when the ship didn’t
move afterwards. Also no problem for ships with waypoint and warp speed set
after moving. These are ships that couldn’t reach their waypoints with actual
speed. But it is still not possible to find out an exact position if the
ship was able to reach its waypoint (no heading set), the ship has struck a
web mine (no warp speed set) or if the ship has been destroyed during or after
movement.
UFO4VPA modifies energy vortex messages by adding some extra information.
These are the position where the ship has been thrown to and additionally the
reliability of the calculation. There are four possibilities:

‘position’: reliable, no penalty
‘probable position’: rather reliable, penalty of 1
‘estimated position’: not very reliable, penalty = 2 – 254
‘possible position’: just speculation, penalty of 255

Penalty means that the ship has to be as many LYs nearer to a minefield as it
has penalty points in order to be allowed to declare a minefield to be
completely swept or newly laid. Or in other words, the penalty points (= LYs)
compensate the inaccuracy of the ship position BEFORE movement.

No penalty is only possible if the ship didn’t move after energy vortex throw.
1 or more penalty points have ships with heading and warp speed set. For those
ships the starting point can be interpolated. 1 penalty point is always given,
but sometimes 2 or more starting points are possible and then the penalty is
the maximum possible inaccuracy (in LYs).
A penalty of 255 means that the ship isn’t allowed at all to look for swept or
newly laid minefields. These are ships that do not have a heading set.

If the ship has been destroyed by the energy vortex a marker is drawn at the
position where the ship has been dragged by the storm (position before vortex
throw). If the ship has only been damaged by the energy vortex a marker is
drawn at the (calculated) position where the ship has been thrown to. This
position is only a suggestion if the heading of the ship is unknown. In this
case the position of the marker is on a line between actual ship position and
ship position before vortex throw (which is the position the ship has been
dragged to by the storm) with a distance to the latter position given in the
vortex message.
But if the ship has been damaged (NOT destroyed) by the vortex and then
destroyed during or after movement the position of the marker will be absolute-
ly nonsense because the position of the new ship is either the position of the
starbase where the new ship has been built if you can see the ship or it is just
(0, 0) if you can’t see the new ship. This new ship position is used to
calculate
(or better: estimate) the position where the ship has been thrown to and that
means that this is just a random position. There are possibilities to avoid this
but that’s not yet implemented.

 

F. Add-on message processing
—————————-

When you are playing a game that uses third party add-ons you will get so
called alternative messages that give information about special missions and
events. These messages always begin with a (-a0xxx) identification string. The
‘a’ means alternative (= no host), the ‘0’ means actual turn and ‘xxx’ stands
for a special add-on ID.
In a game that uses several add-ons you often get dozens of these special
messages and that makes it hard to survey all actions. These actions take
place on several positions, they are either planet or ship positions and are
defined by planet or ship IDs.
VPA can’t use these IDs directly because they have to be a part of the leading
identification string of a message and normally the IDs are placed in the
message body (like ‘(xxx)’ or ‘ID: xxx’). UFO4VPA analyses all messages that
begin with ‘(-a0’, looks for either the planet or ship ID in the message body
and finds out whether the ID deals with a planet or ship. It then changes the
identification string from ‘(-a0xxx)’ into ‘(-p0yyy)’ or ‘(-s0yyy)’. Be
careful, do not mix up these two DIFFERENT IDs. ‘xxx’ is the ID of the add-on
and is not important for VPA (WinPlan uses it to decide which special picture
it should display in the message reader). ‘yyy’ is the planet/ship ID VPA can
use with the message ‘common’ template defined in the file ‘VPA.MSG’.
It is now possible to let VPA draw a special (color, shape) marker on the map
for every different add-on message.

It can cause problems if an add-on writes a message for a ship and that ship
explodes afterwards. If you build a ship in the same turn with the same ID you
will get this marker drawn on the position of the new ship. This can be a
little confusing. But at the moment I don’t have a solution for that.

Processing of add-on messages can be disabled with the -r switch at the
command line.

 

G. UFO data processing
———————-

1. Overview:

One of the most important features of UFO4VPA is the ability to extract the UFO
object information stored in KOREx.DAT (starchart data). UFO4VPA scans all UFO
object entries and if found one, adds a message containing all important UFO
data like name, position, speed, heading and size. Additionally, the minimum
ranges from within the object can be seen by planets or ships are displayed.
With these messages VPA can draw different markers on the map. There must be
of course the right message templates in ‘VPA.MSG’. When using the file
included in this package you will get a lot of new entries concerning UFO
objects. You are free to add more definitions to ‘VPA.MSG’. But be careful,
wrong entries can cause unexpected results or even loss of important
information.
This is also true for the other template files. UFO4VPA may even hang when
playing around with sensitive template definitions.

V1.20 and newer versions of UFO4VPA write additional messages for UFOs that
have a warp speed greater than zero. That means that the waypoints of moving
UFOs can be drawn on the map.
V2.xx support ‘real’ UFO objects (enhanced mode only). VPA can now draw a
circle on the map which represents the size of an UFO object. Additionally
a vector is drawn (if warp > 0) that gives information about heading and warp
speed of the UFO. If the enhanced mode is enabled UFO4VPA does no longer write
waypoint messages for moving UFOs because these are no longer necessary (you
have the vectors instead).
But you should NEVER rely on UFO waypoints. Different add-ons use different
formulas for calculating the waypoints of their UFO objects and there is
always a good chance that the position of the waypoint marker and the actual
position in the next turn will differ. Especially the Asteroid add-on uses
strange formulas and sometimes completely wrong waypoints are displayed. But
normally the error shouldn’t be more than 1 LY in each direction.
If you want to intercept an Asteroid you should always use the ‘IAx’ ship FC.
If the ship is not more than 80 LYs away from the waypoint marker (or ending
point of the vector) and you can move with warp 9 you have a good chance to
reach the Asteroid next turn. But if the distance is exactly 81 LYs it could
happen that you miss it.

If you think you do not need waypoint markers then you can disable writing
waypoint messages with the -u switch at the command line (not necessary if
the /E switch is used).

If there are additional unpacked RSTs (registered WinPlan) available in your
game directory, you will see all UFO objects (and waypoint markers) your
allies can see.

Processing of UFO data can be disabled with the -U switch at the command line.
2. Something about Asteroids:

A well known problem of the Asteroid add-on is the ‘Asteroid moving bug’. The
Asteroids and ships using the Quadbenium jump feature move to another
position than expected. UFO4VPA calculates a new corrected heading for
Asteroids but it can’t do anything for the jumps. You have to compensate that
for yourself. But I can give you some help:

heading | corrected heading
—————————-
1-44 | 90-heading
91-134 | 270-heading
181-224 | 450-heading
271-314 | 630-heading

As you can see it is impossible to jump in direction 30 degrees because this
heading is adjusted to 60 degrees by the Asteroid add-on.
Therefore, I would advise you to use only headings that are not treated wrong
by the Asteroid add-on.

****************************** WARNING !!! ********************************
* *
* Further investigation of the Asteroid moving bug showed that these *
* formulas are partially wrong as far as Quadbenium jumps concerns. I *
* couldn’t find out the right formulas for the jumps so far. So, do not *
* rely on these formulas, use them at your own risk! *
* *
***************************************************************************

If you are playing with an Asteroid add-on that isn’t buggy (I think there is
no such thing), you can disable UFO waypoint correction with the -c switch at
the command line.
3. Again, to make things clear, the command line switches:

-U completely disables UFO processing – no UFO messages at all

/W WinPlan mode (-e /K -r -U -a)

-u UFO messages but no waypoint messages

-c UFO messages and waypoint messages
but waypoints for Asteroids are not corrected

 

H. Alliances
————

1. Auto-config

Every time you start VPA it looks at ‘VPACLRx.INI’ in order to determine who
your allies are and which special colors to use for that races. This file is
generated by VPA if it doesn’t exist and then never changed again. Normally
you have to change this file for yourself.
UFO4VPA can do that for you automatically. It scans the ‘priority build
points’ message and looks for a ‘!+’ directly after the race name. That’s the
sign for an alliance. If found UFO4VPA changes the race color from ‘ENEMY’ to
‘ALLY’. You should read the VPA documentation for further details.
Some players want to assign special colors to certain races and alter
‘VPACLRx.INI’ manually. UFO4VPA would overwrite these settings every time. To
avoid this you can use the -a switch at the command line and UFO4VPA leaves
this file alone.
2. Explore Map

If you are playing in game that uses the Explore Map add-on UFO4VPA analyses
your ‘XYPLANx.DAT’ (which you get from the host every turn) and writes a normal
‘XYPLAN.DAT’ that can be used by any client. This is not necessary for VPA but
clients like WinPlan absolutely need a starmap with its original name.
If you are sharing RSTs (WinPlan or DosPlan) with your allies and you do not
use the /O switch UFO4VPA also analyses the ‘XYPLANx.DAT’ files from your
allies, merges all data and writes a new ‘XYPLAN.DAT’ that holds all starmap
information your allies have investigated (plus your own, of course). Again, VPA
will do that for itself but other clients do not. If using UFO4VPA a WinPlan
user can also benefit from allied starmap data.

 

J. Fleet analysis
—————–

1. Overview:

Every time you run UFO4VPA it checks your ship contacts. These can be just
visual contacts or battles. It then saves this information in the database.

UFO4VPA writes two different types of messages: fleet messages and ship
messages.

A fleet message contains all collected information about the hull types a race
has built and how many ships of that type already had been seen. A comparison
to the last turn is made to give you information about the fleet development
of a particular race (enemy and your own).
Of course, normally you don’t have the information about every enemy ship.
At the beginning of a game the accuracy of that fleet analysis is very low.
If you do not play in a ‘blank score’ game you have the possibility to find
out how accurate it is by looking at the percentages of so far seen ships.

A ship message contains more information about a particular ship. You will
know not only the hull type but also values for crew and damage, engine type
(if possible), armament and ammunition of that ship. But to achieve this
information it is necessary to have a ‘real’ contact.
There are four possibilities to get that contact:

– your own ship has been captured, it has surrendered or you just gave it away
– you have the ability to examine allied RST files (see later)
– you are playing in a game that is using the Gryphon (Jupiter) add-on where
Birds and Privs can use the ‘Remote ID’ feature
– you have lost a battle against an enemy ship

In the last case it is impossible to find out the engine type of the ship if
the E-S bonus (engine shield bonus) is turned off. But if this setting is on
you have a good chance to get also information about the engine type. Sometimes
it is impossible even if the E-S bonus is on, for example if the E-S bonus is
very low, the E-S bonus interferes with the right side mass bonus or if at least
two engine types cost the same amount of MCs. And no luck with enemy ships
fighting against your planets because the E-S bonus is always zero when the
opponent is a planet.

Every ship message deals only with one enemy/allied ship. It contains in-
formation about hull type, crew, damage, engine type (if possible), number/type
of beams, number/type of tubes/bays (if any), ammunition (torps or fighters) and
the moment of last contact. If the crew, number of beams or number of tubes/bays
are not the normal values for the hull type the standard values are also dis-
played.
The name of the ship is not displayed – an enemy could fool you by changing the
ship name.

******************************* Updated in v2.20 *******************************

If an enemy ship uses the FC ‘NTP’ you will still see the correct number of
fighters/torps (and NOT zero) in the VCR. The number of bays/tubes is set to
zero instead. This wasn’t treated correctly by UFO4VPA in versions prior to
v2.20. If a ship has no fighters or torps you can be absolutely sure that the
ship has no ammunition. A ship with unknown equipment from previous turns (no
contact so far) that uses the FC ‘NTP’ will show up in a ship message as a ship
with no bays (normally a carrier MUST have at least one bay even if playing with
the Jupiter add-on) or tubes but with a known tube type (if torpedo ship) and a
known amount of fighters/torps.

Carrier has no bays -> ‘NTP’
Torper has no tubes but tube type is known -> ‘NTP’

********************************************************************************

V2.00 or higher allow VPA to display armament and engine type directly on the
screen (enhanced mode only). With v2.10 VPA can also display crew and damage.
Just click on the ship you had contact with and the available information is
displayed on the right side of the screen.
Ammunition is not visible because VPA only allows presentation of cargo if RST
data for the ship owner is available.

With v2.10 a new message type has been introduced: the ‘Warp Signature
messages’.
These messages just give additional information to the user and are not a real
part of the fleet analysis (see later).
2. A word about accuracy:

Accuracy is not only determined by ship contacts. Of course, the more enemy
ships you have seen and the more ships you have fought against the better the
accuracy of a fleet analysis is.
But there may happen other things in the VGA planets universe a fleet analysis
tool must consider: mine hits, glory device, ships destroyed because of third
party add-on rules.
The key to a reliable enemy fleet status is not only to save and remember the
scanned ships but to delete all destroyed ships from database and to change
ownership of captured or surrendered ships.
UFO4VPA analyses your messages in order to find out whether a ship had been
destroyed or whether the ownership of a ship had changed.

The list of possible events is rather complete now. But there are still some
events not taken in account (especially for add-ons). Feel free to contact
me if you want to make suggestions for enhancements.
3. A word about alliances:

Many players share their RST files with allied races. UFO4VPA reads data from
all unpacked RSTs (yes, you have to unpack them with WinPlan) found in the game
directory. For every particular allied data set the same fleet analysis is made
as for your own data. That means you do not only get information about the fleet
of your ally but also about all enemy ships that only your ally can see (only
the first 50 targets if your ally doesn’t have a registered WinPlan copy). If
your ally had a real contact with an enemy ship and the enemy ship has survived,
you will get the same information as your ally.
4. Warp Signature messages:

This feature is new in v2.10. It’s not a real part of the fleet analysis
because it doesn’t influence your ship database. But if the fleet analysis
is disabled (-F) this feature is disabled as well because it needs message
analyzing of distress messages. That’s why it belongs more or less to this
section.

This feature only works because there is a bug in the host program. If a ship
has
struck a mine and explodes because it has suffered too much damage the host puts
the explosion marker (stored in ‘KOREx.DAT’) at the starting position of the
ship and not at the position of the deadly mine hit. UFO4VPA uses this
additional
information and writes a ‘Warp Signature’ message for that ship. Warp Signature
means that the starting position of the ship is known – the position in space
where the ship has engaged its warp drives. The second pair of coordinates shown
in the message is of course the position of explosion – the position in space
where scanners have lost track because with the ship the warp field is also
gone.

By the way, this host bug mentioned above only influences explosion pointers for
ships destroyed by mine hits. Warp Signature messages are not possible for ships
destroyed in battle or other occasions.

With enhanced mode disabled UFO4VPA draws a marker at the starting position on
the map. If enhanced is enabled you will see a tracer instead which reflects
the traveled distance from the ships starting position to the point of
explosion.

Of course there are several restrictions (as usual). You will get these messages
only if the position of the ship had been unknown in the last turn. And of
course this means that you will never get such a message for one of your own
ships.
I have to say that this routine is not 100% water-proof. There are occasions
where you will get completely wrong information. That’s when messages are
written for Lizard ships and UFO4VPA didn’t have a chance to find out the owner.
If a Lizard ship suffered more than 100% but less than 150% damage from a mine
hit and was still able to reach the orbit of a planet you can’t scan and you
(UFO4VPA) didn’t see this ship in one of the previous turns UFO4VPA assumes that
this ship is a non-Lizard ship and writes a message for the wrong ship. The same
is true if a ship was recognized as a Lizard ship some turns ago but ownership
changed which you couldn’t scan. In that case UFO4VPA assumes that this ship
is still alive and no message is written. In both cases mine hit messages and
explosion markers become out of sync which will also affect all following
explosions (if any).
For security writing of Warp Signature messages is completely disabled if you
didn’t use UFO4VPA at least two turns in raw, at least one Warp Signature is
longer than the distance a gravitonic accelerator ship can move or if there are
more explosions found by UFO4VPA than stored in ‘KOREx.DAT’. But there are still
possibilities that UFO4VPA can’t detect the error(s) and will present completely
wrong Warp Signatures for many ships. You should have that in mind.

Writing of ‘Warp Signature’ messages can be disabled with the -w switch at the
command line.
5. Command line switches:

First, have a look at the possible command line switches concerning fleet/
ship messages:

/F fleet analysis only (-M -i -r -U -a)
-F disable fleet analysis
-f no fleet messages
-S neither enemy nor allied ship messages
-s no allied ship messages
-w no ‘Warp Signature’ messages

The /F switch lets UFO4VPA behave like a fleet analysis only tool.

The -F switch is a special one because that switch disables all action that
deals with ship data processing. In that case ships are neither added to nor
deleted from the ship data base. It’s just like missing a turn.

The next three switches do not disable ship data processing. They only change
the way fleet/ship messages are presented in your message base.

You can use the -s switch to suppress writing ship messages concerning allied
races. This is especially useful if your allies have lots of small ships
like terraformers or fighter builders. Their equipment isn’t really much of
interest and you can avoid getting 100+ messages for unimportant ships.
With v2.xx you do no longer have to use the -s switch if allied RSTs are
available. VPA can display allied ship information for itself and that’s
why UFO4VPA does no longer write messages for these ships.

The -w switch also does not affect your ship database. It just disables
writing of ‘Warp Signature’ messages (new in v2.10).
K. Score processing
——————-

1. Overview:

UFO4VPA writes score messages for your race and all allied races where an
unpacked RST (WinPlan or DosPlan) is available. Two types of scores are
supported: the normal VGAP (basic) score and the PTSCORE v1.3b.
You will see the values of the particular scores and, in brackets, the
difference to the last saved turn. This difference is presented either as an
absolute value or as a percentage.

You can disable these score messages with the -p switch at the command line.
2. Basic VGAP score:

This is the well known, more or less useful VGAP score. Normally the in-
formation about this score is already included in the RST you get from your
host. But if you are playing in a game with blanked scores the additional
score message could be useful for you. You will get this message only if the
VGAP scores are blanked.
The last line gives you information about the ratio between total score and
the duration of the game (number of turns). The difference to the last turn
shows you the speed of development of your empire. A positive value means
that your empire is expanding more rapidly compared to your last turn.
Please do not ask me to implement moving these values into the standard
arrays of the VGAP data. As a major rule UFO4VPA changes only your message
base and leaves the binary data alone. The file where your score data is
stored is a very important binary file which holds timestamps, checksums,
passwords and other important data. A corruption of this file could result
in an unusable turn or even worse, a red alert from your host and attack by
the Tim Continuum.
3. PTSCORE:

If you are not familiar to the PTSCORE you should download its package
and read the documentation first. You can find a link on my homepage.
But I will give you a brief introduction. The main PTSCORE is the ‘used’
score. This score counts all resources that had been used to build planetary
structures, bases, tech levels, base defense, ships and their parts, torps,
fighters and minefields. Paid MCs and supplies count one point each, used
minerals 3 points for every Kt. Used Neutronium doesn’t count.
An example, a base with hull tech level 10, all other techs 1, no defense and
no fighters is equivalent to

(402 + 120 + 340) * 3 + 900 + 4500 = 7986 points.

There are two exceptions: fighters and minefields.
A fighter normally would add 115 points to your score. This would be a rather
big advantage for the fighter races, because the may not pay 100 MCs for a
single fighter, they can do the job for 5 supplies. The Empire doesn’t pay at
all (normally). That’s why in PTSCORE every fighter is 20 points worth, 5
points for the supplies and 15 points for the minerals, regardless whether
you have paid the full price or not.
For minefields it is assumed that the torp type with the lowest possible
PTSCORE had been used. This is normally the Mark 7 Photon.
Note that only those used resources are taken in account by PTSCORE that are
stored in your RST. Resources that are used to build special installations
supported by 3rd party add-ons (schools, universities, theme parks, doomsday
launchers, …) do NOT increase your PTSCORE.

You will get two PTSCORE messages for every available unpacked RST (registered
WinPlan only). The first message holds information about combat score, used
score and total score. Additionally, some special items are listed which are
part of the used score. Here comes the detailed explanation of all scores:

Planet score: all resources used to build mines, factories and defense posts.
This score is part of the used score.

Planetary defense: all resources used to build defense posts. This score is
part of the planet score.

Base score: all resources used to build bases, tech levels, base defense and
fighters defending the base. This score is part of the used score.

Base defense: all resources used to build the base defense and fighters
defending the base. This score is part of the base score.

Storage: all resources used to build ship parts stored on bases. Normally
these are resources for queued build orders or parts of recycled ships.
Torps stored on bases are also part of this score.
The storage score is part of the total score and NOT part of the used score.
You can’t increase your used score by building lots of ship parts or huge
amounts of torps that are just bunkered on your secured bases.

Warship score: all resources used to build capital ships and their ammunition
(fighters, torps). This score is part of the used score.
Unused resources stored in cargo space (MCs, supplies, minerals) are part of
the total score and NOT part of the used score.

Fish: all resources used to build fighters and torps that are stored in
cargo space of capital ships. This score is part of the warship score.

Mines: all resources used to build torps which are converted into minefields.
The calculation is based on the assumption that the torp type with the
lowest possible PTSCORE had been used. This score is part of the warship
score.
Note: UFO4VPA first tries to read the starchart data to find out the amount
of all minefield units for a race. This is only possible if the RST is from
a player who has a registered WinPlan copy. If this is not the case and the
player didn’t offer you an alliance (this is not likely but still possible)
the minefield score consists of minefields you and your other allies could
scan. Minefields out of your (and your allies) scan range can’t be taken in
account which makes this score not very reliable.

Freighter score: all resources used to build freighters. This score is part
of the used score.

Combat score: this score is not supported by the original PTSCORE program.
The idea comes from Tim Wisseman’s AutoScore. The AutoScore is the sum of
all resources used to build warships, to build fighters and torps stored
in the cargo space of warships and the HALVES of the resources used to
build planetary and base defense, fighters on bases and torps converted
into mines. Again, to make things clear:

Combat score = warship score – mines
+ (planetary defense + base defense + mines) / 2

The idea of this calculation is based on the assumption that movable
resources can be used in combat more effectively.

Note, that the combat score calculated by UFO4VPA is based on the rules of
PTSCORE. A fighter counts 20 points and every used Kt of minerals is 3 points
worth. The original AutoScore calculates with 125 points for every fighter
and 5 points for every other Kt of used minerals.

Used score: this is the main PTSCORE which is often used for the calculation
of the players ranking in a tournament game.
This score is the sum of planet, base, warship and freighter scores. NOT part
of this score are ship parts and torps stored on bases, used Neutronium or
unused resources stored in the cargo space of ships.

Total score: the sum of the used score and all other resources that are
available – ship parts and torps stored on bases, all unused resources on
the planetary surface and all unused resources stored in the cargo space of
ships.
NOT part of the total score is the Neutronium stored in the fuel tank of ships,
the Neutronium available on the surface of planets and all not yet mined
minerals.

For combat, used and total score the ratio between score and duration of the
game (number of turns) is also calculated (see basic score for more details).

The second PTSCORE message shows the ratios between the main scores (planet,
base, warship, freighter and combat) and the used score and the ratio
between the used score and the total score.

 

L. Enhanced mode
—————-

1. Overview:

The enhanced mode, introduced with v2.00, is a major improvement for all VPA users who decided to use UFO4VPA. The enhanced mode makes it possible to access the VPA database (‘VPAx.DB’) directly. As a result circles and lines can be used for markers which is not possible via message parsing. And it is also possible to assign more than one marker to a single message. Another advantage of the enhanced mode is the possibility to alter wrong entries in the database because of VPA bugs. And entries in the VPA database can be supplemented if gathering of special information is not supported by VPA.

Of course, there is also a disadvantage. You have to run UFO4VPA twice and VPA once before you can begin to edit your turn with VPA. Using a batch file is highly recommended (read usage section).

The enhanced mode can be activated with the /E switch. This is not the default mode, you have to activate it manually.

To make things clearer I want to explain what is done when using the recommended batch file:

(1) After unpacking your RST with WinPlan you have to run UFO4VPA for the first time. You must specify the /E switch and all other switches you want to use. This first run is similar to the normal mode, there are only some differences. For example a special signature is written to the message base to tell UFO4VPA that it has to do something when run for a second time.

(2) Now it is time to run VPA. Here again, nothing special to say. VPA has to parse the messages and initiate the database for the actual turn. That’s why UFO4VPA has to be run twice, the VPA database for the actual turn must be there and initiated before UFO4VPA can access it.

It is not necessary but you should use the /B (batch mode) switch when running VPA because user input is not recommended before the enhanced mode is not completed. It’s not really dangerous but you will see wrong information when making your turn now. A warning signature is displayed in the last message (PBP message) if you are using VPA for editing your turn before UFO4VPA isn’t executed a second time.

(3) Now UFO4VPA has to be run for a second time. No special command line parameters are accepted here, only race number and game directory. UFO4VPA can now access the actual turn block in the VPA database.

(4) You can now use VPA to make the turn. If you want to interrupt your turn session you can run VPA as often as you want but you can also run the complete batch. It just makes no difference because UFO4VPA knows that the enhanced mode is completed and just makes nothing when run repeatedly.

Following is a more detailed description what is done during the second run of UFO4VPA with enhanced mode enabled.

2. Minefield processing:

First thing done during minefield processing is a security check. Number of minefields recognized by UFO4VPA and number of minefields stored by VPA have to match. If this is not the case the second run of UFO4VPA is cancelled and the enhanced mode is not complete. This is done to secure that VPA has been executed after the first run of UFO4VPA and that both databases (VPA and UFO4VPA) are synchronized.

Then some entries for the amount of mine units are corrected if the +V switch is used. With enhanced mode enabled the values for mine units are not corrected when the minefield messages are written to avoid presenting a second value for true units count.

Next step is correcting the mine style if necessary because of VPA bugs. If a minefield is laid and completely swept immediately after laying VPA is presenting it as a swept web minefield, regardless whether it had been a web or not. And a swept web minefield (laid in a previous turn) is always presented as swept d.s (normal) field. UFO4VPA corrects that.

The last step is the most important one. Here the ages of minefields are adjusted. With enhanced mode enabled UFO4VPA writes ‘old minefield’ messages for fields out of scan range or covered by ion storms. It is not possible to tell VPA via message that these minefields are not scanned in the actual turn. So UFO4VPA has to correct that by accessing the entries directly.
3. Ship processing:

This is for copying values for crew, damage, engine tech and armament of enemy/ally ships you had contact with from the UFO4VPA database to the VPA database. VPA can then display this information for itself. Note that VPA can’t display the number of torps/fighters for ships if complete ship data from allied (unpacked) RSTs is not available. In this case you have to look at the ship message generated by UFO4VPA if you want to know the number of remaining torps/fighters of a ship you had contact with.
4. Planet processing:

If your ally is sending you a message (generated by EchoView) to inform you about his planets and starbases the message will be analyzed and the information copied to the VPA database. VPA can then display this information on the map like you would see it if you had scanned the planets with a ship. Two things to say here. First, when clicking on such a planet you will always see ‘1 turn ago’ because the message generated by EchoView is from the previous turn and of course, actual scan information has always priority over allied information transmitted via message. Second thing, you have to enable this feature by editing ‘VPADATx.INI’ in your game directory in order to tell VPA that it is allowed to accept information from that ally. That’s the same procedure as for enabling exchange of information supported by VPA directly (see ‘VPA.FAQ’ in the VPA documentation for further details).
5. Marker processing:

This part is the most important one of the enhanced mode. It makes it possible to transform simple markers supported by message parsing into circle and line markers with values for radius and vector coordinates and to assign extra markers to a single message which is also not possible via message parsing (a message is only parsed once, allowing only one marker for a message).
So it is possible to display ‘real’ UFO objects with a circle marker that represents the size of an UFO and with a vector that shows heading and warp speed.
Additionally, circle and line markers are used to display the ion forecasts.
Read the ion forecast section and ‘TEMPLATE.DOC’ for further details.

Introduced with v2.10 are tracers for ‘Warp Signature’ und ‘moving mine/web’ messages (see special sections for further details).

 

X. Comments
===========
When you have comments or find bugs, please do not hesitate to contact me. Also, if you have ideas on how to expand the program or have suggestions for new commands or options, please contact me.
My e-mail address: [email protected]
The Home of UFO4VPA: http://www.chiasma.de/vgap/ufo4vpa/

 

XI. Thanks
==========
Special thanks to

– all Planeteers who excuse my poor English
– all UFO4VPA users who have voted for my page
– Alex Ivlev for programming VPA, the best planets client
– Stefan Reuther for the documentation of the VGA Planets 3.x file formats and investigation of ion storm physics
– Christoph Doerfler for programming support
– Dennis Weise for comments and beta testing
– Pawel Keller for comments and beta testing
– Nate Olsen for ‘Spaceport Andromeda’, the successor of ‘Spaceport Hamburg’
– Armin Trott for ‘Spaceport Hamburg’, the best hosting site we ever had
– The former players at ‘Spaceport Hamburg’ for using lots of add-on features against me 😉
– Oleg Shvartsman for programming ‘Gryphon’ & ‘Nemesis’
– Dan Gale & Dave Killingsworth for programming ‘Race+’, ‘Asteroid’ and ‘Jumpgate’
– Michael Jordon for programming ‘Ahost’
– and all the other programmers who are responsible for add-ons and utilities
NO special thanks to

– Players who quit when things become interesting
– Players who take things too seriously and personally
VGA Planets is (c) copyright and ™ Trademark by Tim Wisseman.
Live Long And Prosper !

Peter