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

From commercial toy-quads to free-ranging hunter-killers: Drone-autonomy levels in Command

April 5, 2025 · Posted in Command, Command PE · Comment

“True drone autonomy isn’t just about flying without a pilot—it’s about making real-time decisions in unpredictable environments, with limited data, constrained power, and no room for error”
– ChatGPT, reflecting on its siblings on the front line

Uncrewed combat & support platforms (aka “drones”) are all the rage these days in defence circles, and not without good reason. However, they suffer from a fundamental limitation compared to more “traditional” crewed platforms: When not under direct human control (ie. in a realistically comms-challenged environment in any non-lopsided conflict), their ability to autonomously carry out their intended mission is drastically curtailed. By how much? Well, contrary to men, not all drones are created equal – and hence one of the new major simulation features of Command: variable drone autonomy levels.

The question of how much autonomy we are willing to grant to conscious-less machines armed with lethal weaponry has long escaped the confines of legal & ethical theoretical discussions, and is already hammered in the front lines of Ukraine, Syria and elsewhere, as well as the virtual battlefields of the major powers where doctrine, tactics and operational art are forged (see this excellent article by Bill Sweetman on the dilemmas of how best to employ CCAs in a future peer conflict).

Public western/NATO literature on the subject commonly refers to different degrees of “drone autonomy” and then assigns individual uncrewed systems to each of them, to distinguish their autonomous capability. The dev team’s chosen structure closely (though not precisely) follows this public nomenclature. Let us explore the different levels and what they actually mean in the field, when their comms are lost:

– Remotely Piloted: These are the cheap & cheerful quadcopters or small-sized wingcraft or UGVs/USVs you can buy at your local store and have up and flying / rolling / sailing within minutes. Due to their low cost and high numbers, they are very popular in battlefields where comms are not contested. They are remotely-piloted and entirely dependent on their human operator for control. If comms are disrupted, they will stick with their last-ordered course and speed until comms are re-established; if they are not, then they’ll run out of fuel/energy and halt in place (or crash if airborne). While offline, they are unable to take any initiative in order to further their mission.

– Self-Recovering: Things are slightly improving here; if the comms link is lost, these units will loiter/hold at their current location and try to rejoin the comms grid; if successful they will resume their mission, otherwise they will autonomously return to their deployment base/host. It doesn’t sound like much, but retrieving back effortlessly your comms-disrupted force rather than losing them to every comms-jammer out there really does make a difference.

– Changeable Mission: (A more accurate description here might be “Flexible in-mission behavior”, but we don’t get to choose the terminology). A pretty significant jump in autonomy here: The offline vehicle will actually move ahead and try to perform its assigned mission. The bad news: Because of the lack of human oversight, the platform will not perform any pre-emptive checks for own damage, bingo/joker fuel status or winchester/shotgun weapon status – checks that (under human supervision & positive control) would trigger an immediate abort & RTB. In other words, it will press on to its mission even if it is objectively incapable of actually pulling it off and surviving.

– Fault/Event Adaptive: Another major step forward in intelligent behavior here: The platform will actually perform pre-emptive checks for own damage, bingo/joker fuel status or winchester/shotgun weapon status, and thus will avoid needlessly kamikazeing itself into a hopeless situation.

– Multi-Vehicle Coordination: Drones can be quite more effective when they are used in big groups (aka “swarms”). This level of autonomy allows a drone to participate in such a group – but only strictly as a group member. It can perform independent maneuvers only if it is the group’s designated leader.

– Battlespace Cognizant: This is an absolutely huge leap forward, and allows an offline unit to finally evaluate targets and threats on its own, rather than sticking to pre-assigned targets only. It can also maneuvers independently even if its part of a swarm, it can intelligently change its desired home base (though only from available fixed bases, not mobile bases like aircraft carriers) and can evaluate UNREP or air-to-air-refueling opportunities.

– Fully Autonomous: Now we are stepping firmly into Cyberdyne Systems territory. Fully-autonomous drones treat comms isolation almost as a nuisance rather than a crippling handicap: In addition to freely evaluating the targets & threats within their predefined mission parameters, they are also free to evaluate and engage any targets of opportunity that are relevant to their available weaponry. They are also able to modify their mission course instead of sticking to their predefined one, as well as changing their home base destination, either fixed or mobile. Such a unit will most definitely ask you for your clothes, your boots and your motorcycle – and you’ll be wise to accede. If the thought of heavily-armed robots having this freedom of action doesn’t give you pause, you might had been an excellent Carmageddon player.

The autonomy level of a drone is displayed on the DB viewer:

It is also accessible (and editable) through the Lua API:

theU = ScenEdit_GetUnit({name='Anka-S UAV', guid='4FTZEE-0HNA5SMK3O9K4'})
theU.autonomylevel = 1500
print(theU.autonomylevel)

(Note: In DB3000 v510 and previous versions, most drones have their stock autonomy level set to “Undefined”. We therefore recommend using v511+ when using this feature)

One common characteristic of off-grid drones is that, when they get disconnected from their side network, their mission becomes “fixed” for them. In simulation terms, they obtain and use a “private snapshot” copy of their mission state as it was at the moment of disconnect, and use that as reference. Any changes on their original assigned mission are NOT reflected on their private snapshot; for example if the doctrine or ROE settings change, or the area of a patrol shifts around, the disconnected drone sticks to its “known” mission parameters; this is one of the key operational drawbacks of even the most advanced autonomous drones.

The Mission Editor has been adjusted to display such “snapshot” missions, if they are the selected ones (for example, if the player is in direct control of an isolated drone and selects its mission):

The ME window now also more clearly displays platforms who are assigned to a mission but are currently off-grid:

When a unit is off-grid, any attempts to transfer it to another mission or change its mission parameters will fail.

Variable drone autonomy levels is an opt-in scenario realism feature (disabled by default, to avoid disrupting existing scenarios). It is one of the biggest new simulation features of Command, and one of the key new additions on the new upcoming major update.

Tags: no tags