![[PHost Logo]](logo.gif) © |
Game Play Summaries
The Portable Host
Version 3.2.3.5g
|
INDEX
Introduction
This page is different from all other documentation pages that come with
PHOST 3 in that it discusses aspects of the game that the player is assumed
to already know. For example, one of the topics below discusses the setup
and operation of a chunnel. This is not specific to PHOST, of course, but
it is an issue that comes up so often and is often clouded in mystery.
The documentation in this file, then, attempts to summarize, for the experienced
player, the exact details of some of the more complicated aspects of game
play. Unless otherwise indicated, the documentation below applies to both
HOST and PHOST.
Back to the index
Playing Advantages of WinPlan over DOS Planets/VPA
In games which have a mix of players, some using WinPlan and some using
DOS Planets or VPA, the issue often arises as to what kinds of advantages
WinPlan players have been given. As of this writing, the following advantages
are known:
-
WinPlan players can see their own minefields without having to scan (mine
sweep) for them. DOS Planets/VPA players must set some ships to perform
the mine sweep mission in order to scan their minefields.
-
WinPlan players can jettison ammunition (fighters and torps) and megacredits
in deep space. DOS Planets/VPA players cannot do this.
-
WinPlan players receive RST files which contain UFO's (that is,
objects listed in the UFO.HST file). DOS Planets/VPA players only
receive old-style RST files (pre-HOST 3.2) which do not contain
this information.
-
WinPlan players (and VPA players) can transfer any cargo from ship-to-ship
at any time. DOS Planets players require the support of external utilities
such as VPUTIL to do this.
Back to the index
Glory Devices
The D19b Nefarious Class Destroyer and Saber Class Frigate are now outfitted
with glory devices. These devices can be used to blow up the ship either
on command, or when a cloaked ship is detected. The use of glory devices
is enabled by the AllowGloryDevice
config option.
Triggering
A glory device can be detonated using one of two friendly codes:
-
pop : the glory device will be detonated unconditionally
-
trg : the glory device will be detonated if a cloaked ship of
the right race is detected at the same place as the glory device ship
When the trg code is used, then the ship's primary enemy setting
determines the race that will set off the glory device. Only cloaked ships
of that race will cause the detonation. If, however, the ship with the
glory device has a Kill mission, then any cloaked ship (except ships of
the same race as the one with the glory device) will detonate the glory
device.
As mentioned above, same-race ships will not detonate a glory device
with the trg code. In addition, ships belonging to a race to whom
the glory device ship's owner has granted the Ship
Level of alliance will not trigger the glory device.
Note that glory devices detonate
after movement but before combat.
Damage
When a glory device detonates, there are several effects that occur:
-
The ship with the glory device is destroyed
-
All ships at the same point in space as the ship with the glory device
will suffer damage. Ships that are not of the same race as the ship with
the glory device will suffer damage equivalent to one mine hit. The remaining
ships (of the same race as the glory device ship) will suffer 10% of the
damage caused by one mine hit if the glory device ship is the Saber, or
20% of the damage caused by one mine hit if the glory device ship is the
D19b Nefarious. In addition, ships that are not of the same race as the
glory device ship but belong to allies to whom the Ship
Level and Combat Level
of alliance has been granted also sustain reduced damage (10% or 20% of
a single mine hit).
-
If the glory device detonates at a planet and the planet has Amorphous
natives, then all natives are converted into supplies at the rate of 1000
natives for 1 supply unit. The planet will then be rid of all the Amorphous
natives. In this case, the owner of the planet does not matter (i.e., this
will work even if the planet owner is the same as the owner of the ship
with the glory device).
-
If the glory device detonates at a planet that is not owned by the same
race as the glory device ship, then 40% of colonists and natives are killed,
and 25% of mines, factories, and defenses are destroyed. Lizard and Crystalline
colonists are immune to this effect, as are Bovinoid and Reptilian natives.
The 25% loss of structures still occurs, even if the colonists or natives
are immune to the glory device effects.
Back to the index
Tow Capture (Boarding Parties)
The Privateers and Crystals are able to capture fuelless ships in space
using a method known as "tow capture" (also commonly referred to as "boarding
parties"). By attempting to tow a fuelless ship, the Privateer or Crystal
ship will assume command of that ship on the next turn. The ship performing
the tow must have fuel, but the tow need not be a successful one. That
is, the tow is really just a targetting mechanism, indicating which ship
is the one to be captured. Unless AllowOneEngineTowing
is enabled, a ship needs two engines in order to perform tow capture.
When a ship is captured in this manner, some of the crew from the captured
ship is lost and must be replaced. For most races, all of the crew is lost.
The following races are exceptions:
-
Empire : 60% of the crew is lost
-
Colonies : 30% of the crew is lost
-
Federation : 10% of the crew is lost
-
Privateers : no crew is lost
The lost crew is replaced by a boarding party consisting of crew from the
ship performing the tow capture. Thus, the number of crew on the capturing
ship will be decreased. However, a maximum of half the crew from the capturing
ship is used to fill the empty crew slots.
The tow capture mechanism is generally enabled by the AllowBoardingParties
config option. This mechanism can be enabled or disabled for the Privateers
and Crystals individually using the AllowPrivateerTowCapture
and AllowCrystalTowCapture
config options.
A ship whose friendly code is nbr will not perform tow capture.
Back to the index
Deluxe Super Spy
The Birdmen's Super Spy mission has an extra component known as Deluxe
Super Spy. Each ship performing the Super Spy mission in orbit of a planet
has a 20% chance of changing the planet's friendly code to be the same
as the ship's friendly code. If there are multiple ships performing a Super
Spy mission in orbit of the same planet, then the ships work together to
linearly increase the chance of success in changing the planet's friendly
code. That is, 2 ships will have a 40% chance of changing the friendly
code, 3 ships will have a 60% chance, etc. Five or more ships are guaranteed
to change the friendly code of the planet.
If the ships performing the Super Spy mission have different friendly
codes, then the planet's friendly code (if changed) will be set to the
friendly code of the ship with the lowest ID number.
When a planet's friendly code is changed in this manner, it may emit
an ionic pulse. See the discussion of Ionic Pulses
below for more details. When the friendly code is changed to one beginning
with the letters mf then the ionic pulse is certain to be emitted
(as long as the planet has at least 30 defense posts).
The Deluxe Super Spy mission is performed automatically whenever a ship
is set to perform the Super Spy mission. There are two exceptions to this
case. When a ship's friendly code begins with the letter x or
X, then no Deluxe Super Spy is performed. That is, no friendly
code changes are attempted and there will be no ionic pulse. For PHOST
only, the Standard Super Spy extended
mission also inhibits the Deluxe Super Spy aspect of the mission.
Back to the index
Ionic Pulses
When a Birdman Deluxe Super Spy mission successfully changes a planet's
friendly code (see the Deluxe Super Spy discussion
above), then the planet has a 20% chance of emitting an ionic pulse that
uncloaks all cloaked ships in orbit of the planet (that is all ships,
not just the ones performing the Super Spy mission). If the friendly code
has been changed to one beginning with the letters mf then the
ionic pulse is emitted unconditionally. In all cases, however, the planet
must have at least 30 defence posts for this to occur. By emitting this
ionic pulse, the planet loses 10 defence posts.
There is no control over this ionic pulse, it is an automatic response
of planetary defence systems.
Also note that the 20% chance of emitting the ionic pulse applies only
to cases in which the planetary friendly code is changed via the Super
Spy mission. For example, if one Birdman ship is performing the Super Spy
mission, then on average, one out of every 5 turns will see a successful
friendly code change. For each friendly code change, there is a 1 in 5
chance of emitting the ionic pulse. Thus, on average, the ionic pulse will
be emitted once every 25 turns (assuming a continuous Super Spy).
Back to the index
Chunneling
The Firecloud Class Cruiser can perform a form of movement called chunneling.
A chunnel is similar to a wormhole in that it
allows travel over great distances, but unlike wormholes, chunnels can
be created by starships. Chunneling is complicated, both in setting up
and in execution. The prerequisites and effects of chunneling will be described
separately. Chunneling is enabled by the AllowChunneling
config option.
Setting up a Chunnel
A chunnel is formed by two Firecloud ships. One Firecloud (the chunneler)
sets its friendly code to be the ID number of the other Firecloud (the
target). The friendly code must be completely numeric (no non-digit characters,
use leading 0's to specify ship ID numbers less than 100). In addition,
the following restrictions apply:
-
The chunneler Firecloud must have at least 51 KT of fuel
-
The target Firecloud must have at least 1 KT of fuel
-
Both Fireclouds must have their warp speeds set to 0
-
Both Fireclouds must be owned by the same player (unless, for PHOST, both
players are allies, have enabled the Ship
Level of alliance to each other, and AllowAlliedChunneling
is enabled).
-
Neither Firecloud may be the successful target of a Tow mission
-
The distance between the two Fireclouds must be 100 LY or greater
Chunneling Effects
Once a chunnel has been successfully formed, the following effects will
occur:
-
The chunneler Firecloud loses 50 KT of fuel
-
The chunneler Firecloud is moved to the same position as the target Firecloud
-
Some ships that are at the same location as the chunneler Firecloud are
also moved to the same position as the target Firecloud. These ships do
not lose any fuel. The ships that will be moved through the chunnel are:
-
ships of the same race as the two Fireclouds, or
-
ships whose warp speed is set to 0, or
-
ships that are cloaked, or
-
ships whose friendly codes match the friendly code of the chunneler Firecloud
(i.e., the ID number of the target Firecloud), or
-
ships without fuel
-
All ships that move through the chunnel will have 0 shields on that turn
for the purposes of combat.
Back to the index
Bioscanners
The Cobol, Brynhild, and Pawn ships are outfitted with a Bioscanner device.
This device is capable of detecting native life and planet climate on remote
planets. Bioscanners are enabled with the AllowBioscanners
config option.
A Bioscanner is activated when a ship performs the Sensor Sweep mission.
The range of the Bioscanner is the same as the configured range of sensor
sweeps, SensorRange. Each
planet within range has a 20% chance of being detected by the Bioscanner
on a single turn (except for the Pawn, which will detect planets with 100%
probability). Planets with at least 20 defence posts can not be detected
by Bioscanners.
A bioscan of an Empire planet will return false information, except
if the ship performing the bioscan is a Rebel ship.
Back to the index
Imperial Assault
The Super Star Destroyer can perform a mission known as Imperial Assault.
This mission is activated by dropping at least 10 clans from the ship onto
an owned planet, at which time all colonists on the planet are killed and
the planet becomes owned by the player that owns the Super Star Destroyer.
The planet will then have 0 defence posts. The Imperial Assault mission
is enabled by the AllowImperialAssault
config option.
This mission will fail if the Super Star Destroyer has sustained any
damage to its hull. The ship must have 0 damage for the mission to work.
The ship must also have fuel to succeed in this mission.
Also, when AllowImperialAssault
is enabled, the Super Star Destroyer is immune to the ATT
and NUK planetary friendly codes at all times.
For PHOST, if the Super Star Destroyer drops clans onto a planet owned
by an ally who has enabled the Planet
Level of alliance, then no Imperial Assault takes place. The clans
are simply added to the planet's population.
Note that Imperial Assault is a ship-related ability, not a race-related
one. Any player in posession of a Super Star Destroyer is capable of performing
Imperial Assault. For PHOST only, the custom hull
functions interface may restrict Imperial Assault capability to certain
players.
Back to the index
Decloaking Ships (The Loki)
The Loki Class Destroyer continuously emits a tachyon pulse that decloaks
all ships within a 10 LY radius of the Loki.
Ships owned by the Federation or the Lizards will not be affected by the
tachyon pulse and will not decloak.
All other races' ships will be decloaked by the tachyon pulse even
if the ship emitting the pulse is owned by the same player! The
Loki must have fuel and must have less than 20% damage in order to emit
the tachyon pulse. This feature is enabled by the AllowAntiCloakShips
config option.
Note that the AlternativeAntiCloak
config option changes the above behavior so that there is no special immunity
for the Federation or the Lizards, but there is immunity for own-player
ships and allies to whom the ship level
of alliance has been granted. See the Alternative
Anti-Cloak section of the "Playing with PHOST"
page for more details.
Back to the index
Minefield Friendly Codes
Minefields are assigned friendly codes. The friendly code of a minefield
is the same as the planetary friendly code of the closest planet (closest
to the center of the field) belonging to the same player as the owner
of the minefield (not just the closest planet). The effects of minefield
friendly codes are as follows:
-
a ship whose friendly code matches that of the minefield will not hit mines
in that minefield as it travels through it
-
a ship whose friendly code matches that of a web mine field will not have
fuel drained from it
-
a ship whose friendly code matches that of the minefield will not sweep
mines from the minefield. When it uses the Mine Sweep mission, it will
just scan them.
Ships may also take advantage of a universal minefield friendly code to
make use of the above immunities. A player's universal minefield friendly
code is determined by one of his planets which has a friendly code beginning
with the letters mf. If no such planet exists, then there is no
universal minefield friendly code for that player. If multiple planets
exist with friendly codes beginning with mf, the planet with the
highest ID determines the universal minefield friendly code.
A ship may use either a specific minefield's friendly code or the universal
minefield friendly code to escape the minefield's effects.
Minefield friendly codes
is a feature which exists for HOST compatibility. With PHOST's alliance
mechanism, players can enjoy all of the above enhancements without
having to worry about friendly codes.
Back to the index
Cloning
The cln friendly code allows ships to be cloned. When a ship is
cloned, an exact copy of the ship is made, with the same type of engines,
and the same number and type of weapons. The mineral cost of the cloned
ship is the same as the original ship, but the monetary cost is nominally
double that of the original ship's cost (in PHOST, this is configurable
on a per-player basis with the ShipCloneCostRate
configuration parameter).
A ship may only be cloned at a starbase. In addition, the following
restrictions apply:
-
The starbase must be owned by the same owner as the ship to be cloned,
or, in PHOST, by an ally who has enabled the Planet
Level of alliance.
-
A starbase can support only 1 clone or 1 regular build order on a given
turn.
-
The planet must have sufficient minerals and megacredits to build the clone,
and the starbase must have equal or higher tech in all 4 tech levels as
the components on the ship being cloned.
-
The ship to be cloned can not be a ship that the ship's owner can normally
build via starbase construction.
-
Ship cloning takes precedence over normal construction. That is, if there
is both a ship to be cloned and a normal build order at a planet, then
only the clone order will be honored.
-
If a ship's clone order is valid, then its speed will be set to 0 to force
it to remain at the starbase for that turn.
Ship cloning is enabled by the AllowShipCloning
config option.
Back to the index
Gravity Wells
Gravity wells pull a ship that is near a planet to the planet's orbit if
the ship is close enough. This is enabled by the AllowGravityWells
config option. In PHOST, the GravityWellRange
and RoundGravityWells
options further dictate the region in which gravity wells have effect.
There are situations, however, in which gravity wells do not pull ships
in to a planet's orbit:
-
if the ship has not moved this turn
-
if the ship is already orbiting a planet
-
if the ship has chunneled (since gravity wells take effect prior to chunneling)
-
if the ship has hyperwarped and AllowHyperjumpGravWells
is disabled
-
if the ship has a warp speed of 1 (unless the ship has hyperwarped, in
which case its speed doesn't matter)
Back to the index
This document is maintained by The Portable Host Project![[Remote]](remote.gif)
(support@phost.de).
Last updated 30 April, 2007