PHost - What's New in PHost 4
This document contains all the important changes in PHost 4.x compared to PHost 3.x and earlier. This file does not claim to be 100% complete. PHost 4 contains some rather intrusive changes, to rules and otherwise, so that one could possibly talk of PHost 4 as a different hosting program. But actually, PHost 3.x and 4.x are based upon the same code base; when technically possible, some of these changes are also made available in a 3.x PHost. We will continue to maintain the 3.x series as long as possible.
In a nutshell: PHost 4 contains all these things that make it too different from PHost 3 to share a common version number.
To get this straight: PHost 4 is a hosting program for VGA Planets 3.0 or 3.5, as a replacement for the Host program 3.x. It has nothing to do with the game "VGA Planets v4", which is something completely different.
Prior PHost versions were numbered 220.127.116.11, where 3.2 is the version of the Wisseman Host they try to emulate and 1.9 is the actual PHost version. Because this causes confusion (to what part does "PHost 3.2" refer in "18.104.22.168"?), and because the two hosts have rather diverged anyway, we decided to drop the first two places of the version number.
PHost can be set up to emulate almost any 3.x host, but still gameplay has noticeable differences.
PHost 4.x supports up to 999 ships. The actual ship limit can be configured in pconfig.src (NumShips). When all players use appropriate client programs, you can use this to delay the ship limit a bit. See under NumShips for more information.
When there are less than 500 ships in the game, PHost generates files compatible with all client versions. Actually, PHost 4.x will always write "Host999-style" result files. None of the known unpack programs have problems with this. However, recent Winplan versions will always unpack results as if they were made by Host999, producing bogus scan reports, so this also works around that problem. PHost allocates ship Ids so that Ids above 500 are only taken when there are more than 400 ships in the game. This way, players can start the game with an "old" client and update later.
PHost 4 introduces per-ship hull functionalities. Originally, ship abilities were tied to particular hulls (i.e. hull 105 always is the Alchemy ship). PHost 3.x allowed you to make these race-dependent (i.e. small freighters only hyperjump when owned by the Rebels). PHost 4 goes a step further and allows to define these things separately for each ship.
If enabled (AssignTo=Ship in hullfunc.txt), this allows some more realistic play: when you capture a Rebel ship, it will hyperjump for you, too, and when Rebels capture a small freighter you built, it will not jump. In addition, it makes possible an add-on that allows you to buy additional capabilities for your ship.
There are now a number of new functions which need the possibility to assign properties to individual ships: ships can be CloneOnce (and get Unclonable when cloned), likewise GiveOnce and Ungiveable. This can be used to make ships more valuable, and to implement additional rules (i.e. "you can't trade ships that are heavier than 400 kt"). There is now also a Level2Tow which makes your ship stronger when towing.
(v4.0i:) PHost 4.0i added another boatload of hull functions. There are now smaller versions of the Chunneling ability, namely ChunnelSelf, ChunnelOthers, and ChunnelTarget. Some old ship abilities can now explicitly be assigned explicitly, to give you more flexibility: Tow, PlanetImmunity, Boarding. You can now give these abilities to any race, and also tie them to ships (e.g. Klingon-made SDSFs are immune against planet attacks). There is a new terraforming function, and a few new defensive and combat features (AntiCloakImmunity, FullWeaponry, HardenedEngines, HardenedCloak, IonShield, Commander). The list ends with a Repair ship, and an Academy ship for the new experience system.
(v4.0e:) Wormhole scanning now happens at the same place as sensor sweeping, too.
This is to simplify game play. For some things, you do not even have to scan in order to see them, so it makes little sense having to perform three different orders to see the others.
PHost now allows all means of communication to be configured out. Since ever, it was possible to disable messages, alliances, remote control, etc. The last means of communication, ship names, can now also be turned off. When AllowShipNames is set to No, players will only see their own ship names; foreign ship names will be suppressed.
This feature is also available in PHost 3.4.
The alternative towing rules have been changed. The ship's movement distance now has a greater impact. Before, a ship's tow strength was 163*(Engine Contribution) + (Distance Factor). Now, the formula is (Engine Contribution) + 19*(Distance Factor). In particular, ships with, say, 3 engines can now tow a four-engine ship in some cases. The distance factor now also considers fuel on the ship. If your fuel suffices for 40 ly only, your distance factor will be 40, even if you have a gravitonic warp 9 ship.
The ability to tow can now be freely assigned to ships instead of just depending on whether the ship has one engine or more. Especially, you can remove tow ability from big baseships, or give it to small scouts.
This new tow strength formula is also available in PHost 3.4b.
Battle order (numeric friendly codes) is now also considered for intercept attack. Previously, ships fought in decreasing Id order. This change is also available in PHost 3.4b.
PHost can now be configured so that colonists survive when a planet has been conquered in regular combat. After all, most of them are civilians. The ColonistCombatSurvivalRate specifies the percentage. However, colonists will get unhappier by ColonistCombatSurvivalRate / 2 points after combat. Because this option has the potential to severely change gameplay, it is only available in PHost 4.0 and later. (PHost 4.1d allows you to make this race-dependant upon both the captor and the captee, see option description.)
Ship list designers can now create Death Rays. Those ignore all shields and just kill crew. Hence, a death ray is well-suited for capturing enemy ships. A death ray is one having a "Bang" value of zero. The same goes for torpedoes.
Combat is affected by experience. Experienced ships fight better than inexperienced ones.
Otherwise, the battle mechanics did not change. When you use neither the Death Ray feature nor Experience, you can continue watching your combat using an older VCR player.
Ships and planets get experience when doing things. Experienced units are better than inexperienced ones in certain aspects. In a nutshell:
Full details are on the Experience page.
In order to allow more possibilities for design races, the special mission of a race is no longer tied to the other race abilities. Using the PlayerSpecialMission option, you can assign any mission to any race.
Many other options were arrayized and can now be configured separately for each player. This allows for some very interesting races to be configured.
During the v4.0 line, PHost learned a lot more about fairness.
Per-Player Id Order: Often, they who come first have an advantage. And, often, low-Id ships are chosen first. To lessen the effects of ship Ids to the game, PHost now does certain things in per-player Id order: every players' ships operate in ascending Id order, but all players' sequences are randomly interwoven. This provides fairness while still keeping the predictability of Id order.
Mines destroy Mines: Overlapping mines do now all explode simultaneously, instead of when they're laid. In addition to making things like Starbase+ and ACP function properly, this also provides fairness. It no longer depends on your Id numbers how many mines you lose when someone else drops some torps inside your minefield carpet.
PHost now supports ion storms. This was the last major HOST feature lacking in PHost. Our storms use similar rules than HOST's, but not identical.
Ion storms are a natural phenomenon that affects ships, to the good or worse - much like meteorites which affect planets.
If you want to use ion storms, set IonStormActivity to a value other than zero (5 is a common choice in the HOST world). The default is zero which means no ion storms. PHost automatically creates, manages and destroys ion storms, there's no need to modify your game mastering process.
The configuration was cleaned up. One of PHost's most distracting points was that huge configuration file. You don't need a university degree to play with PHost -- but do you believe that in the presence of 300 configuration options?
Now, some of the very rarely-used options have been dropped. Others have been made optional so the average host need not bother with them. Ship-list specific parts can be separated out into a separate file that goes with the ship list. All in all, this allows for much shorter game configuration files.
Some options are no longer accepted:
During the 4.1 series, we will further reduce the number of configuration options. For example, there is no need to have a separate switch to turn off Hissing when you can as well assign the player a different special mission - ignoring the fact that probably nobody so far ever wanted to disable Hiss.
Manipulations in the host sequence are now easier. Assignments in the pcontrol section learned a number of new tricks: they are cumulative, allow you to specify the command to execute directly, include variables for directory names, and allow you to execute commands after a section, not just before. The new Addon command allows a simple modular configuration for complicated add-ons.
These features were also introduced in the 3.4 series.
PHost 4 introduces some slightly different file formats. Older PDK add-ons will not work with it until they are recompiled with a PDK that supports PHost 4. Once that is done, the add-ons will function equally well with PHost 3 and PHost 4. Add-ons that do not use the PDK must be ported, if they use auxdata.hst.
The format of auxdata.hst has changed. Actually, that's the driving reason behind the new version number: doing new things in auxdata.hst means we need a new number, and to implement 999 ships and per-ship abilities, we need new auxdata things.
auxdata.hst is now divided into chunks, much like utilx.dat. This means it can now be extended without breaking existing programs. When you update a program for PHost 4, it will most likely work with everything that follows.
We've been adding many new util.dat records. The ultimate goal is to have one record for every sub-space message you get.
PHost now accepts a new TRN command, number 62 "SendBack". This command contains a util.dat record which PHost will simply send back to you. Client-side programs can use that feature to store auxiliary data. See the technical information page for details.
The command message parser was revamped. The two goals were to simplify add-on command messages and to simplify automatic generation of command messages.
These features is also available in PHost 3.4b (externalization: 3.4d).
Many of the messages PHost sends you look a bit bumpy, because they are historically grown and are intended to match Tim's messages bit-by-bit. This is important for programs that do message scanning. Unfortunately, there are many programs that need this, VPA 3.51 being the most popular of them (version 3.61 finally uses util.dat).
That's why PHost 4 introduces a new language file NewEnglish which has most messages revised, typos and ugly grammar fixed, and layout improved a bit. You can select it via the Language config option and the language command. Unlike the original English language, we don't have to maintain compatibility with anything for this file.
Piotr Winiarczyk has contributed a Polish language file.
These changes are also available in PHost 3.4c.
In PHost 4.1 (and 3.5), the language file was converted to a different, easier accessible format. This will allow 3rd-party modifications to the file, and thus simplify new translations.
Last updated 31 May 2015.
Mail firstname.lastname@example.org for support, ideas, bug reports, questions. Contact Details