Multimedia Magazine 7/Multimedia-No7-11-1995.iso/APPLICAT/EDUCATE/VPADDONS/VPHT200.ZIP/VPHOST.DOC

Text File | 1994-11-13 | 39KB | 807 lines

VPHOST - VGA Planets host support utility.   (c) 1993-94  Sysma Automatisering



Disclaimer of Warranties
========================

The program is delivered to you as is. Although copyrighted,
Sysma Automatisering 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 and/or modify the program for your personal use.
You may (re)distribute this program or your own modifications, PROVIDED you
distribute the complete set of original files with your own modified ones
and you distribute them without charging any money or any other form of
compensation.


History
=======

12/11/94   Version 2.00   Added a command to report player passwords.
                          Incorporated the new storage engine also found in
                          VPUTIL, which, amongst other things, increases the
                          message limit a result file can handle to 500
                          messages.
                          Completely revamped the way VPHOST executes it's
                          commands. Commands are now batch orientied,
                          exploiting a configuration file. This was needed,
                          because of the many commands and features added.
                          VPHOST now comes in a DPMI version, because the
                          memory requirements exceed DOS's 640 Kb limit.
08/09/93   Version 1.99i  Fixed a bug in the shrink message function. The
                          messages did get smaller, but the terminating \0
                          character was not placed correctly, causing
                          rubbish trailing in the messages.
07/09/93   Version 1.99h  Added mine field report detection conforming to the
                          message format of HOST version 3.1x
06/09/93   Version 1.99g  Disabled the processing of the host mail base for
                          now, since it appearently causes occasional system
                          crashes. I haven't had time to investigate. Added
                          a function which strippes messages from superfluous
                          spaces and carriage returns. In certain messages
                          this means savings of up to 50 % in memory.
29/08/93   Version 1.99f  Added a max. allowed minefield switch to the
                          'check mine field' command.
21/08/93   Version 1.99e  Finally tracked down what caused the Duplicate Id
                          number error, which occationally occured when
                          reading in the Host Data Files. It turns out that
                          a Colonize mission causes the Ship's Id # to be
                          reset to 0. If two ships get colonized WITHOUT
                          immediately being reused by builing new ships, two
                          ships with Id # 0 exist, triggering the error. This
                          version fixes the problem.
18/08/93   Version 1.99d  Added the feature of adjustable mine field decay.
03/08/93   Version 1.99c  A few minor bugs were fixed.
07/08/93   Version 1.99b  Memory allocation and read/write logic changed again.
                          Allocation is now based upon single records and
                          therefore no limitation exists anymore.
                          Note that this version, although stable, is still in
                          beta testing. It is neither complete, nor tested
                          thorough enough to be guaranteed to work under all
                          circumstances. It is therefore advisable to make a
                          backup of your result and/or data files before using
                          this program.
25/04/93   Version 1.0    First public release of the program. Further
                          enhancements are already planned, but we are
                          awaiting feedback and bug reports of this version
                          first.


Introduction
============

This utility is designed to support and enhance the host part of the game
VGA Planets versions 3.0 only (ie. Planets.Exe). VGA Planets is a strategic
space war/economy simulation game for upto eleven players. The unique feature
of the game is that it plays the turns off-line. This means that there is a
game server (or Host) somewhere where the entire game universe exists. The
game server executes the commands the players provide each game turn and
provides the results, tailored to every player.

Each player gets the results meant for him and uses the game client program
(Planets.Exe) to view the results of the previous set of commands and to issue
new ones. Because each player gets only results from the host concerning his
own ships and planets, it is not possible to see enemy ships or planets when
the game rules don't permit this.

Build into the game is an E-mail facility, which enables the possibility to
send messages to other players. This E-mail facility is also used by the
automated host program to report information back to you regarding the previous
issued commands. You can use this E-mail facility just as you like. A good
purpose would be to perform diplomacy with it. Messages you send to a player X
don't arrive by player Y if you so choose.

At certain planets there are starbases in orbit. These starbases are very
important, as they act as your space ship factory and a space ship repair/refit
location. At every starbase a set of four technology levels are maintained. The
levels are for space ship hulls (ie. the frame to build a space ship),
transwarp drive engines, beam weapons and photon torpedoes. The higher a
techonoly level, the more powerfull the parts concerned become.


