[PHost Logo]© 

Playing with PHOST
The Portable Host



This document describes some of the issues that the PHOST player needs to be aware of. It is assumed that the player is familiar with playing VGA Planets, hence only items that are specific to PHOST are discussed here.

Back to the index 

Viewing Battles with PVCR

Since PHOST combat is different from HOST combat, a different VCR viewer is needed to display PHOST-generated battles. The PVCR.EXE program that comes with PHOST will display PHOST-generated battles from all three versions of PHOST (PHOST 1, PHOST 2, and PHOST 3). Regardless of which client program you use to play your turns, you need to ultimately view your PHOST-generated battles with PVCR. ==> Note specifically that WinPlan players must not view PHOST-generated battles using the built-in VCR viewer. This may cause WinPlan to crash, and will at least show the wrong results.

VPA Users

As of VPA 3.51d[Remote], VPA recognizes and correctly loads PVCR to view battles. Simply place PVCR.EXE in the same directory as VPA. VPA will find and run PVCR to display PHOST-generated battles.

WinPlan Users

Here are the steps to follow for using PVCR.EXE with WinPlan:
  1. If you do not have a copy of the DOS Planets distribution (either shareware or registered) then you must get this distribution (available at many archive sites) and extract the RESOURCE.PLN file. (The RESOURCE.PLN[Remote] file is also available from the PHOST home page; follow the preceding link). This file should be placed in the main WinPlan directory. The remainder of the DOS Planets distribution can be discarded. This file contains bitmaps for the ships.

  2. Install PVCR.EXE in the main WinPlan directory.
  3. To view a PHOST-generated battle, open a DOS window (full-screen) and enter the main WinPlan directory. Let's assume that you are player 3 and that your game is in the VPWORK4 directory. Then, you would type:

    pvcr -s -p 3 vpwork4 

  4. The argument to the -p option is your player number and the game directory should follow all command-line options. Type pvcr -h for a list of other options. A small batch file for the above one-liner could be created to absorb some of the details. Perhaps even a PIF file under Windows (a shortcut under Windows 95), so that a single double-click will open up the VCR's for a game.

DOS Planets Users

Here are the steps to follow for using PVCR.EXE with DOS Planets:
  1. The VCR.EXE program that came with VGA Planets should reside in the main directory. Rename this file to VCROLD.EXE.

  2. Locate the PVCR.EXE program that came with the PHOST distribution (or you may have obtained it separately). Place this file in the main directory and then rename it to VCR.EXE.
You see that we have called the original program VCROLD and installed the new PVCR program as VCR. In effect, we are "fooling" the DOS Planets client program into calling PVCR instead of the original VCR. That's OK, because PVCR automatically knows how to handle both HOST-generated battles and PHOST-generated battles. If a HOST-generated battle is encountered, PVCR will load the VCROLD.EXE program to display it.

This arrangement will work fine for games hosted by both HOST and PHOST. Once you perform the above file renaming, you will most likely never have to worry about it again.

If a new version of PVCR is released (perhaps as part of a new PHOST distribution), then simply install the new PVCR.EXE program as VCR.EXE in the main directory. Leave the VCROLD.EXE program as it is.

Back to the index 

Configuration Options

PHOST has over 210 configuration options, more than twice as many as the original HOST program. You should ensure that your host sends you a PCONFIG.SRC file in effect for your game and that you review it for any non-standard config values. Also, place the PCONFIG.SRC file in your game subdirectory for future reference and for the benefit of utilities (such as VPA[Remote] and EchoView[Remote]) that can read and interpret this file.

==> Note that some utilities, and VPA in particular, will not read PCONFIG.SRC files that come from Unix systems. This is because the end-of-line character sequences are different for Unix files than for DOS/Windows files. On Unix systems, each text line ends with the hexadecimal character 0Ah (decimal 10). On DOS/Windows systems, each text line ends with the hexadecimal characters 0Dh 0Ah (decimal 13 and 10). If VPA (or other utilities) indicate that they cannot read the PCONFIG.SRC file, use a utility program to convert the line endings to DOS format. Many such programs exist, for example addcr10.zip[Remote], chktxt.zip[Remote], and doscvt27.zip[Remote]. If all of the above links are out of date, just ask around for a program, people have been converting files between DOS and Unix for as long as both systems have existed.

