PHost - Frequently Asked Questions

PHost 4.1h


Common Questions

Where do I get the latest PHost version?

The Introduction (readme) document contains the relevant links.

How do I set up a new game?

See the Hosting with PHost document for information on how to create and run games with PHost.

How do I switch a game from HOST to PHost (or back)?

Switching hosts in mid-game is not recommended. If you are familiar enough with the hosting process, familiar with HOST, and familiar with PHost, then you know the answer to this question. If not, don't switch.

Okay, if you insist on it: technically, you can switch from HOST to PHost and back at any time, provided you use a ship list understood by both; the file formats are the same. However, you have to manually convert the configuration. You'll likely annoy some players, though.

One caveat to watch out for is the auxdata.hst file. If you switch from PHost to HOST, the file will remain there although HOST does not maintain it. This may confuse some programs. In addition, when you switch back to PHost, it will find the stale file lying around. Therefore, delete auxdata.hst when you switch from PHost to HOST.

What is the difference between PHost 3.x and PHost 4.x?

PHost 4.x is the current major release. Some often-requested features, most notable support for 999 ships, required a departure from old file formats to new ones, and we used that opportunity to add several all-new features as well. After almost four years of beta status, version 4.1 marks the point where we think the 4.x series has reached production quality.

PHost 3.5 is part of the old "mainstream" release of PHost, the successor of PHost 3.4, 3.3 and 3.2. As the version numbers show, they are all compatible, as far as file formats are concerned. We provide version 3.5 to support existing games. Since the 4.x series now has reached production quality, we'll slowly phasing out support for version 3.x.

Up to now, every 4.0 release has been accompanied with an "almost equivalent" 3.4 release, where the 3.4 contains all the bugfixes and some of the new features of the 4.0 version. In the future, this relationship will be loosened; version 3.5 will receive mostly fixes only.

How can I simulate battles for PHost?

You must use a simulator which explicitly supports PHost. BSim used to be a popular choice. Internally, it supports only PHost 2.x, therefore results will be slightly off in some cases. CCBSim[Remote] supports all PHost 3.x subtleties as well as PHost 4.0, but it has some problems with very long fights. Recent EchoView[Remote] versions have a PHost 3.x/4.x simulator built in, too. As of December 2006, PlayVCR[Remote] has a built-in multi-ship simulator ("CCBSim 2.0") which supports all features of PHost.

If you are using 100% "standard" combat, you can try to use a HOST simulator, such as the one built into VPA and Winplan. Results should give you a vague idea on the outcome, but don't bet on it.

Does PHost 4 support Planets 4?

No. Planets 4 is a completely different game than VGA Planets 3.x. The PHost team has no intention to write a host for Planets 4.

Does program X work together with PHost?

PHost has been developed with compatibility in mind. Ideally, everything which works with HOST should work with PHost as well. If it does not implement explicit PHost support, it'll not be able to access PHost's special features, but it should work nonetheless.

PHost implements some extra features which are not universally supported (such as 999 ships, or MapTruehullByPlayerRace); these have been marked as such and are disabled by default.

Some new options make PHost deviate from other laws-of-nature of the VGA Planets universe, and are at the time of their inclusion in PHost not supported by any program. These options are marked as incompatible in the configuration overview, and are only accepted if explicitly enabled (AllowIncompatibleConfiguration).

Known Troublemakers:

  • PHost does not support TacCom. No-one so far showed interest in TacCom support.
  • Spacelord 3.05 crashes when it sees PList combat.
  • Another Killrace 2.0 damages auxdata.hst files when used with PHost 3.0 or later.
  • chktrn.exe does not support MapTruehullByPlayerRace. This is only a problem because PHCc insists on using it for PHost games, too.
  • The Dan & Dave add-ons (i.e. Starbase+, RacePlus etc.) and probably others do not work without a hconfig.hst file. For example, Starbase+ needs to know the mine unit conversion ratios (UnitsPerTorpRate). To make it work, run hconfig.exe and generate a hconfig.hst file by hand.

How can I host or play on a 64-bit computer?

Many VGA Planets programs are 16-bit software, which new 64-bit operating systems cannot run. However, they will usually run 32-bit software just fine.

For hosting under Windows, use PHost for Win32. The DJGPP port will not work, because it includes a tiny bit of 16-bit code. Likewise, if you use add-ons, these should be compiled with a Win32 PDK, not DJGPP.

For hosting under Linux, use PHost for x86. It is statically linked and doesn't even require compatibility libraries. Occasionally, there may also be a native x64 version.

