This document lists the known differences in operation and functionality
between PHOST and the original HOST version 3.2. Some of these differences
are matters in which the original HOST implementation is unknown and cannot
be determined by comparing input with results. In these instances, PHOST
has implemented similar functionality, but does not necessarily duplicate
HOST results. Other differences were implemented as attempts at improvements
in the game. Finally, some of the differences are bug fixes.
The differences are grouped according to who is affected, the host or
the player. Also, each difference has been labelled as either a major difference
or minor difference. Thus, the player or host who only wants an idea of
the major differences between HOST and PHOST need not read all items.
Back to the index
Major Playing Differences
Note that all planetary special codes (e.g., ATT, NUK,
etc.) are considered special even for ships. For example, two ships with
friendly codes ATT will fight.
VCR program and WinPlan/DOS Planets/VPA
The PVCR program in this distribution is meant to replace the VCR viewer
in all client programs, including the built-in VCR viewer in WinPlan. Please
see the Viewing Battles with PVCR
section of the "Playing with PHOST" page for
more information on setting up PVCR for viewing battles.
Combat is different. Period. Efforts have been made to emulate the
original HOST combat as closely as possible but to expect exactly the same
results from HOST combat and PHOST combat is unrealistic. If there is an
important battle to be fought then you should be simulating it to ensure
that there are no unexpected surprises in PHOST combat.
Thomas Voigt's BSIM
(or a more recent version) program is an excellent simulator of both HOST
and PHOST combat.
PHOST implements alliances in a different way from HOST. Please see
the "Alliances" page for the details of PHOST's
implementation. If you are wondering why the implementation is different,
please note that PHOST's alliance feature predates that of HOST by about
In PHOST 3, there is a link between PHOST alliances and HOST-type
alliances (the "locking alliance codes" mechanism). When you
offer a PHOST alliance on all five alliance
levels, PHOST automatically creates a HOST-type alliance, just as if
you had used an ffX friendly code. This link between PHOST and
HOST alliances is meant to enable compatibility with add-on programs that
make use of HOST-type (but not PHOST-type) alliance information. Please see
the HOST Alliance Compatibility
section of the "Alliances" page for more
HOST 3.22.039 implements a second level of alliance ("FF
allies"). PHOST's vision level alliance is roughly the
In addition to the usual HOST options, PHOST has several unique configuration
options that can tailor the operation of the game. See the Configuration
Options section of the "Playing with PHOST"
page for more details. Also note that many of these options (as well as
some of the original HOST options, too) can be set to different values
for each player.
Movement Through Mines
Movement through mines is slightly more realistic. As in HOST 3.2,
ships that exceed 100% in damage due to mine hits explode immediately and
leave any ships they are towing at the point of the explosion.
One difference in PHOST is controlled by the TowedShipsBreakFree
configuration option. If a towed ship loses its tower due to mine hits,
then the towed ship uses the remaining movement time to move towards its
original waypoint at its original speed (if the TowedShipsBreakFree
configuration option is enabled). Towed ships can also break free if a
towing ship runs out of fuel.
Also, the value of the HullTechNotSlowedByMines
option determines a ship's behavior after a mine hit with respect to the
ship's new speed and maximum distance travelled. Please read the description
of this config option for more details.
Finally, there are 6 new config options that can change the per-light-year
probability of hitting a mine, based upon the ship's warp speed. The host
can also set a warp speed setting at which ships will pass through minefields
with no chance of hitting mines. Please see the Minefield
Travel section of the "Playing with PHOST"
page for more details.
Order of Battle
The order of battle is more completely specified. The implementation is
modelled after the friendly-code-only behavior of HOST 3.2 but some differences
may exist. Please see the "Order of Battle" page
for more details. The use of the ATT and NUK friendly
codes also implies a battle order for planets now. Also, a planet's friendly
code will be changed in battle if it was captured.
The Build Queue
The build queue implementation in PHOST is
different from HOST 3.2. Both are based upon a priority system but that
is about the only similarity. Since PHOST 3.3c, there is a
PBP build system which probably comes
close to HOST's behaviour.
Ship clone orders are treated as normal build orders, except that they
override the base's build order, if any. For example, if a ship to be cloned
at a base leaves the base and another takes its place, the new ship to
be cloned is placed at the back of the queue (since the build order was
For every turn in which a player has build orders in the build queue,
PHOST will automatically send a message to the player listing the entries
in the queue, in decreasing order of construction.
For more details about ship building once the 500-ship limit has been
reached, please see the "Ship Build Queue" page.
Matching Friendly Codes
If a ship has a special friendly code (either registered friendly codes
or the unregistered ones) then it will never match the friendly
code of another ship, planet, or minefield. This becomes significant for
surrendering and combat. For example, if a ship has a friendly code of
mkt then it will fight an enemy ship even if the enemy
ship has a friendly code of mkt. This holds true even for unregistered
games. As another example, if a minefield's friendly code is controlled
by a planet whose friendly code is NUK, then no ship will
match the friendly code of this minefield.
If the ship has not moved this turn
If the ship is already orbiting a planet
If the ship has chunneled
If the ship has hyperwarped and AllowHyperjumpGravWells
If the ship has a warp speed of 1 (unless the ship has hyperwarped, in
which case its speed doesn't matter)
This rule makes it easy to remember when friendly codes do and do not
match. The simple rule
is: Special friendly codes never match anything.
The friendly codes recognized by PHOST as being special are described
by Common Question #15 on the "Frequently
Asked Questions" page.
Note that the universal minefield friendly code prefix mf is not
considered to be a special friendly code.
Towing Cloaked Ships
In HOST 3.2, it is possible to tow cloaked enemy ships. This is not
possible in PHOST unless the AllowTowCloakedShips
compatibility option is enabled, or players are allies and the Ship
Level of alliance is granted.
The HOST behavior rationale is that allies should be able to tow each
other's cloaked ships into combat. Unfortunately, it has the side effect
of giving cloaking races little defence against the Privateers, since even
if a towed ship cloaks, it will never escape the tow of a ship with gravitonic
accelerators. A cheap Privateer gunboat can tow a cloaked ship to a starbase
and just wait for its fuel to run out (due to cloak fuel burn) or its cloak
to fail. The towed ship cannot escape.
PHOST enables allies to tow each other's cloaked ships into combat,
simply by having the allies give each other the Ship
Level of alliance. Thus, there is really no need for non-allies to
be able to tow cloaked ships, and the cloaking races can once again escape
Privateer tows by cloaking. Thus, it is recommended that AllowTowCloakedShips
There are two towing models available in PHOST 3. The model in effect
is selectable using the AllowAlternativeTowing
configuration option. With this option disabled, towing works very much
like HOST. The full rules of towing in HOST, however, are not well known.
Thus, there may be exceptions to PHOST's emulation of HOST's towing model.
For a complete description of how towing works in PHOST 3 under both
towing models, please see the Towing section
of the "Playing with PHOST" page.
Planets Capture Ships
In combat, planets can capture ships if a ship's crew is reduced to 0.
This aspect of the game design was actually intended for inclusion in the
original HOST program. As it would have required patching VCR.EXE
and distributing a new copy to all players, this change was judged too
great to implement in HOST.
Damaged Lizard Ships
In HOST, Lizard ships are allowed to exist with more than 100% damage.
In PHOST, if a Lizard ship ends a turn with more than 100% damage, it is
destroyed. It is still allowed to reach 150% damage in combat and when
travelling through minefields, but it will be destroyed at the end of the
turn (or the end of the battle in combat).
It can be argued that HOST's behavior is a bug (what does it mean to
have more than 100% damage?). In any case, PHOST compensates for this difference
by making the damage-limited ship speed and shield level formulas relative
to 150% damage rather than 100% (see the "Detailed
Operation" page for more details). This gives the Lizard player a slight
advantage to compensate for the disadvantage of not having ships with greater
than 100% damage survive.
The same reasoning holds for planets. Lizard planets are allowed to
suffer up to 150% damage in battle but will explode (be conquered) if they
end a battle with more than 100% damage.
When Gravity Wells are In Effect
It is not clear from available HOST documentation when gravity wells
do or do not affect ships. For completeness, the approach taken by PHOST
is described below. It is believed that this closely (if not exactly) matches
If the AllowGravityWells
config option is ON, then a ship will be pulled into a gravity well after
movement is complete except for the following circumstances:
Web Mine Behavior
There is some confusion regarding PHOST's emulation of HOST behavior
with respect to web mines. Various reports of HOST behavior indicate that
Crystal ships are not drained of fuel in web mines regardless of who the
web mine owner is, that Crystal ships can change the owner of the web mine
simply by laying one torpedo in the mine, etc. plus there are version-dependent
effects. Rather than try to discover and document all of these differences,
we simply state how PHOST handles web mines.
The basic rule is that web mines are no different from ordinary mines.
Web mine draining, however, is a Crystal-only racial ability. The owner
of a minefield (or web mine) is immune to its effects, while others are
not (unless they are allies). Therefore, a Crystal ship will have fuel
drained from it if it is in a web mine belonging to another Crystal player
(in a custom PlayerRace game,
The ownership of minefields cannot be changed, and this holds true for
web mines too. Once a minefield is laid, the race of the ship that laid
the minefield is forgotten, and only the minefield owner is remembered
(which, in most cases, is the same as the owner of the ship). If the ship
laying the minefield is doing so in another race's name (using the miN
friendly code or the Lay Mines
extended mission) then once the minefield is laid, the ship's owner has
no special immunity or claim to the minefield.
Web mines interact with normal mines if and only if the AllowMinesDestroyWebs
config option is enabled. The only consequence of this is in the minefields-exploding
stage. A web mine will not explode normal mines unless this config option
is enabled. Otherwise, it is always true that web mines interact only with
web mines and normal mines interact only with normal mines. For example,
laying a web mine that overlaps another web mine of a different race will
cause minefield explosions (assuming AllowMinesDestroyMines
All of the above can be summarized by remembering that there is nothing
special about web mines (other than that they drain fuel) and they do not
explode normal mines unles AllowMinesDestroyWebs
is enabled. Note that this behavior is consistent with the VGA Planets
PHOST 3.x does not implement Ion Storms. Ion storms are implemented in
PHost 4.0j and later.
Back to the index
Minor Playing Differences
Mine Sweeping Messages
Minefield scans are only reported after all minefield activity is complete.
Thus, a player will only get one message per minefield scanned, regardless
of the number of ships that scanned it. The message will report only the
final statistics of the minefield. In this message, the ship name will
be given as <All Ships> and the distance to the minefield will
be given as 999 LY. Minefields which are successfully swept or scooped
will still generate independent messages.
Laying a minefield also implicitly generates a mine scan message for
Super Refit will not use starbase parts that have been specified in the
current base's ship build order. Even though refit occurs before ship building,
ship building is considered more important. Parts will be used for refit
only if sufficient parts remain to fulfill any build order.
Planet Damage in Combat
A planet that engages in combat will remember its shield and damage status
from battle to battle (on the same turn). HOST doesn't remember damage.
Ship Mission Order
The exact ship mission ordering in the original HOST is not known (although
most mission positions are well known). The mission
ordering as implemented in PHOST is described in the "Detailed
Identical processes may not yield identical results in the two hosts because
of rounding differences. The greatest effect of this change may be in fuel
consumption during the movement phase; your ships may end up with more
or less fuel than predicted by the Planets client program. Do not expect
a ship to arrive at a waypoint with 0 KT of fuel unless the fuel consumption
formulas described in the "Detailed Operation"
page are followed. Ships may also end up 1 LY from expected locations if
a different calculation formula is used to predict movement.
Activity on Unowned Planets
Unowned planets do not produce any minerals or supplies even if there are
mines and factories since there is no-one present to operate them. Similarly,
since there are no colonists, there are no tax collectors and the native
tax rate is always 0. Since transuranium decay, meteors, and meteor showers
are natural processes, these will continue to occur regardless of colonist
life on the planet.
When native life is discovered on a planet, the new native population is
chosen randomly between 2500 and 5000 clans. How HOST does it is unknown.
Meteor Impact Survivors
The number of colonists and natives surviving a meteor is chosen randomly
(and independently for colonists and natives). The range is anywhere from
1% to 100% survival. The method and range chosen by HOST is unknown.
Meteor Impact Happiness Change
The change in happiness for both colonists and natives is chosen randomly
(and independently) to be between -50 and -80.
Amorphous Colonist Loss
The number of clans lost due to Amorphous natives is 5 if the natives are
happy, 20 if they are unhappy (50 <= happiness < 70), and 40 if they
are angry (happiness < 50). The exact numbers for unhappy and angry
natives are unknown in HOST.
Overpopulation Supply Loss
The amount of supplies consumed on an overpopulated planet is computed
according to the formula described in the "Detailed
Operation" page. This formula is only an approximation to HOST behavior
and may not lead to identical results.
Colonist and Native Fighting Deaths
If natives fight (happiness < 20), then natives are lost at a rate of
(40-happiness)/5 percent and colonists are lost at 1/5 of this rate. The
same equations hold in reverse if colonists are fighting. It is not known
how HOST computes these rates.
Up to 3.4e:
Minefields are exploded as soon as they are laid (unlike HOST which has a
separate processing phase for minefield explosions). Only two minefields are
considered at a time: the field that is laid and the field with the lowest
ID number which overlaps the new field. The same number of units is lost
in each field until the two fields no longer overlap. This process repeats
until the newly laid minefield does not overlap any other minefields.
- Since PHost 3.4f, PHOST also has a separate mines-destroy-mines pass.
This way, minefields explore in a 100% fair way, no matter how and when they were
A ship performing the colonize mission will cause the planet to receive
the same number of minerals that went into the construction of the ship
(multiplied by the recycle rate) but no money. This differs somewhat from
the HOST computation.
Alternative Fuel Consumption Model
Fuel consumption can follow a more exact dynamic model where the drop in
ship's mass as a result of fuel burn during travel is taken into account.
This is configurable using the UseAccurateFuelModel
option. With this option enabled, ships will usually consume less fuel
but the fuel estimates shown by the client program will be incorrect. Players
need to rely upon the published fuel consumption formulas in the "Detailed
Operation" page rather than client program estimates. Using the alternative
fuel consumption model is best left for advanced games.
Siliconoid Native Growth
PHOST up to 3.3b, Siliconoid natives are treated the same way as other natives
with respect to maximum native population and rate of growth. In later versions,
they prefer hot planets if CrystalsPreferDeserts is enabled. In HOST, Siliconoid
natives always prefer hot planets.
Ship Distress Message
The ship distress message, generated by ships that are destroyed in battle,
now includes the ship ID number of the destroyed ship.
Cargo Beam-Up Messages
Messages regarding cargo that has been beamed up now include a planet ID
number. Ships that fail to beam up cargo, due to not having matching friendly
codes for example, now receive a message informing them of the transport
Ship Movement Without Fuel
In HOST, very light ships could move over large distances with no fuel
simply due to rounding effects. For example, a Neutronic Fuel Carrier with
0 KT of fuel could move over 50 LY in one turn. In PHOST, this kind of
movement is not possible. If a ship has 0 KT of fuel then the most it can
move is 1 LY if the AllowNoFuelMovement
option is enabled, otherwise it simply cannot move at all.
Maximum Beams/Tubes/Bays With Damage
In HOST, the maximum number of beams, tubes, and bays that a ship could
have was limited by the formula (10 - damage/10). In PHOST, this formula
has been modified (see the "Detailed Operation"
page) to support PHOST's ability to have ships with greater than 10 beams,
tubes, or bays.
Sensor Sweeps Condensed
A player will only receive one sensor sweep message per planet per turn,
regardless of how many ships scanned that planet. The sensor sweep will
be listed as originating from <All Ships> rather than a particular
ship name (since the message may have come from more than one ship).
Exploration Messages Condensed
A player will only receive one exploration message per planet per turn,
regardless of how many ships explored that planet.
Super Spy Messages Condensed
Birdman players will only receive one Super Spy message per planet per
turn, regardless of how many ships performed the Super Spy mission on the
planet. Each ship performing this mission still has an independent 20%
chance of getting caught.
Dark Sense Messages Condensed
Empire players will only receive one Dark Sense message per planet per
turn, regardless of how many ships have scanned the same planet.
Tech Level Downgrades
When HOST downgrades starbase tech levels (for shareware players taking
over registered games) then the amount of money that it would take to return
to the previous tech levels is given to the player. PHOST does not return
this money. Starbase tech levels are downgraded with no compensation. Players
can exploit this behavior in HOST to "trade" tech levels for money.
Base Hulls Recycled
The handling of base hulls when a planet with a base changes ownership
is slightly more realistic. The following rules govern what happens to
When a planet becomes unowned, the base is destroyed along with all hulls
When a base is destroyed in combat (either because the planet is conquered,
or the base's damage exceeds 100%) then all hulls are destroyed.
When a planet changes ownership by means of a ground attack, or by the
give command processor command,
then all hulls are recycled and the minerals returned to the planet (multiplied
by the recycling rate in effect).
Dumping Starbase Parts Respects Build Order
In HOST 3.2, using the dmp planetary friendly code on a base which
has a build order in the build queue (500 ship limit has been reached)
will cancel the build order and recycle all parts. In PHOST, the parts
required for ship construction are not recycled and the build order is
Planetary Friendly Code con
PHOST does support the transfer of configuration information in response
to a planetary friendly code of con, but the configuration is
sent in the UTIL.DAT file instead of as player messages. The contents
of a PCONFIG.SRC file, if present in the game directory on the
hosting system, are included verbatim in the UTIL.DAT file (see
the "Auxiliary Data Files" page for more details
on the format).
Cancelling Build Orders
PHOST allows players to cancel their build orders once the 500-ship limit
is reached when DOS Planets and VPUTIL/VPMKTURN are used (MAKETURN won't
PHOST does not keep old messages. Thus, the DeleteOldMessages
option has no effect. There are no plans to support this feature.
Cloning While Being Towed
HOST 3.2 disallows cloning when the ship to be cloned is being towed
away from the starbase. This behavior prevents two ships from being built
at the same base in one turn, since there are two distinct ship building
phases, one before movement and one after movement. PHOST (and newer
HOSTs --sr) has an inherent
limit of building one ship per turn at a starbase. Thus, there is no need
to implement a restriction against towing ships to be cloned. PHOST will
clone the ship as usual, and the regular build order, if any, will be deferred
until the next turn.
Ship Intercept Range Limit
HOST 3.2 implements a 200 LY range limit on intercept missions. The
reason for this limit is presumably to defend against "blind intercepts".
PHOST has other mechanisms that prevent abuse of this tactic, thus there
is no range limit for intercept missions in PHOST.
Adding to Minefields
When a ship is inside multiple minefields, a Lay Mines mission will add
mines to the minefield with the lowest ID number. In HOST, the mines will
be added to the minefield whose center is closest to the ship. Note,
however, that PHOST's Lay Mines In and
Lay Web Mines In extended missions
give you control over which minefield to add to.
Laying new Minefields
Once the 500 mine limit is reached, no more minefields can be laid.
In HOST, mine laying starts with ship #1, therefore low-ID ships have a
better chance to lay mines than high-ID ships. In PHOST, mine laying happens
in per-player Id order, giving every player a chance to be chosen first.
"VPA Extra Features"
HOST 3.22.036 has a switch "VPA Extra Features" which
permits some actions not doable with planets.exe or older
Winplan. PHOST behaves as if this switch is turned on with
respect to cargo transfers. The new PHOST team believes this rule
interpretation is more useful. Note that HOST 3.22.029 and earlier
behave the same as PHOST.
The other major difference introduced by this switch is that Host
checks intercept missions more rigid before permitting them, to stop
people from intercepting ships they cannot see (as far as host can
tell). This switch comes with a new alliance level ("FF allies") to
officially permit allies to see ships. This is quite similar to what
PHOST has always been doing using the Vision level alliance.
Mine scooping needs beams
Mine scooping, using the msc friendly code or the
Scoop Torpedoes extended mission
requires beams in PHOST, but not in HOST. There are good arguments for
Intercept-Attack honors Battle Order
In HOST (and PHOST 3.4a and below), ships that do
intercept attack (XA) fight in decreasing
ID order. In PHOST 3.4b and later, they honor the friendly code
battle order. This allows you to
choose the order in which your ships fight a common target.
Back to the index
Major Hosting Differences
Back to the index
PHOST does not use the HCONFIG program to generate the game configuration.
Instead, PHOST uses a plain-text PCONFIG.SRC
file, which it expects to find in the game directory.
Host Data Files
The data files used by PHOST and HOST are mostly the same, both in name
and in format of the contents. Some files are different, however. The "Directory
of Files" page has complete information on which files are used by
PHOST does not support the AUXBATT.INI interface, whereby HOST
defers its own combat stage and executes the commands in this file instead.
As of this writing, there are no known programs that make use of this interface.
Note, however, that PHOST's fine-grain hosting control
allows the replacement of combat with external programs. Also, the AUXBC.INI
hook is supported by PHOST 3.
PHOST does not support the sharing of alliance data in TRN files
via the TACCOM program. If PHOST encounters a TRN file with alliance
data in it (using the so-called "leech" method) then it will indicate that
the TRN file is corrupt.
Minor Hosting Differences
Back to the index
PHOST does not keep old messages. Thus, the DeleteOldMessages
option has no effect. There are no plans to support this feature.
This document is maintained by The Portable Host Project
Last updated 17 November, 2006