Out To Sea Again: Command v1.10 has been released

February 26, 2016 · Posted in Command · Comment

The cat is now officially out of the bag; Command v1.10 has been released. The full release notes are available here. Arguably the biggest pull in the new version is a longtime request of Steam-side customers, proper integration of Steam Workshop. But v1.10 has plenty of goodness for simulation freaks and casual players alike. Let’s do a quick recap:

In addition, during the public Release Candidate phase, we snuck in a lot of gunnery-related improvements and numerous fixes, DB additions and other tweaks based as always on the feedback of our users.We had a lot of fun putting this update together and we are certain you will enjoy it as much as we did.

Our attention is now turning on the next major update, version 1.11 (some of our internal beta folks are currently filing their divorce papers :)) plus a few other parallel endeavors that will be disclosed… at some point in the future.

Stay tuned!

Tags: no tags

Preparing To Launch: Command v1.10 Release Candidate 1 now available

January 22, 2016 · Posted in Command · Comment

We have been talking about this for a while, and now it’s here. Release Candidate 1 of the v1.10 update for CMANO is now available for a test drive. Steam users have received an extra dose of TLC on this round and can fetch the update by a one-click switch to the “public beta” branch as described on the release notes.

v1.10 brings a lot of small improvements and a few biggies. Let’s recap the top items:

And in addition to these, there is the usual mile-long list of smaller fixes, tweaks and improvements, in addition to a parade of new database entries on platforms, components, sensors and weapon systems.

Give it a spin and tell us how you like it, and how to make it even better!

Tags: no tags

The road to v1.10: Special Actions, Lua additions and ScenEdit improvements

January 13, 2016 · Posted in Command · Comment

This is the last in our series of posts covering the new functionality offered by the forthcoming CMANO v1.10 update. This time we turn our attention to scenario authoring and Lua scripting.

Special Actions

Special Actions are similar to TOAW’s much beloved “Theater Options”, in the sense that they allow the player to execute a number of pre-defined actions that may bring favorable results (or not – often the best way to model such actions is as high-risk gambles that can spectacularly backfire). Contrary to TOAW, Special Actions can range from the strictly tactical (“Host this SOF squad into the building”) through operational (“request nuclear release”) all the way to grand strategic (“The Assad regime requests assistance from the Russian Federation and makes Latakia airbase and Tartus harbor available to their forces”).

Special Actions are created and edited through ScenEdit (Editor -> Event Engine -> Special Actions) and are made available to the player in normal play mode via Game -> Special Actions (disabled actions are hidden). Such an action may be one-off or repeatable (through Lua it can also be made active for only a finite number of calls, ie. “you may request this 3 times”). From a technical standpoint, Special Actions act as containers for Lua scripts so they can be very powerful. Once an action is executed a message (generated by the script) is shown to the player as to what happened as a result of the action, so scen authors are encouraged to be elaborate in their explanations.

Lua improvements

Lua scripting on Conditions: The immense power and flexibility of Lua scripting is now available not only on event actions but also on conditions. Authors can combine this with the existing event triggers to create very elaborate conditional triggers.

Lua counterparts for existing conditions: The existing “Side Posture” and “Scenario has started” event conditions now have Lua counterparts: ScenEdit_GetSidePosture(SideANameOrID, SideBNameOrID) and ScenEdit_GetScenHasStarted() respectively.

New Lua function: ScenEdit_SetSpecialAction. Usage example: ScenEdit_SetSpecialAction({ActionNameOrID=”MyAction”, IsActive=”True”, IsRepeatable=”False”, NewName=”MySpecialAction”, Description=”This is a very special action”}). This is very handy if the scen author wants to activate/deactivate special actions depending on other events happening.

New Lua method: ScenEdit_GetSideIsHuman(‘SideNameOrID’) . Returns ‘Yes’ if the referenced side is currently under human control, ‘No’ otherwise.

