![[PHost Logo]](logo.gif){kind=logo} © |
Hosting with PHOST |
| © |
Hosting with PHOST |
Note: PHOST's requirements also depend on the compiler it was compiled with.
Under Windows 3.1, the Borland C-compiled version
requires the 32-bit
DPMI server and support files![[Remote]](remote.gif){kind=small}
from the PHOST WWW page. Follow the installation instructions in this
package.
Borland C: Download
the necessary support software
from the PHOST WWW page. Follow the installation instructions in this package. 
You do not need to run Windows to run PHOST 3. You do, however,
need at least a 386-class machine.
DJGPP: The DJGPP distribution archive contains a DPMI server cwsdpmi.exe which is automatically used by PHOST when needed.
This directory contains the VGA Planets files that are common to all games. Included in this directory are all executable programs. Note that this is the usual configuration for most hosts, but is not a requirement.
This directory contains files specific to a current game in-progress. Included in this directory are all *.HST files such as PDATA.HST, BDATA.HST, etc.
The PHOST programs (PHOST and PVCR) accept two command-line parameters that specify the game directory and the root directory (in this order). If these parameters are not specified, then the current directory is used. For example
PHOST /games/planets/game1 /games/planets
PHOST game1
Note that you need not run the programs from the main directory, as is common with many DOS-based VGA Planets programs. These other programs all expect to find global data files (*.DAT files and others) in the current working directory hence they all expect to be run from the main directory. PHOST programs all accept full pathname specifications for both the game and main directories and may therefore be run from any directory.
Other things to note when starting a game:
distribution of portable utilities. You cannot upgrade from PHOST
v2.4 or earlier to PHOST 3. You must first upgrade to the latest PHOST
v2.x version and then upgrade to PHOST 3.
If you want to upgrade an existing PHOST 2.x game to PHOST 3, follow these general steps:
this includes Win32 and DJGPP) then use PCONVERT with the -r flag
to convert your data files to DOS format.| Option | Function |
|---|---|
| -q | Quiet Operation
The -q option prevents PHOST from displaying status information on the screen as it executes. Warnings and errors are still displayed as necessary. This option does not prevent PHOST from writing all messages to the HOST.LOG file so all information is still available in this file for review. This option is useful for spotting warnings and errors, since these tend to get lost in the clutter of the progress messages. |
| -Q | Really Quiet Operation
This option is like a stronger -q option. It prevents all messages from being displayed on the screen, errors and warnings included. As before, all messages will still be written to the HOST.LOG file regardless of the -q and -Q flags. |
| -c player | Check-Only Operation
This option runs PHOST only as a turn file checker. The player argument to this option specifies the player whose turn file is to be checked. If this argument is 0, then all turn files in the game directory are checked. See the section on Turn File Checking below. With this option, PHOST only checks turn files before exiting. Turn files are not deleted and no game files are modified. A file named CHECK.LOG is generated in the game directory which summarizes the result of turn file checking. Note that turn file checking is also a normal part of PHOST operation. In addition, PHOST checks the game data files for integrity before checking any turn files.
|
| -r | Read-Only Operation
This option causes PHOST to perform all normal turn processing but no game data will be written to disk. That is, the *.HST files are not overwritten. Any *.TRN files in the game directory are not removed. Note that *.RST files are generated even when this option is present. PHOST can be run multiple times with this option with no ill effects. This option is useful for testing purposes. Specifying the -r option automatically implies the -k and -i options. |
| -k | Keep *.TRN Files
Normally, after PHOST runs, all *.TRN files in the game directory are deleted. This option causes *.TRN files to be preserved. This option is useful for debugging. |
| -s seed | Random Seed
This option takes a single non-negative integer argument which specifies the starting random seed for PHOST. When PHOST starts with the same game data files and the same *.TRN files, specifying the same random seed on multiple runs causes PHOST to run to the exact same conclusion. This option is useful for debugging and for a particular backup strategy using the -F flag. Note that any add-on or other programs being used that may affect game data must also be able to accept a starting random seed for the same conclusion to be reached. |
| -S | Turn Number Random Seed
This option causes the current turn number to be used as the random seed for PHOST. If this option is used, then re-running turns is more convenient (if the same outcome is desired) since the random seed is deterministic. This option is useful for debugging. |
| -u | No UTIL.DAT Files
This flag prevents PHOST from creating the auxiliary data player files (UTIL*.DAT, see the "Auxiliary Data Files" page). For games in which these files will not be sent to players, this option allows PHOST to run slightly faster. |
| -i | No INI-Files
This flag prevents PHOST from executing any INI-files. This includes the AUXHOST.INI files, as well as any INI-files that are specified via the fine-grain hosting interface. This flag is automatically implied when read-only operation is selected (with -r). |
| -T | Generate Old-Style RST Files
This flag causes PHOST to generate RST files that are in the same format as RST files generated by HOST 3.15. Without this flag, the RST files are in HOST 3.2 format. Specifically, using this flag causes PHOST to exclude mine scan information, ship explosion information, UFO.HST information, and the RACE.NM file in the RST file. Note that HOST 3.2-compatible RST files are only sent to registered WinPlan players. DOS Planets players, and shareware WinPlan players always receive old-style RST files (HOST 3.15-compatible). |
| -t | Print Turn Number
This option causes PHOST to simply print the current turn number (on stdout) and exit. No other processing is performed. This may help some script and/or batch files in managing backups and other activities. If the turn number was successfully displayed, PHOST returns with an exit code of 0, otherwise PHOST returns with an exit code of -1 (and there may be other text displayed on stdout). |
| -d | Print Time Stamp
This option causes PHOST to simply print the current turn timestamp (on stdout) and exit. No other processing is performed. This may help some script and/or batch files in managing backups and other activities. |
| -l | Print Ship List
This option causes PHOST to display the list of ships it is using (on stdout) and exit. No other processing is performed. The ships are listed in groups of 20, with each group corresponding to a slot in the TRUEHULL.DAT file. Each ship has its name, mass, cargo, mineral cost, etc. displayed, along with any special hull functions that it can perform. If the special hull functions are limited to certain players (using the HULLFUNC.TXT interface) then this information is also displayed. This 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. When specified twice, i.e. phost -ll, PHOST uses a slightly modified output format with exactly one line per ship. Special hull functions are not displayed in this mode. |
| -F | Ignore Timestamps in TRN Files
This option is potentially very dangerous and must be used with care. Specifying this option causes PHOST to ignore the timestamp present in *.TRN files. This option is necessary for restoring games from backups when only *.TRN files are stored. There are no other instances for which this option should be specified. |
| -V | VPHOST In Use
This flag causes PHOST to look for PLAYER*.ORG files instead of PLAYER*.TRN files, and to only process command processor commands from these files. All other information in the TRN file is ignored. This flag supports the use of VPHOST with PHOST (see the Hosting with VPHOST section below). |
| -v | Version Info
This option causes PHOST to display its version information and then to exit immediately. No host processing is performed. |
| -C | Write Combat Log
When doing combat, PHOST will write out a log file combat.log containing more detailed information on the battles. This file is intended to be evaluated by battle simulators. |
| -o option=value | Set config option
Changes the value of a configuration option. This switch is mainly intended for use while debugging or setting up a game. For example, -oconfiglevel=2 will temporarily set ConfigLevel to 2 so PHost will warn you even if you forgot an optional setting. When you use this switch to change an option which also is defined in pconfig.src, you'll get a warning. This is by intention; if you wish to make permanent configuration changes, please do this in pconfig.src instead of using this switch. |
The -c option requires a parameter to follow it, indicating the player number whose turn file is to be checked. For example,
PHOST -c 3 gamedir
Turn files are checked for a variety of problems such as staleness, bad commands, cheating, etc. Any problems are reported and PHOST exits without modifying the game files and without removing the *.TRN files. PHOST also returns an error code corresponding to any problems it finds. This makes PHOST suitable for use in a batch file or script which uses PHOST's return value to automatically take appropriate action. The return error codes are as follows:
| Return Code | Turn Check Result |
|---|---|
| 0 | Turn file has no errors |
| 1 | Turn file is missing |
| 2 | Turn file is stale |
| 4 | Turn file is too short (premature EOF) |
| 8 | Turn file is damaged |
| 16 | Turn file is from the wrong player |
| 32 | Turn file checksum is incorrect |
| 64 | Turn file has caused Yellow Alert |
| 128 | Turn file has caused Red Alert |
When multiple turn files are checked (player number is 0), the return code represents a summary of all anomalous conditions and may consist of one or more of the above values OR'ed together. For example, a return code of 1 when checking all players means that at least 1 player's turn file is missing. A return code of 10 means that at least 1 player submitted a stale turn file (code 2), and at least one player submitted a damaged turn file (code 8).
Note that turn file checking also includes a step in which the host data files are checked for integrity. Thus, error messages may be generated which do not relate directly to the turn files being checked. These messages will be present in the CHECK2.LOG file generated by PHOST but not in the CHECK.LOG file, which is otherwise identical to CHECK2.LOG. Checking the host data files can sometimes reveal information about other players (such as positions of their bases) and this information should not be revealed to other players. Thus, the CHECK.LOG file is suitable for sending to players as a pre-host-run turn check, while the CHECK2.LOG file is suitable for review by the host.
A yellow alert means that the turn file is somehow invalid and the commands which are judged to be in error are simply ignored. A red alert is more serious as it is only reported when there is good evidence that an intentional attempt to cheat has been detected.
Here is a brief description of how the above error codes may arise:
Illegal command parameters (such as a planet ID number of 600) raise a yellow alert and only cause the single illegal command to be ignored.
Checks are then performed for every group of ships (and a planet, if any) at a point in space. The basic principle is that at every position in space, the amount of minerals, money, and supplies must remain constant, or must be accounted for by legal actions such as building factories from money and supplies, but not making money and supplies out of factories, for example.
Once all amounts are computed, discrepancies are examined. If something disappears (for example, the "disappearing fighters" bug in DOS Planets) then PHOST will raise a yellow alert and attempt to restore the missing items. This works in the player's favor if a bug in DOS Planets or an external player utility has caused items to disappear, but it can also work against the player if the player is trying to cheat. For example, trying to remove all the minerals from a planet that will be captured on the next turn will raise a yellow alert and in the end have no effect, since PHOST restores the minerals. A yellow alert, then, means that PHOST has found a problem but is giving the player the benefit of the doubt and assuming that the problem is not his fault.
If items appear out of nowhere, a red alert is raised. A red alert is also raised if a player tries to forge a message from another player. Red alerts cause the entire turn file to be ignored as punishment for the player's attempts at cheating.
HULLSPEC.DAT ENGSPEC.DAT BEAMSPEC.DAT TORPSPEC.DAT TRUEHULL.DAT RACE.NM PLANET.NM XYPLAN.DATBack to the index
do this by placing the excess planets at faraway locations (for example,
at locations with an X-ordinate of 0 or 4000). This is the recommended
method for hosting with fewer than 500 planets.
Make sure to check your newly-created
map's checksum using a verification program such as MAPCKSUM
as NEW_MAP can sometimes generate unusable maps.
If a wraparound map is being used, then you may well wonder how planets with an X-ordinate of 0 or 4000 are handled with respect to re-mapping. The key point to remember is that any planet outside of the wraparound region is considered to be non-existent by PHOST. Thus, planets outside the wraparound region will not be mapped into the wraparound region, they will simply be ignored throughout the game.
PHOST uses the -V command line flag to support hosting with VPHOST. This flag is necessary because VPHOST removes all TRN files (after making copies in *.ORG files) and then processes the commands within those files by itself. Unfortunately, this means that all of the command processor commands sent by players are never seen by PHOST. The -V flag tells PHOST to look for PLAYER*.ORG files instead of PLAYER*.TRN files and to only process command processor commands from those files (ignoring all other commands, which will be performed by VPHOST).
To implement this mechanism, PHOST makes use of a file in the game or root directory named XTRFCODE.TXT, if it exists. 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.) The format of this file is free-form, it may contain tokens of up to 3 characters each (representing friendly codes) interspersed with any amounts of white space. Each friendly code is case-sensitive. If the friendly code contains N characters, where N is less than 3, then a ship or planet's friendly code is considered special if it matches just the first N characters.
For example, if the XTRFCODE.TXT file contains:
BJG AJG RJG J
Here is another example XTRFCODE.TXT file that may be used with the RacePlus add-on:
HUD ! !! EGG BAC TCC STB MK GWG RDV BBT SFG
FA FB FP FT FG TA TB BSG C BS ASG RSG J BCT RCT FCT BSB RSB FSB SSC KSP KPL AFC ATC GS EXC BUM MTN
PlayerRace = 1,1,1,1,1,6,6,6,6,6,6
In the client program, the special mission listed for each race will
not change, so the player needs to remember that his special mission may
be different, depending upon his race assignment. For example, if player
4 selects the special mission on one of his ships then the client program
will show the mission as Pillage. But if player 4 has been assigned race
5, then the ship will actually perform the Rob mission. Using the Special
Mission extended mission can bypass this confusion.
It is suggested that players edit the MISSION.INI file to have
the Special Mission extended mission
reflect their true special mission, and use this extended mission instead
of the usual one.
The ship list that a player sees (on the host side) is controlled by the MapTruehullByPlayerRace config option. With this config option enabled, changing the value of a PlayerRace setting also changes the ships that the player can build.
NOTE: This option should
only be enabled if all players in a game are using VPA.
For example, if player #1 is given race #9 and MapTruehullByPlayerRace is enabled, then player #1 will be able to build ships normally available to race #9 (i.e., Robotic ships). Setting MapTruehullByPlayerRace to No allows more control over the ship list available to each player. In this case, each player can not only have their own race assignment, but their own individual ship list, even if two (or more) players are playing the same race. Please see the description of the MapTruehullByPlayerRace config option for more details.
To put it simply, if you are not customizing a ship list and you simply want to change races around while keeping the ship lists consistent with race assignments, just set MapTruehullByPlayerRace to Yes. This also requires that all players in your game are using a client program (currently, only VPA) that recognizes the MapTruehullByPlayerRace option.
Finally, it must be remembered that some special functions are linked to ships themselves, and not to the race that owns them. Gravitonics, for example, is an ability of a ship's hull not of the owner race. The PlayerRace config option only deals with race-related abilities, not ship abilities. Other ship functions which are not affected include hyperwarping, cloaking, terraforming, tachyon anti-cloaking, chunneling, bioscanning, Imperial Assault, glory devices, and ramscoops. Note that all of these functions can be disabled via other configuration options. In addition, the HULLFUNC.TXT interface can be used to modify the hulls that are capable of performing special functions and the players that are allowed to use them.
The special abilities that are controlled by the PlayerRace config option are as follows:
PHOST versions 2.x used a phasing system to execute AUXHOST programs, but this has been eliminated in PHOST 3. The AUXHOST programs may be installed in the same way as they would be for HOST. Unlike HOST, however, PHOST gives AUXHOST programs the full amount of memory available under DOS. That is, PHOST does not keep itself in lower memory, like HOST does. As a result, AUXHOST programs have as much as 320K more memory to work with than under HOST.
HOST alliances are recorded in the GREY.HST file. PHOST 3 will write a HOST-type alliance offer in this file whenever a player has offered all five alliance levels to another player, just as if the player had used an ffX friendly code. This mechanism is one-way, however; PHOST will only write to the GREY.HST file, it will not incorporate any changes to this file into its own internal alliance states.
For more details, please see the Host Alliance Compatibility section of the "Alliances" page for more details.
(support@phost.de).