©	PHOST Features The Portable Host Version 3.2.3.5g Jump to Table of Contents

INDEX

• Introduction
• Playing Features
• Hosting Features

Introduction

This page describes features specific to the PHOST program. We'd like you to think of PHOST in the following way:

The differences between HOST and PHOST behavior are documented in the "HOST/PHOST Differences" page. The new features found only in PHOST are documented right here. For a list of feature differences between the PHOST 2.x series and the PHOST 3.x series, please see the "Changes in PHOST 3" page.

This page is split up into two sections, playing features and hosting features. Some features are of interest to both hosts and players and are listed in both sections. The features that we consider most significant are listed first.

Back to the index

Playing Features

Alliances

PHOST implements formal alliances via the PHOST command processor. Please follow these preceding links for more information. Alliances are one of the most favorite player features of PHOST and are definitely worth the time to investigate.

Players can Play Any Race

PHOST allows any player to assume the racial benefits of any one race. A new config option PlayerRace maps player numbers to the effective race that they will play. For example, if player 1's effective race is 3, then player 1's special mission is Super Spy. For more details, please see the description of the PlayerRace config option.

True Wraparound Map

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.

Wormholes

PHOST implements wormholes in a fashion very similar to the currently available WORM program available for HOST. Please follow the preceding link for more information.

Extended Missions

PHOST supports extended missions via the M.I.T. interface in WinPlan and VPA, or by the command processor in DOS Planets. Extended missions are intended to reduce the dependence of the game on friendly codes. Some of the most common missions performed with friendly codes (torpedo construction, mine laying with a limited number of torpedoes, etc.) can now be performed with extended missions, leaving the friendly code free to determine battle order. Some new missions are also possible now, such as loading minerals and credits from planets to build torpedoes (like lfm but for torpedoes), and beaming up clans from allied planets.

Command Processor

The command processor feature of PHOST allows players to change their race names, set up alliances, send rumors (anonymous messages), and many other neat things.

Configurable Special Hull Functions

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.

Remote Control

PHOST allows players with the Ship Level of alliance to control each other's ships, without giving up ownership. This makes team play much easier. It also eases the burden on players that must fill in for other team members. For more information, please see the "Remote Control" page.

Priority Ship Build Queue

The building of ships once the 500-ship limit is reached is controlled by a priority queue system that is highly configurable.

Configuration Options

PHOST implements many new configuration options that can tailor game behavior. The "Configuration Options" page has a complete list of the new options and how they affect game operation.

Multi-Language Support

PHOST can generate player messages (and host messages) in any one of 8 languages (English, German, French, Spanish, Italian, Dutch, Russian, and Estonian). Players can select the language of their choice using the language command processor command or by having the host set the Language config option.

Please see the "Introduction to PHOST" page for the names of those hard-working folks who took the time and effort to translate PHOST's text database into other languages. If you'd like to join the ranks of these people by translating PHOST's text messages into another language, then contact us!

Transfer Planet Ownership

Planets can be given away from one player to another, much in the same way that ships are given away using the gsN friendly code. The command processor is used to perform this action.

Planets Fire Torps

If the PlanetsHaveTubes option is enabled then planets and starbases will be given tubes and torpedoes in battle, in addition to the normal complement of beams and fighters. The number of torps and tubes, and the torp tech is determined by the defense factor of the planet (and base) and the torp tech of the base (see the "Detailed Operation" page for more information).

If a base is present, then torpedoes that are in storage will be added to the torpedoes available for combat according to the algorithm described in the "Detailed Operation" page. In a fashion similar to fighters, there are replaceable torpedoes that come from the planet, and non-replaceable torpedoes that come from the base. If a planet with a base fires torpedoes, then the non-replaceable torpedoes are fired first and the number of torpedoes in storage at the base will be decreased once the battle is over.

Auxiliary Data Files (UTIL.DAT Files)

PHOST generates auxiliary files (UTIL.DAT files) for each player. These files contain the same information as the player messages except that it is in binary form. This information may be of use to add-on utilities. All three major data tracking utilities (Crystal Ball, EchoView, and Informer) as well as VPA can understand and make good use of UTIL.DAT files. The UTIL.DAT file information is especially useful for players who have a formal alliance. It is recommended that hosts send these files to their players along with the RST files.

Extended Alchemy Friendly Codes

The new friendly codes nat, nad, and nam for Merlin Class Alchemy Ships allow more control over which minerals to build. The nat code builds Duranium and Molybdenum (the same amount of each) but no Tritanium. Similarly, nad builds no Duranium, and nam builds no Molybdenum. These friendly codes work only for registered players.

Travel Behavior After Mine Hits

The HullTechNotSlowedByMines configuration parameter selects between two methods of adjusting a ship's travel after hitting a mine: a HOST-compatible mode and a time-distance mode. See the Minefield Travel section of the "Playing with PHOST" page for more details.

Slower Ships Travel Better Through Mines

Using six PHOST-specific configuration options, the host can configure the game in a manner that allows slower ships to have a smaller chance of hitting mines while travelling through minefields. The host can also set a warp speed limit below which all minefield travel is completely safe. Please see the Minefield Travel section of the "Playing with PHOST" page for more information.

New Towing Behaviors

PHOST's towing behavior has been completely revamped. A new config option, AllowAlternativeTowing, decides between a HOST-compatible towing model and a new, more regular model. The HOST-compatible model is much more similar to HOST 3.22 behavior than the towing model used in PHOST v2.x. The new model (with AllowAlternativeTowing enabled) determines tow strength and tow resistance based upon engine tech and number of engines; warp speed and distance to waypoint (the main determinants of the HOST towing model) are secondary considerations. More details can be found in the section on Towing in the "Playing with PHOST" page.

