Advanced Features The Portable Host Version 4.0h Jump to Table of Contents

Index

• Introduction
• Non-standard Race Assignments
  • Missions and Racial Abilities
  • Ship List
• Message Filtering
• Wraparound Universe
  • Setting up a Wraparound Universe
  • Playing in a Wraparound Universe
  • How Wraparound Works
• Remote Control
  • How Remote Control Works
  • Playing with Remote Control
  • Remote Control Pitfalls
• Tow Conflict Resolution
  • Breaking a Tow
  • Contested Tows
  • Tow Chains and Loops
• Wormholes
  • General Rules
  • Travelling through Wormholes
  • Creating Wormholes

Introduction

This document describes PHost's advanced features, how to set them up and how to play with them. It is intended for players and hosts.

Back to top

Non-standard Race Assignments

PHost allows any player to play any race in the game. This is accomplished with the PlayerRace config option. This option has 11 entries, with each entry specifying the race that the given player is to play. For example:

PlayerRace = 1,1,1,1,1,6,6,6,6,6,6

This has players 1 through 5 playing The Federation, and players 6 through 11 playing The Borg. Values of 12 and larger are also accepted, meaning that the given player will have no special racial abilities.

(v4.0:) PHost 4 goes even a step further and allows to customize the special missions available to the player separately, using the PlayerSpecialMission option. This is intended for design games with custom races. By default, this option has the same value as PlayerRace.

Missions and Racial Abilities

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 11 selects the special mission on one of his ships then the client program will show the mission as Build Fighters. But if player 11 has been assigned race 6, then the ship will actually perform the Self Repair mission. Using the Special Mission extended mission, players 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.

Some client programs may refuse to set your special mission. For example, the Build Fighters is only permitted for fighter ships, so a client program will not allow the Cyborg-playing player 11 to set this mission on a torpedo ship. Using mission 31 instead also avoids this problem.

The following table summarizes the abilities controlled by these two options:

For example, if a race has PlayerRace=7 and PlayerSpecialMission=7, he plays a "standard" Crystal. Giving him PlayerSpecialMission=6 instead, he'll still be like desert planets and be immune to glory devices, but will no longer be able to lay web mines or tow-capture. Instead, he'll be able to repair in space.

Not all of the possible combinations make sense. Unless you explicitly want to try out the new possibilities, we strongly recommend anyone to not have a PlayerSpecialMission option in his game, so that only the 11 standard races are used.

Many other racial abilities are configured by array options. When playing with non-standard race abilities, you have to change them manually. Options which fall into that category:

• AntiCloakImmunity (normally, Feds, Lizards and Birds are immune)
• AllowBuildFighters (normally, only Robots/Rebels/Colonies can build fighters in space)
• ColonistTaxRate, NativeTaxRate (normally, Feds have 200%, others have 100%)
• ExtraFighterBays (normally, Feds get 3, others get none)
• FighterSweepRate, FighterSweepRange (normally, only Colonies may use this; all others have value 0)
• GroundKillFactor, GroundDefenseFactor (normally, Lizards have 30/10 bonus and Klingons have 15/5)
• RaceMiningRate (normally, Feds have 70%, Lizards have 200%, rest has 100%)
• ShipCloneCostRate (normally, Crystals and Privateers have high values to make cloning un-attractive);
• UnitsPerTorpRate (normally, Robots have 4X bonus)

Ship List

Each race can build a unique set of ships; this set is defined in a file truehull.dat. When playing with non-standard race assignments, host and clients have to agree upon a consistent (and sensible) interpretation of that file. This is what PHost's MapTruehullByPlayerRace option is for.

Normally, the truehull.dat is indexed by player number (MapTruehullByPlayerRace=No). All client programs can handle this interpretation. However, the host must modify the file accordingly; for the above example, it must contain five Federation ship sets, and six Cyborg ship sets.

In order to generate such a file, you need Penguin (version 2 or higher) or its clone, Peng (version 0.2 or higher).

• Decompile the ship list (penguin -d);
• Copy the PlayerRace assignment from pconfig.src into truedat.txt;
• Recompile the ship list (penguin -r);
• Send the newly-generated files to your players.