==> Also note that in PHOST 3, many configuration options, including some original HOST options, have been "array-ized". That is, they are now configurable on a per-player basis. Look at the PCONFIG.SRC file carefully; you may have a different setting from the setting of other players! Note that this also applies to the combat configuration options.

Here are some configuration options that you should pay particular attention to, as they may have enhanced functionality or enable add-on-type behavior:

AllowRegisteredFunctions Your host may have configured this game to forbid any player from accessing registered-player functions
TerraformRate This is configurable in PHOST
ShipCloneCostRate Privateers and Crystals are allowed to clone, but may have very high costs
AllowBeamUpClans Your host may disable access to the Beam Up Clans extended mission if he/she deems it too powerful
AllowBeamUpMultiple Your host may disable access to the Beam Up Multiple extended mission if he/she deems it too powerful
These are configurable in PHOST
UseAccurateFuelModel If this is enabled, you won't be able to rely upon the fuel estimates provided by your client program
TowedShipsBreakFree Involuntary tows can be broken in mid-tow
AllowAlternativeTowing The rules of towing can follow one of two different models
MaxShipsHissing Lizard players may have a limit on how many ships may hiss at one planet
SpyDetectionChance The Super Spy mission has a configurable rate of detection
CumulativePillaging The Klingons may perform more than one pillage at a planet per turn
This needs to be enabled for the Privs/Crystals to effect boarding parties
AllowAlliedChunneling Allies can perform chunnels to each other's ships if enabled
CrystalSinTempBehavior Growth on Crystal planets may follow a different model
AllowRGAOnUnowned Controls whether RGA can be performed on unowned planets
RGANeedsBeams Controls whether a ship needs beam weapons to perform RGA
Controls how visible planets are to sensor sweeps
NativeClimateDeathRate Natives may die on harsh planets
MaxColTempSlope Affects maximum number of colonists on harsh planets
Two separate tax rates instead of the single rate for both colonists and natives
RaceGrowthRate Can have different colonist growth rate, perhaps for each player
ProductionRate Can have different supply production rate, perhaps for each player
PlanetaryTorpsPerTube Planets may have tubes in addition to beams and fighters
UnitsPerTorpRate Controls how torpedoes are converted to minefields
Ships may travel better at lower warp speeds and even be immune to mines at certain warp speeds. See Minefield Travel section below.
Controls how much damage a mine hit causes
WebDrainFuelLoss Controls how much fuel a ship in a web mine loses
Controls how fighters can sweep minefields. May also be configured to allow non-Colonial players to sweep minefields with fighters.
RobCloakedShips Cloaked ships may not be immune to robbing
AllowTowCloakedShips Cloaked ships may be prevented from being towed (except by allies)
AllowESBonusAgainstPlanets Ship-to-planet combat may have the engine shield bonus enabled
NativeCombatSurvivalRate Controls how many natives survive when a planet is lost in combat
AllowInterceptAttack The intercept attack phase of combat may be disabled
AllowAlternativeCombat Alternative combat implies a very different model of combat. Make sure you look at all of the other combat-related config options.
AlternativeAntiCloak Loki anti-cloak ships don't decloak your own ships (and other changes).
Back to the index 

Minefield Travel

Travel after Hitting Mines

Travel through minefields after hitting a mine works the same as in HOST except for one potential difference. This is configured by the HullTechNotSlowedByMines configuration option.

When this parameter is between 1 and 11, it represents the minimum level of hull tech which is not affected by mines, with respect to the maximum distance travelled (as in HOST 3.2). For example, if a ship is travelling at Warp 7, then it may move up to 49 LY in one turn, regardless of the number of mine hits, as long as the damage to the ship does not reach 100%. If the ship's hull tech is lower than HullTechNotSlowedByMines, however, its maximum range is limited to 49-10=39 LY for that turn.

Setting HullTechNotSlowedByMines to 1 means that no ships are affected in this way. Setting it to 11 means that all ships are affected. This range of values enables HOST-compatible operation.

