©	Configuration Parameters The Portable Host Version 3.2.3.5g Jump to Table of Contents

INDEX

• Introduction
• The PCONFIG.SRC File
• Parameters Grouped by Function
• General Options
• Movement Options
• Racial Abilities
• Planetary Options
• Space Mines
• Meteors
• Cloaking
• Wormholes
• Combat Options
• Combat Parameters
• Build Queue Parameters
• Parameters Listed Alphabetically

Introduction

PHOST 3 has over 210 configuration parameters that affect its operation. This gives the host a great deal of flexibility in how the game is run and provides many tools for the game designer who wishes to set up a custom scenario. With flexibility, however, comes the price of complexity. For players to memorize and understand the settings of over 210 parameters is a difficult task. Fortunately, all configuration parameters come with reasonable default settings. If the host does not wish to learn about the myriad configuration parameters, he/she can simply leave these settings at their default and rest assured that the game will work "sensibly". To reiterate PHOST's policy on complexity: PHOST is only as complex as you want it to be. Match PHOST's complexity to your own ability and experience.

PHOST's configuration parameters are stored in a file named PCONFIG.SRC, which is expected to reside in the game directory. The format of this file is described in the next section.

If you are only familiar with the original HOST program, note that this differs from HOST's configuration in that there is no HCONFIG program and no HCONFIG.HST configuration file. The PCONFIG.SRC file is the only configuration-related object for PHOST.

If you are familiar with PHOST 2.x, note that PHOST now reads the PCONFIG.SRC file directly, hence there is no need to compile the source file into a PCONFIG.HST file. Both the PCONFIG.HST file and the PCONFIG program have been eliminated in PHOST 3.

The subsequent sections in this document list the configuration parameters in the same order as they appear in the provided example PCONFIG.SRC files. That is, they are grouped according to related functionality. There is also an alphabetical listing of configuration options provided for reference.

Back to the index

The PCONFIG.SRC File

The PCONFIG.SRC file is a plain text file consisting of comments, section delimiters, and assignment statements. It is the assignment statements that set values for the various configuration parameters. The various PCONFIG.SRC files included in the PHOST distribution provide examples which you can modify.

The basic format of each assignment statement is:

Item = Setting [, Setting, Setting, ...]

where Item represents a configuration setting such as AllowMinefields or MineSweepRange. The Setting token represents the value to assign to this parameter. Numeric settings are simply integers, while boolean settings may take the values True, False, Yes, or No (there is no difference between True/Yes and False/No). Multiple settings are required for configuration items which are arrays (although most array-valued parameters allow shortcuts -- see below). In this case, each element is separated by commas or whitespace.

Comments

Comments in the PCONFIG.SRC file are marked by a line beginning with # (after any amount of whitespace). Comments may also be placed following all settings for a configuration item.

Multiple-Valued Assignments

Many configuration parameters are configurable on a per-player basis. This means that each player in the game can have a different setting for the parameter. A common example is the ColonistTaxRate configuration option. There are two ways of setting these parameters. The longhand way is to specify each value, like this:

ColonistTaxRate = 100,120,100,140,100,100,100,100,100,100,100

PHOST also allows a shorthand form of assignment when all players are to use the same parameter value:

ColonistTaxRate = 100

This shorthand assignment simply assigns the same value to all players.

Note that no in-between assignment format is possible. Either a single value may be specified, or all 11 values must be specified.

Sections

The PCONFIG.SRC file may be broken up into sections for use by different add-on programs and utilities. Each section is introduced with a line that begins with a % character and is followed by a section name. For example:

# The following line indicates a section pertaining
# to PHOST. All following assignments will be
# processed by PHOST (up to end-of-file or up
# to the next section delimiter).
% PHOST

PHOST will only process configuration option assignments in a section marked with a section name of PHOST (as in the example above). If there is no section marker, then PHOST assumes that by default all options apply to it and will therefore process all assignments up to the end of the file or the first section delimiter.

The purpose behind section delimiters is to allow add-on programs and utilities to have their own sections for configuring program operation, yet allow the host to only maintain a single configuration file (PCONFIG.SRC). Thus, the configuration information that applies to the add-on program can be placed in a separate section and it will not interfere with PHOST's operation. Note that the fine-grain hosting control configuration is also stored in the PCONFIG.SRC file, under the section name of PCONTROL.

Defaults

Each configuration item has a default setting. If a configuration setting is not specified in the PCONFIG.SRC file, PHOST uses the default value. A warning message will be displayed for each default assignment when PHOST runs. Default assignments are not recommended because they do not explicitly indicate to players the configuration parameters that are in use for a game.

Player Modifications

The PHOST command processor allows players to modify some of the configuration options, such as Language, AllowMoreThan50Targets, and FilterPlayerMessages. When these options are modified by players, a new PCONFIG.SRC file is written out by PHOST and the old file saved as PCONFIG.BAK. The new file is written to the game directory.

Back to the index

Parameters Grouped by Function

This section describes PHOST's configuration parameters, grouped according to related function. The order in which these descriptions appear matches the order of assignments in the PCONFIG.SRC files that are provided with the PHOST 3 distributions. See the next section for an alphabetical listing of configuration parameters.

Each configuration name is followed by the allowable range of values that this parameter can take, as well as icons that describe various attributes. These icons have the following meanings:

General Options

This parameter may be any character string containing up to 31 characters. PHOST makes no use of this value other than writing it to the control record in UTIL.DAT files (record type 13). Player-side utilities can display this name in order to attach a meaningful label to a result file.

This option allows a host to easily set up unregistered games. With this option disabled, all registered friendly codes and other registered-only functionality is disabled, even if a player is using a registered version of the client program.

This parameter indicates the method by which player scores are computed. With the None option, no scoring information is reported (i.e., the counts of all ships, planets, and starbases is set to 0). With the Compatible option, scores are reported in the usual manner.

This parameter enables or disables the inclusion of ship-planet battles in the ship tonnage scoring mechanism (i.e., the TONS.HST file). With this option enabled, a ship that conquers a planet/base in battle will have his tonnage score increased by the combat mass of the planet/base.

With this option enabled, player passwords settings are ignored. All player passwords are disabled.

This option is ignored as of PHost 3.4c.

In previous versions, this option controlled access to the bigtargets command of the PHOST command processor (see the "Command Processor" page). This command is now always enabled.

This option controls the generation of RST files. Currently, the DOS Planets client program can only accept a maximum of 50 scanned enemy ships (targets). Other utilities exist (such as VPUTIL) that can handle more than this number. With this option disabled, the RST files will contain a maximum of 50 targets (the closest 50 enemy ships scanned). With the option enabled, all scanned enemy ships are reported in the RST file, but the player must ensure that he/she does not unpack the file with the original UNPACK utility or havoc will ensue. Compatible external utilities must be used to process the results with this option enabled. This option is configurable on a per-player basis.

 For WinPlan players, this option has no effect. This option may be configurable by players using the bigtargets command processor command (if CPEnableBigTargets is enabled).

With this option enabled, player passwords settings are ignored. All player passwords are disabled.

This option controls access to the language command of the PHOST command processor (see the "Command Processor" page). This option must be enabled for players to use the language command.

This 12-element array of values specifies the language in which players are to receive PHOST messages. Element 0 of the array indicates the language that will be used to generate PHOST run-time diagnostic messages (for the host person). Elements 1 through 11 correspond to player numbers 1 through 11. This option may be configurable by players using the language command processor command (if CPEnableLanguage is enabled). If a player uses the above command, the PCONFIG.SRC file will be automatically modified by PHOST to reflect the change.

This 11-element array of values allows players to indicate whether or not they want their messages filtered. Message filtering is described in the Message Filtering section of the "Playing with PHOST" page.

The array elements correspond to player numbers 1 through 11. This option may be configurable by players using the filter command processor command. If a player uses the above command, the PCONFIG.SRC file will be automatically modified by PHOST to reflect the change.

This option controls access to the racename command of the PHOST command processor (see the "Command Processor" page). This option must be enabled for players to use the racename command.

RecycleRate

valid values: 0 through 100

This parameter indicates the percentage of a ship's mineral content that is salvaged after a ship is recycled at a starbase, disassembled using the Colonize mission, or after ship components are recycled using the dmp planetary friendly code. The minerals obtained from recycling are placed on the surface of the planet.

This parameter indicates the maximum distance from a player's planets and ships at which enemy ships are visible. This config option can be different for each player.

This parameter indicates the maximum distance from a player's ships at which enemy planets are within range for the Sensor Sweep and Bioscan missions. This config option can be different for each player.

With this option enabled, a single planet is chosen at random on every turn. If the planet has no natives, then the planet is given a random number of natives (of random type), with a random government type.

With this option enabled, the Merlin Class Alchemy Ship and Neutronic Refinery Ship are able to perform their special alchemy functions.

