©	HOST/PHOST Differences The Portable Host Version 3.2.3.5g  Jump to Table of Contents

• Introduction
• Playing Differences
• Major Differences
• Minor Differences
• Hosting Differences
• Major Differences
• Minor Differences

Introduction

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 

Playing Differences

Major Playing Differences

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

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 v2.2 (or a more recent version) program is an excellent simulator of both HOST and PHOST combat.

Alliances

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 2 years.

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 details.

HOST 3.22.039 implements a second level of alliance ("FF allies"). PHOST's vision level alliance is roughly the same.

Configuration Options

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 "changed").

 

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.

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 be disabled.

Towing

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 HOST behavior.

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:

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 is OFF

If the ship has a warp speed of 1 (unless the ship has hyperwarped, in which case its speed doesn't matter)

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, for example).

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 is enabled).

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 documentation.

Ion Storms

PHOST 3.x does not implement Ion Storms. Ion storms are implemented in PHost 4.0j and later.

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 that field.

Super Refit

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 Operation" page.

Rounding

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.

New Natives

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.

Minefield Explosions

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 laid.

Reclaimed Minerals

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 failure.

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 base hulls:

1. When a planet becomes unowned, the base is destroyed along with all hulls in storage.
2. 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.
3. 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 not cancelled.

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 work).

The DeleteOldMessages Option

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 either interpretation.

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.

Hosting Differences

Major Hosting Differences

Game Configuration

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.

AUXBATT.INI Interface

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.

TACCOM Support

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

The DeleteOldMessages Option

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 (support@phost.de).