When the HullTechNotSlowedByMines parameter is 0, a different mechanism takes effect that is independent of hull tech. After a mine hit, the maximum damage-limited speed of the ship is recomputed and the ship continues on its journey at that speed. The maximum distance, then, is simply the amount of time remaining for travel multiplied by the new ship's speed. For example, a ship travelling at Warp 8 to a waypoint 64 LY away hits a mine after 32 LY. Its new damage-limited speed is Warp 5. Since 32 of 64 LY have passed, the ship is halfway through its journey. Thus, it can travel an additional 0.5*(5^2) = 12.5 LY towards its waypoint.

Mine Hit Probabilities

Mine hit probabilities work the same as in HOST with two possible exceptions. The first is that the MineHitOdds and WebMineHitOdds config options are per-player configurable, meaning that each player can have a different probability of hitting mines per LY. Second, new config options can decrease the probability of hitting a mine for ships that travel slower, and can make minefield travel completely safe below some given speed. These cases are discussed below in greater detail.

The exact formula for computing a ship's mine hit probability (per LY) is given by (as a percentage from 0% to 100%):

The MineOddsWarpBonusX100 config option in the formula above is a speed derating factor. It describes an increase in safety (i.e., a decrease in mine hit probability) as your ships travel slower than warp 9.

Note that a ship travelling at warp 9 has a mine hit probability of MineHitOdds, as usual, as there is no warp bonus at this speed. A ship travelling at warp 1 gets 8 times the warp bonus reduced from the MineHitOdds base probability. If MineOddsWarpBonusX100 is 5, for example, then each warp speed below 9 decreases the hit probability by 0.05%.

Another factor to consider is the setting of the MineTravelSafeWarp config option. This option indicates the warp speed at which ships have no chance of hitting a mine. That is, travel through mines is completely safe at this or lower speeds.

As an example, let us set MineHitOdds=1, MineOddsWarpBonusX100=6, and MineTravelSafeWarp=3. Here is a chart describing the per-light-year mine hit probability as a function of the ship's warp speed:

  • MineHitOdds = 1 (1%)
  • MineOddsWarpBonusX100 = 6 (0.06% per warp speed below 9)
  • MineTravelSafeWarp = 3 (warp 3 or lower)
Warp Speed Mine Hit Probability (per LY)
0% (safe travel)

Note that there are 3 independent sets of config options that govern mine hit probabilities, depending upon whether the ship is travelling through normal or web mines, and whether or not the ship is cloaked. They all work in the fashion described above, however.

Here are some common settings for these parameters: Back to the index 


There are two towing models implemented in PHOST, a HOST-compatible model and a new, alternative model. The choice of which model to use is determined by the AllowAlternativeTowing config option.

HOST-Compatible Towing

With AllowAlternativeTowing disabled, the HOST-compatible model is in effect. This model does not guarantee 100% HOST compatibility but it gives expected behavior in most cases. This model was based upon extensive testing of the HOST program version 3.22.009. The implementation of this model can be summarized by the following rules:
  1. When a ship tows another ship, the tow succeeds unless the tow can be broken. The tow is broken only if all of the following apply:
  2. A ship cannot tow unless it has 2 or more engines, or the AllowOneEngineTowing config option is enabled.

  3. A ship cannot tow another ship if it is under a successful tow. Chains are broken into pairs (e.g. if Ship A tows B, B tows C, C tows D then A will tow B and C tows D, while the tow between B and C is broken)

  4. When the towing ship has gravitonic engines, its effective warp speed is multiplied by 2. Gravitonic engines do not affect the towed ship's ability to break the tow.

  5. When two ships tow each other (mutual towing), the ship with the lower ID number wins the tow. There are some exceptions to this, however:
  6. When two (or more) ships attempt to tow a single target ship, the towing ship with the lowest ID number will win (unless the tow can be broken).

Alternative Towing Model

With AllowAlternativeTowing enabled, towing depends upon the towing strength of a tower and the towing resistance of the tow target. Simply put, a tow succeeds when the tow strength exceeds the towing resistance (in PHost up to 3.4k, equal tow strength would win as well; in later versions, equal strenght makes the tow fail). When multiple ships want to tow a single tow target, the ship with the highest tow strength wins. Among equal tow strengths, the lowest ID ship will win.