You can also freely edit the ship assignments if you wish.

In case all players use client programs which can handle it, you can also set MapTruehullByPlayerRace to Yes. This instructs the client programs to do the above remapping. The advantage is that you can use unmodified standard ship list files; the disadvantage is that it fails when someone uses a different client.

Programs that are known handle MapTruehullByPlayerRace as of December 2002 are VPA and Planets Command Center.

The special ship abilities are sometimes considered racial abilities. However, it only depends on the truehull.dat file who can build which ships; if you allow the Fed player to build MCBRs, the Fed will have a gravitonic cloaker, although that is usually considered a Privateer ability.

Back to top

Message Filtering

Many people use programs which can read util.dat and display it graphically. Examples of such programs are EchoView, VPA 3.61 and PCC.

Since util.dat contains mostly the same information as the subspace messages, it is somewhat redundant to have both. In addition, player messages can become overwhelming, especially in the later stages of the game, when mine scan messages, sensor sweep messages, dark sense messages, etc. can leave a player with over 200 messages to deal with.

The idea behind message filtering is that the utilities mentioned above will display the information they got from util.dat, and present the information to you visually, so there's no need to read it textually.

Players can turn on message filtering themselves, without host intervention, using the filter command. When filtering is enabled, the following messages will be suppressed:

• Mine Scan reports (but not sweeping or laying)
• Dark Sense reports
• Super Spy reports
• Exploration reports
• Sensor Sweep and Bioscan reports
• Wormhole scans
• Meteor shower messages

Back to top

Wraparound Universe

PHost implements one model of a wraparound universe. In a wraparound universe, ships that fly off the "edge" of the map appear on the other side of the universe. Thus, the universe behaves more like a sphere (or a torus) than a plane. For example, in the original VGA Planets map, you can fly from (1010,2000) due west (heading of 270) and after 20 LY of travel you will appear on the other side, at (2990,2000), where you will continue on your journey flying due west.

A wraparound universe allows players to make more use of all areas on the game map. Depending upon placement of homeworlds, there need not be any more "dead" areas that take a long time to reach and may never even be explored. A wraparound universe also gives each player more neighbors, thus leading to greater interaction between players. Races on opposite sides of the universe that used to be distant unknowns can now be neighbors.

Setting up a Wraparound Universe

To enable the wraparound universe, set AllowWraparoundMap to Yes. In addition, you have to define the wraparound rectangle using the WraparoundRectangle config option. The wraparound rectangle confines all map objects (ships, planets, minefields, etc.). Any ship, for example, that exits the wraparound region reappears within the wraparound region on the other side.

Note that unlike ships and minefields, planets outside of the wraparound region are not remapped onto the region. If a planet is outside of the wraparound region, then PHost pretends that the planet does not exist. This allows custom maps with fewer than 500 planets to be used. Just place the planets outside the wraparound rectangle. Usual map editing tools place such planets at coordinates like Y=0 or Y=9000 which is just fine.

The WraparoundRectangle config option is an array of 4 values. The first 2 values define the X and Y co-ordinates (respectively) of the lower-left corner of wraparound region. The last 2 values define the X and Y co-ordinates of the upper-right corner of the wraparound region.

Note that, since PHost 3.3c, the extreme top and right co-ordinates are no longer part of the map. In older versions they were, which could lead to the strange situation that a ship that moves from Y=2999 one ly to the north would end up at Y=3000, while one that moves 2 ly to the north and back one ly to the south would land at Y=1000.

For example,

WraparoundRectangle = 1500,1000,2500,3000

defines a universe where possible X co-ordinates range from 1500 to 2499, and possible Y co-ordinates range from 1000 to 2999.

Here is another common setting:

WraparoundRectangle = 1000,1000,3000,3000

This provides a standard-sized map which is seamlessly wrapped.