For playing, the best choice probably is PCC2[Remote], which is a 32-bit program that runs under Windows and Linux. A beta version of Winplan 32-bit also exists which should be a good upgrade path for Winplan fans. Other options include JVC[Remote], JVPC[Remote], xk[Remote], but those are probably not maintained anymore.

Finally, a good way to use your old 16-bit software, is the free DOSBOX[Remote] program. It can run DOS Planets as well as VPA and PCC 1.x.

What advantages do players using Winplan or VPA have over others?

Winplan/registered introduced not only a new interface, but also a new TRN/RST file format giving players submitting Winplan-style turn files some advantages over players submitting old-style turns. PHost tries to compensate these differences as good as possible.

PHost distinguishes between three types of client programs: Winplan (turn files submitted with registered Winplan or compatible), DOS Planets (turn files submitted with DOS planets (registered or shareware), or Winplan shareware), and VPA (same as DOS Planets, but sends a client VPA command). When we say "players using Winplan", we actually mean "players using a program that generates Winplan-style turn files".

The following list shows the special treatment PHost does for players using particular client program types:

  • Players using Winplan can see all scanned enemy ships. Others will receive only the 50 closest ones in their RST, the excess targets will be transmitted using util.dat. Thus, if you have a program that reads util.dat, you will see all your targets.
  • Players using Winplan will see Ufo objects, and automatically receive the current race name file each turn.
  • DOS Planets cannot handle extended missions. To avoid that planets.exe gets confused, PHost resets all extended missions to "none" at the end of the turn for those players. They can set these missions using the extmission command, or a program which handles extended missions.
  • DOS Planets cannot handle waypoints larger than 160 ly in X direction or 140 ly in Y direction. Therefore, PHost will trim waypoints before generating RSTs for these players.
  • Players who use Winplan automatically see all their minefields without having to mine sweep. If a Winplan player offers you mine-level, you'll also see all his minefields. As a compensation, PHost 4 introduces ExtendedSensorSweep, which lets ships doing Sensor Sweep also scan for mines, so you don't have to reserve ships just to see your own mines.
  • PHost will reformat messages to DOS Planets players to fit into the DOS Planets message window (21 lines a 40 characters).
  • In PHost up to version 3.4g/4.0d, only Winplan players can jettison ammo or cash. In these PHost versions, Winplan-shareware players cannot jettison at all.

These are the restrictions enforced by PHost. Client programs might impose further limitations. For example, not every client program allows you to set a mission with a parameter larger than 500. Not every client allows you to give a unload-to-planet order as well as a transfer-to-enemy-ship order.

I want to set up a PlayerRace game. Does it suffice to change the PlayerRace variable?

Unfortunately, no. Array options are indexed by player. Some have default values that differ for various players, and you must change them to match your new racial setup. For example, by default, player 2 plays Lizards and has a GroundKillFactor of 30. If player 2 plays Robots, you probably want to lower this value.

As of version 4.0k, the following options are affected: AllowBuildFighters, AntiCloakImmunity, ColonistTaxRate, ExtraFighterBays, FighterSweepRange, FighterSweepRate, FreeFighters, GroundDefenseFactor, GroundKillFactor, RaceMiningRate, ShipCloneCostRate, and UnitsPerTorpRate.

See Non-standard Race Assignments for details.

What is the PHP Abyss? Why did my ships not move and my mines and factories not produce anything? How can I avoid this?

The Portable Host Project Abyss is the PHost version of the Tim Continuum. It is a method of preventing two (or more) players from using the same registered copy of the client program in the same game.

The effects of the PHP Abyss are different from the Tim Continuum (TC). While the TC causes ships to be flung to the remote reaches of the galaxy, the PHP Abyss thinks this is a bad idea since it a) causes flung ships to act like scouts, letting them see parts of the universe they would not normally see, and b) limits the options of hosts. If the TC strikes an honest player (as is the case in 99% of all TC incidents) then the host may wish to re-run the turn. But due to the scouting effect, the affected player has gathered information that cannot be given back.

Instead, the PHP Abyss "freezes" the player's actions for that turn. His ships will not move. His factories will not produce supplies, his mines will not extract minerals, his colonists and natives will not pay tax. It's as if the player picked up a "Lose A Turn" card.

The most common cause for a strike by the PHP Abyss is one person playing multiple races in the same game, but doing so incorrectly. In team games, especially, when one player submits a turn for another player, great care must be taken or the PHP Abyss will strike.

