The new features of Chains Of War: Aircraft Damage

April 27, 2017 · Posted in Command · Comment

The “Release Candidate” (ie. public beta) phase of the v1.12 update (the companion to the upcoming “Chains Of War” DLC pack) continues steadily on the MatrixGames forum. The feedback on the new additions like the new 2x time compression step and much improved 4K/UHD support has been overwhelmingly positive, and the new sonar masking feature has also been well received. Chains of War, however, will introduce a number of major new features with significant effects on scenario design and gameplay. We already had a look at communications disruption. Today we are looking at another significant enhancement, aircraft damage.

Getting back home – in one or more pieces

– The other problem is that the A-10 is vulnerable to hits because its speed is limited […]. We had a lot of A-10s take a lot of ground fire hits. Quite frankly, we pulled the A-10s back from going up around the Republican Guard and kept them on Iraq’s [less formidable] front-line units. That’s fine if you have a force that allows you to do that. In this case, we had F-16s to go after the Republican Guard.

– At what point did you do that?

– I think I had fourteen airplanes sitting on the ramp having battle damage repaired, and I lost two A- 10s in one day [February 15], and I said, “I’ve had enough of this…”

(Interview of Chuck Horner to Air Force Magazine, June 1991)

Comprehensive aircraft damage modeling, while well-modelled on most combat flight simulators, is something of a rare appearance on grand-tactical, operational or strategic-level simulations and wargames, for a number of reasons. Command, following the paradigm of numerous other similar titles before it, started with the simple binary “100% healthy until shot down” model for aircraft. It has always, however, been our intention to do something more comprehensive. With v1.12 we are taking a significant step forward in this regard.

When the “Aircraft Damage” feature is enabled on a scenario (it is “off” by default in order to avoid disrupting existing scenarios), aircraft are evaluated for specific damage when hit by a weapon. Each aircraft now has a damage-point value representing its fundamental structural tolerance (similar to ships, subs and land units & facilities) plus three distinct armor levels – for cockpit, fuselage and engines. When a weapon impacts the aircraft, the damage is applied to the overall structure and in addition the chance of penetration is evaluated against each armor level. Each penetration probability is obviously dependent on the armor level and the nature and severity of the weapon warhead (e.g. penetrating rounds have a better chance than impact-explosive ones), but geometry factors are also taken into account; for example a cockpit hit is far more probable if the weapon impacts in the frontal quarter, engine hits are most common in rear-quarter impacts, while the fuselage is most vulnerable to side hits.

This Fulcrum driver is having a rather bad day

Similar to other platform types, when immediate damage is sustained, secondary fires can also erupt. The aircraft crew will attempt to suppress those every 5 seconds. The fire burns through the aircraft fuselage quite rapidly, causing structural damage, and if it evolves to conflagration can even cause a fuel explosion, destroying the aircraft (few things are as infuriating as blowing up from uncontrollable fire just as you are on final approach to land…). Critical hits from penetration are also possible; if the cockpit is compromised the aircraft is immediately out of control and destroyed, whereas a critical hit to an engine will damage or destroy it (for single-engine aircraft this has rather unpleasant consequences). Aircraft with at least one operational engine can still limp back home but all their kinematic properties are negatively affected. A plane with more than 80% structural damage will disintegrate in mid-air.

Because the existing armor levels were geared mostly towards surface & land targets (the smallest amount of armor being 40mm RHA equivalent), we also had to add several lesser armor levels in order to properly differentiate the differences in armor commonly found on aircraft. The revised armor levels are:

None (Human flesh, unarmored aircraft etc.)
Armor – Handgun (Human body armor or equivalent – can stop a handgun/pistol round)
Armor – Rifle (human body armor or equivalent – can stop a rifle or LMG round (5.56 / 7.62mm etc.))
Armor – HMG (can stop a heavy machine gun or heavy sniper rifle round (12.7 / 14.5mm etc.))
RHA – 20mm (20mm RHA – can stop a 20mm AP round)
RHA – 25mm (25mm RHA – can stop a 25mm AP round)
RHA – 30mm (30mm RHA – can stop a 30mm AP round)
RHA – 35mm (35mm RHA – can stop a 35mm AP round)
Light (41-90mm RHA – as before)
Medium (91-140mm RHA – as before)
Heavy (141-200mm RHA – as before)
Special (201+ mm RHA – as before)

The topmost armor levels will naturally have to be revised in the future as we [ REDACTED ].

