![]() |
Frequently Asked Questions
|
The Introduction (readme) document contains the relevant links.
See the Hosting with PHost document for information on how to create and run games with PHost.
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.
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.
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
supports all PHost 3.x subtleties as well as PHost 4.0, but it has
some problems with very long fights. Recent EchoView
versions have a PHost 3.x/4.x simulator built in, too.
As of December 2006, PlayVCR
has a
built-in multi-ship simulator ("CCBSim 2.0") which supports all
features of PHost. It is still comparatively young code, though.
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.
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.
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:
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".
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.
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.
The PHP 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:
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.
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.
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:
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 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 do message parsing expect messages 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.
Winplan cannot play combat generated by PHost. See here for more information.
Since version 4.0, the game configuration is split into two parts:
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.
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.
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 or Planets Command Center
to see these
ships.
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).
Did the ship have supplies? If so, remember that ships repair themselves with supplies both before and after combat.
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.
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.
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.
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:
AssignTo = Hull Function = PlanetImmunity Hull = * RacesAllowed = 4 10 Function = Boarding Hull = * RacesAllowed = 5 7 Function = FullWeaponry Hull = * RacesAllowed = 1 |
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 = * |
Last updated 20 September 2008.