To successfully submit turns for multiple races in the same game, follow these rules:

  1. Unpack all RST files from the same game into a single subdirectory.
  2. When you run Maketurn, multiple TRN files will be generated. Submit all of these TRN files as a group.
  3. If you re-run Maketurn at a later time, re-submit all of these turns again, even if you didn't change anything.

The turn files must "know each other". Otherwise, the host will assume they were made on different computers.

==> In PHost, the PHP Abyss does not trigger if a player submits a red status turn file (i.e. cheating or shiplist mismatch). Instead, the offending turn file is simply ignored. This is not exactly the same as losing a turn, because ships will continue to move and planets will continue to produce, they will just not receive new orders.

What actions can be performed without fuel?

Check the description of the mission, friendly code or ship function you want to use. If it does not list fuel as a precondition, it does not require fuel. Most actions possible without fuel also contain an explicit note saying so.

Why didn't my ship/planet do X?

Every mission, friendly code and hull function description includes a section Preconditions listing all preconditions for the respective action. We believe these sections to be complete and correct. Therefore, you should be able to figure out why it didn't work by checking the preconditions.

Most of these actions now also generate failure notices in util.dat. These records are intended for diagnoses of this kind, and do often not have a subspace-message counterpart. You can read your util.dat using a program such as EchoView[Remote] or Planets Command Center[Remote].

Note that it is not always easy to decide whether a ship is trying to do something and fails, or whether it is not trying to do it at all. Therefore, such failure reports are not generated for all ships that do not do something.

Back to top

Bugs - Real & Otherwise

My ship burned a different amount than predicted by my client. Why?

The fuel consumption formulas used by the original HOST and DOS Planets/Winplan were not exactly known when PHost was initially written. PHost's formula therefore differs a little from HOST's. It is possible (though unlikely) that your client program may tell you that you only need a certain amount of fuel to get to your destination but in reality PHost may require more. HOST sometimes also requires more fuel than the client programs predict.

Some other reasons why a ship can use a different amount of fuel than predicted:

  • Did you try to cloak? Cloaking also needs fuel.
  • Are you using UseAccurateFuelModel? The "accurate" formula yields different results than the one implemented in DOS Planets and Winplan.
  • Did you tow a ship which changed its mass? Ships may get heavier (Gather-type missions) or lighter (Alchemy, Mine laying).
  • Did someone tow your ship? When you break out of a hostile tow, you'll be moving a different distance than predicted.

Modern client programs such as VPA or PCC aim for precise fuel computations and include support for PHost formulas and predictable events, but can of course not predict your enemies' actions.

See also HOST/PHost differences for a list of all known differences between HOST and PHost, as well as our statement why PHost stays different even though HOST formulas are now well-known.

PHost claims that this minefield/wormhole was away 999 ly but this isn't true!

PHost condenses messages. You get only one report per object, not one for every ship which scans it. Therefore it can't compute sensible distances. After all, you can compute these yourself on your starmap.

Some programs which parse messages expect them to come in a certain, fixed format. For these programs, PHost fills in the dummy value "999 ly".

If this annoys you, change your language to "NewEnglish" using the language command.

Why does Winplan crash when I try to watch my battles?

Winplan cannot play combat generated by PHost. See here for more information.

PVCR displays lots of warnings about missing parameters, although I have the correct pconfig.src!

Since version 4.0, the game configuration is split into two parts:

  • pconfig.src contains the game configuration.
  • shiplist.txt contains ship-list specific information. It belongs to the same set of files as hullspec.dat, torpspec.dat, and so on.

Since people's habits are hard to change, most hosts include only the first file in the game's player files, although the second one should belong there as well. You must install a copy of the correct file before PVCR works correctly.

If you're using a standard ship list (Tim's list, or PList), chances are your host uses the recommended file from the PHost distribution. You can then just install that one (from the config/ sub-directory). The more reliable way is to ask PHost to send you the file, using the con friendly code or the send config command.

Note: Note that PVCR 4.0 erroneously moans about missing EModXXX options when used in a PHost 3.x game. This is fixed in PVCR 4.0a.

Note 2: Before bugging us "why did you complicate matters by requiring two config files", consider that shiplist.txt is actually part of the ship list, and ideally it should be delivered with it. Like you have to install hullspec.dat, beamspec.dat and friends before starting a game, you also have to install shiplist.txt.

PVCR stops while playing a battle until I press a key.

This problem has been observed under Windows.

You probably have some other program running in the background. While PVCR plays a battle, it constantly polls the keyboard. Therefore, Windows thinks PVCR is idle, and it would be better to give the CPU time to the background process. Windows doesn't see that PVCR also updates the display constantly.

