Autonomous killing machines, comms jamming, 3D terrain view, shoddy anti-ship missiles, doctrine/ROE advances and more: Command v1.08 public-beta now available

April 29, 2025 · Posted in Command, Command PE

It’s been only a few months since the releases of CMO v1.07 and CPE v2.4.1, and the Command dev team has been as frantically busy as ever. The next major update, CMO v1.08, has now been made available for a public-beta preview. The full release notes (and instructions on how to get it) are available HERE.

In addition to the previously covered side-enablers and GNSS disruption, the new update also packs a whole lot of new major features. Let’s take a look.

From cheap closely-tethered quads to fully-unleashed murderbots: Drone Autonomy Levels

We have a separate article dedicated to this new feature, as it’s a meaty one. Doing drones justice is table stakes in 2025, and properly demonstrating their comms vulnerability as well as their different degrees of autonomy is an essential part of this. Drones have different autonomy levels which dictate what they can and cannot do when they are comms-isolated (which is a common predicament in a comms-challenged peer-conflict battlespace). If you thought the flying hunter-killers in Terminator were a bit too sci-fi, prepare to be amazed.

Static on the radio: Comms jamming comes to commercial CMO

Ever since comms disruption and its effects were introduced in Command back in 2017, comms jamming as an attack vector was available only in Command-PE. While it was possible to simulate it in CMO as well (look at the “Bekaa Valley” scenario in the “Shifting Sands” campaign), this required some Lua scripting. Given that the main way to disrupt comms is through jamming, and the importance of this attack vector in disrupting drone communications (and thus highlighting their different autonomy levels) it now makes sense to bring script-less comms jamming also to the commercial version of Command.

If you need a refresher on the effects of having the command and control over your units abruptly cut off, have a look at our original coverage on this feature. Suffice to say, a number of things happen when your radios & datalinks are chocked with static, none of them good.

Grand vistas: 3D Terrain view and vertical scaling

This may be seen as the next evolutionary step for the map UI after the (enthusiastically received) “pin-cushion” view. In addition to showing aerospace units at their true altitudes, it is now possible to display the terrain itself in top-down stereoscopic 3D (users of Google Earth or other GIS apps should be familiar with this). This can be useful for both air and ground operations, in better appreciating vertical differences and understanding how the terrain geometry limits available operational options. Phil Gatcomb has already covered this new feature, check it out.

An army runs on doctrine and diesel: Doctrine & ROE UI/UX improvements

This has been a popular user request: While the various doctrine & ROE options are ridiculously powerful and flexible (and they explain why we don’t have to artificially nerf/OP hardware in order to recreate historical results), keeping track of them and being aware of possible conflicts between them or other issues can sometimes be a chore.

So, we set out to radically improve the UI and user experience on this vital aspect of Command:

Instead of having all baseline doctrine options crammed in a single panel, they are now logically divided by operational branch, in a pseudo-tabbed interface. This makes it faster to locate the options of interest and also allows more space for future additions.

Moreover, the population of options can be dynamically adjusted depending on the type of the selected platform (so for example, if you select a friendly submarine, options related to air operations are not shown). In this example, a single ship is selected, and only the doctrine settings that are relevant to surface ships are displayed:

We asked you if you still wanted/used the quick-access panel for the doctrine options on the right-hand column, and you overwhelmingly said no (and we agreed). So, we ripped that off and replaced it with something you will probably find more useful: An intelligent mechanism for detecting common doctrine-related problems or conflicts and (semi-automatically, with user consent) correcting them. Here is an example of a common issue (conflict between mission- and unit-level WRA setting) being detected and a notice presented to the player, who can then resolve this with just a single button click (click on animation to enlarge):

The system is deliberately extensible so that it can be further enriched in the future with other common issues encountered, as highlighted by community feedback. So, tell us what torments you on doctrine management, and we can try to encapsulate the solution there.

When men were men, and missiles slammed into hills: Early anti-ship missile overland restrictions

Here’s something you may not have realized until now: Early low-flying anti-ship missiles (from granddaddy P-15 Termit/SS-N-2 “Styx” up to and including the first versions of Exocet and Harpoon) had rather primitive systems to keep them flying safely above the sea waves. These early guidance systems (simple radar altimeters or even just gyroscopes) were designed primarily for sea-skimming flight, relying on a relatively flat sea surface to maintain a consistent altitude. They were therefore limited in their ability to follow flight paths that took them overland. When directed overland, the missiles encountered varied terrain such as hills, ridges, or buildings, which their rudimentary altimeters could not detect or adjust for. As a result, the missiles were unable to compensate for elevation changes and often crashed into the ground before reaching their targets.

Now if you are in the middle of the Atlantic or in the North Sea, shooting every Harpoon at hand against the incoming Soviet/Russian Northern Fleet, this doesn’t matter much. But if you are playing hide-and-seek in, say, the Norwegian fjords, the Swedish archipelago, the Aegean Sea or the strait of Malacca, it becomes a real constraining factor real fast.

