THE PORTABLE HOST Alliances Version 3.2.2.12 PHOST supports formal alliances between players by modifying its behavior as necessary in order to enable the allies to easily co-operate. Thus, allies can fly through each other's minefields without hitting mines, allies can avoid fighting each other in combat, allies can see each other's ships, and so on. Moreover, each of these alliance features can be tailored for each alliance so that different levels of trust and co-operation can be established. Alliance Mechanics ================== Alliances are formed and broken by using the 'allies' command of the PHOST command processor (see COMMANDS.DOC for details). Briefly, to offer an alliance with a race, a player must send a command message (i.e., a message to himself) that reads: allies add 5 where the '5' indicates that the player wishes to offer an alliance to the Privateers. Any race number from 1 to 11 can be specified. To rescind the alliance offer (and break the alliance, if it has been formed) a command message must be sent that reads: allies drop 5 The different levels of alliance (see below) are modified using the 'config' subcommand: allies config 5 +ship -mines +combat The COMMANDS.DOC file describes the above commands in more detail. For each turn that a player is involved in alliances, PHOST will send a message summarizing the status of alliances (offered, requested, or accepted -- see below). This message contains information that takes into account all alliance management activity submitted by players for that turn (i.e., the status messages are sent after all processing of alliance commands for all players is complete). See the Alliance Examples section in this document for examples of alliance status report messages. Changes in alliances may take effect either before or after host processing, depending upon the DelayAllianceCommands option (see CONFIG.DOC). If DelayAllianceCommands is OFF, then alliance management commands are processed as soon as they are received, before movement and before combat. This allows a player to "backstab" an ally by breaking the alliance and attacking in the same turn. If DelayAllianceCommands is ON, alliance management commands are parsed but not implemented until after host processing. This gives players one turn in which to notice that an alliance has been broken and to prepare for any subsequent action by the former ally. In any case, the alliance status message generated by PHOST will always reflect the updated state of all alliances. Alliance States =============== An alliance may be in one of three states: 1) Offered: the player has offered an alliance to another player but the alliance has not yet been accepted 2) Requested: another player has requested an alliance 3) Accepted: both players have offered alliances to each other and thus they are formally allied. None of the alliance features take effect until an alliance is in this state. An offer of alliance need only be submitted once, it is remembered for the duration of the game or until it is rescinded with a 'Drop' command. Once the target of the alliance also sends an 'Add' command with the first player as the target, the alliance is complete. If either player sends a 'Drop' command, the alliance is broken, but the other player's alliance proposal is still pending and may be used to re-form the alliance (a good tactic if the other player forgets to issue a 'Drop' after being backstabbed!) It must be noted that none of the alliance features are in operation, for either player involved, unless both players offer alliances to each other, thus bringing the alliance to the 'Accepted' state. Thus, even if player A offers an alliance to player B, player B cannot take advantage of alliance features until he too offers an alliance to player A. The Alliance Example section in this document shows an example of alliance negotiation. Alliance Levels =============== An alliance is characterized by the following 5 levels: 1) Ship Level If this alliance level is enabled, the player's ships work in concert with the ally's ships. The 'bigtargets' command (see COMMANDS.DOC) is useful for this level of alliance. 2) Planet Level With this alliance level enabled, the player's planets and starbases become available to the ally. 3) Mines Enabling this alliance level causes the player's minefields to be co-ordinated with the ally. 4) Combat Enabling this option causes allied ships and planets to never fight each other in a combat situation. 5) Vision With this option enabled, everything "seen" by a player is also "seen" by the ally. More details on the above levels are presented in the next section. Alliance levels themselves may be in one of three states: 1) Enabled The level of alliance is enabled to the ally 2) Disabled The level of alliance is not available to the ally 3) Conditional The level of alliance is not enabled to the ally, unless the ally also enables the same level of alliance (perhaps conditionally). By default, when an alliance is created, all levels are disabled. The alliance levels may, however, be modified in the same turn that the alliance is offered. Note that an alliance need not be symmetrical in these levels. For example, player 1 may allow player 2 vision but player 2 may disable vision to player 1. Note that the combat level of alliance makes little sense unless it is symmetrical. Conditional alliance levels allow players to set up alliances in which there is no risk. By requiring that the ally also enable the same level of alliance to the player, both players either do get or both do not get the benefit of the alliance level. The following chart summarizes who benefits from alliance levels depending upon the alliance level state of each player. If a box contains a 1, then it means that Player 1 benefits from the level, if a box contains a 2, then Player 2 benefits from the level. Boxes that contain 1,2 indicate that both players benefit from the alliance level. +-----------------+ | Player 2 | | Offers | +-----+-----+-----+ | - | ~ | + | +-----+---+-----+-----+-----+ | | | | | | - : level disabled | P | - | | | 1 | ~ : conditional level | l O | | | | | + : level enabled | a f +---+-----+-----+-----+ | y f | | | | | 1 : Player 1 benefits | e e | ~ | | 1,2 | 1,2 | 2 : Player 2 benefits | r r | | | | | 1,2: Both players benefit | s +---+-----+-----+-----+ | 1 | | | | | | | + | 2 | 1,2 | 1,2 | | | | | | | +-----+---+-----+-----+-----+ Detailed Alliance Level Operation ================================= Each level of alliance modifies PHOST behavior in some specific ways. These modifications are described below. The descriptions follow the convention that they are written from the point of view of the player offering the level of alliance to his ally. Ship Alliance Level ------------------- * If the Privateers offer this level to an ally, then the ally's ships will not be robbed. * The player's ships will become visible to the ally, regardless of their positions and cloak status. * The player's cloaked ships are able to be towed and intercepted by the ally's ships (since the cloaked ships are visible to the ally). * A player's true hull will be seen by the ally even if the ship is performing a chameleon function (via the PHONEY.HST file mechanism). * The number of ships (freighters and capital ships) belonging to the player will be reported to the ally even if the ScoringMethod config option is set to None. * A player's glory device will not be triggerred by an allied ship. * If a player's glory device explodes then the ally's ships in the same place will suffer the same amount of damage as the player's ships (10% of a single mine hit if the glory device ship is a Saber, 20% for a Nefarious) rather than the full amount of damage. The Combat Level of alliance is a co-requisite in this case. * The player's ships will not be captured by a boarding party (via tow capture) of an allied Privateer or Crystal ship. * A player who enables all three of the Ship, Combat, and Vision alliance levels to an ally will send copies of all VCR's to the ally's RST file. This only applies to VCR's in which the player is involved in directly, not VCR's received by virtue of this alliance mechanism (i.e., there is no "double forwarding" of VCR's). NOTES for DOS Planets, VPA, and shareware WinPlan users: * If a player scans more than 50 enemy ships in one turn, either by himself or by virtue of an alliance, and the AllowMoreThan50Targets configuration option is enabled for the player, then the player MUST use an RST-unpacking program that supports more than 50 targets, such as VPUNPACK or VPUTIL. The standard UNPACK program that comes with VGA Planets CANNOT be used. Registered WinPlan players will be able to see more than 50 enemy ships regardless of the AllowMoreThan50Targets setting. * If a player scans more than 50 enemy ships in one turn and the AllowMoreThan50Targets configuration option is disabled, then all ships beyond the first 50 will ONLY be written to the UTIL.DAT file. This does not apply to registered WinPlan players. Planet Alliance Level --------------------- * The player's planets and bases are written out to the ally's UTIL.DAT file. For the player's bases, only their existence is reported. For the player's planets, the following information is reported: Temperature Native Type Native Government Native Population Colonist Population Minerals Mined (on the surface only) Number of Supplies Number of Credits * A player's bases will load torpedoes onto an ally's ships if the base mission is set to Load Torpedoes. Friendly codes do not have to match. * A player's bases will refuel an ally's ships if the base mission is set to Refuel. Friendly codes do not have to match. * A player's bases will unload cargo from an ally's ships if the base mission is set to Unload Freighters. Friendly codes do not have to match. * A player's bases will yield their ship components to a Federation ship that is performing a Super Refit. Friendly codes do not have to match. * A player's planets will not suffer a ground attack if an ally's ship unloads colonists. The colonists will simply be added to the planetary population. * A player's planets will allow an ally's ships to gather minerals from the planet surface. Friendly codes do not have to match. * A player's planets will allow an ally's ships to perform the Colonize mission. * A player's planets will allow an ally's ship to use the 'lfm' friendly code and beam the necessary minerals off the planet's surface for fighter construction. * A player's bases will allow an ally's ship to clone itself and to use minerals and credits from the planet's surface as necessary for cloning. * A player's planets will not be affected by the Imperial Assault mission. The clans dropped by a Super Star Destroyer will simply be added to the clans on the planet's surface. * The number of planets and bases belonging to the player will be reported to the ally even if the ScoringMethod config option is set to None. * A player's planets will allow an ally's ship to gather minerals and credits required for building torpedoes using the Gather Torpedoes extended mission (see MISSIONS.DOC). NOTES: * The starbase Force Surrender mission still requires friendly codes to match or a ship to have no fuel. This base mission is not affected by the planetary level of alliance. This allows allies to keep their base missions to Force Surrender yet still have an ally's ships present at the base. * ALL planets and bases reported by virtue of an alliance (i.e., not directly scanned by the player) are reported ONLY to the UTIL.DAT file. They are not written to the player's RST file. * The Pillage and RGA missions WILL take place, even if planetary alliance is in place. These missions are often beneficial and it would be counterproductive to disable them to allies. Minefield Alliance Level ------------------------ * A player's minefields will not explode when an ally lays a minefield that overlaps. * A player's minefields will not be swept by an ally's ship performing a Mine Sweep mission. * A player's web mine fields will not drain fuel from an ally's ships that are in the minefield. * A player's mine fields will not interact with an ally's ships with respect to movement through the field. * The player's mines that are listed as mine scan records in the ally's UTIL.DAT file will contain the planet number that controls the minefield. Combat Alliance Level --------------------- * A player that is an aggressor in a battle will not fight an ally's ships or planets. See the file OOB.DOC for the definition of the term 'aggressor'. This alliance level is of little use unless enabled by both players in the alliance. In this case, this alliance level simply implies that the two players' ships and planets will not fight each other. * If a player's glory device explodes then the ally's ships in the same place will suffer the same amount of damage as the player's ships (10% of a single mine hit if the glory device ship is a Saber, 20% for a Nefarious) rather than the full amount of damage. The Ship Level of alliance is a co-requisite in this case. * A player who enables all three of the Ship, Combat, and Vision alliance levels to an ally will send copies of all VCR's to the ally's RST file. This only applies to VCR's in which the player is involved in directly, not VCR's received by virtue of this alliance mechanism (i.e., there is no "double forwarding" of VCR's). Vision Alliance Level --------------------- * If any one of the following messages is generated by a player due to execution of a mission, then a copy of the message is sent to the player's ally: - Mine Scan messages - Sensor Sweep messages - Exploration messages - Wormhole Scan messages - Super Spy messages (for the Birdman player) - Dark Sense messages (for the Empire player) - Bioscan messages The corresponding records are also generated in the ally's UTIL.DAT file. Note that if an ally receives a message by virtue of the vision level of alliance (i.e., he did not receive the message because of a mission he performed) then this message is NOT passed on automatically to any of his allies. That is, it is not the message that is reported to allies, it is the mission status. If you don't perform a mission, you don't report to your allies. * All enemy ships scanned by a player also appear as ships scanned by the ally. The player's own ships are NOT reported to the ally unless the ship alliance level is enabled. * All unowned planets scanned by a player's ships in orbit show up as a planet target record in the UTIL.DAT file (see UTILDATA.DOC). * A player who enables all three of the Ship, Combat, and Vision alliance levels to an ally will send copies of all VCR's to the ally's RST file. This only applies to VCR's in which the player is involved in directly, not VCR's received by virtue of this alliance mechanism (i.e., there is no "double forwarding" of VCR's). NOTES for DOS Planets, VPA, and shareware WinPlan users: * If a player scans more than 50 enemy ships in one turn, either by himself or by virtue of an alliance, and the AllowMoreThan50Targets configuration option is enabled for the player, then the player MUST use an RST-unpacking program that supports more than 50 targets, such as VPUNPACK or VPUTIL. The standard UNPACK program that comes with VGA Planets CANNOT be used. Registered WinPlan players will be able to see more than 50 enemy ships regardless of the AllowMoreThan50Targets setting. * If a player scans more than 50 enemy ships in one turn and the AllowMoreThan50Targets configuration option is disabled, then all ships beyond the first 50 will ONLY be written to the UTIL.DAT file. This does not apply to registered WinPlan players. Alliance Examples ================= This appendix provides some examples for how to work with alliances. The basic steps needed to form an alliance are presented along with the status messages that PHOST returns to the player. For the remainder of this appendix, everything is viewed from the point of view of the Federation player who wants to form an alliance with the Rebels. As mentioned above, an alliance may be in one of three states: offered, requested, or accepted. Initially, the Federation wishes to form an alliance with the Rebels. The player then sends the following command message: a a 10 a c 10 +c +m ~s ~p The first line of the message indicates that an alliance with player 10 (Rebels) is desired. The second line indicates that only the Combat and Minefield levels are to be allowed unconditionally. The Ship and Planet levels are only offered conditionally. That is, they do not take effect unless the Rebel player also enables the Ship and Planet levels to the Federation player. (But nothing takes effect until the alliance as a whole is offered back to the Federation from the Rebels.) At this point, the alliance is in the OFFERED state for the Federation player and in the REQUESTED state for the Rebel player. On the next turn, the Federation player will receive the following message from PHOST: <<< Alliance Status Report >>> (message to Federation) Race Offered to Race Allowed by Race ---- --------------- --------------- 10 ~s ~p +m +c -v This message shows that the Minefield and Combat levels of alliance have been unconditionally offered to player 10 (Rebels), and the Ship and Planet levels of alliance have been conditionally offered. The Federation player sees that no alliance has yet been offered by player 10 (nothing in the "Allowed by Race" column) hence the alliance has not yet been accepted. On this same turn, the Rebel player will receive the following message: <<< Alliance Status Report >>> (message to Rebels) Race Offered to Race Allowed by Race ---- --------------- --------------- 1 ~s ~p +m +c -v This message indicates to the Rebel player that the Federation player (race 1) wishes to form an alliance, with the levels of alliance as described above. As long as neither player takes any further action, PHOST will continue to generate the above two messages on every turn. It is important to note that the alliance HAS NOT BEEN FORMED at this stage -- it is only formed if the Rebel player also offers an alliance to the Federation. Some turns later, the Rebel player decides that he/she wishes to accept the alliance and issues a command message: a a 1 a c 1 +c The first line of the message indicates an offer of alliance to player 1. Since player 1 already has an offer of alliance submitted for player 10, the alliance will now enter the ACCEPTED state for both players. The second line shows that the Rebel player is less trusting than the Federation player since only the Combat level of alliance is enabled. After this command message is processed, the alliance between the Federation and the Rebels is now in effect. PHOST will now generate the following message to the Federation player: <<< Alliance Status Report >>> (message to Federation) Race Offered to Race Allowed by Race ---- --------------- --------------- 10 ~s ~p +m +c -v -s -p -m +c -v Since both offered-to and allowed-by columns are filled in, the Federation player now sees that the alliance with player 10 is complete. Similarly, the message generated for the Rebel player is as follows: <<< Alliance Status Report >>> (message to Rebels) Race Offered to Race Allowed by Race ---- --------------- --------------- 1 -s -p -m +c -v ~s ~p +m +c -v At this stage, the Federation and Rebel ships will never fight each other in combat. In addition, Rebel ships can fly through Federation minefields without hitting mines (along with other benefits). But since the Rebel player has not offered Ship and Planet levels of alliance (-s and -p), the conditional alliance levels offered by the Federation (~s and ~p) are not in effect. The Rebel player does not see Federation ships and planets (other than through normal, non-alliance means). On a subsequent turn, the Rebel player decides that he will trade ship information with the Federation. He enables a conditional Ship Level of alliance by sending the command processor command: a c 1 ~s Now, both the Rebel and Federation player have enabled conditional ship alliances levels to each other. On the next turn, this ship level will be enabled to both players and they will see each other's ships. The Planet Level of alliance is still disabled to both players.