THE PORTABLE HOST List of Differences between PHOST and HOST 3.2 Version 3.2.2.12 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 implementated 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. This file is divided into four sections: Differences, Bug Fixes, New Features, and Omissions. Within each section, the items are listed in decreasing order of relative importance. The differences between PHOST and HOST that are judged most likely to have an impact on hosting or game play are listed near the beginning of the section, while very minor differences will appear at the end. Differences =========== 1. 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: * Files used by PHOST but not by HOST: 1) AUXDATA.HST -- This file is automatically generated by PHOST if it does not exist. 2) PCONFIG.HST -- This file is PHOST's equivalent of the HOST HCONFIG.HST file. This file stores the configuration information for the game. * Files used by HOST but not by PHOST: 1) STORM.NM -- This file stores ion storm names. PHOST does not support ion storms hence it has no use for this file. 2) GREY.HST -- This file stores ion storm and other information. 3) HCONFIG.HST -- PHOST uses PCONFIG.HST instead. 2. VCR program and WinPlan/DOS Planets/VPA The PVCR program in this distribution is meant to replace the VCR viewer in all client programs. For DOS Planets players: The original VCR program must be renamed to VCROLD.EXE while the PVCR program must be renamed VCR.EXE. The VCROLD.EXE program will be called automatically by VCR.EXE (PVCR) when a VCR from a non-PHOST game is encountered. For VPA players: Install the PVCR program as PVCR.EXE in the main VGA Planets directory. VPA will automatically call PVCR when a PHOST-generated battle is encountered. For WinPlan players: Players using WinPlan (Planets 3.5) MUST NOT attempt to view their battles using the built-in VCR viewer. PHOST-generated battles must be viewed externally using PVCR from the command line (see PVCR.DOC and Question #17 in FAQ.DOC). 3. 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.1 (or a more recent version) program is an excellent simulator of both HOST and PHOST combat. 4. 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. See CONFIG.DOC 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 description of the MineOddsWarpBonusX100 option in CONFIG.DOC for more details. 5. 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 file OOB.DOC 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. 6. The Build Queue The build queue in PHOST is different from HOST 3.2 in that it is a FIFO queue (first-in-first-out) while HOST 3.2 uses a priority build point system. The FIFO build queue simply means that ships are built in the same order that their build requests are submitted. For example, if all ship slots are full and planet #2 submits a build order on one turn and planet #1 submits a build order on the next turn, the first free ship slot will go to planet #2. If, however, planet #2 submits a second build order with a ship specification different from the previous order, its build order is moved to the back of the queue. In a single turn, however, build orders are added to the build queue in order of planet ID number. To enhance fairness, however, the first planet polled is not necessarily planet #1 but a planet that is chosen randomly. For example, if planet #123 is chosen at random, then build orders from planets #123 through #500 are accepted in order, followed by build orders from planets #1 through #122. 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. 7. 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. 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 race. * 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) 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 ON. The only consequence of this is in the minefields-exploding stage. A web mine will not explode normal mines unless this config option is ON. Otherwise, it is always true that web mines interact with web mines and normal mines interact with normal mines. For example, laying a web mine that overlaps another web mine of a different race will cause minefield explosions (assuming MinesDestroyMines is ON). 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 ON. Note that this behavior is consistent with the VGA Planets documentation. 8. 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 '' 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. 9. 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. 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. The friendly codes that are considered special are: mkt mdh mdq msc alt ald alm NAL HYP NTP ATT NUK mdN miN WRS WRT lfm dmp bdm gsN nat nad nam cln btt btf btm bum pop trg con nbr Note that for 'mdN', the 'N' can be any digit from 0 to 9 (for example, 'md5'). For 'miN' and 'gsN', the 'N' can be a digit from 1 to 9 or the letters 'a' and 'b' (for example, 'mi4', 'mib'). Also note that the universal minefield friendly code prefix 'mf' is not considered to be a special friendly code. 10. 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 ON, 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. 11. Tow resistance Tow resistance has nothing to do with the waypoint of a ship nor the number of engines. Tow resistance is the same as tow strength which is related only to a ship's speed. If, however, there are two or more ships towing a single target ship, and all towing ships have the same speed setting, then the number of engines is used to determine who will win the tow competition. The ship with the greatest number of engines, naturally, will successfully tow the target ship. If there is a tie in the number of engines, the successful tower will be determined more-or-less randomly. 12. 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. 13. 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. 14. Planets Capture Ships In combat, planets can capture ships if a ship's crew is reduced to 0. 15. 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 FORMULAS.DOC). 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. 16. 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 FORMULAS.DOC file. 17. 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 in FORMULAS.DOC are followed. Ships may also end up 1 LY from expected locations if a different calculation formula is used to predict movement. 18. 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. Likewise, natives continue to grow or die according to the planet's climate, regardless of colonists. 19. 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. 20. 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. 21. Meteor Impact Happiness Change The change in happiness for both colonists and natives is chosen randomly (and independently) to be between -50 and -80. 22. 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. 23. Overpopulation Supply Loss The amount of supplies consumed on an overpopulated planet is computed according to the formula in FORMULAS.DOC. This formula is only an approximation to HOST behavior and may not lead to identical results. 24. 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. 25. Minefield Explosions Minefields are exploded as soon as they are laid. 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. 26. 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. 27. 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 (see CONFIG.DOC). With this option enabled, ships will usually consume less fuel but the fuel estimates shown by the Planets program will be incorrect. Players need to rely upon the published fuel consumption formulas in FORMULAS.DOC rather than the Planets estimates. 28. Number of Battles Reported by Planets The battle files received by players from PHOST (in the .RST result files) will always contain the actual battles fought plus one extra battle. This extra "battle" is not a battle at all but actually contains the combat-related configuration information from the host's PCONFIG.HST file. It is important that both host and player have the same configuration information if the battle is to look the same to both people, thus this information is sent as part of the battle file itself. PVCR will properly handle this information and will only display the actual number of battles performed. The Planets client program, however, does not know about this configuration information and will report that N+1 battles were performed when in fact there were only N battles. 29. Siliconoid Native Growth In PHOST, Siliconoid natives are treated the same way as other natives with respect to maximum native population and rate of growth. In HOST, Siliconoid natives preferred hot planets. 30. 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. 31. 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. 32. 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. 33. 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 FORMULAS.DOC) to support PHOST's ability to have ships with greater than 10 beams, tubes, or bays. 34. Mutual Towing In PHOST, two ships that attempt to tow each other (and have equal tow strengths) will not move. In HOST, one or the other ship was chosen to tow successfully (probably determined by ship ID number). 35. 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 "" rather than a particular ship name (since the message may have come from more than one ship). 36. Exploration Messages Condensed A player will only receive one exploration message per planet per turn, regardless of how many ships explored that planet. 37. Super Spy Messages Condensed The Birdman player 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. 38. Dark Sense Messages Condensed The Empire player will only receive one Dark Sense message per planet per turn, regardless of how many ships have scanned the same planet. 39. 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. 40. 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). 41. 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. 42. 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 UTILDATA.DOC file for more details on the format). 43. When Gravity Wells are In Effect It is not clear from available 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) 44. 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). WinPlan players won't be able to cancel their build orders, however (note that HOST 3.2 has the same limitation). Bugs Fixed ========== 1. Combat All of the bugs that have been associated with combat (beams not firing, different combat strength depending upon which side the ship fights on, etc.) have been addressed. 2. Self Towing Ships that tow themselves move normally to their waypoints. New Features ============ 1. Alliances PHOST implements alliances via the new PHOST command processor (see the file ALLIANCE.DOC). 2. Wormholes PHOST implements wormholes in a fashion very similar to the currently available WORM program available for HOST (see the file WORMHOLE.DOC). 3. Configuration Options PHOST implements many new configuration options that can tailor game behavior. The player is directed to the file CONFIG.DOC for a complete list of the new options and how they affect game play. 4. Command Processor The command processor feature of PHOST allows players to change race names, set up alliances, send rumors (anonymous messages), among other things (see the file COMMANDS.DOC). 5. 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 (see COMMANDS.DOC). 6. 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 (see the file INSTALL.DOC). PHOST with the -c option currently supersedes the external CHECK program. A standalone version of PHOST that performs only turn file checking (and will require less memory) will eventually be available. 7. Planets Fire Torps If the PlanetsHaveTubes option is enabled (see CONFIG.DOC) 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 FORMULAS.DOC). 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 FORMULAS.DOC file. 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. 8. Auxilliary Data File PHOST generates auxilliary files (UTIL*.DAT files) for each player. These files contain "interesting" information in binary form (see the UTILDATA.DOC file for more details). This information may be of use to add-on utilities. All 3 major data tracking utilities (Crystal Ball, EchoView, and Informer) can read and understand UTIL*.DAT files so it is recommended that hosts send these files to their players along with the RST files. 9. 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. 10. Native Deaths Natives die because of overpopulation at the NativeClimateDeathRate rate if the ClimateLimitsPopulation configuration option is enabled. 11. Cloak 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 of why cloaking failed. 12. 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. 13. 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 auxilliary data file (the UTIL*.DAT file) that accompanies the result. The PHOST identification message allows player utilities to recognize a PHOST-generated result file even if no UTIL?.DAT file is present. 14. Ship Recycled Message PHOST will generate a message (and a record in the auxilliary data file) whenever a ship is recycled at a starbase. 15. 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. 16. Travel Behavior After Mine Hits The HullTechNotSlowedByMines configuration parameter selects between two methods of adjusting a ship's travel after hitting a mine. When this parameter is between 1 and 11, it represents the minimum level of hull tech which is not affected by mines, with respect to the maximum distance travelled (as in HOST 3.2). For example, if a ship is travelling at Warp 7, then it may move up to 49 LY in one turn, regardless of the number of mine hits, as long as the damage to the ship does not reach 100%. If the ship's hull tech is lower than HullTechNotSlowedByMines, however, its maximum range is limited to 49-10=39 LY for that turn. Setting HullTechNotSlowedByMines to 1 means that no ships are affected in this way. Setting it to 11 means that all ships are affected. When the HullTechNotSlowedByMines parameter is 0, a different mechanism takes effect that is independent of hull tech. After a mine hit, the maximum damage-limited speed of the ship is recomputed and the ship continues on its journey at that speed. The maximum distance, then, is simply the amount of time remaining for travel multiplied by the new ship's speed. For example, a ship travelling at Warp 8 to a waypoint 64 LY away hits a mine after 32 LY. Its new damage-limited speed is Warp 5. Since 32 of 64 LY have passed, the ship is halfway through its journey. Thus, it can travel an additional 0.5*(5^2) = 12.5 LY towards its waypoint. 17. 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. 18. 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 in CONFIG.DOC 19. Multi-Language Support PHOST can generate player messages (and host messages) in any one of 6 languages (English, German, French, Spanish, Italian, and Dutch). Players can select the language of their choice using the 'language' command processor command (see COMMANDS.DOC) or by having the host set the Language config option (see CONFIG.DOC). Please see the README.DOC file 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! 20. Slower Ships Travel Better Through Mines Using 6 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 MineHitOddsBonusX100 config option description in CONFIG.DOC for more details. 21. Cloak Failure Messages Players can now 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. 22. 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. For more details, please see the INSTALL.DOC file under the heading "Additional Special Friendly Codes". 23. Extended Missions PHOST now supports extended missions via the M.I.T. interface in WinPlan 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). For more information, see the MISSIONS.DOC file. Omissions ========= 1. Ion Storms PHOST does not implement Ion Storms. There are no plans to implement Ion Storms in PHOST. 2. Priority Build Point Queue PHOST does not yet implement priority build points. The build queue implementation is a simple FIFO queue (described above in the Differences section). PHOST will eventually implement some kind of priority build point system. 3. The DeleteOldMessages Option PHOST does not keep old messages. Thus, the DeleteOldMessages option has no effect. There are no plans to support this feature. 4. AUXBATT.INI Interface PHOST does not yet 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.