The tow strength of a ship is determined as follows:

Tow Strength = Engine Contribution + Movement Contribution

Engine Contribution   = (EngineTechLevel^2 * NumberOfEngines * WarpSpeed * GravFactor * TowStrengthEngineScale)
Movement Contribution = Movement * TowStrengthDistanceScale

In addition, if a ship has no fuel then its tow strength is 0.

Currently, tow resistance is identically equal to tow strength.

Loop and Chain Resolution

The above sections described how contested tows and breakable tows are resolved. After that, loops and chains might still remain (like: A tows B, B tows C, C tows D).

==> Note that PHost before version 3.4h did not do any loop resolution, so results are close-to-unpredictable in these versions.

Back to the index 


Formal alliances allow players to work together with a minimum of hassle. The formal alliances implemented by PHOST are more extensive and robust than the locking alliance mechanism recently introduced in HOST 3.22. If you are thinking of allying with a player, or if you are playing in a team game, please read about PHOST's alliance implementation on the "Alliances" page.

Back to the index 


Wormholes are an addon-type feature built in to PHOST. Wormholes allow instantaneous travel over large distances. If your host has enabled wormholes with the AllowWormholes config option, then please browse the "Wormholes" page for more information.

Back to the index 

Wraparound Maps

Two addons that have recently gained popularity are PWRAP and Sphere, for the way in which they wrap the edges of the starmap around so that travel off one edge leads to reappearance on the other side. PHOST has taken this popular idea one step further by extending the concept of wraparound to all aspects of operation, including mine sweeps, mine hits, sensor scans, etc. If your host has enabled a wraparound map with the AllowWraparoundMap config option, then please browse the "Wraparound Maps" page for more information.

Back to the index 

Non-Standard Race Assignments

The PlayerRace config option can be used to allow any player to play any race. For example, player #1, normally The Federation, may play race #5, The Privateers. Nothing prevents another player from also playing The Privateers. If you are playing in a game in which non-standard race assignments are used, then consider the following: Back to the index 


Combat in PHOST is different from HOST. First, make sure you read the section on Viewing Battles with PVCR above. Then, have a look at the combat config options that your host has set for the game in the PCONFIG.SRC file. Note that in PHOST 3, most of these options are configurable on a per-player basis, meaning that you may not have the same combat configuration as other players!

For simulating combat, the BSIM 2.2[Remote] utility is invaluable. It allows you to read a PCONFIG.SRC file and simulate battles based upon the parameters within this file. Do not use the combat simulator built in to VPA[Remote] or WinPlan as they will give incorrect results for PHOST battles.

The order of battle in PHOST is fully described on the "Order of Battle" page.

Back to the index 

Extended Missions

Both the VPA[Remote] and WinPlan client programs support the extended mission (or M.I.T.) interface which allows ship missions beyond those supported by the original HOST program. PHOST takes advantage of this interface to offer several extended missions of its own. These are documented fully on the "Extended Ship Missions" page.

The missions that you can select are determined by the contents of a MISSION.INI file. This file comes with the PHOST distribution, or you may receive this file from your host. You should place the MISSION.INI file in your game subdirectory, so that VPA and WinPlan can display the proper extended missions.

Note that if you are using the DOS Planets client program, you must enter extended missions using the command processor's extmission command. DOS Planets does not use or recognize the MISSION.INI file.

The main reason for extended missions is to free up the much-abused friendly code from doubling as both a determinant of battle order and as a way of initiating missions (such as building torpedoes, scooping minefields, etc.) Using an extended mission to build torpedoes, for example, lets you build torpedoes on the same turn in which you attack an enemy, and leaves the friendly code free to determine battle order.

Other extended missions have been added to implement addon-type functionality. For example, there is a new Standard Super Spy extended mission for the Birdmen, a Beam Up Clans mission, among others.

Back to the index 

Alternative Ship Lists

If you are playing in a game with a non-standard ship list, your host should have sent you the following files: Collectively, these files are referred to as "a ship list". PLIST[Remote] is one example of an alternative ship list, and is highly recommended for use with PHOST.

If you are using the VPA[Remote] or WinPlan client programs, simply place the ship list data files in your game subdirectory. VPA and WinPlan will recognize and use those files instead of the original ship list files.

