New in v1.07: Scenario Attachments (a.k.a. auto-bundling)

February 16, 2015 · Posted in Command · Comment

Ever since Command’s initial release, the players have been asking us for an automated, reasonably idiot-proof way of bundling various content items (primarily map overlays but also other types) together with their scenarios and have them referenced correctly regardless of the scen file’s actual location.

Scenario Attachments, a.k.a. auto-bundling, is our response to this request. It is one of the flagship new features of the v1.07 update.

Scenario attachments are “things” (anything from a single file to a massive directory tree) that you can provide as attachments to a scenario (similar to attaching a file to an email message) and then use them via a new Lua command “ScenEdit_UseAttachment”. What exactly happens when you use them obviously depends on the attachment type. When a scenario packaged with attachments is loaded, its attachments are transparently copied to the local repository and can then be re-used on any other scenario (much like .inst files). The use of a single-point repository solves the “I moved my scen file around and now it cannot find its attachments” problem (this may be familiar to anyone who moves saved web pages around in the file system without their accompanied images etc.).

Here is a concrete example:

a) Author-A constructs a scenario and wishes to enrich it with imagery of an area. From the “Editor” menu, he selects “Scenario Attachments”. This brings up a window listing the attachments currently associated with the scenario:

Here we see we can construct a new attachment, use an existing one or modify (rename/delete) any already on the repository. Clicking on the “Create new of type: […]” will prompt us to locate the source material for the attachment, in this case a geo-referenced image file (map overlay). Clicking on “use existing” brings up another window which lists all attachments already available on the local repository:

Selecting the desired attachment and clicking on “Use selected” will add the attachment to the scenario.

We can then select, from the “Editor” menu, the command “Package scenario for distribution”. A file-dialog will pop up to prompt us for where to save the packaged scenario file. The “packaging” is essentially the process of properly bundling the scenario with the selected attachments on a single zip file, so that they can be correctly identified and loaded (automatically) by end users.

Author-A then distributes the bundled scenario as usual. User-A unzips the bundle file to “\Scenarios” (or anywhere else) and loads up the scenario. Under the hood, the program sees the unzipped “attachments” folder side-by-side with the scenario file and automatically copies the attachments (each one on its dedicated folder, uniquely identified with a GUID) to the user’s local repository.

To use a referenced attachment, you can use the new Lua command “ScenEdit_UseAttachment”, which accepts either an attachment’s name or its GUID. So in this case, by bundling an image overlay to a scenario and creating an “on scen load” event that triggers its use, we can display map-overlay images to the end user without any manual action of his own.

Of course this infrastructure is meant to eventually exploit multiple attachment types, ranging from media files (audio, video etc.) to pre-fab Lua scripts, arbitrary text or binary files etc.

Tags: no tags

New in v1.07: Mission Editor 2.0

February 14, 2015 · Posted in Command · Comment

Command v1.04 introduced the auto-planner for strike missions, and the upcoming v1.07 update vastly expands on this. The new & improved functionality is a major step on the path to making an advanced strike planner with player-generated flightplans, TOT planning, and other features.

Key Mission Editor 2.0 improvements are:

– Automatically generated flightplans for strike missions, including target and Initial Point (IP) waypoints.
– Detailed fuel planning, including tanker support.
– Ability to specify flight sizes (group size).
– Expanded escort functionality.
– Ability to limit air strikes to only flying once, or stop flying when the number of strike aircraft or escorts reach a certain threshold due to losses.
– Ability to automatically generate flight plans for aircraft already airborne.
– Separate Doctrine, EMCON (EMission Control) and WRA (Weapon Release Authority) settings for the strike (main body) element and escorts, allowing different Rules of Engagement (RoE), sensor usage and weapon employment.
– A plethora of new settings for most mission types.
– The editor window has been made resizable.

It should be noted that although the flightplans are automatically generated prior to take-off, they cannot be edited by the player prior to take-off quite yet (they can be fully edited once the first aircraft takes off). This functionality will be added in baby-steps in subsequent releases (1.08/1.09/1.10/1.XX), and will use the new AI-generated ‘skeleton flightplans’ as a starting point for player-generated strike plans. Click on the screenshots to the left for a full-view example of the new auto-generated flightplans.

In addition to the improved strike mission functionality, all other mission types have been given various new features as well. The player can configure flight sizes, transit and station altitude & throttle settings, the minimum number of aircraft needed to trigger the mission, etc. Another noteworthy addition is the new page for strike mission escorts that allows the user to define escort behaviour in greater detail.

Strike mission additions

Here is a short overview of some of the new functionality introduced in Command 1.07. Click on the screenshot below for a full view.

Flight Size: Allows the player to specify the flight size (group size) for the assigned aircraft. Typically, strike aircraft fly in groups of four or six, bombers in cells of three, fighters always operate in pairs, and maritime patrol aircraft generally fly alone. In addition, the user may check the ‘Aircraft numbers below Flight Size do not take off’ flag to ensure that the mission enforces group sizes and do not order aircraft to launch unless there are enough aircraft to satisfy the minimum requirements. So for instance if there are three aircraft assigned to a mission, minimum flight size is four, and flight size restriction option has been selected, the aircraft will not launch.

