There have been substantial changes to the way DCA is planned in R2.0. There used to be several planning options: Specified, Dynamic, Scramble Only, Inactive.

Specified: The user specifies the coverage for the zone in terms of timeframe, preferred platform, and the SCL the platform will use. While it provides greater user control, it comes with some limitations:

• If the Flight has endurance beyond what is specified for that time period, it will only be planned for the specified period (ex. if 2 hours are specified for the coverage, a Flight with 3 hours loiter will only be planned for 2 hours coverage).
• Planning code allows “partial coverage”, meaning that if best Flight can only fill the orbit for 80% of the period, that’s better than none, so it will be planned to fill the 80%. Remember, though, the last 20% will go unfilled; no other Flights will be planned for the remainder.
• If none of the preferred platforms or SCLs are available, no orbit coverage will be planned.
• Start Times & End Times can be in decimals; it used to only allow integers.

Dynamic: This allowed user to allow the planning process to do much of the planning automatically. The “planning” was actually done during execution: When a Flight launched to fill an orbit, the Sector Controller knew when that Flight would depart the orbit based on fuel, and scheduled the next subsequent Flight to fill the orbit (using Alert 2 aircraft). This was generally a pretty easy way to schedule DCA, but was limited, since if a Flight accepted a vector (and consumed its fuel and/or munitions), the Sector Controller would only fill the orbit before the next scheduled arrival if needed to intercept an enemy Flight. Additionally, since dynamically-planned sorties and the Alert 2 sorties were drawn from the same “bin”, it was very difficult for users to manage the appropriate bin size.

Scramble Only: The Sector Controller will launch Alert 1 Flights, and vector them to intercept an enemy Flight in the zone only when needed.

Inactive: Self-explanatory.

Effective with the R2.0 release, Dynamic planning was replaced with Block planning. What’s the difference?

Block: This is truly planning, in the sense that it is conducted during the planning phase, rather than during execution. Users define a period during which they want the orbit to be filled (ex. 01 - 01 or 08 - 20), and the planning process schedules Flights to fill the DCA orbits by scheduling Flights for however long they can stay on the orbit (limited by fuel), placing Flights back-to-back to fill the entire Block of time. Since these Flights are planned, their planned orbit times & TOT are provided in the Flight Plan and ATO Gen instruments (previously, Alert 2 sorties filling a dynamic orbit showed TOTs and Launch times of 0).

Users will see some Flights scheduled for non-“round” orbit times (ex. 2:12 or 0:53). These times are determined by each Flights’ endurance. Occasionally, very late during its orbit time, a Flight may not be able to accept a vector to an intercept if it doesn’t have the fuel available to (a) conduct the intercept, (b) make it to the anchor for refueling on the way home, or © make it home (if no AR is available). One technique the user has (to prevent lost intercept opportunities) is Max Orbit Duration; this will ensure that a Flight will only be assigned to that orbit for a limited time, and should plan to depart with enough fuel to do an intercept late in its orbit if necessary. Likewise, the Min Orbit Duration allows the user to prevent a Flight from flying great distances to spend only a few minutes at the orbit, when there may be air units closer by which could fill the orbit instead. Note: If an orbit has min and max orbit times as 0, then it will not be planned to be filled.

• Depending on circumstances (geography, speeds, launch blocks, etc), there can be gaps in block coverage. To help compensate for gaps, the planning process will try to “insert” another Flight into the gap without violating any of the min/max orbit duration and launch block constraints. For example, if the min and max orbit durations are 1 and 3 hours respectively, but there’s a 0.5 hour gap in coverage, a min duration orbit can’t fit in the gap, but it could if the previous orbit was reduced by 0.5--so long as it doesn’t reduce it to less than 1.0. This process will only slip the landing time of the previous orbit earlier; it will not delay the launch time of the succeeding orbit, since that may violate a launch block constraint. Ex:

Some features were added to the Block planning with the intent of making it easier for the user. Users are required to provide only a limited amount of data:

Block Period: The coverage timeframe for the orbit to be filled (usually a 24 hour span).

Orbit Durations: As described above.

Preferred Platforms: If platforms are listed, they will be prioritized in the order listed. If not, it will be assumed that the user, having made the effort to define the zone, block periods and orbit durations, wished for the orbit to be filled and either forgot to list preferred platforms or wished to allow the planning process to prioritize. In this case, the orbit will be planned using any available platform (prioritized by distance from the orbit).

Note: To “turn off” planning for a zone, select “Inactive” coverage.

SCL: Using the same approach, if the user listed SCLs, they will be planned in that priority. If not, then the planning process will refer to the Weapon System Priority (WSP) list for DCA (which used to be referenced only while planning DCA alert) to determine which SCL to use. Finally, if there is no WSP listed for DCA, then SCLs will be attempted to be planned in the order they are listed in the platform’s SCL configuration list (using only SCLs which contain AA munitions).