Purpose
=======

The purpose of this program is to fix certain flaws in the HOST.EXE program,
and to enhance the functionality of the HOST program of VGA Planets 3.0


DPMI protected mode version
============================

VPHOST is now available as a DPMI protected mode version only. This change
was needed, since the VGA Planets HOST normally needs to process an amount
of data that by far exceeds the capabilities of real mode DOS.

VPHOSTX is the 16 bits DPMI version, and requires at least a 286 machine
with 2 MB of RAM installed. It calls and uses RTM.EXE as it's DPMI service
provider. RTM detects and uses an already present DPMI server (such as HIMEM
or QEMM), but if a server is not yet installed, it installs it's own server
DPMI16BI.OVL, which must be locateable in the current directory, or via the
PATH.

VPHOST32 is the 32 bits DPMI version, and requires at least a 386 machine
with 2 MB of RAM installed. It calls and uses 32RTM.EXE as it's DPMI service
provider. 32RTM detects and uses an already present DPMI server, but if a
server is not yet installed, it installs it's own server DPMI32VM.OVL, which
must be locateable in the current directory, or via the PATH.

In addition, if you wish to spawn the 32 bits version from the MS Windows 3.x
environment, be sure to add the following line to your SYSTEM.INI file, in
the [386Enh] section:

device=d:\your\path\WINDPMI.386

Note that VPHOST as of version 2.00 needs substantially more memory that
previous versions, hence the DPMI releases. Both the 16 and 32 RTM versions
support swapfiles to make the necessary memory available on systems that are
not equipped with enough physical RAM.

VPHOSTX has the swapfile support hard coded build into the executable. It will
attempt to create an 8 Mb swapfile on the same drive and path as the host
game data is located in. When not enough disk space is free, the program will
abort.

VPHOST32 uses the paged swapping logic of the 32RTM program. To use this
feature, specify the following environment variable prior to running either
32RTM as TSR, or VPHOST32. Note that VPHOST32 automatically spawns 32RTM when
this program is not already loaded as TSR.

DPMI32=MAXMEM xxx SWAPFILE=d:\path\swapfile

In this setting, MAXMEM xxx is optional. If specified, xxx specifies the max.
amount of available XMS/extended memory to be used within VPHOST32.


The message transponder
=======================

As of version 2.00 of VPHOST, a message transponder is included. The purpose
of this transponder is to send any binary information from the host to the
players, or vice versa. Typically this transponder is used to pass information
from the host the the players that is not normally included in the result
file format currently in use.

Players may receive data via the transponder in any of three ways. The host
may have instructed VPHOST to send information manually, the player itself
may have requested information, or VPHOST may have initiated the transponder
itself based upon some internal processing condition.

The transponder sends the information in specially formatted messages, which
are not readable directly. The unpack result file routine of VPUTIL (version
2.50 upwards) and VPUNPACK (version 2.20 upwards) are capable of both
recognizing this special format and processing the messages. This means that
you normally would never see these messages, except for the results they
produce on your game data.


Support for team games
======================

If a file named TEAMS.TXT is present in the same directory as the host data
files, it is assumed to contain a list of teams and the assignment of the
players to a team. In this case, scores are calculated as accumulated team
scores and not as individual player scores. This feature enables a host to
let teams play against each other. The amount of ships, planets and starbases
of team members are automatically preserved, in order to keep team members
informed of their progress.

The syntax of the TEAMS.TXT file is very simple. Each line contains a team.
The first field is the team name (max 20 characters), the next fields are
the player numbers of the players assigned to the team. The fields are
separated with comma's.


New features not found in the HOST
==================================

Planets now have special friendly codes to dismantle surplus mines and
factories. Note that these friendly codes are for registered players only,
and that no refunds of any kind are given for mines and factories removed
in this way.

The new friendly codes are:
rmq = Remove a quarter of the mines on the surface
rmh = Remove half of the mines on the surface
rm5 = Remove 50 mines on the surface
rm2 = Remove 25 mines on the surface
rfq = Remove a quarter of the factories on the surface
rfh = Remove half of the factories on the surface
rf5 = Remove 50 factories on the surface
rf2 = Remove 25 factories on the surface