Aircraft are also assigned “damage tolerance” levels before they abort/RTB. For fighter and attack aircraft this is set to 30%, for CAS aircraft 50%, and for all other aircraft to 10%. Once this threshold is exceeded, the aircraft breaks off and attempts to RTB. The player can of course issue an RTB order before this level is exceeded. Damaged aircraft will jettison their heavy stores when RTBing due to damage (regardless of the “Jettison stores under attack” doctrine setting).

Down for repairs

Damaged aircraft that manage to return to their base are not “magically” restored; they need an extensive amount of time to be repaired. The so-called “Estimated Time To Commission” (ETIC) value is calculated based on the extend and types of damage and may range from a few additional hours to entire days or even weeks. Obviously, depending on the duration of the scenario, this may mean that an aircraft is effectively out of the fight (On the Professional Edition, the method for calculating the ETIC is far more extensible and can use private customer data). The estimate for the repair time is communicated to the player through the message log, for example: “Aircraft-X (class Y) has damage that requires an estimated time-Z to restore. The repair time will be added to the aircraft’s ready-time.”

Developing and testing the improved damage model for aircraft has been a lot of fun for the dev & beta teams. There are cases where the differences in combat resolution are not significant; for example heavy AAMs or SAMs will take down a small aircraft, no ifs and buts. On the other hand, with light-caliber AAA or missiles with small warheads (Stinger, AIM-9 etc.) and particularly against large or well-armored aircraft the effect is quite dramatic. We were never comfortable with the fact that a single Stinger or machine-gun burst could bring down a B-52 with a lucky hit; this is now rectified.

Another factor (and a significant “last straw” in making us not delay this feature any longer) is the gradual service introduction of high-energy lasers. By their nature, these are currently not powerful enough to take down an aircraft (or in fact even large drones) with a single burst; concentrated or consistent fire is necessary (oddly, this is reminiscent of gunfire-vs-aircraft in WW2). The improved AC damage model is ideal for modeling this peculiarity which will probably last for at least the near future.

May your battle damage repairs never keep you down for long!

Tags: no tags

Red Phoenix, Team Carney and some fixes: Community scenario pack updated

April 20, 2017 · Posted in Command · Comment

Sometimes this happens too.

The last major update of the Community Scenario Pack contained some scenarios that had been erroneously rebuilt to the latest database versions and, as a result, produced a crash when loaded. The problem was located in the rebuild code and fixed, and Miguel Molina has correctly rebuilt the problematic scenarios.

In addition, two new community scenarios have been included to the refreshed pack:

Red Phoenix – Christmas Day, 1986: North Korea has decided to try and complete the re-unification of the peninsula, by force. Kunsan AFB has already been hit by MiG-23s and sustained damage. The main raid is only minutes away. Take your F-16s to the skies and defend your airbase!
Team Carney, 2019: A variety of minor conflicts have erupted around the world. The United States and its allies have responded by creating a number of “joint response forces” that will operate under the leadership of America’s various Unified Combatant Commands. In this scenario, USAFRICOM and allied forces are called upon to protect commercial shipping from a sudden increase in rebel-sponsored piracy and terror attacks off the coast of Western Sahara.

As always, the community scenario pack is available for download from the Command downloads page: http://www.warfaresims.com/?page_id=1876 . The new & updated scenarios will also become available for download later on the Command workshop on Steam.

Tags: no tags

The new features of Chains Of War: Communications disruption

April 15, 2017 · Posted in Command · Comment

The first few “Release Candidate” (ie. public beta) builds of the v1.12 update (the companion to the upcoming “Chains Of War” DLC pack) have began being distributed on the MatrixGames forum and we’re happy to say the feedback so far has been very encouraging. Additions like the new 2x time compression step and much improved 4K/UHD support have long been favorite requests and it is good to see them well received. Chains of War, however, will introduce a number of major new features with significant effects on scenario design and gameplay. Today we are looking at one of them; communications disruption.

Static on the radio

Most wargames and simulations accustom their users to the idea of omnipresent, instant, always-on communications. The battle may be lost – your forces & assets may be in disarray – but you are always in control of them and aware of their whereabouts, activities and condition. You are always in the know and in power. The pawns in the chessboard are always at your disposal.

But what happens when the lights go out? When the only thing on the radio is static? When the datalink is dead?

This is fast becoming an ever-important question, both because the western armed forces are increasing their reliance on distributed, hyper-connected force concepts (the F-35 and the US Navy’s NIFC-CA being fine examples) and because potential peer competitors, fully aware of this trend, are rapidly improving their electronic attack and cyber-warfare capabilities. The ever-evolving chess game of electronic warfare has never been limited to the radar bands, but more recently communications and datalinks are becoming increasingly appealing targets.

