Command: Modern Operations – The new simulation & editor features

October 22, 2019 · Posted in Command

Command: Modern Operations (CMO, aka CMANO2) is coming soon! Are you ready? As part of our pre-launch coverage, we explore the main features of this new milestone release in the Command franchise.

We have already covered the massive UI/UX changes and improvements in CMO in a previous two – parter piece. We also saw the significant improvements in ground operations. But at the end of the day, Command’s beating heart remains an elaborate simulation engine of air, naval, strategic and joint operations at the tactical and operational/theater level, together with a powerful editor for manipulating and creating with it. So let us take a look at some of the major new features in this area.

Turbo-charged for your pleasure

One of the most immediately noticeable features, especially when running large or elaborate scenarios, is the jump in performance. Command now offers both greater absolute speed in simulation execution (ie. reduced “pulse time” as displayed when the “Show Diagnostics” option is enabled) as well as significantly increased CPU utilization, as a result of improved parallelism. (As an example of the latter, on a recent trial run of “Northern Fury #9: Hold the line”, CPU load was observed fluctuating between 65%-75% on a Core i7-6700 system. This may vary across different systems, of course). Maximum practical unit count has also increased thanks to better memory management, with the result that even more massive scenarios are now feasible.

Until the COWs come home: Comms disruption, aircraft damage & new weapons

As we previously mentioned, it was decided to merge the previously DLC-locked features of “Chains Of War” to the core simulation available with Command. This allow both scenario authors and players to make extensive use of these features without any licensing concerns. We’ve covered these features extensively before, and we included cargo, amphibious and airdrop operations on our previous article on ground warfare, so here is a short summary of the others:

Comms disruption explores the different & numerous ways that a unit can be isolated from its parent side’s communications grid, and the repercussions of “going offline” (spoiler: none of them are pleasant). This feature has been used very successfully on COW, Shifting Sands and The Silent Service, and now it can be used on any scenario. One of the post-launch improvements of this feature is that when a unit re-joins the comms grid, the UI provides much more finegrained feedback on what type of information was updated for a contact (if any), and skips mentioning contact merges that produce no new info. Ready to feel a cold sweat as your units abruptly go out of visibility and out of your control?
Detailed aircraft damage is arguably the most popular feature of the bunch, enabling a much more finegrained level of damage & attrition on aircraft than classic CMANO’s “kill on first hit” paradigm. Since its original introduction, this feature has been significantly enriched with feedback from both commercial & professional users.
Advanced weapon types: High-energy lasers, railguns & HVPs, and tactical EMPs are now available at your disposal, to ~~mindlessly include in the next Transformers flick~~ use in all scenarios addressing the challenges of warfare in the foreseeable future.

Alone and unafraid: Realistic submarine comms

One of the benefits of absorbing the COW features is that now we can freely use them as building blocks for additional functionality, inserting features & mechanics that would previously require some non-trivial Lua elbow grease. Realistic sub comms are one such example.

When this feature is enabled, submarines who go below 40m depth go off the communications grid. As in other cases of comms disruption, they are no longer under direct player control, and only their last reported location is available (this BTW means that sending them deep without first tasking them with a mission may be pointless, since they will simply sit there). The player can, at any time, send a “bell-ringer” ELF signal to a no-comms submarine to recall it to re-establish comms (right-click on sub icon, click on “Summon to re-establish comms”). The sub will attempt to rise to shallow depth to rejoin (this may not be immediate, as it will try to evade nearby hostiles). Once it rejoins, the sub will share its contact updates with its parent side.

Never stray from the path

One of the more persistent problem of CMANO’s navigation AI was that its pathfinder was binary-based: Either a spot was passable by a unit, or it was not. This resulted in a tendency in units to aggressively cut corners in their plotted paths in order to travel to their destination as efficiently as possible, sometimes coming dangerously close to shore or other obstacles. This can result in some unintended “beach surfing”, as this example demonstrates:

In this case, the Freedom is placed in the mouth of the Hormuz straits and ordered to travel inside the Persian Gulf. It plots an efficient path — too efficient, as it nearly clips the shoreline at Khasab. There is a possibility that the ship may get stuck on the shore, if left unattended. Ships generally don’t navigate this way if they can help it.

To address this issue, we implemented a new cost-based pathfinder that evaluates a location’s suitability based on a number of different factors. In the case of ships, a primary concern is local depth and proximity to terrain; generally large ships tend to prefer to maximize both, while smaller ships are somewhat more freewheeling. Using this new logic, ships are now able to plot much more realistic (and gameplay-friendly) courses, as the very same example played out in CMO demonstrates:

Stay in formation

This has been a popular request, which we are finally happy to oblige: The formation editor can now also been used to define and edit aircraft formations. It sounds like a simple change, but in reality we had to go through extensive reviews of the mission AI logics to make sure that this did not interfere with aircraft assembly & grouping logics (in some places it did, and we had to make adjustments). But we think it’s worth it, and you will probably agree: This opens up new opportunities for formation tactics and optimum placement & distribution of air assets in a group, both for regular transit or surveillance as well as combat.

A patrol of four MiG-31B sweeps over the sea north of Murmansk. The group is in loose line abreast formation, to widen the search area. Lead and the nearest wingman are already in position, while the two outer members race to catch up to their stations.

I like the way you move (and think)

Various tweaks & improvements have been applied to the kinematics models & AI routines, with a strong emphasis on aircraft and missiles. Among other items:

Numerous tweaks to aircraft flight model, specifically for “combat” conditions. For example, aircraft no longer “wiggle” between headings as they must first roll towards the turn direction before committing to a turn. This in turn makes inherent roll-rate more important to close air combat maneuvers (This is easier to observe in the Tacview window).
Helicopter diving rates have been reduced (they were previously dropping like a stone)
Surface- and underwater-launched missiles now use the same improved pitch kinematics as air-launched missiles, resulting is more realistic trajectories.
Lofted AAW missiles now begin their terminal dive earlier, to avoid a too-steep approach to the target.
Air combat AI improvement: Aircraft now consider approaching fighters/interceptors as imminent threat, not just missiles. This helps AI-controlled aircraft perform more proactive evasive maneuvers against fighters about to perform gun attacks on them (e.g. MiG-17 vs F-105).
Significant change in unit AI logic: The “evaluate targets” and “evaluate threats” logics are now not performed on every sim pulse, but instead on regular intervals dictated by the OODA-Targeting (modified by crew proficiency) and OODA-Evasion values respectively. Therefore these two OODA values, combined with crew proficiency, become even more critical to a unit’s effectiveness and survivability.

Feeling the strain: Aircrew G-tolerance

If you have ever closely watched a dogfight in CMANO, one of the things that may seem odd if you are familiar with real-world ACM is the seemingly iron-man constitution of the virtual fighter pilots; they seem to be constantly engaging in turns, climbs and dives as tight as their airframes will allow them, without regard for their own fatigue from the continuous high-G acceleration loads. This isn’t how close air combat works in real life; even the best pilots need a breather between aggressive maneuvering in order to allow their bodies to recover, otherwise they become more dangerous to themselves and their side than to the enemy (yes UCAV fanboys, you can laugh now). So we set out to model this nuance in CMO.

When an aircraft is considered to be performing “combat maneuvers”, an extra UI element is shown on unit status panel:

This represents the crew’s tolerance to hard maneuvering. The longer the aircraft is continuously pulling a hard turn, the more this buffer fills up. (Getting out of a hard maneuver, e.g. reversing a turn, reduces this strain and allows recovering. This is one of the reasons that scissors are a popular practice in RL dogfights.)

Once the tolerance is exhausted, the crew begin suffering G-LOC and have to significantly relax the turn (this is easier to notice in Tacview, as the aircraft wing bank visibly changes, but you should also observe a noticeably larger turn radius on the map’s top-down view as well), while regaining their senses and control of the aircraft. Of course the aircraft is particularly more vulnerable during this recovery period, which makes cooperative tactics and mutual support all the more important. The maximum tolerance level depends on aircrew proficiency, so experienced pilots get one more significant advantage against greener adversaries (Ed: Like they need one more…).

Radar frequency agility

Not all radars are created equal. One particular feature that became quite important during the Cold War for radar performance against jamming and other countermeasures was its ability to “frequency hop”, ie. shift its operating frequency to a different value within its feasible operating range. CMO now models this, and two particular operational benefits of this ability:

Frequency-agile radars are significantly harder to noise-jam, as they can shift to a new frequency once their existing one gets flooded with static. The jammer has to either start hunting for the new frequency, effectively hopping after the radar operator, or alternatively flood the entire frequency range with jamming power to make hopping pointless; both counter-actions are feasible but they both have complications of their own.
These radars are significantly less susceptible to doppler-notching maneuvers (more on this below).

This feature became so important to radar engineering & operations from the mid-1960s that, quite often, the main difference between a very capable domestic radar set and its export-cleared variant was the physical removal of the frequency-hopping circuits in the latter kit.

As in other cases, electronic-scan arrays and especially AESAs get massive advantages; in this case, all P/AESAs are automatically considered as being frequency-agile, while older mechanical-scan sets have to explicitly have this declared in the simulation databases.

A notch on the bedpost

Doppler notching, a maneuver designed to exploit a fundamental flaw in pulse-doppler radars in look-down mode, has been included until now abstractly in CMANO as part of the weapon endgame calculations. This time, however, it can be actively and preemptively used as a maneuver, both for missile track lock-break and for general surveillance radar detection avoidance.

Aircraft can attempt to fly perpendicular to an emitter using doppler filtering in order to hide inside its “blind” velocity gate. The effectiveness of the maneuver varies with crew skill (an “ace” pilot will execute it far more effectively than a novice), to discourage manual micromanagement by players. Aircraft under missile attack with a doppler radar guiding the missile will also actively try to beam the radar instead of the missile (the geometry of the two axes can vary significantly). The maneuver is ineffective against pulse-only radars and less effective against frequency-agile radars.

Players can also deliberately plot courses for aircraft that fly perpendicular to known PD search radars, to reduce the actual detection range. (If you’re a Microprose F-19/F-117 virtual vet this may bring back some memories).

Patrolling in style

This has been another popular request: “I like the flexibility of the patrol mission, but sometimes I want to enforce my custom patrol movement patterns instead of the ‘random within defined area’ logic, even at the cost of predictability”. Well ask, and ye shall receive – in the form of an extra patrol mission option: movement style.

This option has two settings: “Random within area” (default) and “Repetable loop”. “Random within area” is the patrol behavior you are already familiar with. If “Repetable loop” is selected instead, the assigned units treat the reference points of the patrol area as a racetrack, just like in a support mission. This allows the player (or scenario author) to define precise, consistent patrol patterns (figure-8, expanding spiral, ladder etc.) while also retaining the “investigate & prosecute” behavior that distinguishes patrol missions from support ones.

When the “Repeatable loop” setting is active, the patrol area is depicted very similarly to support mission racetracks, to emphasize the difference:

Till death do us part: Merge scenarios

This is another gift from the PE world, and we bet it will be a much-appreciated one. If you are a scenario author, you are already familiar with the base & group import/export (ie. the .inst files), and how convenient and time-saving they can be when putting together the elements of a scenario. This “construct once, re-use everywhere” concept has now been taken a step further: You can make individual scenarios and then merge them into a single scenario.

Scenario #1 is treated as the “base” for the merge, so behind the scenes you are essentially cherry-picking all transferable items from scen #2 and adding them to scen #1 (the log output also makes this clear). Elements that are “atomic” or otherwise hard to merge (date & time, weather, title & description etc.) will, on the output, be those of scenario #1.

The power & versatility of this tool should be readily apparent to anyone who’s delved in scenario editing. Now you can create once, store and re-use not just groups or bases, but multiple foundational scenario elements: Sides, missions, events, actions, conditions etc. We have been repeatedly amused by the wacky, quite unforeseen ways the original import/export functionality has been employed by industrious scenario creators, so naturally we are curious to observe how they’ll bend this one to their will.

Lua loco

The Lua API continues its expansion in CMO and offers additional hooks into the simulation engine as well as various methods for pulling the strings of the running scenario. One of the new hooks ties directly into the AI model: You can individually instruct units to, quite literally, not think for themselves (You in the back, quipping “you mean they do this now?” – SIT DOWN!). More specifically, you can set individual units to skip their AI routines for evaluating valid targets and picking out the primary one among them. This has two direct benefits:

It makes it easier to implement custom targeting AI routines in Lua, since an author not longer has to “compete” with the build-in AI for this.
As these routines are among the most CPU-expensive pieces of the simulation pipeline, disabling them can have a drastic effect on the speed & scalability of a large scenario. For example, if you disable the AI cycles of all static/inactive buildings, then only “active” units will use the CPU for this work (internally Command already does a lot of such optimizations, but since it cannot “intrinsically” know which units are static & inactive, it has to check them, which itself is not free).

Additionally, this ability can allow simulating “dormant” states for units (e.g. units begin a scenario in a “comatose” state, but later because of XYZ they become activated).

Stay tuned for more articles & news on Command: Modern Operations soon!

Tags: no tags