These FC's may be usefull when you are done producing and want a higher tax
return from your natives/colonists.

Starbases may be repaired using supplies from the planet's surface, just as
with space ships. 10 Supply units are needed to repair one percent of damage
to the starbase. Also, a special friendly code needs to be set on the planet
as well. The friendly code is REP, and may be used by shareware players as
well.

When recycling a foreign space ship at one of your starbases, you may try
reverse engineering this hull type. First the normal recycle command is
performed, destroying the ship and storing it's engine/weapon/torpedo parts
in the starbase store, and refunding the recovered minerals to the planetary
depots.

Then several checks are performed, of which the minerals check is the most
important one. You have to pay research costs for the reverse engineering job.
The cost is equal to the build cost of the hull type times a host
configurable factor, which by default is set to 2. This amount is deducted
from your planetary depots, if there is no shortage in one of them. Otherwise
you simply loose the hull type.

The last action for a successfull reverse engineering job is the selection
of a free hull slot. This means altering your section of TrueHull.Dat, so
you MUST have access to VPHOST's message transponder on the client (ie.
PLANETS) side. Otherwise the host side has a different hull list than you on
the client side, with all the nasty cheat check problems that arrise when
you try building a new ship.

The slot to use is determined by one of the special planetary friendly codes,
listed here:
r01 - r20 = Designate the hull slot number to use. If another hull type is
            already in this slot, you loose the capability of building this
            ship type in the future !
res       = Designate to use the first free slot. This only works if you
            currently have less than 20 hull types you can build.

When you abandon a planet with a starbase, the starbase stays in orbit and
is not destroyed. When you (or another player) then takes control of such
a planet 1 or more turns later, the starbase is taken as well.

Three scoring algoritms are included in VPHOST. These are the original
scoring system of the HOST, simply counting occupied planets, and a scoring
system that reflect a player's strength by adding the resources that (s)he
used to build ships, starbases and planetary structures. An example will
clarify the last scoring method:

   A starbase has the following build costs:
      402 Kt Tritanium      =   4.02 points
      120 Kt Duranium       =   1.20 points
      340 Kt Molybdenum     =   3.40 points
      900 Mega Credits      =   9.00 points
                               ------
      Total                    17.62 points

Two other files are also generated. The file SCORES.TXT contains the scores
in a plain ASCII file. The file SCORES.ANS contains the same score table, but
now with ANSI control sequences inserted. This file is mainly intended to
be posted on a BBS within the menu structure of such a BBS.


Included configuration editor
=============================

A new program, VPCONFIG.EXE, is included in this package. It can be used to
edit the configuration data of both the HOST and VPHOST simultaneously. It
uses the same screens as the configuration editor found in the VPUTIL program.

The editor consists of five screens, with each screen convering a particular
set of options.

Screen 1:   Ratio editor for each race. It handles the ground combat attack
            and defense factors, and the mining and tax rates.
Screen 2:   Race advantages editor. Configure which racial abilities are
            enabled or disabled.
Screen 3:   Generic options. Edit options not bound to one particular race.
Screen 4:   Enter racial names for each race.
Screen 5:   Editor for VPHOST's extra features. If actions with equivalents
            in the original HOST program are disabled, the original HOST
            program will perform those actions. Otherwise, VPHOST will take
            over those operations.


Commands
========

In this section the available commands of VPHOST will be covered. The general
command line syntax is to issue one command and zero or more appropriate flags.
A quick overview of the commands and flags follows below.

The commands are:                     The flags are:

bp  Execute batch commands            -wPath  Specify work dir for host data
ct  Check turn file for cheating      -pt     Process turn files
rp  Report player passwords           -pr     Process result files
rb  Report the battles                -pb     Process pre-host batch
rh  Report space ship hulls           -pa     Process post-host batch
re  Report space ship engines         -sm     Silent Mode. Echo problems only.
rw  Report space ship beam weapons    -sc     Skip cheat check on turn files.
rt  Report space ship torpedoes       -sh     Show hull costs.
sc  Send configuration to players     -sl     Show hulls in a single list.
sn  Send race names to players        -so     Show owners of hulls.
                                      -p??    Specify player Id # ??
                                      -t??    Specify (max) tech level ??
                                      -tm??   Specify min tech level ??

