The calm before the storm: Command PE v2.4.4 is here

May 31, 2026 · Posted in Command PE · Comment

Yes, it’s that time of the year again; CMO v1.09 was released to an enthusiastic welcome to its new features and improvements, and the time is now ripe for a similar update to Command-PE. Version v2.4.4 is now available for download to new and existing CPE users around the world.

Far more than merely “v1.09 for pro users”, however, CPE v2.4.4 offers several significant improvements on both the user interface and the simulation engine, while maintaining the tradition of fixes, tweaks and additions across the board.

On the UI & workflow assets, the emphasis has been on:

Higher-resolution and more accurate coastal terrain modeling
Expanded mission/event scripting flexibility
Faster and more fluid map interaction at scale
Reduced UI friction in scenario design workflows
Improved at-a-glance tactical readability

Some of the main UI improvements:

– A fourth map icon option has been added, for full APP-6 icons.

– The optional high-resolution (DTED-1 equivalent) global terrain dataset has been completely refreshed on the bathymetry side. Using the 2025 version of the GEBCO grid, and enhanced by the EMODNet European coastal bathymetry dataset (https://emodnet.ec.europa.eu/en/bathymetry ), which provides up 115m/cell resolution in its applicable costal areas (Europe + North Africa + Black Sea + Red Sea + Eastern Carribbean). This provides a much higher level of detail for coastal naval & underwater operations. As before, the improved DTED-1 terrain is available through the optional “HD pack” for Premium-license CPE customers.

– The relief + bathymetry layer has been drastically improved, using the above high-resolution DTM as the source, and re-shaded for more finegrained detail up to 600m (maximum depth for vast majority of submersibles).

– You can now assign an event action to a waypoint:

The unit can be obtained by the usual ScenEdit_UnitX().
The waypoint action is a dropdown of the event actions.
The triggering unit and WP IDs are passed as a local Lua table ‘wpAction’. The full details can be accessed thru the SE functions using the unit (wpAction.unit) and wp (wpAction.wp) GUIDs.

– A new “Aggressive Tile Management” option has been added, for a smoother map zoom/pan experience if the GPU hardware supports it.

– You can now search for a specific menu or submenu through a textbox. This can be very useful if you do not remember where a specific menu command is located (“Now, where was that command about jettisoning secondary stores….”). Just type the command text in the textbox and you will jump right into the appropriate menu.

– Range-ring colors have been added as “notches” on the weapons panel, to at-a-glance indicate the target suitability of each weapon.

– Numerous fixes and tweaks have been added on the Area & RefPoint Manager, as well as the Lua API access to it.

The simulation engine has also received a number of significant upgrades:

– Aircraft transported as cargo: You can now load and transport aircraft as cargo, using the existing cargo system and conventions. This can be used to model the transportation of both manned aircraft (as e.g. in operation “Nickel Grass” during the Yom Kippur War) as well as UAVs. For the full details and instructions, see the section “Aircraft As Cargo” on the web-based Command manual: https://command.matrixgames.com/manual/

– Launch speed-dependent variable burnout speed for air-launched boost-coast AAW missiles. In other words: It is now critically important how fast an aircraft is flying when it launches a boost-coast missile (Optional, enabled by default on new-construction scenarios and quick-battles, disabled by default on existing scenarios).
When enabled, the burnout speed (per altitude) of boost-coast AAW missiles now varies according to the launch speed (in addition to the already-important launch altitude). The weapon’s nominal range assumes a M1.5 launch at 36000ft. If the launch speed is lower (which is usually the case), the effective burnout speed and kinematic range of the weapon will be lower; if however the launch speed is higher this can significantly boost both the burnout speed and the reach of the weapon, way above nominal.
A faster burnout speed provides three critical advantages in the BVR “missile joust”, all other factors being equal:
* Your missile flies further out expanding your WEZ and reducing your exposure to counter-fire.
* Your missile flies at higher average speed, which shortens your commit-engage-disengage cycle and may even turn the tide in your favor if the other guy shoots first.
* Your missile will likely arrive at impact with a higher terminal speed, thus improving its hit probability against an alert and evading opponent.

– Numerous new IAMD-related doctrine options have been added, to facilitate a more finegrained degree of control on ABT, BMD and counter-hypersonic engagements.

– Groundbreaking improvements to the modeling of high-energy laser (HEL) weapons against weapon targets. An Achilles heel on the modeling of HELs in Command until has been the fact that weapon targets (e.g. incoming missiles), contrary to platform targets, have no finegrained/gradual damage model, and thus the often limited damage (in energy terms) dealt to them was frequently misrepresented; the laser shot against them either hit them and always insta-killed them, or missed. A more sophisticated model was necessary, one that took into account the fragility/durability of the weapon target as well as the actual energy delivered to it per successful shot (as already calculated on counter-platform engagements).
Therefore, we developed a system for estimating the durability of each weapon type: for example, a common small-size UAV will be exceedingly vulnerable (most UAVs barely hang in the air), whereas an iron bomb with a precision guidance kit is a much tougher proposition. This “target sturdiness” is then compared against the actual energy delivered by the laser impact (as part of this improvement, the atmospheric absorption model was also thoroughly renovated) and a probability of actually destroying the target is generated. As a result of this change, HELs are now much more faithfully modelled against their primary target set; it now become painfully clear why various armed forces worldwide are in a race for extended ranges and particularly vastly higher power output levels.

– Impact angle / crossing-target as a factor in guided weapon endgame calculations. This has been significantly improved since the original flawed implementation, and takes into account factors such as the target’s LOS bearing-rate toward the shooter, the agility & seeker cross-tracking features of the interceptor, the closing rate etc. So for example under the same difficult circumstances (high LOS rate or high closing speed) the modern ESSM suffers much less degradation than the older Sea Sparrow.

– Plus as always numerous smaller tweaks, improvements and fixes to the UI, simulation engine, connectivity and analysis options.

If you are wondering about the title, the CMO/CPE dev team is already relentlessly preparing a triad of new additions that feature prominently on Command’s development roadmap for the latter half of 2026:

Real-time multiplayer on CMO. Need we say more? This has been announced, is already under testing in a closed-beta environment, and feedback is enthusiastic.
Project Hannibal, a radical renovation of close-combat and ground operations in both CMO and CPE. We gave a glimpse of it on last year’s HOW video, but the whole project is vastly more massive than that. Command already has the best ground ops of any game not focused on them, but Hannibal takes it to another level.
A brand new platform-to-platform comms & datalinks model. If you’ve been noticing that “improved comms & datalinks” is increasingly a major part of the equipment focus on either new or upgraded platforms (“Link-16 and IFDL/MADL everywhere!”), this upgrade will clearly show you what these improved comms give you – and what it means to fight an adversary who out-communicates you.

Stay tuned for updates on these and more developments as the year progresses!

Tags: no tags

End-of-year bonus: Command PE v2.4.3 released

December 16, 2025 · Posted in Command PE · Comment

It’s the most wonderful time of the year, and the Command dev team has one last gift in the stocking for its global professional userbase. After a bit of a delay, but still meeting the intended cadence of two update releases per year, the v2.4.3 update for Command-PE is now finally available for download, for new and existing CPE users.

After the massive v2.4.2 release last August with its smorgasbord of brand new features, v2.4.3 adopts a more conservative approach with an emphasis on reliability, performance and user quality-of-life (QoL) features. Some of the major new features include:

* Explicit GNSS jamming and jammer units: This is effectively the follow-on to the abstract GNSS jamming made possible through the “Side Enablers” feature and introduced in v2.4.2. In addition to defining “access/no access” to specific GNSS networks (GPS, GLONASS, Beidou etc.) at the side- and area-level, you can now use distinct platforms that have the ability to jam these critical systems. Just like with radar & communication jammers, these platforms tend to be expensive and scarce, so you must position them carefully to maximize their coverage and prioritize the assets you wish to protect (or the area to negate). Also similar to other jammer types, their signal can be detected, localized and used to attack these platforms.

More over, the way that GNSS disruption affects terminal weapon accuracy has been tweaked. Instead of measuring the “time without a PNT fix” and using that to calculate the INS drift, the simulation now actually keeps track of the last 50 PNT-fix attempts (both successful and unsuccessful) and uses a simulated Kalman filter to derive the final internal drift. This provides a more true-to-life effect on disruption, as (for example) a single PNT fix is not sufficient to fully “reset” the navigation precision to nominal status.

* Salvo simultaneous weapon arrival: “I wish my cruise missiles arrived at the target area in a nice, strung-out line so that the defences could swat them down one by one” – said no strike planner, ever. The navigation logic on weapons that support TOT has been tweaked so that, within a salvo, all weapons will closely bunch up in order to arrive at the target simultaneously, overwhelming the defences. (Inter-salvo coordination remains the responsibility of the player, either manually or through the MDSP).

* Incremental / timestamped saves: You’ve long asked for an easy way to undo/rollback edits or changes on a scenario, and this it. This new feature saves timestamped copies of the played scenario, instead of overwriting the existing scen/save file. This takes up more disk space, but makes it easy to go back to a past version.

* Improved time synchronization and time acceleration control: The logic of sim-loop execution has been tweaked in order to more precisely match elapsed sim-time and wall-time when running in realtime (1x). This fixes a reported problem where e.g. a 1-minute of sim time could take 1m6sec of wall-time while running in real-time mode. This can be important for real-time exercises & federated simulations (e.g. when using DIS).

In addition, the optional HighSimSpeedTimeSync setting in Command.ini allows throttling of flame and double-flame sim speeds to stay in sync with clock time while running in the GUI, making them equivalent to 30x and 150x respectively.

* Vast A2AR improvements: A enormous amount of work has been dedicated to improving the mechanics and experience of air refueling operations:
– General reliability whit high sim speed: Increased reliability by throttling down sim speed (from double flame to single flame) when performing or about to perform AAR.– Prioritization and Reservation: Reworked prioritization logic to better handle concurrency between clients in scenarios with few tankers, taking better consideration of other enqueued clients when calculating availability of fuel and refueling equipment on the tanker. Also fixed various issues such as AAR being cancelled right after being scheduled, wrong tanker selection criteria being utilized in various situations.– Execution: Tankers and clients now follow refuel orders even when unassigned or without a course, forced and manual refuel orders are respected and refuelling from a tanker that is being refuelled is now prevented.Other fixes resolve issues with AAR triggering on the incorrect lightplan waypoint, cargo missions not refueling on RTB and various other issues that caused AAR doctrine to not be followed as expected.
– Flight Plan Editor: Various fixes, and QOL tweaks to the Flight Plan Editor in the management of Refueling Waypoints and their doctrine setting

* Improved manual salvo control: An “Execute” button has been added to the Manual Weapon Allocation (aka “Shift+F1”) window. Now when the player creates weapon salvos through this window, by default they are scheduled to be executed “far into the future”. If the player then clicks on “Execute” or closes the window, the created salvos are re-scheduled to be fired as soon as feasible. The change causes salvos that are created when using this form to be scheduled impossibly far in the future. When the user clicks ‘Execute’ or closes the form then the salvos are all updated to fire as soon as possible.

Therefore, the units assigned to these salvoes will NOT start executing them (or even maneuvering towards the targets if necessary) until the execution is signaled. This gives the user the ability to delete the salvo, plot a course of the salvo, etc. without having to try and do it before the assigned units start firing.

Other bits & pieces:

* Land-strike weapons that nominally have only fixed targets as valid (e.g. JDAMs) can also be used against mobile vehicles if they are stationary
* The various map-settings menu options have been duplicated on a dedicated “Map Settings” window (accessible through top menu –> Map Settings –> Map Settings Window). This makes it much faster & simpler to change multiple settings in quick succession.
* When evaluating chaff effectiveness (probability to successfully seduce) against a given radar seeker, the target’s apparent radar size (RCS) is taken into consideration. So, for example in a very large (RCS-wise) target the chaff becomes less effective at spoofing the missile, whereas with a very small or stealthy target the chaff will almost always be effective.
* Units that are within the relevant engagement range of another unit (e.g. aircraft inside nominal range of SAM site) and are being illuminated (for weapon fire control / guidance) by that unit will consider themselves under attack (and take relevant action, e.g. evade if allowed) even if no distinct weapon is detected incoming.
* Flight plans are now drawn as orthodromic lines (ie. correctly curving over the globe; most clearly evident on long-range routes)
* Added the ability to change the color of borders, coastlines and the sea ice.
* Various tweaks and improvements to DIS support.
* Units tasked with SEAD patrol will engage not only detected radars but also jammers (both radar- and GNSS-jam emitters).
* On mission types that utilize the “1/3rd rule” and “number of class” settings (e.g. patrols), these settings now include new unit grouping options. Players can choose to group aircraft by Loadout (same class + same loadout), group all units by Unit Class, or use No Grouping, which allows grouping strictly by flight size without filters.
* You can customize the expiration time of any contact type. This can be useful if e.g. you wish to keep submarine contacts around for longer after their last detection.
* Players in an RTMP session can be restricted in certain powers (for example blocked from having Absolute Control mode, or loading autosaves, or changing the time acceleration).
* You can now load a scen/save file simply by drag-&-dropping it into the main map window. (This works only if Command.exe is running under a non-admin context).
* Nuclear submarines with natural circulation on their reactors get significant noise-reduction benefits at shaft speeds up to 15 knots.
* On anti-weapon engagements, if the target’s speed is much higher than the weapon’s max design target speed, PH drops to 1% (pure luck).
* The “Jettison” button now gives you more options of weapon type for you to drop.
* New Lua API abilities: Display satellite-specific data (e.g. launch date), send a unit to refuel, retrieve the current sound level of a naval unit, handle flight plan properties, and display detailed sensor properties.
* Lua calls (not interactive) are now cached when first compiled (string parsing and compilation of a script is one of the worst offender for Lua performance); this should significantly improve performances for recurring calls (such as events) especially long chunks.
* Ability to convert an airbase installation to a single-unit airfield (Right-click –> Scenario Editor –> Convert to single-unit airfield). This can be useful during scenario creation to keep the unit count manageable in large scenarios.
* Improved the way images are fetched on-demand from the server and populate the unit image thumbnail (on the unit status panel) (It is no longer necessary to select another unit and then back the original one in order to see the downloaded image)

And as always, the new update benefits from the updated official scenarios and the most recent releases of the DB3000 and CWDB database.

NOTE: The previously slated for v2.4.3 “Aircraft as Cargo” feature was not ready for inclusion and thus has been delayed. The dev team remains committed to including it on the next CPE update release, in early 2026. Stay tuned!

Tags: no tags

Dank u Brussel!: A roundup of the 12th Command User Event

September 17, 2025 · Posted in Command PE · Comment

It was a week!

From the 8th to the 12th of this September, Command-PE users from across the world coalesced into Brussels for the 12th Command User Event. Attendees reconnected with familiar faces, met new colleagues, shared use cases, and explored the latest Command-PE developments. They also got a glimpse of exciting new features on the horizon.

The Command team was once more honored and exhilarated to host the event and share our past and future work with all present. At the same time, a series of fantastic guest-speaker presentations underlined once more how CPE’s incredible versatility and flexibility have led to it being used for purposes we could never have imagined – while still being the stalwart choice of pros in entirely predictable sections of the defense, wargaming and simulation industry.

As with last year, summaries with photos for each day of the week are available through Matrix Pro Sims’ LinkedIn account:

We would like to thank each and every one of our guests for attending the event. You all made it clear to us that you loved being present and found the experience as useful and informative as each past year, and for us can be no higher vindication and reward.

We would especially like to thank and salute our guest speakers:

Major General Matthew Van Wagenen & Colonel Arnel David (NATO SHAPE)
Vice Admiral (ret) Georgios Floros (Matrix Pro Sims)
Jakub Orlowski (Damen Naval)
Martin Van Lavieren (NavTrain)
Dr Paul Cross & Jamie Etherton (DSTL)
Commander Oliver Kohls & Commander Jorg Feldhausen (NATO COE-CSW)
Even Hvinden (FFI)

You have, once more, opened our eyes and those of our guests, to what is possible out there when using a platform like CPE.

We’re already preparing for CUE 2026 and can’t wait to welcome both familiar and new faces. Mark your calendars and be part of the next chapter in Command-PE’s journey!

Tags: no tags

The muscles for Brussels: Command PE v2.4.2 has been released

August 12, 2025 · Posted in Command PE · Comment

You knew this was coming.

Following the official release of the CMO v1.08 update, it was Command-PE‘s turn to receive a new significant update release. This has now come to pass: CPE v2.4.2 is now available for download to all CPE users.

We have previously covered in detail the new major features introduced in CMO v1.08, and these are all also included in the new CPE update, so a detailed repetition may arguably be redundant. A brief bullet list, however, makes sense as a refresher:

Side-enablers and GNSS disruption
Drone autonomy levels
3D terrain view & vertical scaling
Doctrine/ROE UI & UX improvements
Early ASCM terrain-following restrictions
Chainsaw/Grinder patrol movement style
Depressed-trajectory ballistic missiles

These are not, however, all that is new here, as the new update also includes several features and improvements unique to the professional edition of Command:

New Lua-Hook event overrides: DetermineAttitudeAndThrottleBefore and DetermineAttitudeAndThrottleAfter . These two hooks are relevant to the step where a unit (platform or weapon) determines what its desired new attitude (heading/pitch/roll), altitude and speed are going to be. NOTE: This is distinct from UnitMovesBefore and UnitMovesAfter, which override the actual movement & re-orientation. It is the different between overriding “I want to go there” and “I am physically going there”.
Massive speed performance when using the Lua TCP/IP server feature: The response string now includes “\r\n\r\n” at the very end as a terminator flag, so that the client can see this and immediately close the connection instead of timing out. This allows an increase in communication throughput by *orders of magnitude* when using the Lua TCP/IP interface. Clients that do not recognize this termination will still work normally but will not get the performance benefit.
Variable output frequency for DIS PDUs. Just like with event-export, It is now possible to configure CPE to output DIS PDUs (and especially those of the “EntityState” type) at a variable, rate to allow chocking on the network connection. The configuration follows the format already established for event-export, with output frequency configurable per speed bands of the units in question.
Multiple DIS Force-IDs per CPE instance. Until now a limitation of CPE when acting as a DIS federate was that only one force (ie. side) could be running locally on the running CPE instance. It is now possible to have multiple sides locally owned on the running CPE instance.
You can now add custom DBs to the DB folder and load them in ScenEdit immediately, without needing to restart CPE.
It is now possible to use custom (unregistered) database files with the Lua “tool_buildScenario” function.
The WEGO-MP server always uses 1.0s sim pulse and not dynamic throttling

Plus of course all the content and database updates that have also accompanied the recent CMO release.

The new CPE update forms the perfect companion to the upcoming 12th Command-PE User Event, to be held in Brussels this September. Early-bird discount bookings are now closed but there a select few seats still available, so hurry up and reserve your spot today. See you up close next month!

Tags: no tags

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 · Comment

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).

UPDATE: A late arrival: Depressed-trajectory ballistic missiles

This is a new feature introduced in Build 1662, during the v1.08 public beta. By default, most ballistic missiles use the lofted/”high” trajectory leg when fired at less-than-maximum range. (When the firing range is just a small fraction of the max range, this can result in absurdly high apogees; witness, for example, the recent North Korean missile tests.)

Instead, missiles who have the “depressed trajectory” capability will use the “low” trajectory option in any less-than-maximum range shot. This has several advantages: A reduced flight time, a (much) lower apogee which means a reduced detection range & reaction time for enemy ground-based sensors, and spending a higher portion of the flight inside the atmosphere is very useful for systems that utilize maneuverable reentry vehicles (MaRVs).

(NOTE: This feature requires the v512+ databases. Also, initially only the Russian Iskander-M/E and its North Korean analog KN-23 are flagged as such in the database. If you have sources for other systems having the same capability, feel free to share them on the DB tracker: https://github.com/PygmalionOfCyprus/cmo-db-requests/)

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