New Lua method: ScenEdit_SetLoadout. Usage example: ScenEdit_SetLoadout({UnitNameOrID=”Viper #1″, LoadoutID=631, TimeToReady_Minutes=45, IgnoreMagazines=”False”})

Length limit of Lua scripts: The limit has been raised to tens of millions of characters.

You can now order a unit to RTB via Lua: Using the existing ScenEdit_SetUnit method, use the “RTB” key (e.g. RTB=’Yes’)

You can now host a unit to a suitable parent unit/group via Lua (e.g. aircraft to airbase, small boat to larger ship etc.). The new method is: ScenEdit_HostUnitToParent(table). Usage example: ScenEdit_HostUnitToParent({HostedUnitNameOrID=’Eagle 1′, SelectedHostNameOrID=’Bitburg AFB’}) . The unit to be hosted is ‘snatched’ either from mid-air or from its current host.

You can now edit a unit’s fuel level through Lua. Usage examples:
a=ScenEdit_GetUnit{side=’a’,name=’test’}
print(a.fuel)
{ [3001] = { current = 240000, max = 240000 }, [4001] = { current = 3750, max = 3750 } }
fuel = a.fuel
fuel[3001].current=1000
a.fuel = fuel

ScenEdit and Event Engine improvements

* An extra criterion, “minimum classification level”, has been added to the “Unit Detected” trigger. This allows the scenario author to tailor the desired level of target classification reached (everything from simply “detected” all the way to “precise ID”) before the trigger is actually fired. For backwards compatibility, the default level is “Detected – Known Domain”.

* You can now clone events, triggers, conditions and actions.

The v1.10 update for CMANO will soon be available as a Release Candidate on the MatrixGames forum. Stay tuned!

Tags: no tags

The road to v1.10: Electronic warfare improvements and weight-dependent aircraft kinematics

January 4, 2016 · Posted in Command · Comment

Happy new year!

Command Build 757.12, which had been made available unofficially at the start of December, has now officially been released through MatrixGames and Steam. Barring any emergencies, this is probably the last update released as part of the post-v1.09/NI release support process. The development team’s focus is now the next major public update, designated v1.10. Let us take a look at the some of the major improvements that the new version will feature.

Electronic warfare improvements

Image: Jamie Hunter / www.aviacom.co.uk

A rather consistent piece of feedback we have received since the original release of Command is that the offensive jamming (OECM) systems of many aircraft appeared to be overpowered against their target emitters. The “poster child” for this issue was the EA-18G Growler, which was able to flood with jamming even very modern SAM systems such as the S-400/SA-21, to the point where the aircraft was able to even overfly such a SAM battery with impunity.

We investigated these reports, and concluded that the fundamental problem was that our radar/ECM formulas, while technically quite accurate, failed to take into account the various counter-countermeasures (and counters to them, and counters to the counters, ad naseum…) that are applied by both radars and the jammers that target them. Discretely incorporating these techniques in a public-domain simulation is tricky, not least because non-classified information is scarce, both on the details of these techniques and also as to which system supports which tricks.

However, we already had at our disposal a successful template for abstracting and emulating these factors: The technology generation system, employed already on defensive jammers (DECM). We were also informed of the decisive advantages of phased-array systems (and especially AESAs) in countering most jamming techniques.

So here are the steps we undertook to improve the OECM modelling:

* As described, tech generations are taken into account when preparing the variables used on the radar/ECM formulas. The greater the generation difference between jammer and radar emitter, the more pronounced the effect is; so for example a very modern jammer like the forthcoming NGJ has a fair chance of defeating a modern radar like the 96L6 Cheese Board or the YLC-27, while it will laugh at older systems like (non-modernized) Tall King or Spoon Rest. (The other already-existing factors that affect jamming effectiveness like distance, positional geometry, sidelobes, emission characteristics like beamwidth, frequency band, PRFs etc. etc. are all still there and are critical as ever, but the tech-gen gap adds an extra wrinkle.)

* Phased-array systems get decisive bonuses both on the radar and on the jammer side (NGJ is an example of the latter). AESAs in particular are able to ignore many OECM techniques altogether thanks to their very low sidelobes, high SNR and advanced beamforming capabilities.

As an example of how these refinements affect tactical employment, we ran the popular but artificial “lone EA-18G jam-attacks S-400 battery head-on” strawman setup. In this case the SAM battery was using only 48N6DM missiles (TVM/SAGG guidance) and was supported by a 91N6 (Big Bird D) brigade-level surveillance radar. The 91N6 briefly detected the Growler at 168nm but immediately lost it again. It was able to re-detect it and hold it reliably only at 71nm. The battery’s 96L6 (Cheese Board) acquisition radar detected the aircraft at barely 14nm, and the 92N2E (Grave Stone) fire-control radar was able to achieve missile lock at just under 7nm (…cue the fanboy hordes screaming that our numbers are way off).

(As an aside, the large range gap between firm target track and reliable TVM/SAGG missile lock may help explain the design rationale for fitting both the 40N6 and 9M96 missiles [the other two weapon options for S-400 batteries] with active-radar seekers. In theory, both of those missile types could have been launched against the EA-18G as soon as a reliable track was achieved and the contact entered their respective kinematic envelopes.)

So as we see, modern OECM systems are still quite effective even against modern radar systems but not nearly as omnipotent as was hitherto the case. Against older threats, modern jammers remain overwhelmingly effective as has been repeatedly demonstrated in real-life air operations in the last few decades.

Weight-dependent aircraft kinematics

Fully populating the aircraft loadout entries in the DBs with weight and drag data has enabled us to refine a significant aspect of aircraft kinematics: The effect of weight on agility and manouvering. Until now, although weight and drag were taken into account for fuel consumption puproses (and indeed were re-calculated continously so that e.g. an aircraft that dropped its bombs would immediately experience a benefit in endurance and range), the aerodynamic performance itself (including evasion against attacks) always assumed an “airshow” configuration (minimal external stores, half-full fuel load). This mostly worked for air-combat loadouts but could cause significant distortions in evaluating attacks against heavily-loaded aircraft.

So now the actual aircraft weight, including fuel and stores, is continously calculated as the “weight fraction” (compared against the nominal “airshow” values and the maximum take-off weight) and it has a decisive effect on actual performance. Sustained turn rate, climb/dive rate, acceleration and attack evasion agility are all affected by this.

As an example, a USAF F-16CM Blk52 (2014) with a light A2A-patrol loadout (2x 370USG tanks, 4x AIM-9X, 1x ALQ-184 DECM pod) at 36Kft has a weight fraction of 0.44 with full internal fuel. With this fraction the aircraft has a 16.7 deg/sec sustained turn rate (against the nominal 22.8) and its evasion agility is reduced from the nominal 4.9 to 3.6 (not taking into account any other factor such as crew proficiency, impact angle etc.). In contrast, the very same aircraft in a heavy attack loadout (2x 370USG tanks, 2x GBU-31(V)1 JDAM, 2x AIM-120C-7, 2x AIM-9X, 1x AAQ-33 Sniper-XR pod, 1x ALQ-184(V) DECM pod) has a weight fraction of 0.68, which reduces its turn rate to 13.4 deg/sec and its evasion agility to just 2.9.

As fuel is consumed this fraction steadily decreases and the aircraft performance increases, and of course even more so if the loadout stores are expended.

So if you have been watching the news and see aircraft on actual ops carrying much fewer stores-per-sortie than the “Christmas tree” brochure drawings, part of the reason is range/endurance but a significant consideration is also this: Too much weight can really get you killed.
On the next post, we will take a look at the most significant ScenEdit & Lua improvements that v1.10 brings.

Tags: no tags

The road to v1.10: New weaponry capabilities

December 24, 2015 · Posted in Command · Comment

Happy holidays everyone!

Command Build 757.12, which had been made available unofficially at the start of December, has now officially been released through MatrixGames and Steam. Barring any emergencies, this is probably the last update released as part of the post-v1.09/NI release support process (Command is still 50% off at MatrixGames and Steam until early January!). The development team’s focus is now the next major public update, designated v1.10. Let us take a look at the some of the major improvements that the new version will feature.

Cooperative Engagement Capability (CEC)

New to the term? Here’s a quick primer. TL/DR version: You shoot the weapon (and often get out of harm’s way), I guide it to impact; typically by mid-course datalink, less frequently so by terminal illumination (e.g. radar or laser).

Strictly speaking, this capability is not new. The Russian Navy already had since the early 1960s the ability to use its Tu-95RT Bear-D aircraft and Ka-25RT Hormone-B helicopters as airborne relays to “shepherd” heavy carrier-killer missiles launched from surface ships or submarines towards their targets. The US later introduced some weapons like the Walleye II ER-DL, the SLAM, the AGM-130 etc. which allow a different aircraft from the launch platform to guide them. And then of course there is the ubiquity of the buddy-lazing paradigm. What is new nowadays is that computers and networks have matured to the point where this guidance model is fast/responsive enough to be used against air targets.

Perhaps unsurprisingly, the first operational application of CEC emerged in Sweden in the late 90s, where Gripen-C/Ds of the Swedish air force were able to perform AMRAAM “blind shots” based on offboard shared data. But now with the emergence of NIFC-CA in the US Navy, CEC is going mainstream.

In a simulation like CMANO and its older siblings, it is tempting to take the “easy route” for modelling this ability by simply allowing everyone to guide everything. This creates problems in the sense that it does not really highlight the increased combat capability of the new systems. What is the AIM-120D good for (other than improved kinematics) if older versions of the AMRAAM offer the same guidance flexibility in-sim? So something stricter becomes necessary.

The implementation followed by the CMANO dev team allows great flexibility (database-wise) in defining that a given datalink component may allow cooperative use when installed in platform-A but not so when installed on platform-B. The same goes for different generations of the same basic weapon (e.g. AMRAAM-D vs. earlier versions). This allows modelling the differences in capability without having to spawn multiple versions (CEC-enabled and non-CEC) of the very same datalink system. It also highlights the necessity of bringing all the basic pieces together to really exploit the new functionality. For example an F-15C may tote the new AIM-120D but without any CEC-compatible platform (such as an E-2D or CEC-updated Aegis cruiser/destroyer) in the vicinity, it cannot really do a true launch-and-leave.

Let’s see how all these acronyms benefit the virtual commander. (Click for full size)

This is a typical nightmare scenario for an Aegis cruiser: The ship is operating in the littoral, close to high mountains that sharply reduce its visual and radar horizon. An attack by multiple supersonic sea-skimming missiles against the ship is underway. While the orbiting E-2C has provided early warning, this is not helping the ship significantly: the target tracks are imprecise and the Tico cannot engage the missiles because it is blocked by the mountains (the ship’s SM-2 missiles require terminal radar illumination). By the time the missiles pop over the mountain ridge and can be engaged, it will be too late.

Let’s observe the same situation with CEC-enabled assets in place.

The orbiting E-2D uses a new improved radar which enables establishing firm target tracks. The big change, however, is that now the cruiser has CEC-enabled datalinks and SM-6 ERAM missiles, and can start shooting them as soon as the inbound targets enter the kinematic envelope. Notice that most of the ERAMs are still in their midcourse phase (lofted high to maximize range) and still high enough that they can maintain their datalink (brown line) to the ship that launched them. However, the first-to-impact ERAM has already dived below the ship’s horizon and lost LOS to it and thus its connection to it – but the E-2D has taken over guidance for it (brown line between E-2D and ERAM). Effectively the ship is shooting blind and completely relying on the E-2D for guidance. And it works. This is CEC.

ABM Warhead Modifiers

Q: So guys, how can we model the apparently mediocre performance of the Patriot PAC-2 in Desert Storm against Iraqi ballistic missiles?
A: Well, I guess we can adjust the baseline Pk numbers and the max target speed values so that it behaves well against aircraft speeds but begins suffering at ballistic-speed targets.
Q: Okay, but won’t that also make it unrealistically ineffective against aerodynamic high-speed targets (e.g. SR-71)? From what we know, Patriot is quite effective against anything with wings.
A: True that. Okay, how about we set separate Pk baselines for air targets and missile targets.
Q: That might work, but then you have the problem that PAC-1/2’s handicap was not against missiles in general; it was specifically against ballistic targets. Its warhead, fuzing etc. were optimized against aerodynamic, winged targets and should have no problem working against e.g. cruise missiles (Patriot, like Aegis, was expressly designed with Soviet high-diver cruise missiles in mind). It had no problem intercepting the ballistic targets, but faced severe difficulty in actually destroying them. Most of them were knocked off course or broke up into multiple smaller but still lethal pieces.
Then you also have the factor of follow-on systems learning from the DS experience and improving on the ABM aspect. S-300VM/SA-23 for instance uses a directional-frag warhead (very much resembling a rotating claymore mine on top of a missile) and this has been also adopted by a few other systems, most notably Crotale NG and 9M96. And then of course you have the hit-to-kill trend nowadays with everything from PAC-3 to THAAD to even pure-AAW kits on the table. All these fancy new missiles aren’t actually much better than PAC-1/2 at hitting ballistic targets; they are however much better at actually blowing them away. And that’s to a large part due to their improved warheads. How do we show that?
A: ……..

(Yes, our brainstorming sessions are often like that)

So, we had to do something new. And we did.

A familiar scene if you’re old enough: An Israeli PAC-2 battery in the outskirts of Tel Aviv engages an incoming Iraqi ballistic missile in the first days of Desert Storm.

In addition to the standard continuous-rod warheads, we have added two more types of ABM-optimized warheads: Directional-fragmentation and hit-to-kill (HTK). We also modified the weapon-impact code to account for the special circumstances revolving engagements of ballistic targets (missiles & RVs).

This is what now happens when a SAM/ABM impacts an incoming missile/RV:
– A conventional warhead has a 15% chance of outright destruction of the target, and a 30% chance of significant trajectory deviation (CEP increased by 3x). If none of these happens then the target missile/RV suffers only a minor deviation (CEP increased by 1.5x).
– A directional-frag warhead has a 30% chance of outright destruction of the target, and a 60% chance of significant trajectory deviation (CEP increased by 3x). If none of these happens then the target missile/RV suffers only a minor deviation (CEP increased by 1.5x).
– A HTK warhead reliably destroys the target every time.

Trajectory deviations are cumulative, so an incoming missile/RV may be impacted multiple times by non-HTK ABMs and still survive but impact far away from its intended aimpoint (this happened in a few instances in DS).

AAW weapons with advanced warheads are also favored by AI crews in “best weapon to use” calculations, as their warheads also make them more lethal on anti-aircraft engagements (having your aircraft literally impaled by a HTK missile must be a relatively unpleasant experience…).

Weapons with advanced AAW/ABM warheads in the DB3000 database include:

Arrow 3
ASM-135A ALMV
GBI [CE-I, GMD]
GBI [CE-II Blk 0, GMD]
GBI [CE-II Blk 1, GMD]
KM-SAM [Modified 9M96]
MIM-104F Patriot PAC-3 ERINT
MIM-104F Patriot PAC-3 MSE
R.440 Crotale-NG VT1
R.440N Crotale-NG VT1
RIM-161A SM-3 NTW Blk I
RIM-161B SM-3 NTW Blk IA
RIM-161C SM-3 NTW Blk IB
RIM-161E SM-3 NTW Blk IIA
SA-12a Gladiator [9M83]
SA-12b Giant [9M82]
SA-21a Growler [48N6DM]
SA-23a Gladiator [9M83M]
SA-23b Giant [9M82M]
SA-25 [9M96]
SA-25 [9M96D]
SA-N-21c Growler [9M96]
SA-N-21d Growler [9M96D]
THAAD C-1
THAAD C-2

One-click EMP strike

EMP effects from nuclear detonations are not new; we introduced them already in v1.09 and they have been a lot of fun to use and experiment with. They were not however easy to use from an end-user perspective unless one was willing to get down and dirty with Lua in the scenario editor. v1.10 changes that. Now even aunt Elma can paralyze your country.

The trick in smoothly integrating EMP attacks on existing weapon mechanics (and especially UI) is to make as few data changes as possible. In the real world, any nuclear warhead that can be lofted at high altitude (ideally near-orbital) is a crude but effective candidate for a continent-wide EMP strike (the physics of EMP propagation were a constant source of amusement during our research; the realization, for instance, that detonation altitude determines effective reach much more so than warhead yield). Would it be possible to simply make EMP-oriented copies of all nuclear ballistic missiles in the DB? It would, but it would create lots of logistical problems and would deprive players of the real-world flexibility of selecting the attack mode at the last possible moment.

So we created a framework for such “special mode” weapon attacks:

What is better than throwing a 18-megaton warhead at Elmendorf AFB? Why, bursting that same warhead high over Elmendorf and frying every transistor in Alaska and western Canada of course!

There is not much to say beyond the obvious: When you select this attack mode, the ballistic missile will detonate at high altitude instead of the normal low altitude airburst or groundburst (depending on target type) that nuclear warheads typically go off at. This ensures a powerful pulse extending out to more than a thousand km and knocking out sensors and communication systems. Such an “opening gambit” attack is in fact a common threat scenario when considering rogue nuclear states like Iran or North Korea.

Suffice to mention, the same framework can be re-used for other special weapon attack types in the future.

And there is much more to talk about….

Tags: no tags