There are some flags vaild for more than one command, so they will be listed
here. All other flags and the meaning will be covered with the commands on
which they act.

   -wPath
   ------

   Specifies the directory 'Path' in which the player data files can be found.
   VPHOST will also look for the global data files in this specified directory.
   If it finds a complete set there, it will use them. Otherwise the current
   directory is assumed to contain these global data files. The latter is
   consistent with the behaviour of both PLANETS and HOST. The first
   possibility is an extention to allow games with different universes to
   be played and kept apart simultaniously.
   If neither the specified directory nor the current directory contain a
   complete set of global data files, the startup directory (ie. the
   directory containing VPHOST) is searched for these files.

   -p??
   ----

   Specifies a player Id number. Some commands allow this selection and limit
   their operation to the specified player. If no player Id is specified at
   the command line, all players present in the game are assumed.


Command bp
==========

This command is the core of VPHOST's universe processing. It consists of
four phases, and each phase may be executed separately. Each phase leaves the
universe in a consistent state after processing, to allow other tools to be
used as well.

   -sm
   ---

   Enable silent mode. When silent mode is selected, only the most minimal
   information is echoed to the console. This information includes which
   phase is entered, and any problems found during the processing of each
   phase.

   When silent mode is not selected (default), detailed information about
   the universe processing in each phase is echoed to the console, including
   statistical information.

   -sc
   ---

   Skip cheat checking when processing turn files. Normally, cheat checking
   will occur whenever a turn file is processed. Any commands that are found
   dubious are echoed to the console, and removed from the command stream,
   to prevent cheating to enter the main universe.

   -pt
   ---

   Execute the phase of processing the turn files. This phase should be done
   only once for each player every turn, since the commands a player has
   produced are incorporated into the universe, overwriting the previous
   state. Specifying a player Id is allowed, and processing limits to this
   player only in this case. A player's turn file is renamed to PLAYER??.OLD
   after this phase is completed. This automatically deletes the turn file
   and prevents the HOST from processing turn files. This is desirable, since
   the HOST contains nasty bugs when processing turn files.

   The following sub phases are handled for each turn file:

      + Resource consistency check.
        This sub-phase takes every object (ship/planet/base) for which one
        or more commands were handed in, and breaks them down to their basic
        building components (Mega Credits, Clans, Supplies, Ores). The test
        is simple, on each (x,y) location the totals before and after the
        commands are executed must be equal.
        This check thus catches adding, removal AND spontanious transfer
        of any resource !
        Furthermore, the target for a command (ship/planet/starbase) is
        checked for the actual ownership. If a player sends a command for
        an object that is not owned by this player, all commands for any
        object on the same (x,y) location are canceled.

      + Shareware version check
        Only entered when a turn file is send in by a player that used the
        shareware version of PLANETS. Any registered features detected are
        either blocked or rolled back to shareware allowed levels. This check
        extends to registered friendly codes. The checks only apply to the
        actual commands, not every object the player owns. In this way, a
        shareware Borg player (for example) keeps it's tech level 10 bonus
        after all natives are assimilated, which is clearly not the case with
        the original HOST. This is also one of the main reasons the HOST
        must be denied processing of turn files.

      + Cheating checks
        Remaining cheat checks are performed. These checks include the
        following:
        * Checking ships for excessive cargo and/or fuel.
        * Checking whether Mega Credits were converted back into supplies.
        * Checking whether ship parts were build without the appropriate
          tech levels. All illegal parts are destroyed. This test is run AFTER
          the shareware check reduces registered tech levels to the shareware
          allowed maximum, if appropriate.
        * Checking whether planet/starbase structures exceed their allowed
          maximum. Planetary structures are completely refunded, due to a
          known bug in PLANETS that actually 'allows' too may structures to
          be build. All other surplus structures are destroyed.
        * Checking whether structures and/or ship parts were illegally
          removed.
        * Checking whether the starbase fighter store contains too many
          fighters. Any surplus fighters are destroyed.
        * Checking whether torpedoes/fighters were illegally build (for ships
          in deep space) or removed (all cases).

      + Command execution
        All allowed changes are now incorporated into the main universe files.
        This is also the phase that sets a new player password, and sends
        messages to other players. The messages transponder is used to
        analyse the messages that are send.

   Unless stated otherwise, when a cheat is detected, ALL commands for ALL
   objects (ships/planet/base) on the same (x,y) location are blocked and
   removed from the command stream. This preventive action ensures that no
   cheat will ever make it into the universe data itself.
   Also, detailed information about any cheat detected is echoed to the
   console, allowing the host to take whatever action (s)he seems appropriate
   to take.

   -sc
   ---

   Skip the cheat checks. Used in conjunction with the -pt flag.

   -pr
   ---

   Execute the phase of generating result files. Basically, this produces the
   same results as the original HOST, but with three major differences. First,
   the external message base is checked, and any messages stored there are
   automatically tossed. Secondly, this command may be used on a single player
   Id and third, this command may be used any number of times on the current
   universe data, without the need to run the HOST at all.

   Some extentions are added, however. This routine may send ship, planet
   and/or starbase data of team members with a result file. Ships are send
   as scanned targets, not as the official ship records. Special care should be
   taken whenever starbase data of team members is send, since PLANETS cannot
   handle this correctly. VPUTIL, on the other hand, has no problems with
   starbase data of other players.

   This phase also generates the scoring messages and the mine field report
   messages. These messages are entered only in the result file and not in the
   HOST message base. Part of the alternate scoring system is the erasing of
   the object counters the HOST places in each player's result file. Only
   the counters of the player himself, it's team members and the counters
   of objects the host has enabled, are retained.

   -pb
   ---

   This command is intended to be run before the HOST itself, and after the
   turn files have been processed into the main universe. This phase is the
   most extensive one, and executes almost everything the HOST itself performs
   as well, specifically, the non incremental actions. This means, for example,
   that the HOST is still responsible for ship to ship/planet combat, ship
   movement, tax collection, mine and factory operations, structures decay and
   mine field handling. Everything else is handled by this command, in the
   following order:

   * Check and process planets.
     + Handle the new planetary friendly codes.
     + Reduce tax rates of natives to the minimal level that guarantees
       maximum yield. This prevents players from 'blowing up' planets with a
       tax rate of 100 %, which is a nasty way to play and is becoming more
       and more popular with many players.
     + Increase / decrease native government type whenever the native
       happyness state passes one of the thresholds. This feature allows for
       more subtle control over the natives that you rule. It also means that
       natives only start rioting when their government type has reached the
       state of Anarchy, which is more realistic as well.

   * Check and process starbases.
     + Check for reparation of a starbase using supplies, just as with space
       ships.
     + Check the build order of a new space ship against the parts present
       in storage.
     + Check the space ship fix/recycle commands, and execute the fix command.

   * Check and process space ships.
     + Check for ships that have no fuel. If a ship has no fuel, all orders
       except the beaming up of fuel are cancelled, including a primary
       enemy setting. Beaming up of fuel is processed as the first action
       if the ship has no fuel.
     + Beam down resources to a planet/jettison in deep space.
       Clans are not allowed to be jettisoned into deep space.
       As long as ANY fuel is in the ship, beaming is allowed and fully
       implemented, so no resources are lost. So if you beam all of your
       fuel out of your ship, everything you beam still arrives at the
       correct destination.
       If clans are beamed down and the planet is unowned, the planet will
       be colonized. When an abandoned starbase is still in orbit, the
       starbase is (re)taken as well.
     + Beam up resources from a planet's surface. When beaming up from a
       team member's planet, the friendly codes are not required to match.
       Beam up orders are always reset to exploration, whether a beam up
       order was successfull or not.
     + Repair space ships using supplies. This comes before the alchemy
       function, so Alchemy Ships may be repaired this way as well !
     + Execute alchemy and refinery functions. Also handle the build
       fighters and build torpedoes is space, using the 'mkf' and 'mkt'
       friendly codes respectively.
     + Check ship missions for validity.
       - Colonize (ie. decommission) is only allowed in orbit of unowned or
         your own planets.
       - Check tow mission against the new tow rules. Reset the tow mission
         if the tow fails to comply with any of the new rules that are
         enabled.
       - Check the intercept mission.
       - Check individual race advantage missions to see if they are enabled.
         If not enabled, these missions are reset to none.
       - Check the cloak mission. Reset the cloak mission if cloaking is
         not allowed. This also applies to ships with more damage than the
         cloak damage threshold allows for a successfull cloak.
       These checks ensure, amongst other things, that only one mission can
       be performed by each ship. The original HOST actually allowed a
       tow, intercept AND another mission simultaneously.
     + Evaluate any ground combats that resulted from beaming down orders.
       When evaluating the defense factor, defense posts of a starbase are
       included. When a planet is conquerred, the taxrates are reset to 0,
       and the happyness of both colonists and natives are reset to a random
       value betweem calm and happy. When a starbase is captured as well,
       the hull inventory is checked and rearranged to suit the new owner's
       hull type list. Any hull types the new owner is not capable of building
       are destroyed.
     + Check for any ships without fuel that must surrender to a starbase.

   * Check for starbase build commands, and execute the build command if one
     is found and is valid.

   * Check for space ships with a colonize (ie. decomission) command. The
     ship is taken apart, and the resources recovered are added to the
     planetary stockpile. If this happens over an unowned planet, and clans
     were on board, the planet will be colonized as well. Note that the
     check on space ships only allows a colonize mission on a ship when it
     is actually in orbit of either an unowned or one of your own planets.
     Finally, the ship build queue for this player is checked and if a build
     order is available, it is executed on this same ship slot.

   * Check for space ships that are designated to be recycled. The process is
     equivalent to the previous colonize command, except that the ship must
     be in orbit of your own starbases with a recycle command for this ship.
     When reverse engineering is enabled, the planet/starbase is checked for
     a reverse engineering friendly code. If one is found, the available
     planetary resources are checked as well. If sufficient resources are
     available, the price for reverse engineering is payed, and the new hull
     is added to the list of max. 20 hulls a player can build, scrapping
     another hull type if necessary.
     Note that reverse engineering only takes place on hull types not
     already in the hull type list for the player, and that sufficient
     resources must be present. The recycle command will ALWAYS be executed,
     so be carefull when reverse engineering !

   * Check for new space ships to be build.
     By default the same queue as the HOST uses is implemented, but this
     can be overridden by a more sophisticated one. This new queue
     implementation walks players before starbases. So first player 1 is
     checked for a build order, then player 2, player 3, etc. When player 11
     has been checked, player 1 is checked again for a second build order, etc.
     For each player the last starbase that build a ship is remembered. Also,
     the last player that executed a build order is stored, so the next time
     the queue continues at player Id + 1.
     The queue can be overridden by kill bonusses for each player. A kill bonus
     is added to a player whenever this player destroys an enemy ship. The
     kill bonus is cumulative over the turns VPHOST is run, and the bonus
     counter is reduced by one each time the player builds a ship.
     The effect of the kill bonus queue is that active players are rewarded
     for the risks they take and may fill up the slots their actions helped
     become free before non active players get a chance of building a ship.

   * Check for Federation refit commands.
     The HOST programs contain major bugs in handling the super refit, hence
     the implementation here. As you can see, Super Refit takes place after
     the building of a ship, so there is no chance anymore that a super refit
     takes the very components away that were intended for the new ship to
     be build at the same base.

   -pa
   ---

   This command is intended to be used immediately after the HOST has run.
   It checks the universe and cleans up any mess the HOST may have created.
   Typically, it calculates the CORRECT mass for each space ship in the
   universe.

   The following phases are executed:
   * Processing every combat and giving each player his correct build queue
     bonus based on the outcome of the battles.
   * Ship missions are checked for invalidated cloak mission (for example when
     a cloaker hits a mine and the damage is now higher than the cloak
     threshold. This is another example of a HOST bug that is fixed), and
     invalidated tow and intercept missions.
   * The scores are calculated and the host score files are produced.