Beginning with v1.12, Command makes a bold step forward in exploring this domain. We want to show players both the “how” and the “why” of communication lines breaking, and the practical effects of units being isolated from their parent side’s common picture.

Causes…

A unit can have its communications disrupted in a number of ways:

If all its onboard comm devices and datalinks become non-operational (damaged or destroyed):

This frigate is about to become very lonely

Through the Lua scripting API: As an example: ScenEdit_SetUnit({Name=”USS Vigilant”, OutOfComms=”True”}). This is a very versatile technique as it can be used to model any number of factors, both man-made and natural, that can cause a unit to go “off-grid”:
- A submarine hooking up to HF or satellite communications when it goes to periscope depth, and breaking contact again when it submerges.
- A satellite linking only temporarily with its ground station to dump its intelligence product and receive new tasking instructions, then again going in isolation in space (contrary to popular fiction, even modern intelligence satellites are rarely, if ever, in constant link with their ground control stations).
- A cyber attack directed at the internal comms infrastructure of the targeted platform. (Your comm devices may be physically untouched, but the server at the core of the comms exchange just got taken over. Tough world! Chains Of War has strong examples of this.)
- Physical incapacitation (damage/destruction) of a critical C3I node leading to other units dependent on it going offline (remember that many of the first-night targets in Desert Storm were headquarters, C3 bunkers and comm buildings? You can now recreate why this was a critical action).
Through the scenario editor GUI, by selecting the unit and marking it as “out of comms”:
This is less powerful than using the Lua API but a simpler and faster way for quick setups. So for example you may use this to configure a unit to be “off grid” at the start of a scenario, and follow-up with a Lua script depending on some later action that changes this unit’s connectivity.
By jamming its comm devices, using communications jamming equipment similar to existing OECM systems. [NOTE: Integrated comms-jamming is a feature reserved for the Professional Edition. However, with a bit of creative work you can use the Lua API to approximate this in the commercial version of Command.]

…and Effects

So what are the results of a unit going “off-grid”?

The most obvious effect is that the unit is no longer under your positive control. You no longer know where it is currently located (you only know where it was when it last checked-in, and if any of your other still-connected assets manages to make contact with it, this “last datum” is updated). You don’t know what it is doing, what its fuel, weapons or damage status is. You don’t know if it is peacefully loitering with not a care in the world or if it is fighting for its life. You will know its fate with certainty only when it comes back to its base – or is destroyed first.

“Last we heard from Garry he was somewhere there… and that’s all we know.”