Post-Cold War littoral operations emphasized this handicap even more, and as a result evolved guidance systems from the mid-90s onwards addressed this limitation. New systems like LRASM, NSM or Onyx/Yakhont (SS-N-26 Strobile), as well as evolved iterations of older classics like Exocet Block 3 or Harpoon Block 2 have no problem navigating themselves overland, even often using the terrain to their advantage in order to surprise a target ship near the coast.

Command now models this factor with a new opt-in realism option: “ASCM terrain-following restrictions” (disabled by default, to avoid disruption on existing scenarios). When this feature is active, early ASCMs who lack true TF capability cannot overfly land with elevation higher than their cruise altitude (unit is actively blocked from firing, both in auto-fire and also through the manual weapon allocation window). If the weapon is fired nevertheless (e.g. BOL shot) and encounters terrain higher than its cruise altitude, it smashes into it. (This means that is possible, but risky, to fire such missiles over very low-elevation land terrain such as atolls etc. – just like in real life.)

Non-TF ASCMs with waypoint capability (e.g. Harpoon Block 1C) can be fired with a plotted course around landmasses, to avoid the “land between shooter and target” restriction when this feature is active. On the manual weapon allocation window, if the selected salvo has a suitable complex course that avoids landmass, non-TF ASCMs show up as “green” (can fire).

Grinding like a chad: Chainsaw/Grinder patrol movement style

Another consistent request from the user community. The grinder or chainsaw patrol pattern is a naval air patrol tactic used to maintain continuous surveillance or presence over a specific area (typically over the sea) by a sequence of aircraft flying overlapping racetrack or circular routes.

In this pattern, multiple aircraft (such as maritime patrol planes, airborne early warning aircraft, or fighters) take turns flying long, looping tracks in a coordinated sequence, where one aircraft is always on station while others are en route to or from the patrol zone. As each aircraft nears the end of its time on station, the next aircraft arrives to take over, creating a seamless “grinding” or “sawing” motion of coverage. This graphic may better illustrate this:

(original credit: https://x.com/RSE_VB/status/1897710024937365913 )

The purpose of the grinder pattern is to provide persistent situational awareness, surveillance, or defensive coverage over critical areas like carrier strike groups, chokepoints, or potential enemy approaches. Its utility lies in efficiently managing limited air assets to ensure that a surveillance or combat-ready presence is maintained 24/7, while allowing for necessary rotations, refueling, and maintenance without leaving gaps in coverage.

While this patrol pattern was originally developed primarily for aircraft in an air-surveillance context, Command allows using it for any platform type in any kind of patrol mission (e.g. ships in an ASuW, ASW or sea-control patrol).

Other bits of note

A whole lot of improvements and fixes related to airstrike-planning logics and refueling. If you’ve given up on a specific scenario (or historical raid) because you couldn’t get the AI to behave exactly as needed, give it another try now.
A longstanding problem with scenario performance degrading due to a ballooning message backlog has been fixed. If you have developed a habit of saving & reloading large scenarios every few hours to work around this, rejoice.
The “significant hiccup every 1 sim-minute if a lot of airstrikes are preparing to launch” problem has been fixed.
All the scenarios in the “The Silent Service” DLC have been overhauled, with all known issues fixed and various tweaks and improvements applied.
Numerous other scenarios have received various fixes and improvements, and the DB description files have been updated, courtesy of Steven Lohr and kgambit.
Contact datablocks now conform much closer to established NATO & APP-6 standards, discriminating between a contact’s track number and its classification/ID name. The amount of information shown on datablocks (just track & name? track & name and kinematics? everything?) is now also configurable, which can help A LOT in decluttering “busy” maps.
The Sentinel-2 map layer now uses per-zoom-level tile packing, which allows increased performance and also faster download and installation, particularly on external hard disks (if the bane of your CMO Steam installation is “stuck at 99% FOR HOURS”, this should be your salvation).
The unit-status thumbnail and the DB-viewer now use webp (instead of jpg) as the image format, which thanks to its greater efficiency both takes up less space and is much faster to download (You may temporarily have a shortage of shown images as these are repopulated from the server on-demand)
When running in interactive-GUI mode (not benchmark), the simulation thread gets set to “Lowest” priority. This reduces raw sim-engine performance, but has two UX benefits:
(a) It reduces the impact of sim execution on UI responsiveness (map zoom/pan lag, general UI lag etc.) and
(b) It reduces the impact of sim execution on the overall OS responsiveness (If you’ve ever observed your entire OS respond sluggishly while an epic missile-spam schlachtfest unfolds in Command, you know).
Plus numerous other additions, tweaks and fixes as laid out in detail in the release notes.

Given the “public beta” nature of this release, we are eagerly awaiting for the user community’s feedback. Don’t be shy, tell us what you like, what you hate, and what doesn’t work as designed (or as expected, which isn’t always the same thing). And above all, have fun!

Tags: no tags