Command ct
==========

This command performs the same actions as the bp command with the -pt flag.
The only difference is that execution of the commands doesn't take place. This
effectively produces a command to check a turn file for possible cheats. It
is possible to specify a single player Id.

Note that the -sc flag is also recognized by this command, but that this would
produce a meaningless command, since the sole purpose of this command IS cheat
checking.

Command rp
==========

This command reports the passwords each player has currently set for himself.
It is equivalent to Tim Wisseman's CRACK program.

Command rb
==========

This command lists all battles that were fought the last time the HOST has
run. It is possible to view all battles of one particular player. A host may
use this report to view the activity/progress in the game.

Command rh
==========

This command generates a report of all the possible space ship hulls a race
can build. The report comes in two parts, hull capabilities and hull costs.
It is possible to select one player and list only this player's hulls.

   -t??
   ----

   Specifies upto which technology level the space ship hulls should be
   included in the report. If omitted, technology level 10 is assumed.

   -tm??
   -----

   Specifies from which technology level the space ship hulls should be
   included in the report. If omiiied, technology level 1 is assumed. If both
   this flag and the previous one are specified, a subrange of technology
   levels can be created. If in this case the value for this flag is larger
   than the value for the previous one, this flag is treated as if it was
   not specified.

   -sh
   ---

   Generate a report with the building cost of the space ship hulls, instead
   of the hull specifications.

   -so
   ---

   Generate a report showing which races have a hull in their arsenal. This
   switch overrules the -sc switch if both are specified.

   -sl
   ---

   Generate the report as one continuous list, instead of compiling a list
   on a per race basis. This switch can be used together with the -so or -sc
   switch.