For its part, the cut-off unit loses all the benefits of the common side-wide operational picture; its situational awareness now reaches out just to the limit of its own sensors and no further. It has no idea what is going on “out there”. It can still detect, investigate and prosecute contacts on its own and proceed with its assigned mission if it has one, but all the benefits of mutual support are gone. Cooperatively patrolling a large area to split up areas? Nope. Efficient fire coordination? (“You shoot bandit #1 and I’ll take #2”) Forget about it. Even worse, it now has to be really careful with anything that shows up on the scope. Is that new contact a friendly or an enemy? You’d better hope its RoE and doctrine settings take such a situation into account – or prepare for blue-on-blues!

Meanwhile, Garry is now alone and trying to adjust to the sudden loss of SA from the nearby AWACS. Notice the only contact still “fresh” is the one that the F-15 is actually detecting on its own; the other contacts, hitherto provided by the E-3, are now deteriorating fast.

Units that lose their comms connectivity retain local copies of the contacts that were available to them before they went offline; essentially they inherit a snapshot of their parent side’s theater picture at the moment of their breakaway. However, without the benefit of information exchange with their parent network, this snapshot immediately starts to lose its currency and most of the contacts will soon vanish unless refreshed by the unit’s own sensors. (It’s like walking down a busy street, taking a last look around and closing your eyes. The longer you remain blind, the less relevant & useful your last memory will become.)

Units that manage to get through their “isolation” and re-join their side comms network share their contact information. You can use this to model things like film-return satellites (the Russians still use them!), a submarine sharing its intelligence take after rejoining its battlegroup etc. If the parent side already has these contacts, the updated information (including BDA – very handy!) is merged and used to refine the contact information.

As mentioned, the player has no control over his “disconnected” units. However, playing out a scenario in ScenEdit mode (which is essentially “cheating” but also very useful for analysis) affords an additional ability: To literally jump into the cockpit/CIC of the isolated unit and experience its “loneliness” first-hand (Editor –> Isolated POV view. This menu selection is only available when the “Comms Disruption” feature is enabled for the scenario). This is an excellent way to understand how a comms-isolated unit perceives its environment and reacts to it (which is usually quite different from when it operates as part of an integrated network). Quickly switching between “side-wide common picture” and “isolated POV view” can be a real eye-opener as to the value of a well-connected battleforce and the hazards and challenges of “comms off”. It is simple enough to say “we’ll not transmit so the bad guys cannot sniff us out”. But how well can you really fight in the dark?

Living with vulnerable comms

During the course of our internal testing, we realized players using this new feature will probably have to adjust to a different mindset as well as absorb the new options it affords them. A few random thoughts:

Non-kinetic options are now significantly more expanded. Forget jamming radars; now you can do some real sneaky tricks. It is remarkable how much more brittle and inefficient, say, an IADS becomes when you can selectively take any of its critical nodes offline. Michael Scofield would _love_ to be able to brick the guards’ phones during his break-out/break-in escapades. Put another way: Going ultra-stealth or swarming cruise missiles over every radar & SAM site are no longer your only, or even your best options.
An initial tempting thought was to freely use comms disruption as a standard built-in feature to all existing scenarios. We soon discovered, in hilarious ways, how this can wreck scenarios that were not designed with this factor in mind. As an example, in the standalone scenario “Duelists”, we “flipped the switch” on the Soviet surface group just to see what would happen. Because the group had a standing “forbidden zone” around it that automatically marked violators as hostile, and in combination with very liberal “shoot first” ROEs, the ships in the group almost immediately proceeded to blow each other out of the water with righteous fury, with even a distant Oscar sub joining the action with its beastly antiship missiles. It really was blue-on-blue in its most pure, raw form.
Apart from the obvious step of making this new feature optional so that existing scenarios can function as before, we also added a lot of “reasonable smarts” to the AI crews so that events like the above Soviet shootout were less likely to happen. So for example, when detecting a new contact close to where a friendly off-grid unit was last known/reported, the side-wide AI is now a bit more careful even if the new contact is a violator of a forbidden zone (“easy on the trigger, guys… maybe it’s Garry after all”). Likewise, cut-off units compare their new contacts with the most recent datum of their known comrades and will ignore contacts that seem to be right on top of where their buddies were when they last heard from them. After putting together such refinements and re-trying the Duelists test, the isolated Soviet units were now significantly more restrained on how they prosecuted sudden new contacts after their breakaway.

(On the flip side, if you are the one creating the chaos, this creates excellent “false flag” opportunities for exploiting it. For example, if you can swiftly and unobserved dispatch comms-isolated units that are part of an enemy distributed force, the longer you can remain in their general location the longer it may take for their friends to get suspicious of you. Cloak and dagger fans rejoice!)
Comms vulnerability really drives home the dirty little secret of most network-based CONOPS. People talk about swarms, distributed lethality and all the rest of current jargon – but all of this assumes reliable communications.
This also reinforces the importance of sufficient individual capability: A modern warship, even when comms-isolated, is still a powerful unit. It has a fair chance of accomplishing its mission even without the obvious benefits of cooperation with its consorts. On the other hand, a “swarm” unit (be it a small speedboat, a drone etc.) that relies on the “my strength is in the pack” principle? Take comms off and its power drops precipitously (it is not an accident that comms-jammers are rather more favored for counter-drone defence than hard-kill measures).

Some other scenario-editing ideas for taking advantage of this feature:

Special actions, with units on the opposing side getting their comms knocked out. This is used to simulate a computer network attack, but could also represent saboteurs physically disrupting the comms network.
A “unit enters area” trigger where a friendly unit representing a jammer (ie, an EA-6B Prowler or similar) arrives on station. The script is fired, and representing its jamming capabilities, units on the opposing side have their comms taken out.
A “unit enters area” trigger where run-off the mill friendly units get their comms knocked out, forcing them to continuing prearranged missions or move aimlessly in circles until they run low on fuel and return to base. This, especially in earlier-period scenarios, simulates units outrunning their lines of communication. It can also be used to simulate submarine operations.

Looking forward

Further improvements to the comms-disruption feature are already planned and underway, but most of them are currently restricted to the Professional Edition. In the meantime, it is obvious that this feature represents a huge step forward in modeling the intricacies of modern operations, and scenario authors are likely going to have a creative blast with it just like with other existing features. What are YOU going to do with it?

Tags: no tags