It should be noted that flight size limitations are on a per-base/ship, aircraft type and loadout basis, as flights are formed using aircraft from the same ship/base, aircraft type and loadout. As such, even when there may theoretically be enough aircraft to execute the mission, should the units be spread across several air bases and using varying loadouts, the mission planner may not be able to assemble enough aircraft to fill a flight.

Mission Fuel: How much reserve fuel shall the mission planner calculate with? In case we’re expecting to bring heavy ordnance back to base then the mission planner needs to assume higher fuel burn rates from the target area to base. This will in turn reduce maximum strike radius. The players have the option to manually select which fuel plan to use, with the standard configuration being the loadout’s default setting. In most cases, strike loadouts assume ordnance is dropped at max radius.

Minimum number of ready strike a/c required to trigger mission: In some cases it makes sense to halt strike operations when losses have reached a certain level. This setting allows the player to set the minimum number of aircraft that must be available for the mission to launch. For instance, a Tu-22M-2 Backfire regiment can be configured to continue strike operations for as long as it can muster 4 flights of 3 aircraft each, i.e. 12 aircraft total.

Maximum number of strike a/c allowed to fly missions: There are instances where it would make sense to keep strike packages on a certain size, and add additional aircraft for reserve to replace potential losses. For example, a Tu-22M-2 Backfire regiment can assign 21 aircraft to the mission, but maximum 6 flights of 3 aircraft each will actually fly, 18 total.

Minimum strike radius (minimum distance to target): Do not attack targets closer than the given distance, in nautical miles.

Maximum strike radius (maximum distance to target): This value overrides the loadout’s maximum strike radius (in nautical miles). In some cases it is desirable to limit 800-nm range A-6E Intruders to only strike targets out to a range of maximum 500nm due to escort range concerns. Or, if air-to-air refuelling is available, limit strikes to 700nm because there aren’t enough tanker capability to mount effective strikes beyond that range.

Radar useage: Anti-ship strikes should be flown under strict EMCON to delay detection, but often the aircraft need to update target positions prior to weapon launch. This setting allows the aircraft to go active at the ingress attack waypoint or Initial Point (IP) point, locate targets, fire missiles, turn off radars, and head back to base under EMCON.

Tankers: This option allows or denies the use of air-to-air refuelling when the strike planner determines maximum radius. In many cases it makes sense to mainly rely on internal fuel, even if tankers are available, as the overall tanker capacity is too small to support larger strike operations. It should be noted that this is the same setting as ‘Aerial refuelling’ in the Doctrine window, and was added to the Mission window for easy access.

Aircraft numbers below Flight Size do not take off: When set, this flag only allows fully assembled flights to take off. If the flight size is four aircraft, and only three are available, they will not be allowed to launch. It is strongly recommended to use this flag for most missions to produce real-life behaviour. You do not normally want single fighters to take on intercepts, strike, or patrol missions all by themselves, as they will find themselves at a huge tactical disadvantage. The minimum number for fighters, attack aircraft and bombers should therefore never be lower than two. For strike, four aircraft is most common.

Allow off-angle attack (‘Auto-Planner’): This is basically the old ‘Auto-Planner’ that allows aircraft to attack targets off-angle if the loadout has attack ingress & egress legs. The maximum off-angle figure depends on the maximum range of the weapon. Furthermore, iron bombs, rockets and other short-range weapons assume the aircraft will have to overfly the target to deliver weapons and have the egress route on the opposite side of the target. Stand-off weapons (range greater than 6nm) will drop weapons at max range and then exit the target area using the same route as they came in.

One time only: As the name implies, missions can be limited to one single strike only. There are many cases where this setting is useful, especially in historical scenarios and scenarios of extra long duration.

Strike mission escorts

The new Escorts tab has many of the same options as strike missions. An important difference is that the pane is split in two; the upper part is for configuring armed escorts such as Suppression of Enemy Air Defences (SEAD) or fighters, while the lower part is for non-shooting escorts such as electronic warfare (EW), airborne early warning (AEW) or recon. The lower section allows non-shooting aircraft to fly singly, where as shooters typically fly in flights of two. The escort tab also has special settings not used by other mission types:

Maximum threat response radius: This is the maximum range (in nautical miles) that escorts may respond to threats. In high-threat environments it is usually not desirable to have the SEAD or fighter escorts leave the strike package to deal with the first enemy fire-control radar or air contact detected. It is better to save these assets until the strike package is directly threatened, and the player can specify the radius manually.

Example 1: Tu-16 Badger strike on naval group

It is 1979 and six Tu-16s Badgers of the Soviet Red Banner Northern Fleet have been ordered to strike a small US amphibious group as part of a limited air and naval operation in the Norwegian Sea. The aircraft are each armed with one under-belly AS-2 Kipper anti-ship missile, and have been assigned to an anti-ship strike mission along with two Tu-16 Badger J stand-off jammers for escort. The bombers will fly in a single group of six aircraft (although we could have used two cells of three aircraft instead). For a detailed view of the mission setup including escort configuration, see the screenshots above.