With this option enabled, the 3 terraforming ships (Bohemian, Eros, and Onyx) are able to perform their terraforming function.

Terraforming ships can only terraform when they have less damage than configured here. The default value is 100, so they can terraform regardless how damaged they are.

This option controls the rate at which science ships change a planet's temperature. This rate indicates the number of degrees of temperature change for every turn that a science ship is in orbit of a planet. This config option can be different for each player.

This option is obsolete. The ability to send non-anonymous messages is now solely controlled by AllowPlayerMessages.

In PHost 3.4a and before, this option controls access to the message command of the PHOST command processor (see the "Command Processor" page).

With this option disabled, player-to-player messages are not allowed. That is, players will not be able to communicate with each other unless the host provides the players with e-mail addresses of other players. This option was intended to allow for non-diplomacy games in which each player must try to win the game without the help of any other races. See also CPEnableRumor below.

This option has no effect. It is provided for backwards compatibility with PHOST 2.

This option controls access to the rumor command of the PHOST command processor (see the "Command Processor" page), and the *w* feature. This option must be enabled for players to use the rumor command.

In PHost version 3.4a and before, if the AllowPlayerMessages option is OFF, the rumor command is disabled, regardless of the CPEnableRumor setting.

In PHost 3.4b and later, this option can be enabled while AllowPlayerMessages is off, so players will be able to send anonymous messages only. When CPEnableRumor is off and AllowPlayerMessages is on, rumors will be sent as normal messages, with correct "FROM" line.

Alternate name for this option: AllowAnonymousMessages

This option controls access to the allies command of the PHOST command processor (see the "Command Processor" page). This option must be enabled for players to use the allies command.

When this option is set to External, the allies command is externalized.

This option controls whether or not alliance management commands (in the PHOST command processor) are implemented before or after combat. With this option disabled, a player can "backstab" his ally by breaking off an alliance in the same turn that he/she attacks the unsuspecting former-ally. This works because alliance management commands are implemented before combat. With this option enabled, however, the alliance management commands don't take effect until the end of host processing (after combat). Alliance status report messages are only generated by PHOST after alliance management commands take effect. Thus, the DelayAllianceCommands option also affects when these messages are generated. The alliance status messages always reflect the updated alliance status, be it before or after combat.

With this option enabled, then, a player will see that the ally has broken off the alliance and is given a one-turn window in which to implement actions to protect his empire.

This option controls access to the give command of the PHOST command processor (see the "Command Processor" page). This option must be enabled for players to use the give command. The gsN friendly code is still available for giving away ships, even if this option is disabled.

When this option is set to External, the give command is externalized.

This option controls access to the remote command of the PHOST command processor (see the "Command Processor" page). This option must be enabled for players to use the remote command. For more details on remote ship control, please see the "Remote Ship Control" page.

When this option is set to External, the remote command is externalized.

This option controls the use of the cln friendly code. Ship cloning is not possible unless this option is enabled.

This option controls the monetary cost of a cloned ship as a separate value for each player. Each entry in this array represents the cost of cloning a ship for that player, as a percentage of the ship's normal cost. For example, a value of 200 means that cloned ships will cost twice as many megacredits to build as they would cost normally. This config option can be different for each player.

 Note that in PHOST, the Privateers and Crystals are not prohibited from cloning, as they are in HOST 3.2. Their clone cost values may be set to 32767 however to make cloning very unattractive. Note, too, that this config option only affects the monetary (i.e., megacredits) cost of cloning. The mineral costs are not affected.

This parameter is currently unused.

This option controls access to the send command of the PHOST command processor (see the "Command Processor" page). This option must be enabled for players to use the send command or to use the special con planetary friendly code. If this option is disabled, then neither the send command nor the con planetary friendly code have any effect.

This option has no effect and is included only for backwards compatibility.

This config option either allows or denies access to the extended missions recognized by PHOST. See the "Extended Ship Missions" page for more details regarding extended missions. Also see the ExtMissionsStartAt config option below. When this option is disabled, WinPlan players that try to submit an extended mission order receive a yellow alert and the mission is not changed. Extended mission orders that come via the command processor interface are ignored and an error message is returned.

This config option is used to set the base value of the extended missions recognized by PHOST. See the "Extended Ship Missions" page for more details regarding extended missions. By default, this config option is 20 meaning that mission #20 is the Build Torpedoes mission, mission #21 is the Lay Minefield mission, etc. Changing the base value offsets all mission numbers accordingly.

The value of the ExtMissionsStartAt config option must be synchronized with the contents of the MISSION.INI file used by WinPlan and VPA players. If any DOS Planets players are in the game, then they too need to be told about the ExtMissionsStartAt value so that they may successfully use the extmission command processor command (see the "Command Processor" page).

The only purpose behind this config option is to allow PHOST's extended missions to co-exist with other add-on programs that may want to use the M.I.T. extended mission interface. If there are no other programs that use extended missions then this value may be safely left at 20. The only known program to use extended missions at the time of this writing is the FHost add-on, and this program uses extended missions starting at 200. Thus, there is no conflict with PHOST. Also see the AllowExtendedMissions config option above.

This config option is used to set the range of UFO numbers reserved by PHOST for the reporting of wormholes. From this start value ranging up to the next 200 values, PHOST will write out UFO's that represent wormhole scans (to WinPlan players only, of course).  Any existing UFO's from other programs in this range will not be seen!

For example, with WormholeUFOsStartAt set to 300, then UFO numbers in the range 300 through 499 will be reserved for PHOST's wormholes. Any UFO maintained by an add-on program whose UFO number is in this range will not be seen.

This config option enables the usage of a wraparound map. For more information, please see the "Wraparound Maps" page.

This 4-element array defines the boundaries of the wraparound map region, if a wraparound map has been enabled (using AllowWraparoundMap). For more details, please refer to the "Wraparound Maps" page.

This option controls the usage of the Beam Up Clans extended mission. With this option enabled, the extended mission allows ships to beam up clans from friendly planets.

This option controls the usage of the Beam Up Multiple extended mission. With this option enabled, the extended mission allows ships to beam up from friendly planets all types of minerals, as well as clans, supplies, and money, all at the same time. Clans cannot be beamed up unless AllowBeamUpClans is also enabled.

This option specifies whether players are permitted to see each others' ship names. At a setting of Yes (default), everyone can see the names, as usual. When set to No, visual contacts, battles, messages -- everything that cites alien ship names -- will only contain a dummy name ("Ship NNN"). When a ship changes ownership, in combat for example, its name will be padded out as well. The setting Allies will allow allied players (ship level) to see each others' ship names.

This option is intended for anonymous games, to avoid that people communicate via ship names, or recognize each other by their naming style. If you as a player want to prevent other people from seeing your names, there are a few utilities that do the trick client-side, so there's no need to bug your host :-)

Note that this option has bad (read: no) interaction with remote control. If there is a ship whose name you shall normally not see, you will see the name when you control the ship. The rationale is that setting up a ship-level alliance plus remote control requires enough communication so ship names are your least problem.

This option does not affect anything in the game, it affects how the configuration file is handled.

• Value 0 (default) is, well, the default behaviour.
• Value 1 causes PHost to complain (warning) if you forgot an optional setting. For example, the DisablePasswords option is normally not required and it doesn't harm to leave it out. With ConfigLevel = 1, PHost will warn you anyway.
• Value 2 causes PHost to complain if you forgot an unnecessary setting. For example, when AllowHiss is off, the HissEffectRate is not needed. At ConfigLevel = 2, PHost will complain if you left out such an option anyway.
The intention is that, when preparing a config file, you can increase the ConfigLevel to check whether you left out some option that is important to you. This setting itself is optional.

Movement Options

This option controls the gravitonic action of planets on nearby ships. With this option enabled, all ships that end their movements within a certain region near a planet are drawn into orbit of the planet by the planet's gravitonic attraction. This attraction region is either a square or a circle, depending upon the setting of the RoundGravityWells option.

This parameter indicates the size of a planet's gravity well. The default HOST behavior affords a region centered on a planet within which ships are affected by the planet's gravitational pull and are automatically placed into orbit around the planet. This parameter allows the "radius" of the region to be configurable. Gravity wells can be one of two shapes, depending upon the setting of the RoundGravityWells option. If round gravity wells are enabled, then gravity wells are circular regions and the GravityWellRange parameter indicates the radius of the circle centered on the planet which defines the gravity well region. If RoundGravityWells is disabled, then gravity wells are square regions and the GravityWellRange parameter indicates half the length of one of the square's sides. That is, the gravity well square is centered on the planet and has sides of length 2*GravityWellRange. This parameter has no effect if the AllowGravityWells parameter is not enabled.