No co-ordinate of the wraparound region may be less than 0 or greater than 10000. In fact, it is recommended that the wraparound region be located away from these boundaries (e.g., don't make the lower-left corner closer to the origin than (1000,1000)) for proper operation of many external programs.

The WraparoundRectangle config option has no effect if AllowWraparoundMap is not enabled.

Playing in a Wraparound Universe

Wraparound universes can be a challenge to work with when you have to imagine your ships flying from one edge of the universe to another within a single turn. Landing on planets on the opposite side of the map, for example, requires much planning. Fortunately, some client-side programs are currently available that replicate the map (i.e., they tile the plane with the map) so that cross-boundary motions are much easier to visualize and plan.

• VPA (a DOS client program) supports square wraparound maps centered at (2000,2000).
• PCC (a DOS client program) supports almost all wraparound maps (map size must be even).
• EchoView (a Windows information tracking utility) supports square maps of arbitrary size and position.

Since wraparound maps are rather popular, most other new tools should also support it.

How Wraparound Works

The most important rule about wraparound is: there is no special rule. All processes work seamlessly across the map border. When a ship sits at the left border and moves to the left, it will appear on the right. When a minefield with 100 LY radius is 50 LY from a border, it will reach over the border, 50 LY into the opposite quadrant.

Caveat: There's one caveat to watch out for. When you set a very long waypoint ("1900 ly to the right"), the ship may move in an unexpected direction. PHost will always move ships along the shortest possible path to their waypoint, possibly using a wrap boundary to make the journey shorter.

Caveat 2: External add-on programs may not know about or respect the wraparound settings. Thus, they may move ships outside the wraparound region, and not modify their effects to take wraparound into account. PHost will move all ships outside of the wraparound region back into the region, but there may be other interactions that are not so easy to predict. Check with the documentation of the add-on program for any mention of wraparound support.

Sphere and PWrap: It is not recommended to use Sphere or PWrap with PHost. Although these add-ons also implement a wraparound universe, they can not deliver the full integration as PHost does. For example, minefields near a border will not reach into the opposite quadrant with these add-ons. You should definitely never use Sphere or PWrap when AllowWraparoundMap is enabled.

Back to top

Remote Control

Remote ship control is a PHost feature which allows players to give commands to allied ships without having to relinquish ownership. This can be useful in many situations. For example, in team games, it can be quite difficult to coordinate a fleet of ships owned by different players. Using remote control, one player can assume control over the others' ships and give orders to them.

How Remote Control Works

Remote control is simple in operation, and hopefully simple to understand as well.

Normally, when you own a ship, you'll see that ship in your RST file, and it will execute your orders. If you're Crystal, your ship will be reported as a Crystalline ship, and you will be able to Lay Web Mines.

When you remote-control a foreign ship, that ship will belong to the original owner for the complete host run. Before RST files are generated, however, the ship is turned over to you, and will be reported in your RST (you can only give commands to ships which are in your RST). In the next turn, after TRN processing, the ship will be given back to its original owner. For example, when you're Crystal and control a Bird ship, that ship will act as a Bird ship all the time. It will be able to Super Spy and not to lay Webs. It will be reported as a Crystal ship in RST files.

All other players will see that ship as belonging to the Crystals, but PHost will tell them that it's actually a Bird ship. It does so by sending a util.dat record as well as by adding a tag to its name.

To summarize, here's what happens with remote control:

1. A player assumes remote control over a ship by sending a command message (see below). Let's assume you're Crystal and want to control a Bird ship.
2. Host processing proceeds normally. The ship is still owned by its original owner - Bird Men in this case - and will perform its normal orders.
3. Right before RST files are sent out, PHost changes the "ownership" field to Crystals.
4. You will see that ship as if it were yours in your RST, and all other players who see that ship will see that, too. You can now give commands to the ship. The original owner, Bird Men in this example, will also see this ship as a foreign ship, and has no control over it.
5. When you send in your TRN, and PHost runs again for the next turn, PHost will process your commands for that ship. Afterwards, the ship will revert to its original owner. For the complete host processing, the ship will again behave as a Bird Men ship.
6. Continue with step 3.

Some things to note:

• Both the original owner (Bird Men) and the remote control player (Crystals) can cancel the remote control at any time. The original owner uses remote forbid, while the remote control player uses remote drop. When this happens, the remote control player can still continue to give orders for this turn, but next turn, the original owner will again be in control.
• The owner of a ship prevent it from being remotely controlled (remote forbid command).
• The owner of a ship must offer you the ship level of alliance for you to be able to take control.
• (v4.0e:) As a shortcut, the original owner of a ship can place a ship under remote control in one step using remote give. This is otherwise identical to remote allow from the original owner followed by remote control from the new remote control player.
• The give command can be issued by either the original ship owner, or the remote control player. The ship will continue to be remotely controlled if the new owner also permits it. All other commands (beamup, extmission, and so on) can only be given by the remote-control player, because it's he who is in control of the ship. Note that give is completely different than remote give.
• The remote control interface is enabled by the CPEnableRemote config option. Without this option enabled, players have no access to the remote control commands.

Playing with Remote Control

Presentation

During play, remotely-controlled ships will appear to be owned by the player who controls them, not who owns them. This is an important distinction: if you see a Crystalline-controlled ship approaching which actually belongs to the Bird Men, you have to set primary enemy Birds to attack it.

PHost tries in several ways to tell you that:

• Both the original owner and the remote control player will receive player messages listing the ships, their true owner, and their remote control player. This information will also be reported in util.dat. Advanced client programs, such as Planets Command Center, VPA and EchoView will also display this information (for example, PCC will say "a Bird Men ship under Crystalline control").
• Non-involved players who scan a remote-controlled ship will also get the util.dat record.
• The names of all ships under remote control will be modified by PHost to end in *N, where N is the code for the true owner (1..9 for Feds to Robots, A for Rebels, B for Colonies). For example, when the Crystals in our example name the Bird ship NX Borgslasher, PHost will report that name as NX Borgslasher*3 in Result files, so everyone knows that it's actually a Bird ship. In subspace messages, the ship will have its real name, without the tag.
• PHost will prevent that you name your own ships ending in *N to avoid spoofing.

You need to know the true owner of a ship in many cases:

• If you want to attack a ship, you need to set the Primary Enemy to the true owner, not to the player who controls it.
• When you want to set a mission which is restricted to certain players, it's the true owner which defines whether it will work. For example, when you're Crystal and set mission 9 on a remotely-controlled Bird Men ship, the ship will do Super Spy (the Bird Men's mission 9), although many programs will list the mission as Lay Web Mines (the Crystalline mission 9). If your client doesn't let you set the mission you want, use the extended mission 31, Special Mission, instead.

Acquiring and Relinquishing Remote Control

When the owner of a ship permits it (see below), you can acquire control of that ship by sending a remote control command. For example, to assume control over ship 37, you send the command "remote control 37". Next turn, the ship will be in your RST so you can control it.

To return control back to the original owner of a ship, send a remote drop command, as in "remote drop 37". You can still give orders for this ship, for the current turn, but next turn, the ship will be given back to its original owner.

Controlling Remote Control

As soon as you offer someone the ship level of alliance, they can remote-control all your ships. You can prevent ships from being remotely controlled by sending a remote forbid command. For example, to disable remote control for ship 38, you would send the command "remote forbid 38". If the ship currently is under remote control, it will be forcibly given back to you.

You can choose that all newly-built ships should be forbidden from remote control by sending a remote forbid default command. Note that this will only affect new ships; all ships which you already have are not affected. You must send individual remote forbid commands for each of them.

To allow remote control for some ship again, use the remote allow command, as in "remote allow 38". As above, you can also use "remote allow default" to make all newly-built ships remotely-controllable by default.

Remote Control Pitfalls

Because a remote controlled ship is still owned by its original owner, it will report its actions to that original owner. In particular, if that player has not offered you vision level, you will not see the result of sensor sweep, mine sweep or exploration.

Starting with PHost 4.0d/3.4g, some messages are forwarded to both the real owner and the remote-control owner of a ship:

• Mission results: Beam up (all flavors), Lay mines (all flavors), Colonize (success and failure), Hiss, Rob (robber and victim), Tow failures, Super Spy Deluxe, Build fighters (all flavors)
• Results of ground attack
• Ships which passed a minefield and/or hit a mine
• Cyborgs beaming aboard debris after a fight
• Wormhole travel
• Cloak failures (all reasons, including anti-cloak)
• Ship initiated or passed a chunnel
• Ship tow-captured by Crystals or Privateers
• Ship hit by glory device
• Cargo trimmed from overloaded ship

Remote control currently has bad interaction with AllowShipNames restrictions. To make it short, restrictions between a ship's real owner and the ship's remote control owner are currently not enforced for ships which are under remote control. We believe this is not too serious a problem because setting up remote control needs communication anyway.

Back to top

Tow Conflict Resolution

There are three types of conflicts which can arise during towing: the towee might break the tow, many ships try to tow a third, or there might be a tow chain or loop.

Note that these rules do not apply to tow-capture.

Tow conflicts are resolved in the order as specified here, after all other preconditions of towing (see mission description) have been fulfilled.

PHost implements two models of conflict resolution. The preferred one, alternative towing, is selected by enabling AllowAlternativeTowing, and is based upon a tow-strength reasoning. In addition, PHost supports HOST-compatible towing, a model which tries to mimic the Wisseman HOST rules. It should yield the expected results in most cases.

Breaking a Tow

If the towee cooperates (TowedShipsCooperate), it will not break the tow.

If the tower has a Level 2 tractor beam and the towee has not, he can always tow the target. Likewise, a ship with level 2 tractor beam cannot be towed by one without. If both ships have this device, or neither of them, the following rules apply. Ships must have fuel and a non-zero warp factor to use their level 2 tractor beam.

Alternative Towing: Towing depends on the tow strength of the tower, and the tow resistance of the tow target. The tow succeeds if the tower's strength equals or exceeds the tow resistance. If the towee has a larger tow resistance, he breaks the tow.

Tow strength is determined as follows:

Tow_strength = Engine_contribution + Movement_contribution

Engine_contribution = Engine_tech^2 * Num_engines
   * Warp_factor * Grav_factor * TowStrengthEngineScale
Movement_contribution = Movement_distance
   * TowStrengthDistanceScale

• Engine_tech is the tech-level of the engine (i.e. 10 for Transwarp Drives)
• Grav_factor is 2 for ships with gravitonic engines, 1 otherwise
• Movement_distance is the distance this ship can move this turn. This is the distance to its waypoint, limited by the maximum movement distance according to its speed (e.g. 81 at warp 9 with normal engines), limited by available fuel. Note that this computation includes mass of the towee.

Tow resistance is computed using the same formula, but using only the towee's mass in computing the fuel/distance limit.

These rules can be summed up as follows:

• good engines win over bad engines
• ships with many engines win over ships with few engines
• fast ships win over slow ships
• gravitonic engines win over non-gravitonic engines

HOST-compatible Towing: HOST-compatible towing is based on an analysis of the behaviour of HOST 3.22.009. The rules can be summarized as follows:

• A tow breaks if all of the following conditions are fulfilled:
  • The towed ship's warp speed is greater or equal to the towing ship's warp speed. If the towing ship has gravitonic engines, its warp speed is doubled; this does not apply to the towed ship.
  • The towed ship has a waypoint further than warp-squared lightyears away (i.e. more than one turn of travel most of the time).
  • The towed ship has at least 25 kt fuel.
  • The towed ship has at least two engines (if AllowOneEngineTowing is disabled).
• When two ships try to tow each other (mutual towing), the low-Id ship wins most of the time. Exceptions are:
  • If both ships have the same warp speed, and both are set to travel more than one turn (warp-squared lightyears), they break apart and each moves towards its waypoint.
  • If the high-Id ship meets the criteria for breaking the tow (see above), it will tow the low-Id ship.
  • As for the simple towing case, gravitonic engines for the lower-ID ship double its effective warp speed. This effect does not hold for the higher-ID ship.

Contested Tows

If multiple ships try to tow a single ship, only one can finally be successful.

Ships with Level 2 tractor beam (and fuel, and non-zero warp factor) always win over ships which do not have such a device. Among the remaining ships, PHost chooses according to the following rules.

Alternative Towing: The ship with the highest tow strength wins the conflict. Among equal tow strengths, lowest Id number wins.

HOST-compatible Towing: Lowest Id-number wins.

Tow Chains and Loops

Tow chains (A tows B, B tows C, C tows D, D tows E, etc.) are broken up such that the first tow always succeeds. In this example, A will tow B. Since a ship which is being towed cannot tow another ship, B will not tow. C will tow D, and D will not tow.

Loops can also remain in very few cases. In this case, PHost will pick one ship whose tow succeeds, and resolve the rest using the above chain resolution rules.

• A ship with Level 2 tractor beam (and fuel, and non-zero warp) wins over ships without such device.
• Under alternative towing, the ship with the highest tow strength wins. Among equal tow strengths, lowest Id wins.
• Under HOST-compatible towing, the lowest Id ship wins.

Note that PHost versions before 3.4h/4.0e did not do loop resolution, so results were close to unpredictable under these versions.

Back to top

Wormholes

Wormholes are imaginary connections between two points in space. You can travel through wormholes with your ships.

General Rules

Wormholes have two endpoints. Both endpoints have an Id number; unlike the other Id number sequences, wormholes are numbered starting from zero. A wormhole can be unidirectional or bidirectional. A unidirectional wormhole only allows travel from the lower-numbered (even) endpoint to the higher-numbered (odd) one, whereas bidirectional wormholes allow travel in both directions.

Wormholes have a mass. This mass affects various things:

• visibility range
• radius of the entry/exit point
• how safe it is for large ships to travel through the wormhole

Wormholes have an instability. The higher the instability, the higher the risk for a ship of getting damaged during a wormhole travel.

The wormhole endpoints can move towards a waypoint, and otherwise have general jitter. The wormhole disappears if both endpoints reach the same position. Likewise, the mass and instability of a wormhole can change over time.

Ships can scan for wormholes using sensor sweep or WRS. Exact scanning rules are documented on the formulas page. Only wormhole entry points can be seen this way, the exit point of a unidirectional wormhole will not be seen!

For Winplan clients, wormholes are mapped to Ufos. PHost allocates two Ufo slots for a bidirectional wormhole, one Ufo slot for a unidirectional wormhole. PHost uses up to 200 Ufo slots starting with WormholeUFOsStartAt. Existing Ufos in that range will not be seen.

See also: Wormhole formulas, Wormhole-related configuration items.

Travelling through Wormholes

Ships can travel through wormholes. If WrmVoluntaryTravel is enabled, wormhole travel is voluntary: set the friendly code to WRT to travel through a wormhole. As a confirmation for wormhole travel, the friendly code will be changed to WRS in this case. If voluntary travel is disabled, ships will always be moved through wormholes if they end their movement inside a wormhole endpoint, even if they do not want that.

Wormhole travel consumes fuel. If the ship does not have enough fuel for the ride, it will be heavily damaged and thrown to a random place in the universe. Even if you have enough fuel, it is possible that your ship gets damaged. You cannot tow or intercept through a wormhole. After travelling through the wormhole, ships must usually decloak (WrmTravelCloaked).

The ship will not end at the exact center of the wormhole. It will end up up to 10 ly in each direction from the center. Therefore, if you enter a wormhole with many ships at the same position, they will not necessarily end all at the same position again.

See Wormhole Travel Formulas for details.

Creating Wormholes

Wormholes are only supported if AllowWormholes is enabled in pconfig.src (default). In this case, PHost will look for a text file wormhole.txt which contains wormhole definitions.

A wormhole definition consists of 6 to 10 numbers in one line, separated by whitespace:

X1 Y1 X2 Y2 Mass Instability Wp_X1 Wp_Y1 Wp_X2 Wp_Y2

You can write comments in this file starting a line with ';' (semicolon) or '#' (hash sign). Blank lines are ignored.

PHost will read and update wormhole.txt. A backup copy of the old file will be written as wormhole.bak.

If a wormhole's two endpoints become coincident (by natural displacement, for example), the wormhole is considered "collapsed" and becomes inactive. It still appears in wormhole.txt to avoid renumbering wormholes and confusing player-side tracking utilities. If you want to add wormholes in mid-game, add them to the end of wormhole.txt for the same reason. Likewise, if you want to delete a wormhole, mark it inactive by setting start and endpoint to identical values.

Back to top

Last updated 11 July 2004.