Countdown to War Planner: Simulation Additions & Improvements

Command’s “War Planner” update (aka “Tiny”) is set to release just a few days from now. Are you ready for Command’s biggest update yet?

In this multi-part series we take a look at the various key features introduced in this massive, FREE upgrade to Command.

We have already seen in sequence the “headline” major new features of this release; this time turn or attention to various smaller-scale but still critical additions & improvements on the simulation engine, who altogether raise the fidelity and power of Command as a wargaming and simulation tool to new heights.

This article concludes our pre-release coverage of the War Planner update and its major enhancements. We would like to thank everyone who assisted in the public beta of this massive release and provided useful feedback. You have been very much a part of this update – so enjoy it!

In this series:

• Overview
• General Improvements and User Interface
• The Operations Planner and multi-missioned units
• The Multi-Domain Strike Planner
• Cargo 2.0 – The Logistician’s Nirvana
• Simulation Additions & Improvements

---

Simulation Additions & Improvements

NEW FEATURE: Energy-based flight model for boost-coast missiles

Boost-coast anti-air missiles (ie. most tactical missiles that are not powered continuously) now use a much more realistic flight model that distinctly models the initial boost-sustain and post-burnout regimes, and takes into account the effects of gravity (shedding speed while climbing and regaining it when diving) and aerodynamic drag. The drag changes with altitude, built-in drag coefficient and whether the weapon is maneuvering (pitching/turning) or not. This change makes it possible to apply real-life “exhaust the threat” tactics and further constrains edge-of-envelope shots.

The onboard fuel (and thus boost duration) varies with the type of missile propulsion. Most AAW missiles (e.g. Sidewinder, Sparrow, all Standards, pre-D AMRAAMs etc.) still rely on the “traditional” boost-(optional sustain)-coast sequence, in which case the rocket motor is active usually for a few seconds. Some missiles (SA-4, SA-6, Sea Dart, Meteor etc.) use ramjet propulsion to provide for a much longer burn duration, and this allows them both a much higher average speed-to-target but also a higher energy state on the terminal engagement, which increases their chance of impact. Other new systems like the AIM-120D use “dual-pulse” rocket motors to again achieve a substantially higher overall energy state.

(NOTE: On missiles that use this model, the “fuel bar” indicator now represents only the remaining boost-sustain fuel, NOT to the total remaining energy. After burnout, the fuel bar is removed and the weapon will coast until it reaches its stall speed.)

 

Significant changes in default aircraft defensive maneuvers

Instead of beaming and diving to the deck by default, now they will first try to outrun an incoming missile while matching its relative pitch (i.e. climb if the missile is below them, or dive if it’s above them), and if the missile closes the distance they will then attempt to beam it (or its parent guidance) while also reversing their climb/dive.

To counter these counters, new additional WRA firing-range settings (including “No-Escape Zone”) are available, offering a much more comprehensive set of range options (see the UI improvements article). A2A and S2A missile engagements are, as a result, both more dynamic and far more realistic now.

(NOTE: These two changes have been arguably the most controversial ones during the public beta of the War Planner. The typical complaint by many players is “My AMRAAMs are now useless unless if fire them almost at point-blank range”. Our response to this is: EXACTLY. Welcome to the real-world kinematic limitations of most AAW missiles (against agile & alert targets, at least). This part of the reason that most (all?) real-life BVR kills have been achieved at significantly less-than-nominal launch ranges. Watch this BVR tactics video from F4 BMS and note how on each case the missiles are dragged-out rather than outmaneuvered.  WRAs and configurable firing ranges are a thing – and with the new percentage-based settings and NEZ they are more powerful than ever. Learn them, practice with them and use them. Or get used to becoming your adversary’s chew-toy, first by the enemy AI and later by other human players as MP comes to commercial CMO.)

 

NEW FEATURE: Passive Coherent Location System (aka “Passive Radar”)

The term “passive radar” has grown to broadly encompass two significantly different concepts; one is ESM/SIGINT-based air-surveillance systems and the other is multistatic radars with third-party emitters. The latter is called Passive Coherent Location System, and for a general background on the technology and CONOPS see here: https://en.wikipedia.org/wiki/Passive_radar

PCLS systems can be very capable against VLO targets (if the geometry is right), and their passive nature makes them inherently less vulnerable to SEAD attacks (although of course the emitters-of opportunity may themselves be targeted). On the other hand the geometry restrictions can be a tough taskmaster (the emitter, the receiver and the target must form a clean-LOS triangle otherwise there is no detection) and the signal propagation geometry sharply reduces the effective detection altitude. Therefore such systems are most effective when combined with other traditional active & passive surveillance sets rather than operating completely on their own.

The v488+ releases of the DB3000 database contain several “non-detecting emitter” platforms such as radio, TV, and cellular antennas or navigation beacons such as LORAN. It also contains a prototype PCLS vehicle that can be used in testing and as the basis for operational variants.

 

NEW FEATURE: Distinct mobile ground units

