The road to v1.10: Steam Workshop

December 18, 2015 · Posted in Command · Comment 

Command Build 757.12, which had been made available unofficially at the start of December, has now officially been released through MatrixGames and Steam. Barring any emergencies, this is probably the last update released as part of the post-v1.09/NI release support process (Command is still 50% off at MatrixGames until early January!). The development team’s focus is now the next major public update, designated v1.10. Let us take a look at the some of the major improvements that the new version will feature.

Steam Workshop ScenariosMenu

With the release of v1.10 one important new feature is Steam Workshop integration, giving players a new avenue to share and discover scenarios!

One quick note we here at Warfare Sims would like to point out that the new Steam Workshop functionality will in no way supersede the existing scenario distribution channels (the community scenario pack and the matrix scenario forum). The wildly successful community scenario pack showcases the very best of the scenarios released to date and will continue to be released periodically with additional updates. In fact highly rated Steam Workshop scenarios will find their way into the community scenario pack.

Submitting a scenario to the Steam Workshop couldn’t be easier!

First, open Command via Steam. Then, open the scenario you would like to upload in ‘edit mode’. After that press the “Publish scenario to Steam Workshop” button near the bottom of the Editor menu.

Publish Form

Attach a special preview image, or use the screenshot of the action on the screen as the thumbnail for the scenario.

After that it’s as simple as pressing ‘Publish New Item’. Its sent off to Steam, and made available on the Steam Workshop immediately!

Item in steam

Now, to download this scenario you must subscribe to the scenario.

Subscribe

After hitting that ‘Subscribe’ button the next time you open Command via Steam the scenario will be downloaded to a special new folder in your Scenario directory.

Scenario after subscription

The Steam Workshop allows scenario authors to be able to auto-update their scenarios, an author can make a change to a scenario and update the existing item on the Workshop and then this update will automatically be sent to all those who ‘subscribe’ to the item.

ASBM Test

We look forward to taking a look at the scenarios you upload! The inclusion of Steam Workshop in v1.10 introduces a whole new way to share scenarios, in addition to the already existing channels of scenario distribution!

Tags: <, >

The road to v1.10: Waypoints for cruise missiles

December 12, 2015 · Posted in Command, Uncategorized · Comment 

CruiseMissile1Command Build 757.12, which had been made available unofficially at the start of December, has now officially been released through MatrixGames and Steam. Barring any emergencies, this is probably the last update released as part of the post-v1.09/NI release support process (Command is still 50% off at MatrixGames until early January!). The development team’s focus is now the next major public update, designated v1.10. Let us take a look at the some of the major improvements that the new version will feature.

Complex missile courses for fun and profit

Arguably one of the most visible changes in v1.10 is the new ability to plot complex routes with multiple waypoints for cruise missile attacks. While this was already possible for weapons under positive datalink control (e.g. heavy Russian “carrier killer” missiles like the SS-N-19), this is now possible also for completely autonomous weapons. Let’s see how this works.

(click for full size)

In this completely hypothetical example, the USS Ohio, loaded with Tactical Tomahawk (TACTOM) land-attack cruise missiles, is tasked to attack the air facilities at Latakia airbase in order to hamper Russian air operations from this important base. The airfield is protected by a battery of Pantsir-S1 short-range air-defence vehicles and, most importantly, a full S-400 long-range air-defence missile battery.

From the position that the Ohio is currently located, a direct missile attack would appear the most obvious course of action. However, we have already tried this on a previous test run and observed that the airfield’s location (placed on a ~40m elevated plateau overlooking the Syrian coast) offers a near-perfect field of view for the air-defence radars located at the base. The results against an attack coming directly from the sea were thus predictable:

Even with a large-scale missile strike, the majority of the TACTOMs were detected, engaged and destroyed by the S-400 battery well before crossing the coast. Leakers were then engaged successfully by the Pantsir-S1 systems. While some of the missiles did manage to impact their targets, this was more a result of simply overwhelming the airfield’s defences by sheer numbers (the S-400 battery ewas completely drained of weapons, and the Pantsir-S1 vehicles nearly so) rather than outwitting them.

So let’s see if we can execute a smarter, more efficient attack. We observe that the airbase, while having an excellent view to the west, is somewhat lodged between the coast and the so-called “Syrian Coastal Mountain Range“. This ridge could make an excellent radar mask for our TACTOMs if we can get them to attack the base from this direction rather than from the sea.

So let’s do exactly that:

Using the manual weapon allocation window, we assign a salvo of 4 TACTOMs to one of the airfield facilities. We select the salvo (blue outline) and click on the “Plot course” button under it. This temporarily hides the allocation window and allows us to plot the desired course:

In this case we set the missiles to cross the coast at Lebanon, skirt behind the mountain ridges on their way up north and pop up to attack the base at the last possible moment. Note that we do not have absolute freedom in plotting such courses: We are constrained both by the maximum range of the weapon and also the number of available waypoints to use. This is not a problem for TACTOM, but numerous anti-ship missiles have only a handful of waypoints available.

This is the result of the revised attack, from the Russian point of view:

The difference is quite dramatic. The 96L6 (Cheese Board) radar that supports the base defences detected the first TACTOMs at just 12.8nm, as they popped over the mountain ridge. Combined with the inevitable OODA delay, this gives the Russian SAMs very little time to react. If the TACTOM strike is as massive as before, the Russian repair crews at Latakia are going to have a very busy day…

Units under AI control are also able to utilize missile waypoints to their benefit. Although not currently able to “think” about radar/SAM coverage as in the above example, they nevertheless attempt to make off-axis attacks whenever possible (this obviously depends on how much weapon range they can spare) in order to hide their true bearing from their target. No longer does the bearing to a detected incoming missile provide an immediate clue to the attacker’s location:

The inclusion of missile waypoints in v1.10 introduces a whole new range of tactical options based on RL operations, and we are certain the players will find even more uses for them (complex TALD/MALD flight paths anyone?).

Tags: no tags

Countdown to War Planner: Simulation Additions & Improvements

January 5, 2023 · Posted in Command · Comment 

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:

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:

ZueeFXi.png (1017×609)

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:

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

Tags: no tags

The great leaps of v1.11: Under the sea and under the hood

March 14, 2016 · Posted in Command · Comment 

uss-north-dakotaThe v1.10 update for CMANO was released on Feb 26 to widespread acclaim. The dev team is already hard at work preparing the next upcoming major release, version v1.11. After the panoply of new features in past updates, what new tricks do the CMANO devs have up their sleeves? Let’s take a peek.

Under the sea: Improvements on submarine ops

Updated Air-Independent Propulsion (AIP) model

The implementation of Air-Independent Propulsion (AIP) has been refined in Command v1.11. While it is possible to recharge the submarine’s batteries using AIP, the low power of typical AIP systems relative to the diesel-powered generators means that it would take extremely long time to recharge a deeply discharged battery. Storing energy in batteries is also a less efficient than storing the energy in the AIP reactants. As such, AIP is best used to minimize discharge of the submarine’s batteries, and wait with conventional diesel engine recharging to a time and location that is more suitable. This means the AIP system will only be able to keep up with battery drainage at creep throttle setting. At higher speeds, the electric motors will require more power than the AIP can deliver, which forces the sub to eventually snorkel.

New submarine doctrines

Submarines have several new doctrine settings. The new settings are:

Dive when threat is detected: User-selectable options are No, Yes on periscope/surface search capable radar detection, Yes when ships are within 20nm or aircraft are within 30nm, or Yes on both ESM detection and threat proximity. In some cases it is not desirable to go to the surface to snorkel or use the periscope. The player can configure whether the submarine should dive if a threat radar has been detected, if there are nearby air or surface threats, or both.

Recharge battery %, transit / station: Set the batter percentage at which the submarine should snorkel to re-charge when in transit or on patrol.

Recharge battery %, offensive / defensive: Set the battery percentage at which the submarine should snorkel to re-charge when engaged offensive or defensive.

Air Independent Propulsion (AIP) usage: User-selectable options are No, Yes, or Yes when engaged offensive or engaged defensive. Allows the player to limit AIP usage, including saving the AIP fuel for attack and defence only.

Dipping sonar: User-selectable options are Automatically deploy in hover and less than 150ft altitude, or Only deploy manually or when assigned to mission. Enable unassigned helicopters to dip their sonar while loitering.

Avoid contact: User-selectable options are Yes or No. This setting isn’t used much by the AI quite yet as it is currently being overridden by built-in mission logics. The functionality be further expanded in the future.

SubmarineDoctrine001(Click on image for full view)

 

Under the hood: Performance, memory & pathfinding improvements

“We need greasy, fast speed!”

Command v1.11 runs significantly faster than earlier versions of the simulator. Small/simple scens run just as fast as before (although older PCs may notice a difference in them too), but the benefits become most apparent in large complex scenarios, with speed increases between 3x-10x being common in many setups. The massive gains have come from a number of sources; memory optimizations (see below), more efficient data structures, careful removal of wasteful operations etc. Great care has been taken to leave the “business logic” of the simulation untouched in order to prevent the appearance of bugs. The end result is that v1.11 provides a substantial performance improvement while fully retaining the simulation finesse that Command is renowned for.

New options for game speed

Having a highly detailed and feature-rich simulator engine comes with its share of disadvantages. Command is chock-full of functionality that can easily chew up trainloads of CPU-cycles and cause the sim engine to crawl on even high-end computers.