The known-good fix is to stop the background process. Maybe you also manage to fix it by playing with the DOS-box property settings. The quick workaround is to press a key or fiddle with the mouse so Windows thinks you're talking to PVCR.

This has been observed with the program CPUCool, but probably things like Seti@Home are good candidates for this problem, too.

Why can't I see these enemy ships on my viewer? DOS Planets says they are out of scan range but they clearly are not.

The DOS Planets 3.0 program has an internal limit of 50 enemy ships. If more than 50 enemy ships are scanned in a given turn, then the excess ships have only their position, owner, and mass reported and the client program reports that they are out of scan range.

PHost still reports the information in util.dat, record 10. You can use a third-party client program such as VPA[Remote] or Planets Command Center[Remote] to see these ships.

What happened?! All my starbases disappeared, ships are in the wrong place, everything is wrong!

If you've enabled AllowMoreThan50Targets and are not using a program that can handle these extra targets, you may experience very strange behavior in DOS Planets. Note that the UNPACK program that comes with DOS Planets cannot handle more than 50 targets and must not be used if the AllowMoreThan50Targets option is on.

The AllowMoreThan50Targets option (and the related bigtargets command) are almost never needed these days; programs which can display more than 50 targets can usually also fetch them from util.dat (DOS Planets-compatible programs) or kore.dat (Winplan-compatible programs).

Why does PVCR show this ship as sustaining 10% damage but when I look at it, it only has 8% damage?

Did the ship have supplies? If so, remember that ships repair themselves with supplies both before and after combat.

I'm trying to cancel a build order from my starbase but the build order keeps showing up next turn.

The Maketurn included with DOS Planets, and older versions of Winplan, can not transmit build cancellations to the Host.

If you're using DOS Planets, use a different Maketurn program. All Maketurn programs known to work are listed in the next entry. However, many of the third-party maketurns might not encode cargo transfers generated by DOS Planets correctly, causing PHost up to version 3.4i/4.0f to reject the turns.

If you're using Winplan, PHost implements a workaround.

All my build orders got canceled! (or) PHost rejects my TRN as being damaged!

You're using a Maketurn program which is incompatible with PHost. Programs known to work are:

The Maketurn program must be careful not to trigger PHost's workaround for the above bug, and must send all commands in the canonical order. See Technical info on turn files for details.

I'm fighting, but I do not get build points (PAL, PBP)!

The usual cause for this problem is that you are allied with the ships you're fighting. You do not get build points for fights against allies. It does not matter what alliance levels you offer. You have to cancel the alliance completely using allies drop.

The intention of this rule is to prevent allies from "generating" activity points by capturing ships back and forth.

My Rebel/Klingon ship was attacked by a planet! My two-engine ship did not tow! My MBR did not tow-capture that ship!

Probably your game is using Init = Clear in the shiplist.txt file.

In PHost 4.0i and later, the PlanetsAttackKlingons, PlanetsAttackRebels, AllowOneEngineTowing, AllowCrystalTowCapture, and AllowPrivateerTowCapture options only describe the initial assignments of the PlanetImmunity, Tow and Boarding abilities, respectively. The same holds for the FullWeaponry part of AllowFedCombatBonus. Init = Clear will wipe out these assignments, so the Rebel/Klingon ships will not be immune, ships will not be able to tow and board.

There are two ways to solve this problem by changing the host configuration:

  • Switch to Init = Default. This will, however, also assign initial values to all the other abilities, so make sure you're not introducing unwanted abilities here.
  • Add the missing abilities to your shiplist.txt file. The following fragment adds the former racial abilities:
    AssignTo = Hull
    Function = PlanetImmunity
      Hull = *
      RacesAllowed = 4 10
    Function = Boarding
      Hull = *
      RacesAllowed = 5 7
    Function = FullWeaponry
      Hull = *
      RacesAllowed = 1
    Adding the Tow abilities is a little more work, you would have to list all ships that should be able to tow in your config file. The following fragment would work for the standard ship list with one-engine towing disabled (split into two statements for convenience):
    Function = Tow
      Hull = 3-8,12-14,17-23,25,26,28-50,52,53,55,56,58,60-64
      RacesAllowed = *
      Hull = 67-70,72,74-76,78-84,86,89,90,93,94,96-102,104,105
      RacesAllowed = *
    If you want all ships to be able to tow, it is of course enough to have one Hull = * line.

Back to top

Last updated 31 May 2015.

Mail for support, ideas, bug reports, questions. Contact Details