A Tu-16 Badger D recon aircraft spots the NATO ships off the coast of Norway and radios the location to base. A few minutes later, the naval bombers launch and proceed towards the target. As per mission settings, the aircraft fly in a group of six, and has two jammers for escort. The mission planner automatically generates a flightplan around the No-Navigation Zone covering the Norwegian mainland (red zone), using a buffer of 0.2 angular degrees which translates to 12nm at equator and approximately 4nm on Kola.

In this case the mission planner plots straight across the No-Navigation Zone from the target waypoint to the first egress waypoint. This may look odd. But keep in mind that the weapons will be released at the IP point. Since the aircraft use stand-off weapons they will not actually overfly the target waypoint, but instead head for the first egress waypoint. It should also be noted that, since the strike planner had to navigate around a threat zone it ignores the ‘Auto-Planner’ flag, and uses the same target ingress and egress route.

The mission has been configured to use active radar on final approach to the target, starting at the ‘Attack Ingress’ waypoint. Here, the aircraft have also been ordered to full military throttle at 36 000 ft altitude. The waypoint orders are automatically filled in by the mission planner so the aircraft follow the flight profile specified by the loadout. Note the contact age of the ships, they were last seen ca 45 minutes ago and the Tu-16s are now actively searching for them. The Weapon Release Authority (WRA) has been configured to use all weapons against the first target detected, and soon after six missiles are on their way. When the weapons have been fired the Tu-16s call Winchester, turn off their radars and head for the first egress waypoint.

The US Navy frigate USS Talbot puts up a heoric defence but it’s single-arm Mk22 launcher and single target illuminator isn’t able to deal effectively with the threat. One anti-ship missile is shot down, two are decoyed by chaff, one malfunctions, and two score direct hits on amphibious transport USS Ogden. The ship sinks in a matter of minutes. Mission accomplished.

Example 2: Starfighter strike on Soviet SAG

At Bodo air base in Northern Norway, six F-104G strike-fighters of 334 Squadron have been readied with AGM-12 Bullpup missiles to deal with a Soviet Surface Action Group (SAG) in the Norwegian Sea. In 1979 the Royal Norwegian Air Force operated several Starfighter squadrons, and one of these specialized in anti-invasion anti-shipping strikes using licence-produced Bullpup missiles. Note that the max strike radius for this loadout is 375nm with the given flight profile. Another important point is that the mission’s target is the Kynda-class cruiser Varyag, however we’ve unchecked the ‘Pre-Planned Targets Only’ flag so the aircraft will proceed to attack other ships if Varyag is sunk.

The mission’s Weapon Release Authority (WRA) has been set up to use all weapons against one target at a time, which ensures the Starfighters concentrate their fire on one ship. The doctrine has been configured to not use guns (new option in 1.07) against the ships , and the Starfighters will just launch the missiles and get out!

The mission is configured to attack in flights of two aircraft (lead and wingman), use radar to locate targets, and never allow aircraft to take off in flights smaller than two aircraft. Lastly, we request the automatic strike planner to attempt to generate off-angle flightplans so that the aircraft will approach from different (random) directions. Note that off-angle attacks are not possible at maximum range as there is only enough fuel to reach the target flying in a straight line.

The strike planner takes about one minute to generate the flight plan and the aircraft launch soon after. Note that each flight has its own flightplan, and will approach the target using different routes. The waypoints along the route are automatically configured with correct altitude and speed settings as specified by the loadout’s flight profile. Since the Starfighters are armed with stand-off weapons they will release these at maximum range and attempt to exit the target area on the same axis as they came in. When armed with shorter-range weapons with a maximum range less than 6nm, they will overfly the target and follow a different egress route.

The first flight passes the ingress attack waypoint, adjusts altitude to 300ft above the waves, and turns on radar to help locate the targets. The primary target, the Kynda-class missile cruiser Varyag, is at the center of the surface group.

Flight lead eats a SAM but his wingman (now promoted to lead) successfully evades and manages to score one near miss (weapon impacts the sea 31 feet from the target, causing considerable blast damage) and one direct hit on the cruiser. The Starfighter is shot down by a wall of 30mm fire soon after. Guess we now know why NATO began developing stand-off anti-ship missiles to deal with these highly potent (by 1970s standards, anyway) Soviet AAW ships.

The last two flights are closing in on the target, firing a total of six Bullpups and scoring several more hits on the cruiser, sinking it. One of the four Starfighters is hit by SAMs before reaching launch parameters, and two more are hit by SAMs and gunfire as they come off the target.

The sole surviving Starfighter heads for home, having dodged several more SA-N-1s. Thanks to low altitude and high speed, the fighter quickly exits the Soviet SAM envelope. Mission accomplished, but five out of six fighters were lost in the process.

Tags: no tags