![[PHost Logo]](logo.gif) © |
Changes in PHOST 3
The Portable Host
Version 3.2.3.5g
|
INDEX
Introduction
This file describes all of the changes found in the 3.x series of PHOST,
as compared to the 2.x series. It is assumed that the reader is familiar
with all of the features found in PHOST 2.x. This document consists of
a brief but detailed listing of changes, intended to give hosts and players
familiar with PHOST 2.x a definitive reference of what has changed in between
the two major versions. For a more high-level view of PHOST's features,
please see the "PHOST Features" page. For a
list of recent changes to the latest release of PHOST 3.x, please see the
"Version Changes" page.
The changes in PHOST 3.x are summarized in this section by category.
The details of the changes follow in the next section. The final section
contains a summary of how the configuration options have changed between
PHOST 2 and PHOST 3. This section may help hosts who wish to upgrade their
games to PHOST 3.
Configurability
Hosting Environment
-
PHOST is now a 32-bit program
-
PHOST reads the PCONFIG.SRC file directly,
hence the PCONFIG program has been eliminated
-
PHOST uses the same format for data files on all platforms, hence the PCONVERT
program has been eliminated
-
The use of phasing flags (-1, -2, and -3) has
been eliminated. PHOST now uses the same AUXHOST.INI interface
as HOST (but with full memory available for add-ons).
-
PHOST now supports the AUXBC.INI hook
Customization (Design Games)
-
The new HULLFUNC.TXT interface allows
complete flexibility in the ship list
-
"Array-ized" configuration options allow formerly-global options to apply
on a per-player basis (including combat options)
Add-On Enhancements
-
Wraparound map behavior (e.g., PWRAP) is now
internal to PHOST and greatly enhanced to cover all aspects of the game
-
Remote control of allied ships eases co-ordination
of efforts in team games and alliances.
-
Allied players can perform inter-player chunnels (if enabled by AllowAlliedChunneling
config)
-
Allied players can fix each other's ships at starbases
-
Sweeping minefields with fighters now available to all players (see FighterSweepRate
and FighterSweepRange
config options)
-
New ship towing models allow a choice
between high HOST compatibility or new, alternative towing model
-
New extended missions for gather-build of fighters
(to free friendly code for combat ordering), standard Super Spy (i.e.,
non-Deluxe), gathering of credits from planets, gathering of clans from
planets, and gathering of multiple items from planets in a single turn.
-
New alternative anti-cloak
mechanism prevents own-player ships (and allied ships) from decloaking. New
anti-cloak immunity option gives
any player immunity to anti-cloak ships.
Improvements for Add-On Developers
-
PHOST now supports a fine-grain hosting system
that allows AUXHOST-type hooks to be executed at any position in the mission
ordering, or even as replacements for PHOST processing stages.
-
PHOST uses the same format for data files on all platforms, hence the PCONVERT
program has been eliminated.
-
The use of phasing flags (-1, -2, and -3) has been eliminated. PHOST now
uses the same AUXHOST.INI interface as HOST (but with full
memory available for add-ons).
-
PHOST now supports the AUXBC.INI hook.
-
Add-Ons may now write battles to the VCR.HST file and have them
sent to players in their RST files.
-
A new file SHIPSCAN.EXT is
written to the game directory containing ship scan information.
-
A new send fcodes command processor
command allows the client side to obtain a list of all friendly codes considered
special by PHOST
-
The File Transfer record type in UTIL.DAT
files now automatically converts text file end-of-line characters to MS-DOS
format (if hosting on a Unix system)
-
Compatibility with HOST-type alliances
has been implemented at the file level
Miscellaneous Improvements
-
Documentation has been converted to HTML format and expanded
-
HOST 3.2 compatibility has been improved in several areas (eating supplies
increases maximum colonist limit, towing model, newly built ships get random
ID numbers, chunneling occurs after glory devices explode, Lizard ships
get damage-limited number of beams/tubes/bays in combat relative to 150%
damage rather than 100% damage, non-Crystal web mines don't drain fuel,
alliances now recognized by add-ons)
-
Money and minerals for cloning do not have to be present at a starbase
until the turn on which the clone is ready to be built
-
Natives no longer grow or die on unowned planets
-
Friendly codes are now randomized after a hyperwarp (to prevent inadvertent
hyperwarping) and after a ship is given away. When friendly codes are randomized,
they are no longer set to completely-numeric codes (to prevent unwanted
chunneling and setting of battle order).
-
Message filtering can cut down on the
number of messages received by players.
-
Even stronger cheat checking
-
PVCR 3 displays ship hull names and allows viewing a single battle from
the command line.
Back to the index
Detailed List of Changes
-
PHOST is now a 32-bit program. On non-DOS systems, this is not a change.
For DOS, however, this means that you now need at least a 386-class machine
to run PHOST. It also means that you must run PHOST under an
operating system that supports 32-bit DOS programs. Such operating
systems include Windows 3.1 with Win32s, Windows95, Windows NT, and DOS
machines with a DPMI server. PVCR continues to be a 16-bit program.
The benefits of a 32-bit PHOST program include not having to run PHOST
in phases (see below) and not having to worry about running out of memory.
-
PHOST data files are now transportable across all platforms. The same data
files that are used under DOS can be used on any other platform that PHOST
3.x runs on. There is no need to use the PCONVERT program (which no longer
exists and is not part of the PHOST 3.x distribution).
If you are currently running
a PHOST 2.x game on a non-DOS system, you must use PCONVERT 2.x to convert
the files to DOS format (using the -r switch) before ugprading
to PHOST 3.x.
-
PHOST now reads the PCONFIG.SRC
file directly. Thus, the PCONFIG program is no longer used (and is
not part of the PHOST 3.x distribution).
-
PHOST allows the ship list designer (or adventurous host) to modify
the special functions (like cloaking, chunneling, etc.) that various
hulls can perform. Previously, special hull functions were linked to certain
hulls with no possibility of modification. For example, only the Firecloud
Class Cruiser was capable of chunneling. It was not possible to assign
chunneling capability to any other ship.
Using the new HULLFUNC.TXT interface, it
is now possible to assign any special function to any hull (or, conversely,
to remove a special function from a hull). Also, it is possible to limit
the players that may use a special function. For example, it is possible
to say that the Firecloud can chunnel, but only when it is owned by a Borg
player.
-
PHOST allows the host to have fine-grain control
over the internal processing stages. An AUXHOST-type hook can be inserted
at nearly any point in PHOST's internal mission ordering and can even replace
one of PHOST's built-in processing stages. This gives add-on programs much
greater control over what they can do and when they have to do it. See
the "Fine-Grain Hosting Control" page for more
details.
-
PHOST can implement a true wraparound map, much
like the external add-on programs PWRAP and Sphere, except that PHOST reaches
beyond the limitations of those programs to allow everything to
wrap around. This includes minefields, sensor sweeps, ship scans, etc.
The wraparound feature is enabled by the AllowWraparoundMap
config option, and the wraparound region is configured by the WraparoundRectangle
config option.
-
PHOST now implements a priority build point system that is meant to arbitrate
the building of new ships once the 500-ship limit has been reached. This
system is similar in principle to HOST's priority build points (PBP's)
but different in implementation. More details can be found on the "Ship
Build Queue" page.
-
Some configuration options have been "array-ized". That is, they can now
have different values for different players. These config options are:
-
Most combat configuration options have been "array-ized", meaning that
different players may have different combat capabilities. The only combat
config options that have not been array-ized and remain the
same for all players are:
-
Three new combat config options have been added. These are all "array-ized"
options meaning that they can have different values for different players.
The new options are:
-
The PCONFIG.SRC file now allows
a shorthand way of assigning the same value to all elements of an array-valued
config option. Simply specifying one element will fill all array elements
with that value. For example:
is equivalent to:
TerraformRate = 2,2,2,2,2,2,2,2,2,2,2
This allows hosts to not worry about which config options have been "array-ized"
(see above).
-
Added a new extended mission, Standard
Super Spy. This mission only works for Birdman races. This mission
functions exactly the same as the regular Super Spy mission, but it does
not perform a Deluxe Super Spy mission (i.e., no planetary friendly
code changes are attempted). A Standard Super Spy mission can also be performed
by setting the ship's friendly code to begin with 'x' or 'X' (for HOST
compatibility). The extended mission, however, is clearer to the player
and frees the friendly code to determine battle order.
-
Added a new extended mission, Gather-Build
Fighters. This mission only works for the Robots, Rebels, and Colonies.
This mission mirrors the use of the lfm friendly code, but it
takes one parameter that specifies the maximum number of fighters to build,
and also serves to free the friendly code for use in setting combat order.
-
Added a new extended mission, Beam Up
Credits. This mission "pulls" credits from a planet rather than having
them "pushed" onto the ship using the bum friendly code.
-
Added a new extended mission, Beam Up
Clans. This mission allows ships to beam up clans from friendly (e.g.,
allied) planets. As this mission represents new, add-on-type behavior,
the usage of this mission is governed by a new config option, AllowBeamUpClans.
-
Added a new extended mission, Beam Up
Multiple. This mission works in conjunction with a new command processor
command, beamup. The extended
mission allows a ship to beam up varying amounts of multiple minerals (and
clans, supplies, and money) from a friendly (e.g., allied) planet. As this
mission represents new, add-on-type behavior, the usage of this mission
is governed by a new config option, AllowBeamUpMultiple.
-
Added two new extended missions, Lay Mine
In and Lay Web Mines In. These
missions allow the player to specify a specific minefield ID number in
which to add mines. This gives players more control over minefield behavior
when there are multiple overlapping mines.
-
Added the ability of allied players to chunnel to each other's ships. Two
players that are allied and that have enabled the ship
alliance level to each other can now chunnel to each other's ships
(if those ships are capable of chunneling). The chunneling rules are the
same as for intra-racial chunneling. As this feature represents new, add-on-type
behavior, allied chunneling is only allowed if the AllowAlliedChunneling
config option is enabled.
-
Added the ability of allied players to fix each other's ships at starbases.
If a player enables the Planet Level
of alliance to his ally, then he will be able to use the Fix mission at
a starbase to fix an ally's ship (i.e., restore the full crew complement
and set the damage level to 0%).
-
Added new config options FighterSweepRange
and FighterSweepRate
to allow sweeping minefields with fighters by all players, not just the
Colonies. These two options now replace the ColonialFighterSweepRange
and ColonialFighterSweepRate config options. Attempting to set
these latter two options will cause PHOST to issue an error message.
To maintain compatible behavior, i.e., only allow the Colonies to sweep
minefields, use the following settings:
FighterSweepRate = 0,0,0,0,0,0,0,0,0,0,20
FighterSweepRange = 0,0,0,0,0,0,0,0,0,0,100
modifying the true sweep rate and range for the Colonies as desired.
-
Added a new config option, SpyDetectionChance,
to allow the detection rate for the Super Spy mission to be configurable.
This config option does not affect the Deluxe Super Spy mission.
-
Added a new config option, MaxShipsHissing,
to limit the number of ships that can perform the Hiss mission at any one
planet.
-
Added a new config option, AllowExtendedMissions,
to give the host control over whether or not extended missions should be
recognized.
-
Added a new config option, AllowAlliedChunneling,
to configure the ability of inter-racial chunneling (between allies). See
the "Alliances" page for more details.
-
Added a new anti-cloak immunity
config option.
Previously, anti-cloak immunity was given to the Federation and the
Lizards, and extended to the Birdmen in HOST 3.22.022. As of PHOST 3.2.3.2,
anti-cloak immunity is no longer a racial ability but is now
per-player-configurable using this option.
-
Added two new config options, ColonistTaxRate
and NativeTaxRate, to set
tax revenue rates for colonists and natives separately. These two new options
supersede the old RaceTaxRate option (which set the tax rate for
both colonists and natives). Both of these new options can have different
values for different players.
-
Added a new player-specific config option, FilterPlayerMessages
to implement message filtering. This
simply prevents players from getting certain messages which duplicate information
present in their UTIL.DAT files.
-
Added a new command processor command, filter,
to allow players to modify their settings for the FilterPlayerMessages
configuration option.
-
Removed the AllowAdvancedCloaking config option. Disabling the
advanced cloak feature can now be done using the HULLFUNC.TXT
interface.
-
Added a new command line option in support of the new
HULLFUNC.TXT interface. The -l option causes PHOST to list
(to stdout) the ship list that PHOST will be using for the given
game directory and root directory (if specified). This list will include
the special functions that each hull can perform, as well as the players
that can perform this function (if such a restriction exists). This new
option is useful for generating a ship list report to send to players when
the ship list has been modified by the host. It is also useful for checking
your work when writing or modifying a HULLFUNC.TXT
file.
-
Phasing has been eliminated. That is, PHOST no longer requires the -1,
-2, and -3 flags and no longer runs as three separate
programs. Instead, PHOST uses the same mechanism as HOST: AUXHOST.INI
files that indicate which programs to run. For more details, please see
Using AUXHOST Addons section of the "Hosting
with PHOST" page.
-
A new external program phase has been added in support of custom combat
add-ons. Immediately prior to combat, PHOST will look for and execute the
contents of a file named AUXBC.INI, if it is found in either the
game directory or the main directory. (HOST 3.22.005 compatibility)
-
The PHOST data files (including the ship list) are now checked for meeting
file size requirements. This will catch many common cases of incorrect
PHOST behavior due to corrupted game files.
-
UTIL.DAT record #7 (Battle Result) is
now also sent to the allies of the participants in the battle, as long
as the ship, combat, and vision levels of alliance have been enabled to
the allies. This is now consistent with the sharing of VCR's with these
allies (introduced in PHOST v2.12).
-
Clone build order behavior has been slightly modified. Previously, once
the 500-ship limit was reached, the planet supporting a clone order was
required to have sufficient money and minerals for all turns in which the
clone order was in the build queue. If on any turn there were fewer than
the expected number of credits or minerals, the clone order would be cancelled.
Now, this requirement has been removed. It is possible to enter a clone
order into the build queue without a sufficient number of credits or minerals.
If, however, the clone order is ready to be fulfilled on a given turn and
the minerals/money are not there, the clone order is simply ignored and
removed from the queue.
The build queue report now marks clone orders that would fail with the
character '!'. This mark indicates that should the clone order appear at
the top of the build queue next turn, ready for construction, the clone
order would fail due to insufficient minerals or credits at the planet.
This new clone order behavior frees players from having to reserve minerals
or money on a planet when they know that a clone order is many turns away
from being fulfilled.
This new behavior has also slightly modified other aspects of ship building.
Previously, if a clone order was invalid and the base had another, regular,
ship build order, the regular ship build order would go through. Now, an
invalid clone order prevents the base from building a ship through the
normal build order.
-
Newly-built ships are now assigned random ID numbers. (HOST 3.22.005 compatibility)
-
Chunneling now occurs after glory devices explode (HOST 3.22 compatibility).
In PHOST 2, chunneling occurred as part of movement, before glory device
explosions.
-
Lizard ships now have their damage bonus applied to the number of beams,
tubes, and bays that are available in combat. For example, a non-Lizard
ship with 50% damage will have half of all beams, tubes, or bays available
for combat, while a Lizard ship with 50% damage will have 2/3 of these
weapons available (since damage is computed relative to 150% rather than
100%).
-
Non-Crystalline web mines no longer drain fuel from ships. Hitting a web
mine always causes fuel loss, regardless of the minefield's owner, but
only Crystalline web mines now drain fuel from ships sitting in web mines.
-
Natives no longer grow or die on unowned planets.
-
After a successful hyperwarp, a ship's friendly code is changed from HYP
to a random 3-character string to prevent additional, unwanted hyperjumps
on subsequent turns.
-
After a ship is given away using the gsN friendly code or the
give command processor command, the ship
is now given a random friendly code that is not completely numeric. Previously,
the ship was given a numeric friendly code which, in at least one reported
case, caused the ship to chunnel without meaning to do so.
-
Newly built ships are no longer given completely numeric friendly codes
(to prevent unwanted chunneling, etc.)
-
The formulas for native and colonist climate deaths have been slightly
modified to limit their population to 25,000,000 in all cases.
-
The maximum number of clans supported on a planet is now increased by planetary
supplies when the AllowEatingSupplies
configuration option is enabled. Also, the number of supplies eaten is
now related to the number of clans over the maximum climate limit, rather
than the number of clans that have died due to climate. This now more closely
matches HOST 3.22 behavior.
-
Super Spy messages now include the number of supplies on a planet. As a
result, the format of the Super Spy message has changed slightly. Similarly,
the Super Spy UTIL.DAT record
(record type #4) now has an extra field for the number of supplies. (HOST
3.22.010 compatibility)
-
PHOST alliances are now reflected as
HOST-type "locking alliances" for the benefit of add-on programs that
only recognize HOST-type alliance information.
-
Added new cheat check for illegal cargo transfers to same-race ships or
non-existent ships.
-
Added new cheat check for cheating using numeric overflow techniques.
-
PHOST will now look for the PLANG.HST file in the game or root
directory, as before, but if it is not found, PHOST will then look for
PLANGENG.HST, also in the game or root directory. Thus, it is
no longer necessary to rename PLANGENG.HST to PLANG.HST.
Hosts who wish to conserve disk space may simply delete PLANG.HST
and only support English-language messages in their games (through PLANGENG.HST).
To simplify the hosting of both PHOST 2.x and PHOST 3.x games, PHOST
3 will also recognize the language database under the names PLANG3.HST
and PLANG3EN.HST. The PHOST 3 language database can be installed
as PLANG3.HST (or PLANG3EN.HST for the English-only version)
while keeping the PHOST 2.x language database as PLANG.HST.
-
Because the PCONFIG.HST file is no longer used, PHOST now uses
a different mechanism for storing player-modified configurations. In PHOST
2.x, PHOST would store player-modified values of the Language
and AllowMoreThan50Targets
config options in the PCONFIG.HST file. In PHOST 3, the PCONFIG.SRC
file is directly modified with the new information. PHOST will make a backup
copy of the PCONFIG.SRC file in the game directory (named PCONFIG.BAK),
comment out the old assignment for the config option, then follow it with
a new assignment statement that reflects the player-modified configuration
setting.
-
When using the -c flag, PHOST now creates two log files, CHECK.LOG
and CHECK2.LOG. Both files contain almost the same information,
the only difference being that CHECK.LOG no longer has the results
of host data file checking. This solves an arcane problem: checking host
data before checking the TRN file is a good idea to preserve integrity
but it has the potential of revealing private data to all players.
For example, if player 2's TRN file is being checked but one
of player 1's bases has an invalid base build order, an error message will
be displayed indicating that the host data has an error (the invalid base
build order). This error message will also include the ID number of the
base, and this data is all part of the turn check information that is sent
back to player 2. Thus, player 2 has inadvertently discovered the location
of one of player 1's bases.
In PHOST 3, CHECK.LOG no longer contains the results of host
data file checking (but CHECK2.LOG does).
Thus, the CHECK.LOG file is suitable for sending back to players,
while the CHECK2.LOG file is suitable for review by the host.
-
A new file is written to the game directory after ship scans are performed
in Phase 3. The SHIPSCAN.EXT
file contains information regarding which players have scanned or can otherwise
see a given ship at the end of the turn. This may help some add-on programs.
-
A new send fcodes command processor
command allows the client side to obtain a list of all friendly codes considered
special by PHOST. In response to this command, PHOST will send a file named
XTRFCODE.TXT in next turn's UTIL.DAT file using the File
Transfer record type. This file will contain all of PHOST's internal
special friendly codes as well as any additional codes specified in
the XTRFCODE.TXT file on the host
side. Note, then, that the player's XTRFCODE.TXT file will
have more friendly codes than the host's version of this file. The two
files will not be identical.
-
The "minefields exploding" message now has the correct encoding for WinPlan's
message sorting mechanism.
-
The File Transfer record of UTIL.DAT
files now sends text files with the correct MS-DOS line endings (i.e.,
CR-LF instead of just LF) when hosting on Unix systems.
-
The new -d PHOST command-line option prints the current time stamp
and exits. This option may be useful for implementing some automated hosting
scripts.
-
The new -i PHOST command-line option prevents PHOST from reading
and interpreting AUXHOST.INI files. This option may be useful
for debugging.
-
PVCR now displays the names of the ship hulls involved in the battle along
with the ship names on the battle selection screen.
-
The new -b PVCR command-line option allows the user to view a
single battle, specified as a number following the -b option.
-
New UTIL.DAT records have been added (types 37 through 40). Please
refer to the "Auxiliary Data Files" page for
more details.
-
The bigtargets command processor
command now has a minimum abbreviation of bi instead of just b
in order to distinguish it from the new beamup
command.
Configuration Option Changes Summary
The following config options have been deleted. Please remove these options
from your PCONFIG.SRC file:
The following config options have been renamed (and enhanced). Please
review the "Configuration Parameters" page and
modify the names of these options in your PCONFIG.SRC file.
The following config options have been added. Please review their descriptions
in the "Configuration Parameters" page and add
them to your PCONFIG.SRC file.
A whole new set of config options related to the priority build queue have
been added. Please see the "Ship Build Queue"
page for more information. You may add these to your PCONFIG.SRC
file or exclude them, in which case default values will be used.
This document is maintained by The Portable Host Project![[Remote]](remote.gif)
(support@phost.de).
Last updated 7 December, 2001