Command v1.11 adds a ‘Game Speed’ tab in the Options window that allow players to easily turn off CPU-intensive features that may not be needed in the current scenario. The player can also choose to enable a shortcut to the ‘Game Speed’ tab from the main window. The shortcut changes color depending on how many CPU-intensive features are active, which helps the player to quickly determine if the simulator is running at optimum speed.

GameSpeed002

GameSpeed001

Memory handling

Since many Command players still use 32-bit operating systems, the sim is limited by a 32-bit memory space. Although switching to a pure 64-bit environment would confer many benefits, the current reality is that we will probably be stuck with 32-bit limitations for quite some time. This is the bad news.

The good news is that Command v1.11 has significantly improved memory handling. During testing, large scenarios have been running continuously for 36-48 hours without any speed drop, memory corruption, or Out Of Memory (OOM) exceptions like those reported on past versions. Another noticeable memory stress-test, loading large scenarios in rapid succession, has been passed with flying colors (more than 60 “monsters” in a row were loaded without any issues).

It is therefore a reasonable claim that most (dare we say all?) of the memory issues that have caused problems in past versions have now been resolved.

Area (Polygon) Validation

In Command, all areas such as mission areas, exclusion zones, no-navigation zones and event trigger areas are geometric figures called polygons. If the lines that make up a polygon cross then the area is considered invalid, and it is difficult for the in-game ‘point-in-polygon’ function to determine if a unit is inside or outside this area. We have noted that sometimes players and scenario designers accidently create areas that are indeed invalid, and tasks such as navigation and target prioritization may not behave as expected.

As such, all windows with area editors now have a ‘Validate Area’ button that allows the player to quickly determine if the polygon is valid or not. The simulator will also display the polygon in the tactical map. This includes areas used by the event engine. Event engine areas are displayed on the tactical map in a ‘Hot Pink’ color (of course…) when the event editor or event trigger windows are open.

Furthermore, all areas in a scenario are validated on load, and the player will be presented with warnings if the scenario contains invalid polygons.

Pathfinding refinements and new options

Command has a pretty sophisticated pathfinder which is used by the built-in navigator to find routes around obstacles like land masses, islands, shallow water (for submarines), No-Navigation Zones, and polar ice. The elevation data used in Command has a resolution of 900 meters at the equator, which is roughly 0.008 angular degrees. The number of sampling points per degree of latitude remains constant which means the resolution increases as we get closer to the poles (with exceptions at the extreme north or south), and the resolution at 60 degrees north or south will be twice that at equator (450m between elevation points).

Pathfinding is extremely expensive in terms of computing power. Finding a path covering just one hundred nautical miles will have to check millions of elevation points, and No-Navigation Zones and polar ice will have to be checked for each of those points as well. Although Command uses multi-threading and hands off complex tasks to helper-threads on other cores, the pathfinding operations will still have to be queued and processed. This steals significant amounts of computing power from all the other multi-threaded operations.

As a consequence, Command was designed with both coarse and fine-grained pathfinding. Coarse pathfinding has a 0.05 angular degree resolution, while fine-grained pathfinding uses 0.005 degrees. The advantage of using coarse pathfinding is speed; it is significantly faster. The drawback is of course that it doesn’t check all elevation points and may miss narrow peninsulas and tips of land, tiny islands, and narrow straits.

In previous versions of Command, fine-grained pathfinding would only take place when the distance was less than 8 nautical miles, and it would search for a path in a box that was 0.5 angular degrees larger than the box made up of the start and end points. Because of these rather strict range limitations it was rarely used. This was by design, but had the side-effect of making some players think the elevation data and pathfinding model was flawed – it never was.

Command v1.11 allows players to configure when to use fine-grained navigation. Our recommendation is to use this feature with caution as it will slow down simulation speed significantly, and for instance a 50 nm course with 2 degrees lat/lon search area outside the start and end points may take up to five minutes to compute on a fairly fast computer with an SSD. After all, the pathfinder needs to check nearly one million (!) points. Most players will probably continue to use the default settings, but in some cases such as ops in littoral waters, being able to change this setting will make a big difference as the ships will no longer drive across an island or two by accident.

FineGrainedNavigation(Click on image for full view)

Command’s navigator code can perform complex pathfinding tasks. Smaller paths are typically resolved in a matter of seconds, however longer paths may have to evaluate millions of terrain points and it can take several minutes finish each pathfinder request.

As an example, if you place a sub in the Indian Ocean and put a single destination waypoint in the Atlantic Ocean just off Gibraltar, the navigator will be perfectly capable of finding its way through the Red Sea and Suez canal, across the Mediterranean, into the Atlantic Ocean… a distance of more than 4000nm. See screenshot below, the dotted line indicates it is a navigator-created path as opposed to a manually plotted or mission-created path. (Let’s see any other similar game do that :))

Navigator001

