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