Alternative Anti-Cloak

PHOST 3 implements a new config option, AlternativeAntiCloak, which selects between a HOST-compatible anti-cloak mechanism and a new, alternative mechanism. The new anti-cloak behavior gives own-player ships immunity to anti-cloak (so you don't decloak your own ships) and extends this immunity to allies who have been allowed the ship level of alliance. Please see the Alternative Anti-Cloak section of the "Playing with PHOST" page for more details.

Native Deaths

Natives die because of overpopulation at the NativeClimateDeathRate rate if the ClimateLimitsPopulation configuration option is enabled.

Cloak Failure Notification and Mission Reset

If a ship has a cloak mission but has either insufficient fuel or excessive damage for cloaking to succeed, the ship's mission is cleared as an indication to the player. Players can also  receive messages whenever a cloaking mission fails due to any one of the many possible reasons behind the failure (e.g., random chance, lack of fuel, excessive damage, etc.) The AllowCloakFailMessages config option enables these messages.

HYP Friendly Code Reset

After a successful hyperjump, a ship's friendly code is changed to a random 3-character string in order to prevent another, unwanted, jump on the next turn.

PHOST Identification Message

PHOST will generate a player message on every turn (usually the last message a player sees) identifying the current result file as having been generated by PHOST. This allows external player utilities to handle PHOST-generated result files differently from HOST-generated results. This message also contains eight integers which are digests over the host's main data files as well as the configuration file and race name file in effect for the game. These digests can aid external utilities in automatically determining the correct ship list files to use for playing the turn. The digests over the configuration file and race name file alert player utilities to the fact that the host's configuration has changed.

The information in this message is simply a subset of the information found in the control record (record type 13) of the auxiliary data file (the UTIL.DAT file). The PHOST identification message allows player utilities to recognize a PHOST-generated result file even if no UTIL.DAT file is present.

Ship Recycled Message

PHOST will generate a message (and a record in the auxiliary data file) whenever a ship is recycled at a starbase.

Advanced Refinery and NAL Code

The advanced refinery function of the Aries Class Transport is disabled if the ship's friendly code is set to NAL.

Registration Status Carryover

A registered player will maintain his registered-player status even for turns in which no TRN is submitted (or the TRN is stale, corrupt, has a red alert, etc.) This allows the player to miss turns and not have his ships with registered-only friendly codes behave as if the player was unregistered.

For example, a ship performing a mine laying mission with a friendly code of md1 would lay 10 torps per turn, if the player is registered. If the player misses a turn, HOST would consider the player to be unregistered and would convert all of the ship's torps into mines on that turn, since the mdN friendly code is a registered-only code. PHOST, however, remembers that the last TRN submitted by the player indicated that he was a registered player hence PHOST assumes that the player is registered and consequently only lays 10 torps.

Additional Special Friendly Codes

PHOST can now make use of yet another file in the game directory, XTRFCODE.TXT. This file should contain a list of friendly codes that PHOST is to consider special and will therefore never allow to match (not for combat, not for gathering minerals at planets, etc.) This mechanism is meant to support add-on programs.

Back to the index

Hosting Features

Players can Play Any Race

PHOST now allows any player to assume the racial benefits of any one race. A new config option PlayerRace maps player numbers to the effective race that they will play. For example, if player 1's effective race is 3, then player 1's special mission is Super Spy. For more details, please see the description of the PlayerRace config option.

True Wraparound Map

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.

Wormholes

PHOST implements wormholes in a fashion very similar to the currently available WORM program available for HOST. Please follow the preceding link for more information.

Configurable Special Hull Functions

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.

Priority Ship Build Queue

The building of ships once the 500-ship limit is reached is controlled by a priority queue system that is highly configurable.

Configuration Options

PHOST implements many new configuration options that can tailor game behavior. The host is directed to the "Configuration Parameters" page for a complete list of the new options and how they affect game play. Note that PHOST comes with several configuration files that are ready for use in various situations (normal ship list, PLIST ship list, etc.) A novice host can use one of these configuration files as-is, or can use it as a template for a customized game.

Fine-Grain Hosting Control

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.

Turn File Checking

PHOST contains an integrated turn file checking algorithm (similar to the external CHECK utility). Turn file checking is a normal part of host processing, but PHOST can be run with the -c switch to perform only the turn-checking function.

PHOST with the -c option currently supersedes the external CHECK program. In fact, PHOST's turn file checking can be used even for HOST games, as its checking algorithms will catch cheating attempts that neither CHECK nor HOST will catch. It is safe to simply use PHOST with the -c option on a HOST game; no data will be modified.

Turn File Status History

PHOST generates a file named TURNSTAT.LOG in the player directory after every turn which summarizes the turn status information for that turn. This file is created if it does not exist. If it does exist, the current turn's information is appended to the file. The file documents whether player files are missing, whether they are stale, whether they gave rise to yellow or red alerts, etc. Viewing the TURNSTAT.LOG file is a quick way of seeing which players are having trouble submitting turns on a regular basis.

AUXBC.INI Hook

PHOST now supports the AUXBC.INI hook mechanism introduced in HOST 3.22.005. In the same way that AUXHOST1.INI and AUXHOST2.INI files are executed, the AUXBC.INI file is read and each command executed immediately prior to PHOST's combat phase.

Back to the index

This document is maintained by The Portable Host Project (support@phost.de).