In addition to modelling mobile forces as “aimpoint facilities” (see: https://www.warfaresims.com/?p=1159 ), it is now possible to explicitly model individual vehicles with their own customized properties such as armor, propulsion, mounts, sensors etc.

The new-style ground units have unlocked certain brand-new capabilities, such as true amphibious vehicles (with distinct speed & fuel consumption properties overwater and on land).

 

NEW FEATURE: Intermittent emissions

This band-new feature allows to control the behavior of emitting sensors so they emit in intervals instead of only continously or never.

Alert levels

The first thing to do is to configure a unit’s interval according to the alert level. The alert level is set in the EMCON setting of any unit and affects the whole side. Below, in the “Active Emission Interval” we have the intermittent emission configurations for each alert levels. The side’s alert level will determine which intermittent emission configuration to use:

Emission Intervals

Let’s configure an EMCON behavior for the yellow’s alert level. By default, the interval type is set to continuous, this is the usual behavior in command where an enabled sensor will emit continuously. Emission Duration is the duration in seconds of an emitting phase. Interval is the duration in seconds of a silent phase between 2 emitting phases. Interval random variation is the random duration in seconds we add to an interval. This allows unpredictability of the cycle and is particularly useful to disrupt the enemy’s plan:

The action of waking up mean that the radar will temporarily turn into continuous and ignore intermittent behavior, until time until sleep mode is elapsed. The Wake when detecting threat checkbox controls this behavior, a threat is a unit defined by the checkboxes group includes stance and includes ID. If the radar detects an unfriendly or hostile or unknown contact with any identification level, then we wake up the radar.

If you want a unit to inherit all configuration from its parent check Use parent group parameters:

NOTE: intermittent emission will NOT make a radar active or inactive as depicted below:

Intermittent emission controls whether or not an active radar will be silent or emitting at a given moment.

Custom emission intervals configuration

If you want to use all alert level, you will need to define each interval configurations, and perhaps you want a way to override the alert level and have some units feel special and use their own rules:

To do this, populate the Custom interval tab as you will and make sure the Use custom preset only checkbox is checked.

 

NEW FEATURE: Custom Environment Zones 

Multiple & moving weather fronts? Check. Bend the laws of physics on a localized area? Can do. Specify carefully hand-picked weather, terrain and other environmental properties in order to test or compare sensors and other environment-dependent components? Yup. Unleash your inner nature wizard with this puppy.

Using this new feature, you can define a zone where you can tailor the environment & weather properties. This can be useful if you want a “controlled environment” for sensor checks, mobility & damage tests etc., but can also be used as a localized “weather override” for scenario purposes. 
To create a CEZ, bring up the Refpoint Manager and switch to the “Cust Env Zones” tab. Create a zone as usual, and then click on “Edit”. A new window should appear, in which you can define the weather & environment properties:

 

NEW FEATURE: Palletized weapons and other stores

This is a new capability that has been making the public rounds lately, as a result of a series of videos by AFRL  on the Rapid Dragon concept. using pallets packed with guided weapons, aircraft not usually associated with frontline attack operations (such as transports) can contribute to the firepower volume allocated at enemy forces.

As usual, there are caveats. The fact that weapons are fired from released pallets, rather than individually fired from the parent platform, means that weapon allocations must happen in batches; if a single missile in say a 12-pack is allocated, the full dozen has to be allocated either on the same target or others. (There exists of course the theoretical option of allocating only the desired amount of weapons and just sacrificing the rest of the pack, but the cost of the majority of modern weapons makes this an unlikely scenario).

Therefore, accurately modelling this new capability (and the decisions & restrictions it enforces) to Command has been a lot of work. Here’s what we’ve come up with:

• Pallet Weapon: the paradroppable system (usually a pallet, but may also be a container etc.) containing the payload
• Pallettized Weapon: the content of the pallet, the actual weapon that will be delivered

Pallet Weapons can be fired by specific aircraft that are equipped with suitable loadouts (C-130, C-17 etc.). Several new representative loadouts have been included in the DB3000 database:

 

Pallet and Weapon Allocation

Pallet Weapons can be allocated to a target both as a Pallet or by assigning a single target for every Palletized Weapon in the aircraft Loadout. When allocating a whole Pallet, all the weapons within it will be added to the salvo, and all of them will share the same target as the Pallet:

Single (individual) Pallettized Weapons can also be allocated clicking on the relative node in the tree:

NOTE: As mentioned, due to the nature of the weapon system the whole Pallet is dropped even when some of the weapons within are not allocated. So take care to allocate the full pack! A message will serve as a reminder in order to avoid wasting weapons:

 

When the Pallettized Weapons are allocated separately, the system will recognize how many Pallets are needed to fill the requested salvo quantity and will drop the appropriate amount of Pallets:

Pallet and Weapons Behavior

When dropped from an aircraft, the Pallet will align itself following the correct loitering pitch, and after reaching that pitch it will deploy the parachute and start to loiter. After the Pallet starts to loiter, all the allocated weapons are fired from the Pallet:

Example with multiple Pallets:

Pallets have one more tick up their sleave: Because they remain in coms (datalink) with their parent aicraft, you can allocate additional weapons remaining in them while they are para-dropping. Obviously this can be very useful for delayed fires against targets as the tactical situation evolves. This can be done simply by clicking on a Pallet and then allocating its hosted weapon(s) as usual:

Effect on WRAs

All the WRA will now include the weapon info for the Pallettized Weapons. Since the Pallet itself is just a carrier, it is not subjected to any WRA and will follow the WRA of its hosted Pallettized Weapons:

 

New facility category: Surface + Underground

This new facility category represents facilities that are buried underground but also have major access from the surface in order to operate. Examples are all ballistic missile silos, some command bunkers, retractable coastal-defense turrets like ERSTA etc. These facilities are vulnerable to damage/destruction both from direct weapon impacts on their surface area and also from underground shock from near misses by penetrator weapons (or exceptionally powerful surface detonations e.g. from a multi-megaton warhead or asteroid impact).

 

Significant improvements on ballistic missile kinematics 

Ballistic trajectories have been reworked from the ground up, using true Kepler equations to reflect the movement of planetary bodies. This produces true-to-life boost-phase profiles and overall trajectory parameters (this is important in order to more faithfully model the abilities & limitations of BMD systems).

Improvements in ABM DLZ calculations

ABM systems have additional fail conditions in their DLZ evaluations compared to normal SAMs. A prime example is the intercept “hard floor” for exo-atmospheric systems. For instance, SM-3 cannot make intercepts under 100km in altitude (because its “warhead”/kill-vehicle is effectively a miniature spacecraft with a very sensitive IR seeker and no aerodynamic control, and thus cannot function within the atmosphere). This factor severely restricts the system’s intercept window: If the estimated intercept point is within the atmosphere, it is already too late to shoot. This screengrab from a LM THAAD-ER promo video illustrates this well:

In addition, the case of “intercept will happen within weapon minimum range” has been added as a fail condition to DLZ checks.

 

Overhauled Reaction Times

The differences in reaction times, and their effects, are now more critical than ever. All units use common-reference “Combat System Generation” (“Cockpit Generation” for aircraft) to model the modernity of their combat systems, combined with an “Ergonomics” value to handle intra-generation differences (the atrocious switchology on early missile-age aircraft will most definitely get you killed now). Older, WW2-era ships may take up to 5 minutes to engage a target, while Aegis cruisers fire in <20 seconds. Cold War fighters will be beaten to the draw by modern, fifth-generation fighters. Overmatch, that ever-elusive dream, is now possible – but beware, it goes both ways.

Until now, the existing OODA model was hobbled by two major problems. First, most values were way too fast. Detection, targeting, and/or evasion usually took less than 20 seconds. This works for ships equipped with modern combat systems, e.g. upgraded Aegis; not so for Cold War clunkers (or, heaven forbid, a pre-WW2 battleship). Second, having to manually set OODA values per-ship meant inconsistent reaction times across combat system generations.

For the revised model, we’ve added a new component to ships: the Combat System Generation (CS Gen), which can range from Gen 1 (1945-1950) to future Gen 7 (2030+). Whether you’re plotting contacts on a plotting board, federated CPUs, or an integrated system – and the age of the components making up those systems – will have a huge effect on your ability to quickly react to and engage targets. A modern Aegis ship can spot, track, and engage a contact in about 20 seconds; for a ship with a WW2-vintage CIC, the process balloons upwards to almost five minutes. If your first detection of an incoming missile comes from your own radars, it may not be enough.

There is an exception for small craft, which regardless of age generally have extremely fast reaction times (this is because their targeting process essentially consists of shouting at the guy on the MG to “shoot that guy over there RIGHT NOW”). However, this is mitigated by their comparatively less powerful sensors and weapons: being quick on the draw doesn’t help much when the Mk1 Eyeball on your RHIB spots a Hellfire inbound.

“But wait,” we hear you object. “Doesn’t this mean that, given an especially old ship and a modern threat, I may find myself completely helpless against an incoming missile?” The answer is yes: those Final Countdown scenarios are going to play out very differently now. This was a major concern for naval planners during the Cold War (the development of NTDS, the US Navy’s first automatic data-exchange system, was driven by classified exercises & wargames in which USN ships were consistently sunk before they could react to incoming air & missile strikes).

For aircraft, the flying equivalent to the “Combat System Generation” for ships, the “Cockpit Generation” is a way for us to approximate pilot load – and subsequently reaction times – based on cockpit design. Aircraft can be assigned one of six cockpits: “Basic Instruments Only,” intended for the simplest aircraft; “Steam Gauges, ” as for WW2-era fighters; “Complex Steam Gauges,” for the nightmarish mid-Cold War fighters; “Partial Glass Cockpit,” for transitioning aircraft of the ‘70s-90s; “Glass Cockpit,” for most modern aircraft; or finally a “Panoramic Cockpit Display,” representing the new single-screen touch displays coming to a fifth-generation fighter near you.

Just as a ship is only as good as its CIC, your aircraft are only as good as their cockpits – and whether your pilots are forced to fiddle with a forest of knobs, switches, and dials or able to glance at an easy-to-read LCD will affect their performance. Of course, the difference between aircraft cockpit generations is far less than the difference between ship CS generations, measured in seconds rather than minutes – but in an aerial engagement, seconds do count.

For submarines, facilities and mobile ground units, we have followed a similar path. We split submarine combat systems into six distinct “generations,” ranging from the early Mk1/3/4 TDC used in WW2 to the modern AN/BYG-1 and future witchcraft as featured in SSN(X). Facilities and ground units required a slightly different system: rather than using multiple “generations” as with ships and subs, these annexes distinguish between fixed and mobile systems and whether said system uses manual or assisted guidance. For example, radar-assisted AAA (e.g. Skyshield) will be faster to engage than a manual gun (ZSU-57); both (towed) systems will be slower at evasion than a SPAAG. The same is true for manually laid artillery vs. those with digital fire control, towed artillery vs. SPGs, etc. While less detailed than our system for ships, subs, and aircraft, we felt this was “good enough” for the level at which these platforms are simulated in Command. (And, of course, we always have the manual override for when we have specific platform data.)

This is obviously is a major set of changes and potentially game-breaking for older scenarios. For this reason, the SBR tool now also includes the ability to preserve “legacy” OODA values when migrating scenarios to v494+ databases. For pro users, the DB Editor also offers the ability to explicitly set custom values and selectively override the generation-derived ones.

Extra wrinkles: Ergonomics

Not every aircraft built with steam gauges was equally difficult to fly; not every ship built in a certain decade could react with identical speed. Certain platforms gained a reputation for being especially easy to operate (the Viggen, for example, had a remarkably well-designed cockpit); others, like the Komar-class missile boat, were the bane of their operators. Much of this can be ascribed to ergonomics, the consideration (or lack thereof) of human factors in design.

The new “ergonomics” field – ranging from “Awful” to “Excellent” – is intended to reflect these intra-generation differences, acting as a sort of OODA “buff/debuff” and giving the ability to adjust values to reflect upgrades, etc. without needing to take the drastic step of upgrading the combat generation.

And, of course, you still have proficiency in the mix. Players now have an interesting mix of factors to consider:

– “Tech generation,” e.g. CS/cockpit generation: when was your platform designed/built, and what sort of tech was in play at the time? Are you working with ancient WW2 plotting boards or Aegis?

– Usability/ergonomics/design: are you working with beautiful, top-of-the-line COTS human interface tech or the nightmare that was mid/late-Cold War Soviet systems?

– Proficiency: Do you have well-trained, well-rested/motivated crews, or are you dealing with bottom-of-the-barrel conscripts?

Those three factors will all have to play into your operational planning.

 

Radar & IR Stealth Modifier Improvements

Sensor improvements come coupled with a massive overhaul of signature modifiers in the DB, which significantly improve the realism of our stealth model by drawing clearer distinctions between shaping and RAM generations.

Prior to the v494 DB releases, we could classify an aircraft as having “light,” “medium,” or “heavy” stealth shaping … and that was it. These modifiers were applied always in all aspects (no ability to define e.g. a frontal-only reduction modifier). Modeling of IR signature suppression (IRSS) techniques was even more limited.

In v494+ we completely overhauled our existing VLO modifiers to account for shaping and RAM generations. In addition we also added several special flags to indicate the presence (or lack thereof) of certain stealthy design features. This allows us to model not only general, whole-craft stealth but also context-specific or aspect-specific features such as S-shaped intakes, exposed fan blockers, active cancellation, and stealth pylons. For example, S-shaped intakes reduce the likelihood of being detected head-on, while LO pylons reduce the impact of externally-carried stores.

This overhaul also extends to IR modifiers. As with radar stealth, we completely rewrote our “general” modifiers to represent whole-aircraft IR signature suppression techniques (distributed vs. conventional fuel tanks, low-E coatings etc.) and added several additional aircraft codes to represent specific IRSS features. These codes include shielded “anti-Strela” exhausts, masked exhausts, heavily masked / slit-shaped exhausts, and peak temperature reduction or “cool-air mixing”. Note that certain IRSS features come with downsides and limitations: slit-shaped exhausts, for example, will make you harder to spot but paradoxically easier to lock on to with IR weapons due to back pressure penalty; in another example, anti-Strela exhausts are most effective against someone trying to get a lock from below.

The full list of added signature modifiers is:

• RCSS – Active Cancellation
• RCSS – S-Shaped Intake(s)
• RCSS – Exposed Fan Blocker(s)
• RCSS – Stealth Pylons
• IRSS – Shielded Exhaust (Anti-Strela)
• IRSS – Masked Exhaust
• IRSS – Heavily Masked / Slit-Shaped Exhaust
• IRSS – Peak Temp Reduction (Cool-Air Mix)

We’ve backfilled all LO/VLO aircraft in both DBs with these features as best as we could determine. (Naturally, in many cases and especially with contemporary stealth fighters, exact details are sometimes hard to come by.) These changes mean that various LO/VLO aircraft are now much harder (or easier) to detect than you may be used to. We have solid confidence in the results; comparisons with known real-world RCS & IR data yield accurate numbers. However, we’re also open to feedback: expect tweaks in future DB releases as we hone the new values. Pro users can of course manually input their precise classified figures as before.

 

IR & Visual Sensor Improvements

Closely related to the above, this was initially presented and discussed in the professional edition context (see presentation side to the right) but applies equally to the commercial edition.

IRSTs and high-mag cameras are no longer near-magical counter-VLO sensors. They may still be your best bet for detection, but you won’t be volume-scanning for stealth fighters at >100nm anymore. (You can still spot/track them pretty far enough IF something/someone else first cues you there). Abhirup Sengupta broadly explains the tech background behind this limitation well in this Quora post.

The relevant sensors now have a dual value in the search range listing in the DB value, to make it more explicit where their volume search extends to. For example, this listing for the PIRATE IRST system on RAF’s Typhoon Tranche 3:

…indicates that the system can perform un-cued volume search out to 20nm, but can track already-detected targets out to 100nm (both cases under ideal conditions).

Visual and IR checks are now also susceptible to look-down clutter. For example, it is easier for an IRST (or the plain Mk1 Eyeball) to pick out an aircraft over the horizon line than against the surface background.

 

Degree-Definable Sensor Arcs and Vertical Scan Limits

This is a seemingly small but important improvement to our sensor modelling: at last, sensor arcs can optionally be defined in degrees, rather than just in “pie wedge” set sectors. We’ve also implemented vertical sensor arcs, which were especially important during the Cold War. Older air-to-air radars were often limited to a small chunk of vertical space (20 degrees or so), which meant that fighters would struggle to detect aircraft far below or above them. For air planners, this meant “Low CAPs” and “High CAPs” were necessary. Soon you too will have to consider altitude in your CAP coverage.
(Note that current DBs do not have vertical sensor arc data backfilled, so this won’t have an immediate effect on gameplay until we can do a bit more research. Expect to see an RFI in the public Github for arcs and scan limits.)

 

Parallelized attack salvo calculations

The creation of attack salvos is now largely run in parallel instead of sequentially.

Some background to this: Until now, the creation of attack salvos was done purely sequentially. Unit-1 examines if it can attack (both doctrinally and physically) a contact; if yes, it creates a new salvo or adds its weapon(s) to an existing one for the same target with same weapon ID. Then Unit-2 does the same, etc. etc. until a suitable salvo for the given target is filled to capacity. This presents a number of issues:

• Because of the sequential nature, a potential “Unit-3” which perhaps is better located to attack the same target, or perhaps has a more suitable weapon for it, may not be considered at all (if a suitable salvo for the given target is filled-to-capacity by previous units). This can lead to problematic situations like this.
• Again because of the sequential calculation, this process does not exploit multiple CPU cores and can significantly slow down a pulse execution in a large/busy scenario.

Units now perform the salvo evaluations in their own individual threads and submit “firing proposals” to their side. The parent side groups firing proposals per-target and selects the most promising one, based on criteria that depend on the nature of the target (e.g. for aerospace targets an important factor is time-to-impact). Once selected, the salvos are executed as usual.

 

Weather effects for surface ship speed

This is an optional new feature. When enabled, deteriorating weather conditions (and especially increasing sea state) has an adverse impact on the maximum speed that ships can travel. This effect is particularly acute on small-displacement ships. Depending on sea state and ship size, a ship may be forced to run at 3/4, half, 1/4 speed or even heave (effectively remain stationary).

The information about the weather-related limitation is shown in various ways:

• On the ship datablock
• On the Unit Status panel
• On the throttle/altitude window

Because this feature can potentially unbalance existing scenarios, it is optional (can be toggled on the “Scenario Realism Features” window) and is “ON” by default when making a new scenario, and “OFF” by default when loading an existing scenario.

Aircraft maximum airborne endurance

 

This fixes the “aircraft may stay up indefinitely by multiple A2A-refuellings” realism flaw. Aircraft are now limited in their total airborne endurance depending on their size, type and crew complement. The information about current airborne total time and maximum endurance is listed on the fuel panel and is color-coded for at-a-glance evaluation (dark red is bad). If an aircraft reaches it max endurance limit, it enters an “RTB – Exhaustion” state, turns straight for its home base and will refuse any manual orders to change course or engage in any other activity.

 

Other simulation bits and pieces

– Added new ASuW doctrine option: “Use missile waypoints” (NO by default). When set to Yes, ASuW missile shooters will use the missile’s waypoint/dogleg capability (if present and if the range allows it). If set to No, ASuW missile shots will always go “straight in” (for old-timers, this is the default CMANO pre-v1.10 behavior).

– Non-ABM-optimized AAW missiles (e.g. Stunner) use a direct-flight profile when engaging ballistic targets (even if they have a lofting/cruise altitude set in the DB)

– An AAW missile’s attitude control type is now taken into account when determining Ph reduction due to reduced terminal energy:

• Interceptors with non-aerodynamic control (e.g. SM3, THAAD) have no reduction at all
• Interceptors with aerodynamic-only control (ie. most SAMs) have the as-standard reduction
• Interceptors with combined aero & non-aero control (e.g. Aster 15/30, 9M96) halve their Ph reduction (the non-aero control diminishes the negative effect of low terminal energy on maneuverability)

– Optional speed improvement: Do not share-and-deduplicate contact messages between allied sides.

• HOW TO ENABLE: On Command.ini, under the category [Game Preferences], add this: “DedupAlliedMessages = False”
• PROS: In scenarios with numerous sides allied to each other, this can provide a significant boost to sim performance.
• CONS: When this is enabled, sides do not receive contact-related messages (new contact, contact status change, contact lost etc.) from their allied sides. NOTE: The contact data itself is shared as always, it’s only the log-messages that are not shared. This may or may not be a significant hindrance depending on your gameplay style.

– Ships & submarines now attempt to evade incoming torpedoes more realistically, following these guidelines. Submarines will additionally alter their depth to avoid the torpedo(es) if appropriate.

– Added new sonar sub-type: Vertical Flank Array (DB v494+ required). These have been present in some Russian sub classes for a while, and are now backfitted on the Ohio class and earmarked for future US SSNs. They provide improved tracking capability (can establish a high-quality TMA track sooner).

– Expendable UAVs (and weapons/decoys) can now have their plotted course programmable in throttle & altitude

– Surface targets are now affected also by underground explosions, though not nearly as much as underground facilities (they receive much less of the transmitted shock). This makes it possible to damage/destroy buildings through near misses by penetrator weapons.

– New simulation feature: Certain weapons occupy their launcher while they are enroute (e.g. most wire-guided torpedoes & ATGMs). The mount cannot be reloaded before the weapon is destroyed one way or another. (Requires DBs v489+)

– ADDED: RWR detection of SARH/TVM illumination auto-generates an (incoming) missile contact, even if the missile itself has not yet been detected yet. This provides realistic ahead-warning (and thus evasion opportunity) to the targeted aircraft.

– New simulation feature: Daisy Chain-type weapon datalinks (DB v489+ required). This allows weapons to communicate directly with each other instead of being slaved to a datalink platform.

– The AI can now employ Mobile Air Decoys (MALD/TALD) (DB v489+ required).

– Support missions can now be created without a ref point (with a visual warning). Example use: Turn on ground based radars without having to turn them on the side-level or individually.

– AI improvement in wingman logic: Distances when evaluating contacts is measured from the group LEAD (not from itself), so the wingman will not chain-investigate away from lead. Also, wingmen do not investigate contacts alone if some other aircraft in the same mission is checking it. So if there are more unknowns than flights, wingmen may start breaking off to investigate them when they are in weapons range of their lead, otherwise they will not.

– Dual-seeker ARMs (e.g. AARGM) can now be fired (non-BOL) against non-emitting targets

– Relaxed the “have reached formation station” check threshold for aircraft (makes them less eager to throttle up to get to station)

– Ship attack AI tweak: When attacking with a contact bomb (ie. saboteur or kamikaze), if possible use flank throttle to minimize the target’s reaction window.

– The visual & IR signature modifiers of in-flight missiles have been tweaked so that they are picked up at shorter ranges. This prevents unrealistic early detection of incoming missiles and thus too-effective maneuvering against them.

– Aircraft AI tweak: When in normal loiter mode (no mission flight or plotted course), wingmen ignore their formation station and just stick close to the leader

– Added: Fuel resupply and rearm for submarines

– Tweaks to sonar cavitation model:

• Cavitation is now dependent on desired speed (ie. screw turn rate) rather than current vessel speed
• The noise boost from the onset of cavitation is now gradual (instead of all or nothing), and its magnitude depends on how much above the cavitation threshold the desired speed is

– Aircraft will now pitch up/down as necessary if weapon release is blocked by vertical boresight limits

– When undetected units fire gun/missile weapons, their visual signature blooms temporarily and they are susceptible to detection.

– BOL-fired torpedoes will snake if they are able to

– Added new navigation doctrine option: “Direct path” for ground units. This causes land units to head straight towards their destination without any pathfinding considerations.

– Added: Mine-Clearing mission can now also use “repeatable loop” movement style (so e.g. use explicit sweeping lanes)

– MIRVs are now released from ballistic missiles in sequence, one every 5 seconds (instead of all together)

– ARMs are less effective against low-band emitters (increased chance of a miss)

– Active sensors on aircraft are temporarily de-activated when approaching a target tanker for refueling (this is a safety measure to avoid igniting the tanker’s fuel).   

– ALARM parachute loiter capability added (this requires DB3000 v489+)

– Vehicles now use cargo load/unload time calculation similar to aircraft

– Cargo transfers now attempt to keep grouped units (that are stored in cargo) together when possible.

– Amphibious vehicles assigned to an active mission but stored in cargo will be checked against available docking facilities on their host unit. If available, they will self-unload into the docking facility. This is currently checked every 30 seconds though only one unit can self-unload per check. Amphibious vehicles cannot use davit type docking facilities.

– Docked amphibious vehicles that are assigned to an active mission will launch automatically if they’re in range of the mission area. This is the same behavior as boats currently perform for cargo missions, but amphibious vehicles auto-launch for all mission types.

– Ground Units can now perform cargo missions.

– Added “X days underway” tracking value for subs (example).

– Tweak to radar clutter logics: AESAs which refresh/revisit existing target tracks can narrow their beams and effectively cancel-out clutter altogether. This does NOT apply to volume-search scan against not-yet-detected targets.

– Implemented distinct horizon propagation values for different sensor types. Typical factors are 1.23, 1.5, and 1.06 for radar, ESM, and EO/IR respectively. These parameters are defined in the “Electronic Warfare and Radar Systems Engineering Handbook”.

Countdown to War Planner: General Improvements and User Interface

Command’s “War Planner” update (aka “Tiny”) is set to release in less than a month. Are you ready for Command’s biggest update yet?

In this multi-part series we take a look at the various key features introduced in this massive, FREE upgrade to Command.

Following the Overview, today it is the turn of general improvements and new UI features.

In this series:

• Overview
• General Improvements and User Interface
• The Operations Planner and multi-missioned units
• The Multi-Domain Strike Planner
• Cargo 2.0 – The Logistician’s Nirvana
• Simulation Additions & Improvements

---

General speed improvements: A lot of individually small speed improvements both in the map/UI as well as the simulation engine combine together to provide an improved gameplay experience – as well as improved analysis throughout in the professional edition.

New “Double Flame” time acceleration mode: Command until now has been using two distinct time-slice settings for simulation fidelity: 0.1-sec (aka. “Finegrained mode”) and 1-sec (aka “Coarse mode”). Some of our users have asked for an additional “very coarse” 5-sec timeslice in order to achieve even greater simulation speed.

We were reluctant to step into this rabbit hole for some time, as once you start cranking up the timeslice length weird things start to happen (easy and classic example: weapon is at time-X in front of the target, at X+5 sec beyond the target, and no impact check can be easily made). However, we came up with a reasonable solution to this conundrum: automatically “throttle back” the timeslice setting to 1-sec whenever something that requires this precision happens or is about to happen, and freely let loose the speed demons in any other case. This has been tested extensively with very satisfying results, both in terms of simulation stability/integrity as well as the chief driver, performance. (Anecdotally, one of the early adopters used this feature to turn a nine-hour analysis into a three-minute run instead. Obviously, the performance benefits can vary wildly according to the scenario and use-case.)

And why is it called “Double Flame”, you may ask? This is why:

 

New feature: Benchmark mode: This provides an objective way to measure & compare a system’s performance and suitability for CPE, by repeatedly running any selected scenario in headless mode (similar to Monte-Carlo execution, but without any analysis results). By default, the execution is run using fine-grained pulse mode (ie. 0.1-sec pulses) in order to stress-test the simulation engine and the hardware resources; however, “coarse” and “very coarse” options are also available.

Some notes on this:

– The benchmark mode indicates the performance only for the simulation engine, not for the map/UI engine. For this reason, the rest of the UI (main window and map etc.) is hidden away while the benchmark window is active.

– It is best to run scenarios that can be run AI-vs-AI (e.g. “Duelists”, “The Tiger and the Dragon” etc.), otherwise one of the sides is going to remain idle during execution.

– Total scenario running time is not shown, because it can be an unreliable performance metric (e.g. did the scenario end quickly because it was run fast, or because an “end scenario” trigger was fired?).

 

Hypersonic glide vehicles (HGV) and directional-EMP (D-EMP) weapons: Previously available only in the Professional Edition, these two weapons types are now also available in the commercial edition.

• Directional EMPs: CMANO v1.12 introduced omnidirectional tactical-EMP weapons. CMO now expands on this feature by also simulating directed-EMP warheads such as the one fitted on the USAF’s experimental CHAMP project. Using weapons with directional-EMP warheads is simple: Allocate the weapon at the desired primary target, and the weapon will first reach this target, “zap” it with its EMP payload, then head to the next nearest target, zap that one, then head to the next nearest target etc. until it runs out of fuel (or is shot down). This mode of operation makes D-EMP weapons very useful against clusters of closely-grouped targets with sensitive electronics, as is commonly the case for EW/GCI radars, C4 nodes, SAM batteries etc. The DB3000 currently has one directional-EMP weapon: Weapon #3407 – AGM-158B JASSM-ER [D-EMP], a variant of the common AGM-158B tactical cruise missile. By default, it is available for loadout #25091 (24x AGM-158B D-EMP), carried by: Aircraft #4325 – B-1B Lancer – USAF, 2018, IBS. Of course, weapon records holding this weapon can also be shoehorned into any aircraft loadout using ScenEdit, as normal.

• HGVs: Hypersonic Glide Vehicles (HGVs) are boosted into near-space by rockets, then dive back into the atmosphere and glide towards their (usually distant) targets, optionally using a complex trajectory with pre-specified waypoints to complicate detection and interception. As many HGVs are still “developmental” systems with many aspects of the behavior of deployed systems (such as Avangard) are still subject to classification rules, Command’s implementation relies mostly on currently publicly available data, partially from the tests of experimental hypersonic vehicles like the HTV-2. Command’s current implementation assumes a sharp dive into the atmosphere after release from the parent booster, followed by a pull-up maneuver that establishes the HGV to a shallow glide trajectory towards its target. (In the database, the “Cruise altitude” value is used to mark the altitude at which the pull-up maneuver will start). This is an example of the trajectory shortly after atmospheric pull-up, as displayed on Tacview: Players can optionally also plot a waypoint trajectory, in the same way as they can plot a complex course for cruise missiles.

Separated autosave for each scenario: The “Resume from autosave” function now fetches from the new Autosaves folder the latest modified root scenario folder that contains the specific autosaves, and then uses the autosave.scen of this folder. If you want to load an autosave from a specific scenario, you can select a scenario in the “load scenario” window and a “load autosave” button will appear if a valid autosave exists. This ability can be very useful if you need to keep save copies from multiple different scenarios you may be playing.

Formation presets: You can now quickly arrange the members of a group using any of a range of formation presets:

The presets work with any unit type and allow quickly positioning units relative to each other and to the group’s lead. There are various controls on a new toolbar within the formation editor:

• The “Formation” selector allows picking from a number of different presets. These are defined in the file \Resources\Formation\StandardFormations.txt, which also documents the format so that you can add your own variants if needed.
• The “Spacing” value sets the spacing between each unit, either in nautical miles or in meters.
• The “Heading” value sets the assumed heading when ordering the formation position.
• The “Assign” button arranges the formation stations based on the previous settings; all group members will do their best to get themselves into these positions ASAP (they may not be physically be able to, for example when a surface group transits a narrow strait; in this case they will converge towards the group lead).
• The “Place” button is visible only in ScenEdit mode, and instantly teleports the group members to their assigned stations (useful for quickly arranging a group without the real-world delay, e.g. when constructing the initial setup of a scenario).

 

Improved Mission Editor layout: This can sound minor initially, but the feedback we have received indicates a massive quality-of-life upgrade. The ME window has been significantly revamped, with the sections for assigning/unassigning units, configuring mission settings and selecting strike targets now all relegated to separate tabbed windows. This opens up the previously cramped space of the ME window and allows much more “real estate” on each of those sections, both making usage easier and also providing more room for future additions:

 

Mission Editor – Generate flight plan for assigned aircraft: One of the new features added to the ME is the ability to generate a flight plan for any air mission before the assigned aircraft take off. This can be used either in close integration with the Multi-domain Strike Planner (more on that on a next post) or as a stand-alone feature.

 

Mission Editor – Clone existing mission: Another “small but mighty” quality-of-life improvement: Copy an existing mission’s settings to a new one. If you need to create a lot of similar missions quickly and don’t want to use scripting for any reason, this can be a significant time-saver:

 

New bathymetry layer: CMO’s original “Relief” layer was very warmly received, and a persistent request has been to provide a similarly rich visual layer for the bathymetry data. Such a layer was indeed made available, initially for the release of CPE 2.0 in 2021, and now we are glad to make it available in the commercial version:

This layer can be very useful for all aspects of underwater operations, from submarine & ASW ops, to mine and counter-mine systems and tactics, UUV control etc.

 

Load/save doctrine XML templates: One more popular request is now realized: Players have long asked for the ability to customize a ruleset for Doctrine & ROE settings (including EMCON, WRA etc.) and then be able to apply that as a template to other units, groups, missions etc. This is now possible, by the ability to save and reload such templates. In addition, because the save file is in raw XML format, the contents of the template can be freely edited – by hand, or by automated XML-parsing tools or scripts. Obviously this opens up a variety of automation capabilities.

 

Expanded WRA range options: The introduction of realistic boost-coast kinematics for AAW missiles, and the accompanying changes to default aircraft missile evasion behaviors (more on both of these on a forthcoming post) has made players more interested in more WRA range options. So in addition to the existing absolute-number figures, percentages of nominal range are now also available (25%, 50% and 75% of nominal). Furthermore, given that the new missile kinematics now reward evasion behaviors favoring outrunning the missile rather than trying to beam/notch it, a no-escape zone (NEZ) range option has been added to WRAs for AAW targets:

The logic of NEZ is actually pretty simple: If the target turns instantly at the moment of weapon launch and runs away from the firing unit, will the weapon be able to run it down? (If the target has been class-identified, its maximum possible speed at its current altitude is used as the reference “runaway” speed; if not, its current observed speed is used instead).

The benefit of using NEZ for a missile shot is that it makes it highly unlikely that the target will able to outrun the shot. On the other hand, against a high-performance target this leads to a severe reduction in practical launch range: Make your shot too conservative (to deny the adversary a chance to outrun your weapon), and you may possibly surrender the engagement initiative to the enemy. Again, a matter of trade-offs and risk management.

 

Revised message log: You generally liked CMO’s existing message log for its versatility and power, but you were not terribly fond of its “grouping by type” of messages. You told us you prefer a single waterfall-like flow of messages (ironically, much like CMANO’s original one) but with the option to dynamically show/hide messages by type. So this is what we came up with:

• Messages can now be filtered by type directly by clicking on each of the type descriptions in the olive-green buttons (when a type is disabled, its corresponding button color changes to red).
• Clicking on the “All” button instantly enables/disables all types.
• Clicking on the “>Raw” button toggles between “raw” (aka “waterfall”) and interactive modes.
• Clicking on the red-circled icon will detach the message log to its own window, and clicking it again will re-dock it.

 

New logged-message category: Doctrine/ROE changes.Like all other message types, this can be configured to appear on the message log, raise a pop-up and optionally stop the clock, show a message balloon etc.

 

Area & reference-points manager: Another migrant from Command-PE, this very handy tool will be your new best friend if you use areas and zones a lot (and in non-trivial scenarios we’ll assume you do):

This offers a centralized interface for editing reference points on large-scale scenarios. Ref-points and zones can be organized by tagging and visually distinguished by different colors. This can be superbly helpful, for example, for setting apart different patrol areas or exclusion zones.

 

Graphical Display of Satellite Pass Prediction: The “Satellite Pass Prediction” window now has an extra tab, which displays the same information in a more visual manner:

The tabular “spreadsheet” display or orbital passes still remains available, and is still a very powerful way of obtaining the info you need (e.g. sorting by any information field), but this graphical way provides an at-a-glance ability to quickly compare satellite availability windows.

 

Quick manual weapon allocation: Don’t trust the AI to make the optimum weapon allocation (or you’re the kind of micromanagement freak that never appears in grognard circles), but the full manual weapon allocation window intimidates you with its myriad combinations of shooters, targets and weapons? There is now another way:

Yes, it’s nothing Earth-shattering and if you’re a longtimer of the genre you’ve already seen this on other games. Still, you apparently like it well enough that you consistently asked for it in Command too, and we are happy to oblige.

Notice, too, the new “Investigate” and “Drop Target” commands. “Investigate” is another popular long-time request; the unit(s) will intercept and “shadow” the contact of interest but not engage unless in self-defense. Some additional new commands not shown in this screenshot:

• Refuel To Tanker
• Join Group As Escort
• RTB
• Assign New Home Base

 

Plot a course for the selected unit directly by right-clicking anywhere on the map: This is a boon to players coming from RTS games, where right-clicking to direct units is as instinctive as breathing. As in RTS titles, you can also plot multiple waypoints in succession by holding the shift key. During testing this was found to be annoying for some players who prefer the good old F3 way, so this behavior can be enabled/disabled through the game options window.

 

New optional UI/Map element: Barks: Barks are short text notifications that can be set to appear, briefly, anywhere on the map. Some examples:

The appearance and “styling” of the barks (color, text, duration etc.) is fully customizable through the Lua API, so you have full power to add them on any action performed. We can only begin to imagine what some of the more resourceful modders in the community will do with this feature.

 

New optional UI/Map feature: Slug trails: This something you may already be familiar with, if you have past experience with air-traffic control radar screens, sonar tactical consoles etc:

Slug trails can be configured through the Game Options window:

 

Flexible usage of CPU threads on LOS Tool: When we introduced the Line-Of-Sight (LOS) tool in CMO, some players whiplashed from “Meh, CMO does not utilize my multi-core CPU as much as I expected it to” to “HELP!!! When The LOS Tool is active, the rest of the game slows to a crawl!” (Don’t say we didn’t warn you…)

With this in mind, we added the ability to configure how many of the CPU’s available hardware threads (ie. virtual cores) can be allocated for use by the LOS Tool, therefore leaving the other cores/threads available to the UI and simulation engine:

 

Improvements on replenishment menus: The “Replenish” context menu now displays which type to rearm and will find automatically the eligible supply platform with this weapon in store. The context menu only shows the relevant weapons that have missing ammo, so it is easier to replenish a unit from various wide-spread supply facilities/vehicles/ships and keep track of what is missing. Example:

 

Ability to toggle more involved attacks (stick until winchester) in strike missions (toggle in strike mission UI):

 

Configurable sim-pause behavior: You can now configure whether opening up certain windows such as the DB viewer or Air-Ops will implicitly pause the simulation execution or not:

 

Include direct-path area in CZ rendering: When looking at a submarine’s sensor coverage of its CZ rings (if applicable), it can be easy to lose sight of the inner direct-path area where sonar detections are most feasible. This has now been rectified:

Note that this range represents the surface-level detection ability (detection range against under-layer targets, for example, will likely be lower) and dynamically adjusts to weather & environment conditions (boosted by surface ducting if present, shrunk by bad weather if present etc.)

 

Minimap improvements: The different minimaps have been improved in their presentation and unit rendering, and they also now include land-cover type in their color. Example:

Countdown to War Planner: Overview

It’s finally coming!

After nearly a year of frantic, tireless development, and an extensive public beta, we are excited to announce the imminent public release of the biggest update in Command’s history (yes, even exceeding the gargantuan changes of the CMANO-to-CMO transition): The War Planner update.

Known tongue-in-cheek to beta testers and early adopters as the “Tiny” release (as it has been anything but), the War Planner update brings dozens of super-major feature additions (including some features previously restricted to Professional Edition), hundreds of simulation improvements, and myriads of tweaks and bug fixes to rival even the launch of Command: Modern Operations in sheer scale. It has been named as such, because many of the changes and new features are oriented towards giving players an unprecedented power and flexibility in organizing and automating complex operations that previously required a lot of manual work and tedious coordination. Waging elaborate, theater-wide multi-domain operations has never been easier.

And the best part? It’s all completely free.

To get a taste of what’s to come, following is a highly-compressed summary of the major features of this colossal update. These will be elaborated in much greater detail in forthcoming articles.

In this series:

• Overview
• General Improvements and User Interface
• The Operations Planner and multi-missioned units
• The Multi-Domain Strike Planner
• Cargo 2.0 – The Logistician’s Nirvana
• Simulation Additions & Improvements

---

Operations Planner: Ever wished you had an ATO-like overview of all missions and operations planned or currently executing, their status and hierarchical priorities and dependencies? With units or even entire task forces automatically switching from one mission to the next as objectives are achieved? Wish no more. The brand-new Operations Planner makes this, and much more, a reality.

Multi-Domain Strike Planner: Throw away your planning spreadsheets! You asked/begged/hostaged family members for it, and now it’s here. Coordinate massive, complex strike missions with time-on-target, complex flight plans (incl. in-flight refueling) , multiple attack patterns and multi-domain strike combinations. “Bringing everything together on a strike is just too complex/difficult” is officially over as an excuse. If you don’t master this, your adversary most definitely will.

Cargo 2.0: The sub-header for this feature is often “The Logistician’s Nirvana” – and that should be your first hint. Transfer both combat units and also weapons, stores, fuel and any arbitrary material. Place your cargo on a multitude of different container types, from standard ISO-blocks to specialized boxes, each with its own peculiarities. Transload cargo at airbases, ports, railyards etc. in order to haul it over even transcontinental distances. Automate all this through cargo and (NEW!) transfer missions. Set up complex logistical chains from mainland factories all the way to the front line. Conquerors from Napoleon to Alexander would have given their right arm for such a tool – and you get it for free. Who ever said life is fair?

Area & Reference Point Manager: Areas, zones, ref-points and overlapping fields oh my! A centralized way to manage anything and everything related to reference points.

Custom Environment Zones: Multiple & moving weather fronts? Check. Bend the laws of physics on a localized area? Can do. Specify carefully hand-picked weather, terrain and other environmental properties in order to test or compare sensors and other environment-dependent components? Yup. Unleash your inner nature wizard with this puppy.

Air combat mechanics overhaul: Boost-coast AAW missiles (ie. the vast majority of them) now correctly accelerate to their maximum speed by their boosters and subsequently coast over the rest of their flight, trading altitude for speed (and vice versa) while also shedding speed due to drag – especially on sharp maneuvers. This makes them much easier to avoid at the edge of their envelope, where their energy reserves are depleted. Missiles with specialized long-burn motors have a decisive terminal-energy advantage over plain boost-coast systems. Virtual pilots are aware of these new dynamics and will exploit them to “drag out” incoming missiles, with beaming/notching as a last resort. To counter these counters, new additional WRA firing-range settings (including “No-Escape Zone”) are available. A2A and S2A missile engagements are, as a result, both more dynamic and far more realistic now.

“Double-flame” time acceleration: “I wish my simulation runs had executed more slowly, I had time to spare” – said no-one on their deathbed. Aside from an array of general sim-speed improvements, this update brings a brand-new exclusive (and optional) time accel mode: “Double Flame”. This cranks up the virtual timeslice to 5 seconds, massively speeding up simulation execution. “Hold on”, we hear you say, “bad things start to happen when you get so coarse in your timeslice”. You bet they do. So how did we solve it? Find out in one of our follow-ups.

HGVs and D-EMPs now available: Yes Dorothy, the previously available only in CPE hypersonic glide vehicles and directional-EMP weapon types are now available in the commercial version too. Yes, they can be pretty useful if used correctly – especially in coordination with other, more abundant assets. No, they won’t save you from certain doom if the rest of your ops suck. Treat them as magic saviors at your peril.

Palletized Weapons & Stores: Yes, we know you’ve all seen AFRL’s videos on the Rapid Dragon concept. Yes, we know you drooled over the new possibilities. Newsflash: So did we. So now you can do that too. Is it awesome? You bet it is.

Passive Coherent Location System (PCLS) sensor, aka “Passive Radar”: How do you detect and track stealth aircraft? One of the possible ways is to break out of the classic monostatic radar paradigm and embrace alternative solutions like PCLS. Are they omniscient? No. Do they have operational drawbacks, some of them quite severe? Yes. In the right conditions, can they detect stealthy aircraft that conventional radars are hopeless against? Yes, yes and yes. Find out how.

Intermittent Emissions: Radars and other active emitters no longer have to strictly choose between active and silent: You can now blink, and schedule how to. No scripting necessary! (But scripting still a very powerful option). Find out how, in our follow-up article.

Revised Mission Editor: “It’s insanely better than before!” is the least positive comment we’ve heard about the revised ME layout. Now you too can experience what every beta player considers the finest visual experience since “Love Actually: The Directors Cut”.

Revised Message Log: You asked (intensely and consistently…) for a fully filterable message log, dynamically enabling/disabling messages per type, while also retaining the “responsive nature” (show location, optionally show balloon etc.) of the messages. Oh and also keeping all the existing goodies (docked or free-floating, “raw”/waterfall mode, per-type coloring, balloons etc.). Our first reaction was “So, you essentially want Visual Studio’s errors & warnings list?” Our second reaction was “Maybe this is feasible after all”. Our third reaction was to go ahead and build it. And there was much rejoicing throughout the land.

Distinct Ground Units: As much as we keep telling you Command is not SPMBT or Combat Mission, you keep asking for distinct ground vehicles. So there you go.  Command now offers individual ground units, in addition to the previous method of modeling them as aimpoint-facilities. You’ll find ground units modeled with the same level of detail users expect of ships and aircraft: propulsion, fuel, mounts, sensors, etc. are all simulated, as are characteristics like armor (incl. ERA, slat armor, etc.). Ground units bring brand-new capabilities to the fight, such as amphibious vehicles capable of transitioning between land and water (with distinct speeds and fuel consumption in each domain).

Save/Load Doctrine & ROE Settings: Sorry, Cimmerian; crushing your enemies and seeing them driven before you is only the _second_ best thing in life. The first-best, is to carefully construct your Doctrine & Rules of Engagement settings for a specific side, mission, group or individual unit, and then export them to a text file where they can be freely re-imported for any other simulation object as well as edited, either by hand or in an automated fashion. With power such as this in one’s hands, no prayers to Crom are necessary.

Overhauled Reaction Times: The differences in reaction times, and their effects, are now more critical than ever. All units use common-reference “Combat System Generation” (“Cockpit Generation” for aircraft) to model the modernity of their combat systems, combined with an “Ergonomics” value to handle intra-generation differences (the atrocious switchology on early missile-age aircraft will most definitely get you killed now). Older, WW2-era ships may take up to 5 minutes to engage a target, while Aegis cruisers fire in <20 seconds. Cold War fighters will be beaten to the draw by modern, fifth-generation fighters. Overmatch, that ever-elusive dream, is now possible – but beware, it goes both ways.

IR & Visual Sensor Improvements: IRSTs and high-mag cameras are no longer near-magical counter-VLO sensors. They may still be your best bet for detection, but you won’t be volume-scanning for stealth fighters at >100nm anymore. (You can still spot/track them pretty far enough IF something/someone else first cues you there)

Radar & IR Stealth Improvements: Sensor improvements come coupled with a massive overhaul of signature modifiers in the DB, which significantly improve the realism of our stealth model by drawing clearer distinctions between shaping and RAM generations. We also added special DB “flags” to indicate the presence (or lack) of certain stealthy design features such as S-shaped intakes, exposed fan blockers, active cancellation, and stealth pylons. The overhaul also extended to IR modifiers, which now not only model whole-aircraft IRSS (distributed vs. conventional fuel tanks, low-E coatings) but also specific IRSS features such as shielded “anti-Strela” exhausts, masked exhausts, heavily masked / slit-shaped exhausts, and peak temperature reduction or “cool-air mixing”.

Formation Presets: Tailor your formation’s layout with a number of different presets (wedge, circle, echelon, line, diamond etc.) or make and store your own custom template. Customize facing and distancing to suit your preferences. Transitioning from parade to full-attack and back (perhaps in the middle of your parade?) has never been easier.

Bathymetry Layer: Visualize the terrain contours of the naval domain as clearly and as richly as you already do for the overland globe surface. A must for every facet of underwater ops, from sub/ASW hunts to mine warfare to UUV control to tracking whale migrations. Jacques Cousteau would have rightly wept.

Graphical Satellite Pass Display: The “Satellite Pass Prediction” window now offers a graphical representation of future satellite passes, sparing users the need to compare timeblocks to figure out which satellites will be overhead when. Who needs data grids when you can visually compare availability windows…. right?

Benchmark Mode: Looking to compare rigs? Command now includes a benchmark mode, which will repeatedly run any scenario you choose in “headless” mode and output performance metrics. Now your machine’s sorry state will be plain for all the world to see.

Miscellaneous UI Improvements (Weapon Quick-Allocate, Slug Trails, “Barks,” etc.): Quickly allocate weapons manually, without needing to bring up the (intimidating to some, apparently…) manual allocation window. Have units or contacts bark to each other (yes, you read that right). Make unit & contact movement paths & histories more obvious (and easier to visualize in a screenshot) by enabling “slug trails”. Plus a few more tricks we’ll see in detail on the UI-dedicated UI follow-up.

Weather effects on ship seakeeping: Sea state limits are no longer treated as hard lines. Smaller ships are now affected by progressively higher sea states, which will slow their max speed but not necessarily immobilize them. Moving from the QE to a small sloop now most definitely feels like it.

Aircraft Max Endurance: If you’ve ever used the “keep aircraft in the air indefinitely through repeated air-refuelings” cheat, first: SHAME ON YOU! Second: You won’t be able to do it anymore.  Aircraft are now limited in persistence both by their onboard consumables and also crew fatigue. And you wonder why everyone loves drones.

---

As you can see, there is a lot here to unpack in greater detail – and we intend to just exactly that, in a series of follow-up posts dedicated to each of the major areas of improvement.

So stick around!

Nerf Wars: On downgrading Russian systems & units in Command

So, ever since it became clear that Russian combat performance in Ukraine has been “less than stellar”, there has been a persistent request in many corners of the web towards the Command dev team. The request can be summed up as:

“So, when are you guys going to nerf Russian equipment in Command’s database, to match what we are seeing in Ukraine? It seems it is performing well below official specs.”

(Oxford Dictionary: “to nerf”: (of a video game developer) reduce the power of (a character, weapon, etc.) in a new instalment or update of a video game.)

A naval-oriented variant of this comment is: “I tried simulating the attack on the cruiser Moskva, and I just couldn’t sink it as happened it real life. So CMO is probably talking up Russian hardware.”

Now, there is a short and direct answer to both these claims, but we have been advised not to print it here. So let’s go into the more elaborate and slightly more polite version instead.

Command, by default (ie. stock DB values) represents Russian systems (and all other nation’s systems) as they are meant to be used, by trained crews employing them according to their design doctrine. Shortly after the Ukraine conflict got going for real, a US general remarked that “Russian hardware works pretty well… when used by Ukrainians”.

(As a quick example of this, Carlo Kopp had written an unusually insightful analysis on what happens when Russian SAMs get used correctly, and also what happens when they are not. Favorite quote: “The Syrians used mobile missiles in a fixed configuration; they put the radars in the valley instead of the hills because they didn’t want to dig latrines — seriously.”)

At the same time, Command also recognizes that combat is not a sterile hardware contest, and provides a lot of “soft factor” options (crew proficiency settings, reaction times, doctrine settings, EMCON, ROE etc.) to offer the ability to represent sub-optimal usage of said hardware. You can have two different units use exactly the same hardware with vastly different effectiveness and survivability (our favorite reference example is Iraqi 1991 SA-6 battery vs. Serbian 1999 SA-6 battery).

An example list of the factors you can edit:

• Proficiency levels, both side-wide and per-unit
• Reaction times (OODA loop values)
• Doctrine settings
• Rules of Engagement
• EMCON settings
• WRA settings (ie. firing doctrine)
• Per-component equipment failure

That very last aspect is particularly important in light of what has been recently learned WRT the system readiness on the Moskva. According to the leaked readiness report (standard caveat for CYA-shaped leaks), both the central SA-N-6 fire control radar and the short-range SA-N-4 systems were effectively disabled due to equipment malfunction and were waiting for replacements. In addition both the main guns as well as the main air-search radar were also inoperative. In other words, the Moskva was sent to an active warzone almost naked against air/missile attack.

Can this be faithfully reproduced in Command? Absolutely.

Can other factors, such as apparently poor crew proficiency which led to both poor reaction times and also abysmal damage control, also be modelled? Also yes, very easily so.

So why then do some CMO users out there find it so hard to reproduce results like the Moskva sinking? (Or the Saki airbase strike, or S-300/400 batteries not being omnipotent, or UAVs apparently roaming at will, or…)

TOUGH LOVE WARNING: Because some people’s idea of “testing something in the scenario editor” is to quickly plop down a few units here and there, in their stock-DB setups, give them free fire reign against each other, and call it a day. No customization for soft factors, component status or any of the other real-world aspects that directly impact the end result.

Thankfully, some players are disciplined enough to do it right. Here is an example, soon after the actual sinking itself when info was still scarce. (This of course is far from “the last word” on the subject. SMEs are still debating e.g. how the Sheffield went down after a single Exocet hit while the Stark survived two of them. Hell, even WW2 events are still up for analysis. It’s a safe bet that the Moskva sinking will be endlessly discussed by our grandchildren.)

It is tempting indeed, to embed the soft-factor issues directly into the DB entries themselves, so that when you spawn a Russian unit on the virtual battlefield, it’s in a sorry condition out-of-the-box, ready to be clobbered. The price you pay for this expedient approach becomes obvious only later, when you realize that not only you lost the ability to clearly separate man (and context/circumstances) from machine, but you also railroaded yourself intellectually into believing that this Russian unit will always behave like this.

Does this matter? Let us consider, for instance, an Israeli staff sergeant nerfing Egyptian tanks in a wargame just prior to Yom Kippur in 1973 “because they were such pushovers just a few years back”. Did this specific example happen? Maybe, maybe not; but we know for a fact that the Israeli military establishment grossly underestimated Egyptian & Syrian forces because of their lightning successes in 1967 (they essentially nerfed them in their mental “databases”), and that plenty of Israeli soldiers paid for that intellectual myopia with their lives. Is this a mistake we want (or can afford) to repeat?

Such a radical shift in combat effectiveness with identical/similar hardware does not happen just between conflicts, but also within the span of a conflict itself. Returning to Ukraine for an example, in the early days of the “rush for Kiev” we observed a lot of Russian SHORADS batteries getting bombed by aircraft while completely inoperative. As it turns out, apparently the rapid speed at which these elements were forced to move (to screen the assault forces) prevented them from properly screening/leap-frogging each other and thus actually operating as they are designed and supposed to do. When later these very same systems were properly echeloned with the forces they covered during the Russian withdrawal to Donbass (and also undeniably as the hard lessons of the first weeks were distilled to the surviving operators), their effectiveness and survivability were restored to expected levels. (And then the Ukrainians introduced HARMs in the theater… but that’s another story)

How can you represent such drastic differences in effectiveness in the very same unit, if the soft-factors are embedded in the database entry? Short answer: You can’t.
(Longer answer: You can cheat/hack your way into it by having multiple entries in the DB, each representing different competence levels and equipment maintenance. It’s a very hacky solution, a maintenance nightmare, and again you are mixing up man, machine and context. We sometimes were forced to do something like this back in the computer-Harpoon days, simply because Harpoon had absolutely no soft factors. Nowadays we can and must do better.)

So, to recap: We would be doing a grave disservice to both our commercial players and especially pro customers by directly embedding soft factors into the DB just so that Joe Player can get a realistically-degraded Moskva out of the box. Platforms and systems in the DB are spawned in pristine condition and (by default) are assumed to be crewed competently: This is not a design oversight, but a conscious and carefully-considered decision. Players can then modify the platforms themselves, turning them into anything from decrepit spank-targets all the way to invincible fortresses, and shape the context of the virtual environment in their favor or against them, in order to either recreate historical situations or explore hypotheticals of past, present or future. But in every case, it’s something that they will have to roll up their sleeves and do themselves. To quote Norm Koger from two decades ago: “Word processors ask a lot of those who would use them to create stories”.

Thanks, and carry on.

Don’t stop me now: Command PE v1.15.5 now available

It has been 10 months since the last official PE release, and the WS dev team has been pretty busy on multiple fronts. The time is now ripe for another significant official update: Command PE v1.15.5 is now available to new and existing pro customers.

The new update brings a deluge of additions and improvements big and small, including some features explicitly developed as customer requests. These include:

New sensor type: Passive Coherent Location System (aka “Passive Radar”). For a general background on PCLS, see here. PCLS systems can be very useful both as a covert means of airspace surveillance and as a potent counter-VLO asset to be combined with other, more traditional sensors. They do have several drawbacks and vulnerabilities (for example, they can be limited in altitude coverage because of their bistatic nature, and each receiver must have clear LOS to both the target and the transmitter in order to process the reflection), but as long as these can be accommodated, PCLS sensors can significantly enhance an IADS and complicate enemy efforts to disrupt it.

New major feature: Distinct mobile ground units. In addition to modelling mobile forces as “aimpoint facilities” , it is now possible to explicitly model individual vehicles with their own customized properties such as armor, propulsion, mounts, sensors etc. These new units now have their separate data annex (“Ground Units”), and can be browsed on the DB viewer:Apart from the obvious benefits of easier targetability and clearer per-unit cargo assignment, the new-style ground units have unlocked certain brand-new capabilities, such as true amphibious vehicles (with distinct speed & fuel consumption properties overwater and on land).

New feature: Formation presets. You can now quickly arrange the members of a group using any of a range of formation presets:

The presets work with any unit type and allow quickly positioning units relative to each other and to the group’s lead. You can either assign the relative positions to the group units or, if in ScenEdit mode, you can directly “teleport” the members to their assigned positions (this can be very useful for scenario authors, obviously).

Major enhancements to Command-CLI. Command-line execution was one of the hottest new features of the v1.15 upgrade (see this article by Northrop Grumman on how they have been using it for a DARPA initiative to train AIs with literally quadrillions of scenario variants), and we have receive lots of feedback and suggestions as to how to improve its utility. Two big new features are:

• You can now launch a CLI instance in interactive mode, using the Lua TCP-socket as the control interface. This ability combines the high-performance, low overhead and parallel execution benefits of CLI with the full-control interactivity of the full-GUI client.
• CLI mode now supports both coarse and finegrained timestep modes.

Improvements to Multiplayer. The layout of the various MP-specific UI elements has been improved to be less intrusive, the transmission delay of scenario snapshots has been sharply reduced using a “delta” comparison engine, and various fixes and tweaks have been added.

New doctrine/ROE/WRA feature: You can now define decimal figures for WRA engagement and self-defence ranges, using the relevant Lua methods. For example:
ScenEdit_SetDoctrineWRA({guid = ‘d7db0f50-bf1a-4977-ad57-15c30ef3f91a’, target_type=’Aircraft_Unspecified’, weapon_id=134}, {‘2′,’inherit’,2.5,7.8})

In addition, a new message type (Doctrine/ROE) has been added to the message options, and thus can be configured to appear on the message log, raise a pop-up etc. This makes it easier to receive immediate feedback/confirmation on script-driven WRA changes.

Various tweaks & improvements on the event-export tables, directly based on user feedback.

You can now control the jettison of aircraft stores through Lua. This is a more powerful and flexible method than the GUI, as it allows dumping stores at any arbitrary point (not just when under attack), and provides finer control as to what items will be jettisoned (all stores, externals only, heavy stores only, or even a specific weapon ID)

Plus a wide assortment of other tweaks, fixes and improvements across the various functionality tiers of the application.

Work is already underway on the next update releases. Stay tuned, as there are some impressive things on the horizon!

« Previous Page — Next Page »

Main Menu

• What is 'Command'?
• Professional, Academic & Student Edition
• What the Press Say
• Customer Testimonials
• Scenario & Add-On Downloads
• Mega-FAQ
• Official Forum
• Contact Us
• Links
 

Webshop

BUY at MatrixGames
BUY on Steam
BUY on Humble store



 

Trailer Video

Command: Modern Operations
 

Old Harpoon Material

• What is 'Harpoon'?
• Waypoint Magazine
• Harpoon3.6 1937-1949
  (WW2)
  Database & Scenarios
• Harpoon3.6 1950-1964
  (Colonial Wars)
  Database & Scenarios
• Harpoon3.6 1965-1979
  (Missile Age)
  Database & Scenarios
• Harpoon3.6 1980-2015
  (DB2000)
  Database & Scenarios
 

• Archives

  • February 2024
  • December 2023
  • October 2023
  • September 2023
  • August 2023
  • July 2023
  • May 2023
  • March 2023
  • January 2023
  • December 2022
  • November 2022
  • October 2022
  • September 2022
  • August 2022
  • March 2022
  • November 2021
  • October 2021
  • September 2021
  • August 2021
  • May 2021
  • April 2021
  • March 2021
  • October 2020
  • May 2020
  • March 2020
  • February 2020
  • January 2020
  • November 2019
  • October 2019
  • September 2019
  • May 2019
  • March 2019
  • February 2019
  • January 2019
  • November 2018
  • October 2018
  • September 2018
  • July 2018
  • May 2018
  • March 2018
  • February 2018
  • January 2018
  • November 2017
  • October 2017
  • September 2017
  • July 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • September 2016
  • August 2016
  • July 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • January 2016
  • December 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015
  • January 2015
  • December 2014
  • November 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • January 2014
  • December 2013
  • November 2013
  • October 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • February 2013
  • January 2013
  • December 2012
  • October 2012
  • August 2012
  • July 2012
  • April 2012
  • January 2012
  • November 2011
  • October 2011
  • September 2011
  • July 2011
  • May 2011
  • April 2011
  • March 2011
  • February 2011
  • December 2010
  • November 2010
  • October 2010
  • August 2010
  • June 2010
  • May 2010
  • April 2010
  • March 2010
  • February 2010
  • January 2010
  • December 2009
  • November 2009
  • October 2009
  • September 2009
  • August 2009
  • July 2009
  • June 2009
  • May 2009
  • April 2009
  • February 2009
  • December 2008
 

• Recent Posts

  • Nitro boost and DB magics: Command-PE v2.3.1 released
  • Command Showcase: Icebreakers released!
  • Santa’s coming to Defense town: Command PE v2.3 now available
  • Command Showcase: Operation Desert Falcon released!
  • 10th Command User Event in Rome: A Confluence of Defense Innovation