If this option is enabled, then gravity wells are circular regions around a planet, otherwise they are square regions. The GravityWellRange parameter indicates the size of the region (i.e., the radius of the circle or half the length of the square's sides).

If this option is enabled, then the three ships capable of hyperwarping (PL21 Probe, B200 Class Probe, and Falcon Class Escort) are allowed to perform hyperwarp jumps.

If this option is enabled, then hyperwarping ships are affected by the same gravity wells as normal ships. Otherwise, a ship that is hyperwarping is not drawn into a planet's gravity well on the turn in which the hyperwarp takes place.

The hyperdrive will stop working when the ship has this much damage or more. The default setting is 100: hyperdrives work at any damage level. You may want to reduce this value; after all, damaged ships must slow.

With this option enabled, fuelless ships are able to move 1 LY per turn. In this type of movement, mine hits are not a concern.

With this option enabled, ships consume fuel based upon a differential time model in which the mass of the ship is updated continuously (the mass decreases since on-board fuel, which is consumed over time, contributes to total ship mass). As a result, ships will tend to consume less fuel (see the "Detailed Operation" page for the fuel consumption formula), although for short distances or low mass ships, they may consume more fuel due to rounding differences (in fact, a lack of rounding) as compared to HOST.

With this option enabled, the fuel consumption estimate given in the client programs will usually be slightly overestimated, which may be a good thing because some client programs can underestimate the fuel consumption. As mentioned above, over short distances or for low-mass ships, the fuel consumption may be underestimated. Turning this option on requires players to invest some time and effort into ensuring that no surprises befall them. If the players find that trusting the client-program fuel estimates is more important than using the accurate fuel consumption model, then this option should be turned off.

With this option enabled, all ships are allowed to perform the Tow mission. With the option disabled, only ships with two or more engines are allowed to tow.

This option controls how towed ships behave if the ship that is towing them runs out of fuel or is destroyed by a mine. With this option disabled, all movement for both tower and tow target stops once the tower either runs out of fuel or is destroyed by a mine hit. If this option is enabled, however, then the ship that was being towed will use the remaining amount of movement time to move towards its original waypoint at its current speed. That is, the towed ship breaks free of the tow and performs its own movement if the tower can no longer maintain the tow (due to lack of fuel or to having been blown up).

This option controls the way in which towing is implemented. Disabling this option causes towing to work in a HOST-compatible manner. With alternative towing enabled, a different model is used that takes into account engine tech, number of engines, warp speed, and distance to waypoint. More details can be found in the Towing section of the "Playing with PHOST" page.

These options affect tow strength computations. Increasing TowStrengthEngineScale puts focus more onto the ship's equipment, TowStrengthDistanceScale focuses the distance it can move.

These parameters have default values of TowStrengthEngineScale = 1 and TowStrengthDistanceScale = 19, respectively, and we recommend you to use these. Note that in PHost versions before 3.4b, the defaults were hard-coded as 163 and 1 (which gave the ship's equipment a huge effect, making big ships almost un-towable even when they didn't move). When you switch from such a PHost version to 3.4b or higher in mid-game, you should probably set these values to 163 and 1 to not offend anyone.

Racial Abilities

This array indicates the racial abilities that each player will be given. Normally, player 1 plays race 1 (Federation), player 2 plays race 2 (Lizards), etc. This customary mapping of player number to race number can be modified with this config option. Each player may be assigned a race number from 1 through 11, or be given the special race number 12 to indicate that no racial abilities will be available. Any number of players may play the same race. In the extreme, all players may play the same race, or all players may play without racial abilities.

For more information, please see the Non-Standard Race Assignments section on the "Hosting with PHOST" page.

 NOTE: This option should only be enabled if all players in a game are using VPA.

This option works together with the PlayerRace config option to control the list of ships that a player can build. Setting MapTruehullByPlayerRace to Yes causes the ship list in use to be mapped by effective race, not player number. In other words, it is the race that you are playing (as determined by PlayerRace) that determines which ships you can build. Setting MapTruehullByPlayerRace to No causes the ship list in use to be mapped solely by player number; the PlayerRace config option is not used. Thus, it is simply your player number (not race) that determines which ships you can build.

To be more specific, the list of ships that a player can build is contained in the TRUEHULL.DAT file. This file contains 11 slots of 20 ships each, each slot describing the 20 ships that a given player can build. The MapTruehullByPlayerRace setting determines whether this file is indexed by player number or by effective race (as determined by PlayerRace).

As an example, both player #1 and player #2 are playing race #9 (Robots). With MapTruehullByPlayerRace enabled, both players can build the 20 ships contained in slot #9 of TRUEHULL.DAT. Thus, if the host simply uses the default TRUEHULL.DAT file that comes with a ship list, both players will see a list of ships that is "correct", i.e., belongs to race #9. The above is only true, of course, if the player is using a client program (currently, only VPA) which recognizes the MapTruehullByPlayerRace config option. With MapTruehullByPlayerRace disabled, player #1 will be able to build the ships described by TRUEHULL.DAT slot #1, and player #2 will be able to build the ships in slot #2. It is up to the host to modify the TRUEHULL.DAT file to contain the ships that each player is allowed to have.

 Thus, setting MapTruehullByPlayerRace to No entails more work for the host, but also allows greater flexibility in that two players can play the same race, yet have different ship lists.

With this option enabled, the Federation is afforded certain advantages in battle. Their ships are given an automatic hull mass bonus of 50 KT. All of their beam weapons, tubes, and fighter bays are available to fire, regardless of the ship's damage. Finally, their ship's shield levels are raised by 25 units from one battle to the next on the same turn.

In the HOST program, Federation ships are also given an extra 3 fighter bays in combat. In PHOST 3, this feature is controlled by the ExtraFighterBays config option.

With this option enabled, the Federation Super Refit mission can be performed.

With this option enabled, the Loki Class Destroyer will uncloak all ships within a 10 LY radius of its position.

Anti-cloak ships (Loki) can only decloak enemy ships when they have less damage then configured here. The default is 20, meaning that only Lokis with 0 to 19% damage can decloak.

Enabling this option gives a player immunity to his own anti-cloak ships, and removes the special immunity for the Federation and the Lizards. The own-player immunity also extends to allies who have been granted the ship level of alliance. Please see the Alternative Anti Cloak section of the "Playing with PHOST" page for more details.

A player with anti-cloak immunity will never have his cloaked ships decloaked by anti-cloak devices (i.e., the Loki).

 Note that in HOST, anti-cloak immunity is a racial ability given to the Federation, Lizards, and Birdmen. As of PHOST 3.2.3.2, anti-cloak immunity is now a player ability and care needs to be taken if the PlayerRace config has been modified. Assigning one player to play race 1, 2, or 3 does not automatically afford them anti-cloak immunity; it must be enabled using this AntiCloakImmunity option.

 Note that this option does not interact with the AlternativeAntiCloak option described above. For HOST compatibility, AlternativeAntiCloak should be set to No and AntiCloakImmunity should be given to Federation, Lizard, and Birdman races. When AlternativeAntiCloak is enabled, remember to remove anti-cloak immunity from the Federation and Lizard races (if so desired).

With this option enabled, the Lizard Hiss mission can be performed.

HissEffectRate

valid values: 0 through 100

This parameter controls the amount of happiness increase effected by a single ship performing the Lizard Hiss mission. The exact usage of this parameter is described on the "Detailed Operation" page.

This parameter controls the maximum number of ships that can perform the Hiss mission at any one planet. If more than the configured number of ships are hissing at one planet, the excess ships will have no effect upon the happiness levels of the colonists and natives. Together with the HissEffectRate config option, the maximum increase in happiness that can be effected via the Hiss mission is HissEffectRate*MaxShipsHissing.

This parameter indicates the percentage chance that a Birdman ship performing the Super Spy mission will be detected by the planet. For example, a value of 20 indicates a 20% chance of discovering a Super Spy mission in progress. Note that this parameter is unrelated to the Deluxe Super Spy mission.

With this option enabled, the two ships outfitted with Glory Devices (the D19b Nefarious Class Destroyer and Saber Class Frigate) are allowed to use them.

This option controls the use of multiple Klingon ships in performing the Pillage mission. With this option enabled, each ship performs its own independent Pillage mission, for cumulative effect. With the option disabled, only one ship is allowed to pillage any given planet on a single turn. Among multiple ships, the ship with the lowest ID number will perform the pillage.

RobFailureOdds

valid values: 0 through 100

This option indicates the percentage chance that a Privateer rob attempt will fail. When a rob attempt fails, the ship attempting to rob fails to rob any of the ships that are candidates for robbery.

With this option enabled, the Lady Royale Class Cruiser can generate credit revenue from on-board clans.

With this option enabled, the Crystals and Privateers are able to capture ships in space by using a Tow mission. Note that the two options AllowPrivateerTowCapture and AllowCrystalTowCapture further limit this ability to the Privateers and Crystals separately. That is, if AllowBoardingParties is enabled, then the Privateers can perform tow capture only if AllowPrivateerTowCapture is enabled, and similarly for the Crystals.

This option is only meaningful if AllowBoardingParties is enabled. Then, if AllowPrivateerTowCapture is enabled, then the Privateers are allowed to perform tow capture.

BorgAssimilationRate

valid values: 0 through 100

This parameter indicates the percentage number of existing colonists that are used to convert natives into Cyborgs.

This parameter is arrayized and can be set to a different value for every player. It affects only players who actually play Borg, i.e. whose PlayerRace is 6.

This option enables chunneling via the Firecloud Class Cruiser.

This option defines the damage level which causes chunneling to fail. At the default, 100, any Firecloud may chunnel, because any ship has less than 100% damage. If you, for example, set this to 30, only Fireclouds which have less than 30% damage can take part in a chunnel (this limit is applied to both chunnel partners).

This option enables allies to chunnel to each other's ships without requiring both chunnelers to belong to the same player. Both players must be formal allies and must have the Ship Level of alliance enabled to each other. With this option disabled, both chunneling ships must belong to the same player for a chunnel to take place.

This specifies the minimum range of a chunnel. By default, the minimum range is 100 ly; you may want to lower that setting in small universes.

With this option enabled, the Crystals are allowed to lay web mines.

With this option enabled, the Crystals and Siliconoid natives (the latter in PHOST 3.3c and later only) favor hot planets over temperate ones. Their growth rates, maximum populations, etc. are all based upon a target temperature of 100 degrees rather than 50 degrees as for the other races (see the "Detailed Operation" page for more details).

This option controls the maximum number of colonists and growth rate of colonists for Crystalline planets when the CrystalsPreferDeserts option is enabled. Without CrystalSinTempBehavior enabled, colonist growth is linear in temperature, as is the maximum number of colonists. With this option enabled, both growth and maximum number of colonists follows a sinusoidal curve with the peak occuring at a temperature of 100. However, there is no growth below temperatures of 15 degrees and the maximum number of colonists below this temperature is limited to the same number of colonists as other races. This option gives a slight boost to the Crystals since it allows more colonists to thrive and provides for quicker growth (on non-arctic planets) than for the linear model.

Although, since PHOST 3.3c, Siliconoid natives are affected by the CrystalsPreferDeserts option, they are not affected by this option. Growth is always linear for Siliconoids.

This option is only meaningful if AllowBoardingParties is enabled. Then, if AllowCrystalTowCapture is enabled, then the Crystals are allowed to perform tow capture.

DarkSenseRange

valid values: 0 through 32767

This option controls the distance at which Empire ships are able to perform their Dark Sense mission. All planets within this range from an Empire ship using the Dark Sense will be sensed, except for Rebel planets which cannot be sensed at all.

This option allows the Empire to capture planets using the Imperial Assault mission from a Super Star Destroyer.

This option enables the use of the Robots' Build Fighters mission.

This option allows the Rebels to build fighters on-board their ships.

This option allows the Rebels to perform their Ground Attack mission.

This option controls whether or not the Rebel Ground Attack mission may be performed on unowned planets.

With this option enabled, Rebel ships must have beam weapons in order to perform the Ground Attack mission. This feature is meant to parallel the necessity of beams for performing Pillaging and Hissing.

This option allows the Colonies to perform their Build Fighters mission.

This parameter indicates the number of KT of neutronium generated for every light year travelled by a Cobol Class Research Cruiser. No fuel is generated by the ramscoop if the ship is being towed or is on an intercept mission.

With this option enabled, the Aries Class Transport is allowed to perform its neutronic refinery process (converting minerals to fuel).

With this option enabled, the ships equipped with Bioscanners (the Cobol, Pawn, and Brynhild) are allowed to perform their bioscanning functions.

Planetary Options

This option allows planets to use the ATT and NUK friendly codes to become aggressors in combat (see the "Order of Battle" page). With the option enabled, planets can attack enemy ships that come into orbit.

When AllowPlanetAttacks is enabled, this option determines whether planets are allowed to attack Rebel ships. With the option disabled, Rebel ships are immune from being attacked by planets.

When AllowPlanetAttacks is enabled, this option determines whether planets are allowed to attack Klingon ships. With the option disabled, Klingon ships are immune from being attacked by planets.

This parameter indicates the minimum number of defense posts on a planet necessary to make the planet totally impervious to sensor sweeps. Planets with this many (or more) defense posts will not show up on ship sensor scans. Planets with fewer defense posts will show up with a probability determined by the number of defense posts (see the "Detailed Operation" page and the FactoriesForDetectable and MinesForDetectable options).

This parameter indicates the minimum number of factories on a planet which must exist for the planet to show up on ship sensor scans. If there are fewer than the minimum number of factories required, the planet will not be scannable (unless there are sufficient mines instead, see the MinesForDetectable parameter). Also see the DefenseForUndetectable parameter.

This parameter indicates the minimum number of mines on a planet which must exist for the planet to show up on ship sensor scans. If there are fewer than the minimum number of mines required, the planet will not be visible to sensors (unless there are sufficient factories instead, see the FactoriesForDetectable parameter). Also see the DefenseForUndetectable parameter.

AllowEatingSupplies

valid values: Yes No

When this option is enabled, colonists on planets which are overpopulated will consume supplies in their efforts to survive. The amount of supplies consumed is described on the "Detailed Operation" page. Enabling this option also increases the maximum climate-limited population supported on a planet based upon the number of supplies on the planet.

This option controls the maximum population on planets as well as the growth rate of colonists on planets. With this option disabled, a planet's temperature has no effect on the growth and limits of a planet's population. Several formulas (described on the "Detailed Operation" page) are affected by this option.

ClimateDeathRate

valid values: 0 to 100

This parameter controls the rate at which colonists die on overpopulated planets. This parameter has no effect if ClimateLimitsPopulation is disabled.

Like the original HOST ClimateDeathRate parameter, this parameter indicates the percentage of the native population that is to die on a given turn if the population exceeds the maximum allowable for the planet. If the parameter ClimateLimitsPopulation is off then the NativeClimateDeathRate parameter has no effect.

This parameter controls the maximum colonist population allowed on arctic and desert planets (see the "Detailed Operation" page for the actual formula). This parameter allows the host to determine how useful arctic and desert planets are in terms of supporting colonists and hence industry.

This parameter controls the rate at which new minerals are generated in a planet's core due to transuranium decay (also known as the Transuranium Decay Rate, or TUDR). The density of a mineral in the planet is also a factor. The governing equation is given on the "Detailed Operation" page.

This parameter indicates the number of mines, factories, and defence posts that a planet will lose on each turn for which these structures exceed the maximum allowed by a planet's population. This config option can be different for each player.

New PHost 3.4: Because structure decay happens on unowned planets, too, you can set the decay rate separately for those.

This array stores a player-dependent parameter indicating the rate at which minerals may be extracted from a planet's core. A base value of 100 is the default, indicating that the mining rate is the same as the mineral density. This config option can be different for each player.

This array stores a player-dependent parameter indicating the taxation rate for colonists. A base value of 100 indicates that tax revenues match the values predicted by the client programs. A value of 200, for example, doubles the rate of colonist taxation. A value of 50 halves it. This config option can be different for each player.

Alternate name for this option: RaceTaxRate

This array stores a player-dependent parameter indicating the taxation rate for natives. A base value of 100 indicates that tax revenues match the values predicted by the client programs. A value of 200, for example, doubles the rate of native taxation. A value of 50 halves it. This config option can be different for each player.

This array stores a colonist growth rate percentage for each player. The base value of 100 means that colonists grow at 100% of the usual rate (as determined by the usual factors of temperature, happiness, etc.) Higher or lower RaceGrowthRate values affect this growth rate in proportion. For example, a RaceGrowthRate of 50 means that colonists will grow at half the rate that is determined by temperature, happiness, etc. Please see the "Detailed Operation" page for the exact formula used for colonist growth.

This array stores a supply production rate percentage for each player. The base value of 100 means that production proceeds at 100% of the usual rate (as determined by the number of factories, Bovinoid natives, and the number of colonists on the planet). Higher or lower ProductionRate values affect this production rate in proportion. For example, a ProductionRate of 50 means that supplies are produced at half the nominal rate. Please see the "Detailed Operation" page for the exact formula used for supply production.

MaxPlanetaryIncome

valid values: 31-bit integer >= 0

This parameter indicates the maximum number of megacredits that a planet may generate on one turn from both colonist and native taxation revenue combined.

This parameter indicates the number of fighters that a starbase will build automatically on each turn, without money. The required minerals for fighter construction must still be present on the planetary surface and will be consumed as usual. This config option can be different for each player.

This parameter indicates the number of free torpedoes a planet gets in combat for every torpedo tube a planet has. This option is relevant only if the PlanetsHaveTubes option is enabled. The number of planetary tubes and torps are given by formulas described on the "Detailed Operation" page.

This parameter indicates whether starbases are allowed to use their torpedoes in combat. This is the default. If you turn this option off, planets can only use their free torpedoes (from the PlanetaryTorpsPerTube setting). This option is relevant only if the PlanetsHaveTubes option is enabled.

This parameter indicates the minimum happiness on a planet after it is conquered in regular combat, conquered in ground combat or Imperial Assault, or colonized by dropping clans or using the Colonize mission.

If natives are unhappier than the value specified in this option (e.g. from excessive taxation), they'll be improved to this value. The same goes for colonists, with the exception that newly colonized planets always start with happiness 100, i.e. the maximum possible.

This option is intended to limit the damage a player can do to a planet he is sure to lose. It does not limit happiness on a planet which remains under a race's control; RGA or excessive taxation may make a planet unhappier than configured here. This option also has no effect on voluntary planet trades (give planet command).

This option exists in PHost since version 3.5c, and has a default value of 20. Previous versions behave as if it had the value -300, and thus do not limit happiness beyond the hard limit implied by all happiness computations.

Space Mines

This option controls the use of minefields. If this option is enabled, then ships may lay minefields.

This option specifies the maximum number of minefields that can exist in the game. By default, there can be only 500 minefields. You can raise that limit up to a value of 10000. Players must enable access to high-ID minefields (ID > 500) using the bigminefields command of the PHOST command processor (see the "Command Processor" page). It is unknown which clients can handle high-ID minefields. (Note that you can also set the limit lower than 500 if you wish)

Minefields with IDs higher than 500 are stored in a separate host data file and will be ignored by HOST or older PHOST versions.

Alternate name for this option: NumMinefields

This option controls the generation of RST and UTIL.DAT files. If disabled then only minefields with IDs less or equal than 500 will be reported. (This option has no effect if CPNumMinefields is disabled.) Clients usually scan the player messages to gather information about minefields. However, since HOST had a 500 minefield limit it is unknown if (and which) utilities can handle minefields with IDs higher than 500.

  This option may be configurable by players using the bigminefields command processor command.

This option has no effect if the CPNumMinefields option is set to a value of 500 or less.

This parameter can be used to limit the number of minefields each player is allowed to have. It is intended to prevent that players lay many ``junk'' minefields to fill up minefield slots and prevent their enemies from laying.

When a player already has as many minefields as configured here, he will not be able to lay more minefields. The default value, 10000, means each player can fill all mine slots if the other players let him, like in earlier versions of PHOST and HOST.

The current number of minefields and the limit will be reported to the players each turn by a message and a UTILx.DAT record.

Note that PHOST never deletes minefields over the player limit.

If you lower this limit, consider setting AllowMinefieldIdentity to Allies or No.

The AllowMinefieldIdentity option configures whether players are allowed to lay minefields in other players' identity (e.g. using the Lay Minefield extended mission or the miX friendly code). It extends the older MineIdNeedsPermission option which is still accepted.

AllowMinefieldIdentity	MineIdNeedsPermission	Effect
No	-	Feature is not available.
Yes	No	Feature is available.
Yes	Yes	A player can only lay minefields in another player's name if the other player agrees. Agreeing means both players must be allied, and the (future) owner of the minefield must offer a minefield alliance level to the owner of the ship. The idea is that the minefield owner allows the ship owner to spend one minefield slot.
Allies	-	Same affect as Yes/Yes case above.

The MineIdNeedsPermission option is now redundant; we recommend using AllowMinefieldIdentity=Allies to achieve the same effect as MineIdNeedsPermission=No.

This parameter controls the maximum radius of any minefield at any time. When laying minefields, the number of torps converted to mines is limited so that the final size of the minefield does not exceed this limit. This config option can be different for each player.

This parameter controls the maximum radius of Web minefields. It defaults to the same value as MaximumMinefieldRadius.

This array of parameters indicates the rate at which torpedoes are converted to space mines and vice versa. Each player has his own configurable rate. The base rate value is 100 meaning that one Tech 10 torpedo generates 100 mines. See the "Detailed Operation" page for the exact usage of this parameter in laying and scooping minefields.

Up to PHost 3.4l, this parameter affected normal mines and web mines. Since 3.4m, web mines are controlled by UnitsPerWebRate below.

This parameter is the same as UnitsPerTorpRate, but it affects web mine laying. If this parameter is not specified, the same value as for UnitsPerTorpRate is used.

When this option is enabled, two minefields that overlap will destroy each other, mine-for-mine, until the minefields no longer overlap.

This mutual destruction occurs after the mine laying pass. With AlternativeMinesDestroyMines enabled, it also happens when a minefield is laid.

This option only has an effect when AllowMinesDestroyMines is enabled. When these options are both on, mines that overlap due to mine laying will immediately explode. This is the only behaviour available in PHost 3.4e and below.

When this option is off (default), all mine laying actions are processed first, and intersections are checked later.

When this option is enabled, the action of the AllowMinesDestroyMines option is extended to web mines. Basically, this option can be interpreted as controlling whether or not web mine fields interact with normal minefields. If this option is enabled, then web mines can destroy normal mines and vice versa. With this option disabled, web mines can only destroy web mines, and normal mines can only destroy normal mines. If the AllowMinesDestroyMines option is disabled, then the AllowMinesDestroyWebs option has no effect.

When this option is enabled (default), players can use Universal Minefield Friendly Codes (mfX) to grant their allies immunity to their mines. Since this can also be achieved by a minefield-level alliance in a less fragile way, the Universal Minefield Friendly Code can be turned off now.

When this option is off, friendly codes starting with mf are no longer special. Attempting to use Super Spy to set a planet's friendly code to mfX will no longer automatically trigger the Ionic Pulse.

This parameter controls the distance at which a minefield becomes visible to a ship performing the Mine Sweep mission. This config option can be different for each player.

This parameter indicates the percentage chance per light-year travelled of hitting a mine, when travelling through a minefield at warp 9. Travel through minefields is modelled as a series of random, independent events, so that each light-year travelled incurs a fixed probability of hitting a mine (nominally given by this parameter). This config option can be different for each player. The MineOddsWarpBonusX100 parameter can modify this probability based upon the ship's warp speed. The MineHitOdds parameter indicates the base mine hit probability for a ship travelling at warp 9; the actual probability may be lower depending upon the ship's speed and the setting of MineOddsWarpBonusX100 (as well as another parameter, MineTravelSafeWarp). See the Minefield Travel section of the "Playing with PHOST" page for a more detailed discussion of mine hit probabilities.

This parameter can be used to reduce a ship's chances of hitting a mine based upon the ship's speed. It is proposed that slower ships have lower chances of mine hits since they have more time to detect and avoid mines. This parameter indicates the reduction in mine hit probability as a function of drop in warp speed below warp 9. The default value for this parameter is 0, indicating no reduction in probability. This config option can be different for each player.

For more details, please see the Minefield Travel section of the "Playing with PHOST" page.

This parameter indicates the highest warp speed at which uncloaked ships can travel through a normal (not web) minefield without any chance of hitting a mine. That is, travelling through a normal minefield at this speed or lower is completely safe. The default value for this parameter is 0 meaning that travel is never safe. This config option can be different for each player.

This parameter allows the damage suffered by ships hitting mines to be configurable. This parameter can be interpreted as the percentage damage inflicted on a 100 KT ship as a result of a single mine hit. By default, this parameter is 100 indicating that a 100 KT ship will suffer 100% damage (this is the default HOST behavior). Reducing this parameter to 80, for example, means that a 100 KT ship will only suffer 80% damage and an 80 KT ship will suffer 100% damage.

This parameter indicates the percentage of mine units that disappear from a minefield on each turn due to natural decay processes. This config option can be different for each player.

This parameter indicates the number of mines that a single Tech 1 beam weapon can sweep on one turn. The formula for computing the total number of mines swept is given on the "Detailed Operation" page. This config option can be different for each player.

This parameter indicates the distance at which beam weapons are able to sweep minefields. This config option can be different for each player.

This parameter is similar to the MineHitOdds parameter except that it applies to web mines. It indicates the percentage chance that a ship will hit a mine on each light-year of travel through a web mine field (when travelling at warp 9). This config option can be different for each player.

This parameter can be used to reduce a ship's chances of hitting a web mine based upon the ship's speed. Both cloaked and uncloaked ships are affected by this parameter. Please see the Minefield Travel section of the "Playing with PHOST" page for more details. The default value for this parameter is 0, indicating no reduction in probability. This config option can be different for each player.

This parameter indicates the highest warp speed at which ships can travel through web minefields without any chance of hitting a mine. That is, travelling through a web minefield at this speed or lower is completely safe. Both cloaked and uncloaked ships are affected by this parameter. The default value for this parameter is 0 meaning that travel is never safe. This config option can be different for each player.

WebMineDecayRate

valid values: 0 through 100

This parameter indicates the percentage of mine units that disappear from a web mine field on each turn due to natural decay processes.

This parameter is similar to the MineHitDamageFor100KT parameter except that it applies to web mine hits. That is, for the default web hit damage of 10, a 100 KT ship will suffer 10% damage (this is the default HOST behavior).

This parameter controls the amount of fuel drained each turn from ships stuck in web mines. This amount is drained unconditionally, even when the ship just sits in the mines.

This parameter controls the amount of fuel drained each turn from ships that hit a web mine. The fuel amount lost is 1/6 of the ship's fuel tank, or the value specified here, whichever is greater. The default is 50. This amount is drained in addition to the WebDrainFuelLoss.

This parameter indicates the number of web mines that a single Tech 1 beam weapon can sweep on one turn. The formula for computing the total number of web mines swept is given on the "Detailed Operation" page. This parameter may be different for each player.

This parameter indicates the maximum distance at which beam weapons are able to sweep web mine fields. This config option can be different for each player.

This parameter controls the maximum distance at which fighters are able to sweep mines. The default (fixed) value of the original HOST is 100 LY for Colonial ships and 0 for other ships. This config option can be different for each player.

 Note that this config option replaces the original ColonialFighterSweepRange rate, which applied to Colonial ships only. This new option allows all players to sweep using fighters. To disable minefield sweeping with fighters for a player, set the FighterSweepRate config for that player to 0.

This parameter controls the number of mine units that a single fighter can sweep from a minefield. This config option can be different for each player.

 Note that this config option replaces the original ColonialFighterSweepRate option, which applied to Colonial ships only. This new option allows all players to sweep using fighters. To disable minefield sweeping with fighters for a player, set the rate to 0.

This option controls whether or not Colonial fighters are able to sweep web mine fields. With this option disabled, Colonial fighters are only able to sweep normal minefields.

This option currently has no effect.

This parameter indicates the minimum hull tech level of ships that are not to have their movement shortened by 10 LY for each mine hit. This parameter also selects between the strategy used to limit travel after a mine hit. For more details, please see the Mine Travel section of the "Playing with PHOST" page.

Meteors

This parameter indicates the percentage chance that on each turn a single large meteor will impact on a random planet.

This parameter indicates the percentage chance that any planet will be struck with a meteor shower on each turn. All planets are considered independently.

This array indicates the range of mineral content that a meteor shower may add to a planet. There are 8 elements in this array and the elements are interpreted as follows:

Nmin, Dmin, Tmin, Mmin, Nmax, Dmax, Tmax, Mmax 

where Nmin is the minimum amount of Neutronium provided by a meteor shower, Nmax is the maximum amount of Neutronium from the meteor shower, etc.

This parameter indicates the number of meteors that should be forced to impact on planets on each turn. The affected planets are chosen at random. This parameter works independently of the RandomMeteorRate parameter so that there may be a fixed number of meteors impacting (configurable with this parameter) plus a random number of meteors on each turn.

This array indicates the range of mineral content that a meteor strike may add to a planet's core. There are 8 elements in this array and the elements are interpreted as follows:

Nmin, Dmin, Tmin, Mmin, Nmax, Dmax, Tmax, Mmax 

where Nmin is the minimum amount of Neutronium provided by the meteor, Nmax is the maximum amount of Neutronium from the meteor, etc.

This option has no effect as of PHost 3.4a. Meteor messages are always sent.

Cloaking

This parameter indicates the percentage chance that a Cloak mission or Super Spy mission will fail to cloak the ship on a given turn.

When this option is enabled, players receive messages whenever a cloaking mission fails due to random chance, lack of fuel, excessive damage, travel through a wormhole, or an ionic pulse. The only other possibility of cloak failure is via a tachyon pulse, but this case always sends out a message. With the AllowCloakFailMessages option disabled, players receive no indication that their cloaking devices have failed (except for the tachyon pulse case).

When this option is enabled, then cloaked ships may be robbed by the Privateers.

This option only has meaning if the RobCloakedShips option is enabled, otherwise it is ignored. In this case, the RobCloakedChance option indicates the percentage chance that a Privateer ship will rob a cloaked ship. This chance is applied on a per-ship basis, so that if there are multiple cloaked ships to be robbed, each one has an individual chance of actually being robbed. If RobCloakedShips is disabled, this option has no effect.

CloakFuelBurn

valid values: 0 through 1000

This parameter controls the amount of fuel consumed by ships that are cloaking. See the "Detailed Operation" page for the relationship between hull mass, this parameter, and the actual amount of fuel consumed. If a ship's fuel reserves fall below this level, then it is not allowed to cloak.

This parameter represents the percentage chance (scaled by a factor of 10) that a cloaked ship will hit a mine for each light-year of travel through a minefield (when travelling at warp 9). The true percentage chance is the value of this parameter divided by 10 (e.g., MineHitOddsWhenCloakedX10 = 5 means that a cloaked ship has a 0.5% chance of hitting a mine per light-year when travelling at warp 9). This config option can be different for each player. It is possible to reduce the per-light-year probability of hitting a mine based upon the ship's warp speed. Please see the CloakMineOddsWarpBonusX100 config option, as well as the discussion of Minefield Travel on the "Playing with PHOST" page.

This parameter can be used to reduce a cloaked ship's chances of hitting a normal (not web) mine based upon the ship's speed. Please see the the discussion of Minefield Travel on the "Playing with PHOST" page for more details. The default value for this parameter is 0, indicating no reduction in probability. This config option can be different for each player.

This parameter indicates the highest warp speed at which cloaked ships can travel through a normal (not web) minefield without any chance of hitting a mine. That is, travelling through a normal minefield at this speed or lower is completely safe. The default value for this parameter is 0 meaning that travel is never safe. This config option can be different for each player.

This parameter indicates the minimum damage level at which ships are not able to cloak. That is, ships which are damaged at this level or higher will not cloak. This includes ships performing the Super Spy mission.

This option controls the ability of ships to tow enemy ships while they are under cloak. With this option disabled, cloaked enemy ships cannot be towed (the tow mission will be cleared). Note that a player's own cloaked ships can always be towed, and an ally's cloaked ships can be towed provided that the ally has enabled the Ship Level of alliance to the player performing the tow. The setting of the AllowTowCloakedShips option does not affect these two cases.

With this option enabled, cloaked ships can take part in combat. If a cloaked ship has a primary enemy set, and a ship of that race is in the same position, then the cloaked ship will engage in battle with the enemy ship.

Wormholes

This option controls the use of wormholes in the game. If this option is enabled, then PHOST will look for a file named WORMHOLE.TXT in the game directory and use the wormhole descriptions contained there (see the "Wormholes" page for more details). If this file is not found, a warning is generated. If this option is disabled, then no wormhole activity takes place.

This parameter indicates the maximum predictable magnitude of displacement (in light years) of a wormhole's entry points to their destinations. See the "Detailed Operation" page for a complete description of wormhole movement.

This parameter indicates the maximum random magnitude of displacement (in light years) of a wormhole's entry points. See the "Detailed Operation" page for a complete description of wormhole movement.

This parameter specifies a constant and predictable stability factor to add to each wormhole on every turn. See the "Detailed Operation" page for a complete description of wormhole stability calculations.

This parameter specifies a maximum magnitude of random stability to add to each wormhole on every turn. See the "Detailed Operation" page for a complete description of wormhole stability calculations.

This parameter specifies a constant and predictable amount of mass to add to each wormhole on every turn. See the "Detailed Operation" page for a complete description of wormhole mass calculations.

This parameter specifies a maximum magnitude of random mass to add to each wormhole on every turn. See the "Detailed Operation" page for a complete description of wormhole mass calculations.

This option controls the use of the WRT friendly code for wormhole travel. If this option is enabled, then ships must set their friendly code to WRT in order to travel through wormholes. If this option is disabled, then ships need only be near a wormhole's entry in order to be sucked in and travel through the wormhole.

This parameter is used to calculate fuel consumption for wormhole travel. The length of a wormhole, from start point to end point, is divided by this parameter in calculating the effective length of travel for a ship through a wormhole. See the "Detailed Operation" page for a complete description of fuel consumption during wormhole travel.

This parameter indicates the speed at which ships must navigate through wormholes. This parameter is used to calculate fuel consumption for wormhole travel. See the "Detailed Operation" page for a complete description of fuel consumption during wormhole travel.

This option controls the ability of cloaked ships to remain cloaked while travelling through wormholes. If this option is enabled, then cloaked ships may remain cloaked after wormhole travel. With this option disabled, a cloaked ship will automatically uncloak for one turn after travel through a wormhole.

This parameter controls the size of a wormhole's entry area. The larger this parameter is the bigger a wormhole's radius of entry becomes. See the "Detailed Operation" page for the relation between this parameter and the wormhole entry radius.

Combat Options

This array of values stores the ground kill factor for each player. The ground kill factor rates the effectiveness of a player's colonists at attacking enemy colonists on a planet. A factor of 1 means that each colonist fights at nominal strength. Higher values scale linearly (e.g., a value of 2 means that each colonist fights like 2 colonists). The outcome of ground attack is determined by a formula described on the "Detailed Operation" page.

This array of values stores the ground defense factor for each player. The ground defense factor rates the effectiveness of a race's colonists at defending themselves from ground attack. The outcome of ground attack is determined by a formula described on the "Detailed Operation" page.

With this option enabled, the engine shield bonus is applied to all ships in combat. This bonus gives a boost to the effective combat mass of a ship, based upon the tech level of the ship's engines.

EngineShieldBonusRate

valid values: 0 through 100

This parameter indicates the percentage of a particular engine's cost to apply to a ship's engine shield bonus as an equivalent mass boost. For example, a bonus rate of 50 (meaning 50%) applies half the cost of a ship's engine type as an increase in the ship's combat mass.

With this option disabled, the engine shield bonus is only applied to ships that fight other ships, not to ships fighting against planets.

This parameter indicates the percentage of natives that survive when a planet is lost in combat. The default HOST 3.2 behavior causes 75% of the natives to survive (i.e., a default NativeCombatSurvivalRate of 75).

This option controls whether or not the intercept attack (XA) may be performed by ships which have a cloaking device. For more information on the intercept attack, please see the "Order of Battle" page.

Combat Parameters

This parameter indicates the rate at which fighter bays recharge. A fighter bay can only launch a fighter when it is fully recharged. At every step in the battle, each fighter bay is recharged by a random amount chosen uniformly between 0 and BayRechargeRate. Once the charge level reaches 1000 or greater, the bay can launch a fighter.

This parameter is used to indicate how much of a recharge bonus is given to ships with a large number of bays. See the "Detailed Operation" page for information on how this parameter is used. A value of 0 indicates that all fighter bays recharge at the same rate, regardless of how many bays the ship has.

This parameter indicates the rate at which beam weapons recharge. A beam weapon is fully discharged when it fires at an oncoming fighter or at the enemy ship/planet. The beam weapon recharges at every step in the battle by a random amount chosen uniformly in the range 0 to BeamRechargeRate. See the description of the BeamHitFighterCharge and BeamHitShipCharge parameters.

This parameter is used to indicate how much of a recharge bonus is given to beam weapons of higher tech. See the "Detailed Operation" page for information on how this parameter is used. A value of 0 means that there is no bonus for higher tech weapons.

This parameter indicates the rate at which torp tubes recharge. A tube is fully discharged when it launches a torpedo. The tube recharges at every step in the battle by a random amount chosen uniformly in the range 0 to TubeRechargeRate. Once the charge level reaches 1000 or greater, the tube can launch another torpedo.

This parameter indicates the minimum charge level which a beam weapon must have in order to fire at an oncoming fighter. A charge level of 1000 is equivalent to a full charge. For example, a charge level of 600 means that the beam weapon must be 60% charged to fire at a fighter. Also see the BeamRechargeRate parameter.

This parameter indicates the minimum charge level which a beam weapon must have in order to fire at the enemy ship/planet. For example, a charge level of 500 means that the beam weapon must be 50% charged. A beam weapon will never fire at the enemy ship, regardless of charge level, if the enemy has launched fighters. The beam weapons save themselves for oncoming fighters.

This parameter indicates the maximum ship-to-ship distance at which tubes can launch torpedoes. No torpedoes will be launched until the two combatants are within this range of each other.

This parameter indicates the maximum ship-to-ship distance at which beam weapons can be used to fire on the enemy. No beam weapons will be fired at the enemy ship/planet until the two combatants are within this range of each other.

This parameter indicates the percentage chance that a torpedo hits its target.

This parameter indicates the percentage chance that a beam weapon hits its target. This chance applies equally to fighters and the enemy ship or planet.

This parameter indicates the percentage increase in chance of a beam weapon hitting its target as a function of beam weapon tech. See the "Detailed Operation" page for a description of how this parameter is used. A value of 0 indicates that there is no bonus given for beam weapon tech.

This parameter indicates the number of hits that a fighter can inflict on the enemy ship or planet before being required to return for refuelling. All fighters get a fixed number of hits. Fighter strikes at enemy oncoming fighters do not count against this allotment.

This parameter indicates the percentage chance that a fighter will fire on and destroy an enemy fighter if both fighters are very near to each other in space. This parameter has no effect on fighters that are attacking the enemy ship or planet. These fighters always hit their mark.

This parameter indicates the destructive power in a single fighter beam hit to the enemy ship or planet. This power is a measure of how much damage the enemy suffers as a result of a single strike. The specified number is interpreted in the same way as the destructive power of beam weapons (i.e., as in BEAMSPEC.DAT)

This parameter indicates the kill power in a single fighter beam hit to an enemy ship. This power is a measure of how many crew members will be injured as a result of a single strike. The specified number is interpreted in the same way as the kill power of beam weapons (i.e., as in BEAMSPEC.DAT). This parameter has no effect when the enemy is a planet since planets do not have crew.

This parameter indicates how many metres a ship moves at each battle step. This parameter makes sense in relation to other speed related parameters (see below).

This parameter indicates how many metres a fighter will move at each battle step. Also see the ShipMovementSpeed parameter.

This parameter is used to limit how often fighters can be launched. The bay launch interval is the minimum number of battle steps a ship must wait after a fighter launch before it can launch another fighter. This parameter can be used to tune the battle mechanics when changing movement speeds.

This parameter indicates the maximum number of fighters that a ship can have launched (either attacking or returning to the ship) at any one time. A value of 19 is compatible with the original HOST and values up to 24 are displayed normally by PVCR. Values from 25 to 50 are acceptable but will not be displayed gracefully by PVCR.

This option controls several behaviors in PHOST combat. With this option OFF, PHOST combat is very much like HOST combat in terms of damage to ship and crew (see FORMULAS.DOC). For example, a fighter hit will always inflict at least 1% damage on an enemy ship, regardless of mass. With this option turned on, damage to shields, hull, and crew can be fractional e.g., 0.2%. Furthermore, the formulas used to compute damage are different (see FORMULAS.DOC).

Note that a new ship list, PLIST, has been designed specifically for PHOST and alternative combat. Also note that some of the other alternative ship lists (like ALTLIST3) were designed with a purpose of compensating for some of the perceived deficiencies in original HOST combat. The AllowAlternativeCombat option also has this goal in mind, but the two approaches do not necessarily work well together. It may be better to leave this option disabled when using an alternative ship list that is not designed to work with PHOST's alternative combat.

This parameter indicates the distance in metres at which the two battle participants will stop moving towards each other. The combatants will remain separated by this standoff distance for the remainder of the battle.

When this option is enabled, then planets and starbases can fire torpedoes in combat, along with the usual fighters and beams. This option was meant to give planets a small boost in defensive capability since they are normally quite weak. See the "Detailed Operation" page for details regarding the number of tubes, number of torps, and torp tech of planetary torpedo defense.

This option controls how beam weapons are used to fire on enemy fighters. With this option off, a beam weapon will fire on the nearest fighter (like HOST). With this option on, a beam weapon will first try to fire on the nearest attacking fighter (i.e., coming towards the defending ship). Only if there are no attacking fighters will a beam weapon fire on an enemy fighter that is returning to the enemy ship or planet.

This parameter allows higher tech torps an advantage in finding their target. See the "Detailed Operation" page for the relationship between torp tech and the torp hit probability. A value of 0 indicates that there is no bonus given for higher torp tech.

This parameter controls the rate at which higher tech torp tubes recharge as compared to lower tech tubes. See the "Detailed Operation" page for the relationship between tube tech and the tube recharge rate. A value of 0 means that there is no bonus for higher tech tubes.

This parameter controls the amount of reduction in shields suffered by a ship or planet for a certain amount of destructive power. See the "Detailed Operation" page for the relationship between shield loss and the destructive power of beams, torps, and fighters.

This parameter controls the amount of damage sustained by a ship's hull (or by a planet) for a certain amount of destructive power. See the "Detailed Operation" page for the relationship between hull damage and destructive power.

This parameter controls the amount of damage inflicted on a ship's crew for a certain amount of killing power. See the "Detailed Operation" page for the relationship between crew losses and killing power.

This parameter indicates a number of bays to add to any ship in combat. This number of bays is added after all damage limiting is taken into account. The customary bonus for the Federation is 3 bays. This is a new config option in PHOST 3. For backwards compatibility with PHOST 2.x, set this option to 0 for all players.

This parameter indicates the maximum distance at which a ship or planet can fire on an enemy fighter. This is a new config option in PHOST 3. For backwards compatibility with PHOST 2.x, set this option to 100000.

This parameter indicates the maximum distance at which a fighter can fire on an enemy ship or planet. This is a new config option in PHOST 3. For backwards compatibility with PHOST 2.x, set this option to 3000.

Build Queue Parameters

Please see the "Ship Build Queue" page for descriptions of the following parameters.

This option controls how the build queue is managed. PHost 3.3c supports three types of build queue: the original PHost 3 "PAL" system, a PBP system not unlike HOST, and the simple FIFO system from PHost 2. Depending on the setting, not all of the following parameters are used (but should nonetheless be present in pconfig.src).

This option specifies whether build points (PAL) are made public or not. Normally, build points are secret and every player just gets his own value. With this option set to "Yes", all players will know all scores. This makes sense when you're playing with a PBP queue, to add some predictability.

The default value is Allies; each player gets his own value and the values of his allies (no special alliance levels needed).

This parameter defines a penalty for changing build orders. If a build order is placed on the queue and gains some priority, but is then changed, the base loses a part of their build queue priority. By default, it loses 100% of its priority, thus the new build order starts walking the queue anew.
This option supersedes the SBQBuildChangePenalty parameter. SBQBuildChangePenalty is only available when a PAL-driven build queue is used, and specifies a fixed penalty. In contrast, this option works in all queue modes, and gives relative penalties. SBQBuildChangePenalty still remains available. If you want to use a relative penalty with a PAL queue, remember to set SBQBuildChangePenalty to zero. Otherwise it would remove all the remaining priority left over by this option.

These parameters control the operation of the ship build queue and player activity levels. For more details, please see the "Ship Build Queue" page.

This parameter specifies whether players are allowed to use the PB1 to PB9 friendly codes to re-order their build orders in the queue. See "Order Overrides" for a description of these codes.

This mechanism can be abused to have dummy build orders gain priority in advance, and then upping some new build orders for new battleships using PBx. So you can forbid use of these codes, if you think this is a problem. This option is on by default.

When you use the PBP queue, you should definitely enable this option. You can still disable it, though, for example to prevent priority builds early in the game (like HOST does not permit priority builds until there are 450 ships in the game).

Back to the index

Parameters Listed Alphabetically

A

AllowAdvancedRefinery
AllowAlchemy
AllowAlliedChunneling
AllowAlternativeCombat
AllowAlternativeTowing
AllowAntiCloakShips
AllowBeamUpClans
AllowBeamUpMultiple
AllowBioscanners
AllowBoardingParties
AllowChunneling
AllowCloakedShipsAttack
AllowCloakFailMessages
AllowColoniesSweepWebs
AllowCrystalTowCapture
AllowEatingSupplies
AllowEngineShieldBonus
AllowESBonusAgainstPlanets
AllowExtendedMissions
AllowFedCombatBonus
AllowGamblingShips
AllowGloryDevice
AllowGravityWells
AllowHiss
AllowHyperjumpGravWells
AllowHyperWarps
AllowImperialAssault
AllowInterceptAttack
AllowMeteorMessages
AllowMinefieldIdentity
AllowMinefields
AllowMinesDestroyMines
AllowMinesDestroyWebs
AllowMoreThan500Minefields
AllowMoreThan50Targets
AllowNewNatives
AllowNoFuelMovement
AllowOneEngineTowing
AllowPlanetAttacks
AllowPlayerMessages
AllowPrivateerTowCapture
AllowPriorityBuild
AllowRebelGroundAttack
AllowRegisteredFunctions
AllowRGAOnUnowned
AllowScienceMissions
AllowShipCloning
AllowShipNames
AllowSuperRefit
AllowTowCloakedShips
AllowUniversalMinefieldFCode
AllowWebMines
AllowWormholes
AllowWraparoundMap
AlternativeAntiCloak
AlternativeMinesDestroyMines
AntiCloakImmunity

B

BayLaunchInterval
BayRechargeBonus
BayRechargeRate
BeamFiringRange
BeamHitBonus
BeamHitFighterCharge
BeamHitFighterRange
BeamHitOdds
BeamHitShipCharge
BeamRechargeBonus
BeamRechargeRate
BorgAssimilationRate
BuildChangeRelativePenalty
BuildPointReport
BuildQueue

C

ClimateDeathRate
ClimateLimitsPopulation
CloakedMineTravelSafeWarp
CloakFailureRate
CloakFuelBurn
CloakMineOddsWarpBonusX100
ColoniesBuildFighters
ColonistTaxRate
ConfigLevel
CPEnableAllies
CPEnableBigTargets
CPEnableGive
CPEnableJettison
CPEnableLanguage
CPEnableMessage
CPEnableRaceName
CPEnableRemote
CPEnableRumor
CPEnableSend
CPNumMinefields
CrewKillScaling
CrystalSinTempBehavior
CrystalsPreferDeserts
CumulativePillaging

D

DamageLevelForAntiCloakFail
DamageLevelForChunnelFail
DamageLevelForCloakFail
DamageLevelForHyperjumpFail
DamageLevelForTerraformFail
DarkSenseRange
DefenseForUndetectable
DelayAllianceCommands
DeleteOldMessages
DisablePasswords

E

EngineShieldBonusRate
ExtMissionsStartAt
ExtraFighterBays

F

FactoriesForDetectable
FighterBeamExplosive
FighterBeamKill
FighterFiringRange
FighterKillOdds
FighterMovementSpeed
FighterSweepRange
FighterSweepRate
FilterPlayerMessages
FireOnAttackFighters
FreeFighters

G

GameName
GravityWellRange
GroundDefenseFactor
GroundKillFactor

H

HissEffectRate
HullDamageScaling
HullTechNotSlowedByMines

I

IonStormActivity
IonStormsHideMines

L

Language
LargeMeteorOreRanges
LargeMeteorsImpacting

M

MapTruehullByPlayerRace
MaxColTempSlope
MaxFightersLaunched
MaximumMinefieldRadius
MaximumMinefieldsPerPlayer
MaximumWebMinefieldRadius
MaxPlanetaryIncome
MaxShipsHissing
MeteorShowerOdds
MeteorShowerOreRanges
MineDecayRate
MineHitDamageFor100KT
MineHitOdds
MineHitOddsWhenCloakedX10
MineIdNeedsPermission
MineOddsWarpBonusX100
MineScanRange
MinesForDetectable
MineSweepRange
MineSweepRate
MineTravelSafeWarp
MinimumChunnelDistance

N

NativeClimateDeathRate
NativeCombatSurvivalRate
NativeTaxRate

P

PALAggressorKillPointsPer10KT
PALAggressorPointsPer10KT
PALBoardingPartyPer10Crew
PALCombatAggressor
PALCombatBaseScaling
PALCombatPlanetScaling
PALDecayPerTurn
PALGloryDamagePer10KT
PALGloryDevice
PALGloryDevicePer10KT
PALGloryKillPer10KT
PALGroundAttackPer100Clans
PALImperialAssault
PALOpponentKillPointsPer10KT
PALOpponentPointsPer10KT
PALPillage
PALPlayerRate
PALRecyclingPer10KT
PALRGA
PALShipCapturePer10Crew
PBPCloneCostRate
PBPCostPer100KT
PBPMinimumCost
PlanetaryTorpsPerTube
PlanetsAttackKlingons
PlanetsAttackRebels
PlanetsHaveTubes
PlayerRace
ProductionRate

R

RaceGrowthRate
RaceMiningRate
RamScoopFuelPerLY
RandomMeteorRate
RebelsBuildFighters
RecycleRate
RGANeedsBeams
RobCloakedChance
RobCloakedShips
RobFailureOdds
RobotsBuildFighters
RoundGravityWells

S

SBQBoostExpX100
SBQBuildChangePenalty
SBQBuildPALBoost
SBQNewBuildPALBoost
SBQPointsForAging
ScanRange
ScoringMethod
SensorRange
ShieldDamageScaling
ShipCloneCostRate
ShipMovementSpeed
SpyDetectionChance
StandoffDistance
StrikesPerFighter
StructureDecayPerTurn

T

TerraformRate
TonsScoreCountsPlanets
TorpFiringRange
TorpHitBonus
TorpHitOdds
TowedShipsBreakFree
TowStrengthDistanceScale
TowStrengthEngineScale
TransuraniumDecayRate
TubeRechargeBonus
TubeRechargeRate

U

UnitsPerTorpRate
UseAccurateFuelModel

W

WebDrainFuelLoss
WebHitDamageFor100KT
WebHitFuelLoss
WebMineDecayRate
WebMineHitOdds
WebMineOddsWarpBonusX100
WebMineSweepRange
WebMineSweepRate
WebMineTravelSafeWarp
WormholeUFOsStartAt
WraparoundRectangle
WrmDisplacement
WrmEntryPowerX100
WrmMassAdd
WrmRandDisplacement
WrmRandMass
WrmRandStability
WrmStabilityAddX10
WrmTravelCloaked
WrmTravelDistDivisor
WrmTravelWarpSpeed
WrmVoluntaryTravel

Back to the index

This document is maintained by The Portable Host Project (support@phost.de).