Command re
==========

This command generates a report of all the possible space ship engines every
race can mount on a space ship hull. The report shows both the cost and the
fuel usage factors for every possible warp factor.

   -t??
   ----

   Specifies upto which technology level the space ship hulls should be
   included in the report. If omitted, technology level 10 is assumed.

   -tm??
   -----

   Specifies from which technology level the space ship hulls should be
   included in the report. If omiiied, technology level 1 is assumed. If both
   this flag and the previous one are specified, a subrange of technology
   levels can be created. If in this case the value for this flag is larger
   than the value for the previous one, this flag is treated as if it was
   not specified.

Command rw
==========

This command generates a report of all the possible beam weapons every race
can mount on a space ship hull. The report shows both the cost and the beam
weapon effectiveness for both kill (crew) power and space hull destructive
(explosive) power.

   -t??
   ----

   Specifies upto which technology level the space ship hulls should be
   included in the report. If omitted, technology level 10 is assumed.

   -tm??
   -----

   Specifies from which technology level the space ship hulls should be
   included in the report. If omiiied, technology level 1 is assumed. If both
   this flag and the previous one are specified, a subrange of technology
   levels can be created. If in this case the value for this flag is larger
   than the value for the previous one, this flag is treated as if it was
   not specified.

Command rt
==========