The above path is still a pretty straightforward job for the navigator since it didn’t have to find a route around large land masses. It should be noted that the maximum treshold distance is 20 angular degrees outside the start and end points, which means that the pathfinder would not be able to find a course from the Persian Gulf to the Kola Peninsula because the start and end points are in a north-south direction and the path would have to be plotted beyond 20 angular degrees east or west

In other words, if an Iranian Boghammar boat is assigned to a sea control patrol mission that is not geographically limited by the patrol area or prosecution area, the AI might decide to target a contact far away. The navigator will do its best to plot a path to the target, and will use a lot of computing power to in the process. However in extreme cases it will not be able to find a route, and the Boghammar boat’s AI will soon make another pathfinder request that will do nothing but waste computing power. The cycle will continue for the duration of the scenario, eating up a large percentage of the available computing power and slowing down game execution.

Because of this, we’ve added information about the Pathfinder Queue on the Diagnostics bar. The Diagnostics bar can be enabled via the Options window. This gives the scenario designer and player information about the number of pathfinding requests in the queue, and which platform is currently having its request processed.

Navigator002

Under normal circumstances, units rarely make pathfinder requests. And when they do, the requests are usually processed in 2-4 seconds. If units start making frequent requests it is usually a sign of flawed mission setup. For instance, patrol missions may not be limited by patrol and prosecution zones. Or that patrol areas are too large and ships have to deal with too much land between themselves and their targets. Turning off ‘Opportunity Fire’ can also help, as ships will only stick to mission-relevant targets and not chase after contacts they will not be able to reach.

As with past versions of Command, overall game performance still depends heavily on good scenario design and the way the player has configured the simulator.

Tags: no tags

The great leaps of v1.11: ORBAT recon of air/naval bases

March 13, 2016 · Posted in Command · Comment 

Recon1The v1.10 update for CMANO was released on Feb 26 to widespread acclaim. The dev team is already hard at work preparing the next upcoming major release, version v1.11. After the panoply of new features in past updates, what new tricks do the CMANO devs have up their sleeves? Let’s take a peek.

ORBAT recon of air/naval bases (a.k.a. “I want to spot those planes on the ground!”)

Like pier operations, this too has been a popular request that we are happy to bring to fruition. Aircraft, ships and submarines can now be spotted on their host facilities during a BDA/recon attempt by a friendly unit.

There are two ways of spotting hosted units:

1) When a unit with a visual/IR/radar sensor performs BDA on a naval or air base, it also performs recon on its open-air air (revetments, parking areas, pads, runways etc) or docking (piers, docks, drydocks etc.) facilities respectively.

2) Assets under cover are not completely safe from observation either: If an aircraft enters or exits an enclosed air facility (e.g. a fighter that has just landed is entering a hangar to re-ready) *while a unit is observing this facility*, the aircraft is also spotted (the same holds for e.g. a submarine entering an underground base). This means that “persistent” recon/intel assets (anything from a SOF team parked outside the base, to a stealthy RQ-170/180 loitering overhead or even a satellite perched far up in HEO/GEO orbit) are essential for keeping track of under-roof traffic and inventory.

Units spotted either way are kept on record and classified/identified as per the normal detection/classification rules. This is also reported on the message log. A “spotted hosted unit” record also contains age info so that the player is aware how stale this spotting report is (a “5 mins ago” observation obviously holds different value than a “2 weeks ago” one).

On the map, friendly facilities that host units AND contacts on which hosted units have been spotted are displayed with a “black triangle on yellow box” symbol. This allows at-a-glance awareness of which friendly assets (and contacts) host units:

Recon2

Night over Bandar Abbas, Iran. A stealthy RQ-180 recon UAV is getting dangerously close to the airport facilities (and anti-air defences scattered around) in order to catalogue the base’s aircraft inventory. A few aircraft have already been spotted (notice the black/yellow mark on some of the parking tarmacs). No doubt more are in enclosed hangars and shelters. Will the UAV get lucky and spot any of them coming in or going out?

 

If a unit gets close enough for a re-recon of a contact with spotted hosted units, the existing spot records are re-evaluated and refreshed, and any now-missing units are discarded from the recon reports.

Spotted unit records are listed on the “Contact Report” window, on a new “Hosted units spotted” tab:

Recon3

Three J-7s have been spotted on this tarmac. Not a great catch, but the more high-value units are no doubt inside shelters. A SEAL team under cover would be really useful to catch those; the UAV is already hanging perilously close to the base and must withdraw promptly or risk detection and destruction.

So, how will you exploit this new intelligence capability? Will you use it to finetune your targeting on your next airbase / naval base attack? Will you revise your frontline tactics with the knowledge of what the enemy is (even temporarily) keeping away from the front? Something else entirely? As with most aspects of Command, the possibilities are endless.

Tags: no tags

« Previous Page — Next Page »