==> If you do not correctly install the alternative ship list, you will get Red Alert errors from PHOST!

Your host will only send you a HULLFUNC.TXT or HULLFUNC.DAT file if the game is using custom hull functions. Your host will provide more details in this case. Note that VPA[Remote] and EchoView[Remote] both support the HULLFUNC interface.

Back to the index 

Non-Standard Maps

If you are playing in a game with a non-standard universe map, your host should have sent you an XYPLAN.DAT file. If you are using the VPA[Remote] or WinPlan client programs, simply place this file in your game subdirectory. VPA and WinPlan will recognize and use this file instead of the original map. Your host may also have sent you a custom PLANET.NM file. This file contains the names of all the planets.

==> If you do not correctly install the custom map, you will get Red Alert errors from PHOST!

Back to the index 

Custom Hull Functions

If your host sends you a HULLFUNC.TXT file, then you are most likely playing in a game in which the host has modified the default special function behavior of the ships. This means that ships that did not cloak before could possibly cloak now, for example. For more details, have a look at the "Custom Hull Functions" page.

Back to the index 

Priority Build Points

PHOST implements a priority build system that regulates the building of ships once the 500-ship limit is reached. This system is based upon the same principle as the one in the HOST program: players that are more active should build more ships. The implementation, however, is different from that of the HOST program and you need to ensure that you are aware of, and familiar with the configuration options that guide the implementation.

Back to the index 

Remote Ship Control

PHOST implements an addon-type functionality that allows allied players to remotely control each other's ships. The full details of this implementation are on the "Remote Ship Control" page. Even if you do not use this feature yourself, you may find that some ships in the game are under remote control. ==> You need to be aware of this because you will not see the ship's true owner, unless you look carefully. That harmless Federation scout ship you see coming may actually be a Rebel ship preparing to RGA your planet!

This switch of information can be quite damaging to players who are not aware of the true ship's owner and hence the ship's true capabilities. To prevent this confusion, PHOST implements different forms of information provided to players regarding remote control ships:

Back to the index 

Language in Messages

PHOST can generate player messages in any one of several languages, besides English. You can set the language of your choice with the language command processor command. See the "Introduction to PHOST" page for the names of those hard-working people who took the time to translate the PHOST language database into a different language.

Back to the index 

Alternative Anti-Cloak

PHOST 3 implements two different anti-cloak mechanisms, depending upon the setting of the AlternativeAntiCloak config option. With this option disabled, the setting of the AntiCloakImmunity config option determines which players are immune to anti-cloak ships, regardless of who owns the anti-cloak ship. Thus, a Klingon player in possession of an anti-cloak ship will decloak his own ships.

With AlternativeAntiCloak enabled, own-player ships are also immune to anti-cloak. For example, a Klingon player in possession of an anti-cloak ship will not decloak his own ships. Furthermore, this own-player immunity is extended to allies to whom the ship level of alliance has been granted. Note, however, that the AntiCloakImmunity config option is still in effect to grant absolute immunity to any player.

Back to the index 

Friendly Codes

The friendly codes recognized by PHOST are nearly the same as the ones used by HOST. The only exceptions are: Back to the index 

Message Filtering

Many people use auxiliary information utilities like EchoView[Remote] or VPA[Remote] that can read and understand UTIL.DAT files. Since the contents of UTIL.DAT files mirror the information in player messages, it is somewhat redundant to have both. In addition, player messages can become overwhelming, especially in the later stages of the game, when mine scan messages, sensor sweep messages, dark sense messages, etc. can leave a player with over 200 messages to deal with. PHOST attempts to alleviate this problem by not sending player messages which convey information already present in UTIL.DAT files. This form of filtering is enabled for each player via the FilterPlayerMessages config option.

The idea behind message filtering is that the information utilities will read the UTIL.DAT file and present the information to you visually. Thus, there is no need for you to read about it textually.

Note that you can enable message filtering by yourself (without host intervention) using the filter command processor command.

Here is a complete list of messages which are excluded when message filtering is enabled:

Back to the index 
This document is maintained by The Portable Host Project[Remote] (support@phost.de).

Last updated 9 August, 2002