The Ship Build Queue
PHOST's approach to managing the ship build queue once the 500-ship limit has been reached is consistent with its overall philosophy: empower the host to implement what he/she thinks is the best approach. Rather than trying to decide upon one best method of managing the build queue (and convincing others of its optimality) we have decided to implement a highly flexible system that allows for multiple, different approaches to the problem. The choice of which approach to use is up to the host.
PHOST 3.3c offers three strategies for managing the build queue:
Note that most of this page is still talking about the PAL system. This page needs a re-write.
The flexibility of PHOST's build queue management comes at a price, of course. There are a number of new configuration options that are used to tailor the operation of the build queue. The host who wants to fully understand all possible options is charged with reading the description of these options (and the rest of this file) and using them intelligently. The host that wants to implement a simple, pre-configured strategy is invited to use one of the sample configurations described below.
Back to the index
On any one given turn, a new ship build order (that is, one that is not already in the queue) is assigned a priority in the range 0 through 499. The first new build order that PHOST sees is assigned a priority of 499, the next is given a priority of 498, and so on. PHOST looks for new build orders by starting at a random planet number, in the range 1 through 500. PHOST then looks at each planet in sequence, wrapping around from 500 to 1, looking for new build orders.
For example, on a given turn, PHOST starts looking for new build orders at planet #253. It finds a new build order at planet (with base) #296. This build order is added to the queue with priority 499. PHOST then finds another new build order at planet #427. This is given a priority of 498. PHOST finds no more new build orders up to planet #500, but then starts looking at planet #1 and upwards, finds a new build order at planet #156 and gives it a priority of 497. PHOST stops looking for new build orders at planet #252, one planet short of where it started. The next turn, PHOST will go through the same process but will start at a different planet, chosen randomly.
Various configuration options link actions in the game (such as destroying ships in combat) to a quantity known as the Turn Activity Level (or TAL). The TAL in turn contributes to a long-term estimate of the player's activity known as the Player Activity Level (or PAL). The TAL is computed anew every turn, while the PAL has "memory". Previous activity counts towards the current PAL although previous activity points decay over time.
The TAL is used to boost priorities of ships already in the queue. The PAL is used to boost the initial priority of new ship build orders. The host implements a particular build queue management strategy by modifying the importance of each action in the game on the TAL, and indicating the importance that the TAL and PAL have in modifying ship build priorities.
Back to the index
The Player Activity Level (PAL) is a single number that summarizes the player's overall history of activity. The Turn Activity Level (TAL) is a single number that summarizes the player's activity in a single turn. The TAL is computed anew each turn while the PAL has memory (see below for the actual formulas of computation). The TAL can boost the priorities of existing build orders, while the PAL can be used to boost the initial priorities of new ship build orders.
The effect of the TAL upon existing build orders is configurable with the SBQBuildPALBoost configuration option. The effect of the PAL upon initial priorities of new build orders is configurable with the SBQNewBuildPALBoost configuration option. The PAL can be caused to decay over time so that a burst of activity does not mark the player as being highly active forever. This decay is configurable using the PALDecayPerTurn configuration option.
There are two ways in which the PAL/TAL can affect build order priorities; both were mentioned briefly above. First, the player's TAL on a given turn can be used to boost all of his existing build order priorities. This would relate a player's activity with his likelihood of building new ships. Second, a player's current PAL would be used as a one-time boost for new ship build orders. This connection prevents the punishment of players who have a long period of activity and only submit build orders after that activity has ceased. Without boosting new build orders by the PAL, the player is penalized for not having submitted his build orders earlier, when his high level of activity would have boosted them.
Back to the index
To encourage players to build only ships they really need, the SBQBoostExpX100 option allows to scale down the priority gain depending on the number of build orders a player has.
Back to the index
This is known as a FIFO (First-In-First-Out) scheme and is a natural way of managing queues of items. The SBQPointsForAging config option can be modified as desired by the host to enable, disable, or otherwise alter this feature.
Another way that a build order's priority can change is if the build order itself changes. Normally, when a build order is changed, it is placed at the back of the queue. That is, it is removed from its present queue position and treated as a new build order. This behavior can be changed, however, using the SBQBuildChangePenalty configuration option. Simply put, this configuration option indicates the number of priority points to subtract from a build order when that order changes. If this value is 0, then it means that players can change build orders without any decrease in priority! Thus, they can upgrade the quality of their ships to be built right up to the time that the build occurs. Setting SBQBuildChangePenalty to -1 is the usual case, the build order will lose all of its priority points. (This configuration option is specified as an integer, and may take negative values, but it is treated as an unsigned integer in actual usage, so that the value -1 actually is interpreted as the largest possible unsigned number). The priority of a build order is never allowed to fall below 0.
Back to the index
As an example, consider a build queue that looks like this (considering only your own build orders):
Once a build order has been reordered using an override it is not necessary to maintain this special friendly code on subsequent turns. The new order is maintained in the build queue until a different override code possibly changes the order.
The override numbers 1 through 9 are used to set a relative order, where PB1 indicates the build order to be fulfilled first. Override codes need not be used sequentially. Two bases can be set to a specific order using PB1 and PB2, or PB1 and PB5, or PB8 and PB9, for example. Bases without override codes maintain their relative order but will always appear later in the build queue than any base with an override code. If two or more bases have the same override code, the base with the higher ID will be reordered and the other base(s) will have their override codes ignored.
Note that the PBn friendly codes are considered special by PHOST and will, therefore, never match for the purposes of combat, beam-gather, etc. Note also that PB0 is not an override code and is not in any way a special friendly code.
Finally, note that the PBn friendly codes are meant to mirror the same friendly codes in the HOST programs. Since the build queue in HOST is quite different from PHOST's implementation, the PBn friendly codes serve similar functions but have different effects on build orders.
These friendly codes can be disabled using the AllowPriorityBuild configuration option.
Back to the index
|PALCombatAggressor||Points for being the aggressor in combat. Please see the "Order of Battle" page for the exact meaning of the word "aggressor". Basically, an aggressor is a ship or planet that initiates combat. This config option measures nothing but the initiation of combat (with a combat-capable ship, i.e., not a freighter). If the other ship/planet is owned by an ally (even if the combat level of alliance isn't granted) then no points are awarded.|
|PALAggressorPointsPer10KT||Points for every 10 KT of mass destroyed in combat when the ship/planet was the aggressor. These points are pro-rated for any damage to the enemy ship/planet. If the enemy ship/planet is completely destroyed, the player gets full points depending upon the mass of the enemy ship/planet. If the enemy ship/planet is brought to 40% damage before the aggressor ship is itself destroyed, then the player gets 40% of the points he would have earned had he destroyed the enemy ship/planet. Again, no points are awarded if the two combatants are allies at any level. If a planet was damaged then only the combat mass from the defense posts will affect the TAL (100kt base mass are ignored).|
|PALOpponentPointsPer10KT||Points for every 10 KT of mass destroyed in combat when the ship/planet was not the aggressor. This is the same as PALAggressorPointsPer10KT but applies when the ship/planet did not initiate the combat.|
|PALAggressorKillPointsPer10KT||Points for every 10 KT of mass destroyed in combat when the ship/planet was the aggressor. Points are only awarded when the enemy ship is destroyed and there is no pro-rating based upon partial damage. If a planet was destroyed then only the combat mass from the defense posts will affect the TAL (100kt base mass are ignored).|
|PALOpponentKillPointsPer10KT||Points for every 10 KT of mass destroyed in combat when the ship/planet was not the aggressor. This is the same as PALAggressorKillPointsPer10KT but applies when the ship/planet did not initiate the combat. If a planet was destroyed then only the combat mass from the defense posts will affect the TAL (100kt base mass are ignored).|
|PALShipMinekillPer10KT||Points for every 10 KT of mass when a ship is destroyed by a minefield hit.|
|PALCombatPlanetScaling||Determines how the mass of a planet compares to the mass of a ship for the purposes of awarding points. If this option is set to 100, damaging a planet is worth the same as damaging a ship (per KT of damage). Setting it to 50, for example, means that each 10 KT of planetary damage is only worth half as many points as ship damage.|
|PALCombatBaseScaling||Same as the PALCombatPlanetScaling option but it applies to planets with starbases in orbit.|
|PALShipCapturePer10Crew||Points for every 10 crew members killed on a ship captured in combat.|
|PALRecyclingPer10KT||Points for every 10 KT of mass for a ship that is recycled at a base or colonized at a planet.|
|PALBoardingPartyPer10Crew||Points for every 10 crew members on a ship that was boarded and captured using the Privateer or Crystal boarding party mission. No points are awarded if the boarded ship's owner is an ally (at any level) of the boarding player.|
|PALGroundAttackPer100Clans||Points for every 100 clans killed using a standard ground attack (not including Imperial Assault). These points are automatically multiplied by the defending race's ground defense bonus and divided by the attacking race's ground attack bonus. The attacking player need not completely remove the defender's clans from the planet to acquire points. The defending player receives no points. No points are awarded if the planet is owned by an ally (at any level) of the ship's owner.|
|PALGloryDevice||Points for every glory device that is detonated. Only the player who owned the ship with the glory device receives points.|
|PALGloryDevicePer10KT||Points for every glory device that is detonated, related to the mass of the ship that exploded. Using this option, you can give more points for blowing up a heavy ship than for a small one. Only the player who owned the ship with the glory device receives points.|
|PALGloryDamagePer10KT||Points for every 10 KT of enemy ship mass damaged as a result of a glory device explosion. Partial damage results in partial score awarded: damaging a ship by 20% gives you 20% the nominal points. Same-race and allied ships are not credited.|
|PALGloryKillPer10KT||Points for every 10 KT of enemy ship mass killed as a result of a glory device explosion. If you damage a ship far enough that it explodes, you receive these points in addition to the normal PALGloryDamagePer10KT points. Same-race and allied ships are not credited.|
|PALImperialAssault||Points for performing an Imperial Assault mission. No points are awarded for planets belonging to allies (of any level).|
|PALRGA||Points for performing a Rebel Ground Attack mission on an enemy planet. Same-race, unowned, and allied planets are not credited.|
|PALPillage||Points for performing a Pillage mission on an enemy planet. Same-race, unowned, and allied planets are not credited.|
|PALIncludesESB||If enabled, the PALAggressorPointsPer10KT, PALOpponentPointsPer10KT, PALOpponentKillPointsPer10KT, and PALAggressorKillPointsPer10KT options use the combat mass, including possible bonuses (Engine Shield Bonus, Fed Crew Bonus), for the computation. If disabled, these computations use the plain ship mass without bonuses.|
PALPlayerRate = 0 SBQPointsForAging = 500 SBQBuildChangePenalty = -1All other configuration settings (for build queue management) may be ignored. Ship build orders that are modified while in the queue are sent to the back of the queue.
Alternatively, just set BuildQueue to FIFO, see below.
SBQBuildPALBoost = 10 SBQNewBuildPALBoost = 10 SBQPointsForAging = 500 SBQBuildChangePenalty = 2147483647 # =2^31-1, can also be written simply as -1 SBQBoostExpX100 = 0 PALDecayPerTurn = 10 PALPlayerRate = 100 PALCombatAggressor = 1 PALAggressorPointsPer10KT = 10 PALOpponentPointsPer10KT = 8 PALAggressorKillPointsPer10KT = 5 PALOpponentKillPointsPer10KT = 3 PALCombatPlanetScaling = 100 PALCombatBaseScaling = 100 PALShipCapturePer10Crew = 5 PALRecyclingPer10KT = 1 PALBoardingPartyPer10Crew = 3 PALGroundAttackPer100Clans = 4 PALGloryDevice = 5 PALGloryDamagePer10KT = 2 PALImperialAssault = 5 PALRGA = 5 PALPillage = 5Back to the index
The FIFO system is simple: Build orders are performed in the order of their submission. Each turn, PHOST starts at a random starbase collecting build orders and pushing them on the queue.
When you want to use the FIFO system, all you need to do is to set BuildQueue = FIFO in pconfig.src. The other options are ignored in this mode (but must still be present right now).
For ship lists (such as PLIST) in which each player's top ships are comparable in combat, a FIFO strategy is a very good choice (and a lot less complex).Back to the index
The PBP system is similar to the build queue system in HOST. The basic idea behind it is that players can collect PALs resp. Priority Build Points, and later trade those points for ships.
When this system is used, players must decide which ships are important to them, and mark these as priority builds. This is done by giving the associated starbase a PBx friendly code. Each player can designate up to 9 priority builds this way (because there are nine PBx fcodes, that is. If you use one code twice, only one of them is accepted, so don't do that). As usual, PB1 is most important, PB2 second-most, etc.
When there is a free ship slot to fill, the player with the most PBPs can perform his most important build order. If he has no priority build (or all his priority builds were already performed), or his PBPs do not suffice to do the build (see below), tough luck: then, the player with second-most PBPs is allowed to fill that slot. And so on. When no priority build can be performed, the normal FIFO system is used.
Building ships costs PBPs, the heavier the ship, the more PBPs it costs. The PBPCostPer100KT option defines how many PBPs you need to build a 100 KT ship. There is a minimum cost, however: PBPMinimumCost. If the build order was a clone order, it costs even more PBPs; the PBPCloneCostRate can be used to scale this up.
An example probably helps to understand this. This example configuration can also be found in pconfig5.src:
BuildQueue = PBP AllowPriorityBuild = Yes
This enables the PBP system, and the PBx friendly codes. You should usually enable PBx here, but it makes sense to turn them off for the first so-and-so turns. Like HOST which does not perform priority builds until there are at least 450 ships in the game. Just remember to turn it on when the time is right.
PBPCostPer100KT = 200 PBPMinimumCost = 400 PBPCloneCostRate = 200
Assume you want to build a 150 KT ship. This would cost you 150*200% = 300 PBPs. Since the minimum cost is 400, that build will cost you 400 PBPs. If it were a clone, it would cost twice as much (400*200% = 800 PBPs).
Okay, and where do these PBPs come from? PBPs are good ol' PALs. And the PAL settings define how you get them. The suggested settings are
PALDecayPerTurn = 0 PALPlayerRate = 100 PALCombatAggressor = 0 PALAggressorPointsPer10KT = 2 PALOpponentPointsPer10KT = 2 PALAggressorKillPointsPer10KT = 8 PALOpponentKillPointsPer10KT = 8 PALShipMinekillPer10KT = 0 PALCombatPlanetScaling = 100 PALCombatBaseScaling = 150 # destroying a base gets more points PALShipCapturePer10Crew = 0 PALRecyclingPer10KT = 10 PALBoardingPartyPer10Crew = 0 PALGroundAttackPer100Clans = 0 PALGloryDevice = 125 # Saber: 153, D19b: 96 PALGloryDamagePer10KT = 10 PALImperialAssault = 0 PALRGA = 0 PALPillage = 0
The basic idea is that destroying 1 KT mass gets you one point, building 1 KT costs you two points. Some actions do not contribute to ship destruction aka freeing ship slots; these should not be awarded points. But that's up to you; you could, for example, also have a PBP decay if you wish.
For a more elaborate description of the PBP system, see the PBP page at The Vagabund, which is the basis of this new build queue system.Back to the index