This command generates a report of all the possible torpedo launchers every
race can mount on a space ship hull. The report shows both the cost and the
torpedo effectiveness for both kill (crew) power and space hull destructive
(explosive) power. The last cost value is the cost to build one torpedo to
be launched with the launcher. No cost for raw materials is given, since these
values are 1 Duranium, 1 Tritanium and 1 Molybdenum for all possible torpedoes.

   -t??
   ----

   Specifies upto which technology level the space ship hulls should be
   included in the report. If omitted, technology level 10 is assumed.

   -tm??
   -----

   Specifies from which technology level the space ship hulls should be
   included in the report. If omiiied, technology level 1 is assumed. If both
   this flag and the previous one are specified, a subrange of technology
   levels can be created. If in this case the value for this flag is larger
   than the value for the previous one, this flag is treated as if it was
   not specified.

Command sc
==========

Use the transponder to send the current configuration files to every player
that participates in the game. It is possible to select only one player to
send the information to.

Command sn
==========

Use the transponder to send the current race name settings to every player
that participates in the game. It is possible to select only one player to
send the information to.


Comments
========

When you have comments or find bugs, please do not hesitate to contact us.
Also, if you have ideas on how to expand the program or have suggestions for
new commands or options, please contact us.



Our email address is:

FIDO:      'Jan Peter Dijkstra' at 2:283/323.12
INTERNET:  [e-mail]
           [e-mail]


We can also be contacted by mail. Our mail address is:

Sysma Automatisering
tav. J.P. Dijkstra
Fazantstraat 169
7523 DP  Enschede
The Netherlands

Phone: [phone]
Fax:   [phone]