The latest Command Beta is available on the Open Beta branch. It is available on Steam only currently, via the open beta branch. Please use the following Guide as reference if you need assistance in accessing the beta branch on Steam.
Please see the changes below:
* ADDED: Added 'Add Reference Point at...' menu item and dialog (on "Missions and Reference Points" menu); this allows placing a reference point with great precision, using known lat/lon coordinates.
* TWEAK: [DX11 renderer] Map renders at full pixel resolution of expanded viewport when user uses shortcut button to hide the shortcuts bar, preventing issues with selecting and dragging icons on the map while the shortcut bar is hidden (because the map render was being upscaled to the expanded viewport instead of being resized to the expanded viewport).
* TWEAK: [Ops planner] Tweaked tooltips
* TWEAK: Mixed or homogenous airgroups properly display the composition type
* FIXED: Performance issue when rendering lots of unit icons
* FIXED: Patrol Flightplans where exceeding the defined patrol area if the patrol leg was less than 50 nm
* FIXED: Missing null check in flightplans editor
* FIXED: Only some Patrol flightplans where generated
* FIXED: #15142: SM-6 ARH performs 180 (by pitching over)
* FIXED: RVs could impact short of target & show wrong message due to wrong activation altitude
* FIXED: Kinzhal missile flies into space
* FIXED: Aircraft sometimes ignored mission altitude during cargo transfer mission
* FIXED: Issue when simplifying uncertainity area after expansion, causing incorrect area and rendering artifact (scattered yellow lines )
* FIXED: Repeated exception when aircraft group lead has no plotted course
* FIXED: [DX11 renderer] Both sonobuoy icons and the small angled lines above them appear faded when sonobuoy are set to appear as ghosted.
* FIXED: [DX11 renderer] Filtered-out contact icons appear faded when filtered out; normal otherwise.
* FIXED: [DX11 renderer] Removing a custom layer removes the layer from the "custom layers" menu and from map without null pointer exception
* FIXED: [DX11 renderer] Various rendering issues
* FIXED: #15127: [B1307.14] MDSP & WRA Issues points 2 & 3
* Includes the latest version of the DB-description files. Special props to Artao5 for his contribution in this package update.
* Includes the new v500 release of the DB3000 and CWDB databases.
Ethan Hermanson presents the v500 schema revision:
DB3000 v500 content changelog: https://drive.google.com/file/d/1ukywMO ... sp=sharingIt’s been a few cycles since we last released a schema summary, but we couldn’t let the v500 release un-commemorated.
v500 is worth celebrating. Beyond the usual additions (nearly 500 across DB3K and CWDB, with over 200 associated loadouts) and national reviews of Iraq, Kuwait, and more, this release is one of our most significant DB updates yet in terms of schema. With v500, we’re laying the groundwork for transformative change even beyond past updates like our OODA rework.
The Comms Overhaul (currently not used in-sim)
Comms in Command have traditionally been fairly binary: a unit is either “in comms,” or it is not. There was proper logic in place to handle weapon datalinks and, more recently, CEC engagements (i.e., the ability of a sensor to pass target/firing data on to a separate shooter), but these were similarly simplistic: a weapon could be guided by offboard data, or it could not.
Our challenge was to create a new system that put this highly technical domain “in play” for both pro and commercial users without veering into unapproachable technobabble. Rather than leaning into the intricacies of wavelengths, attenuation, data transfer rate, etc., we opted to focus on the characteristics of communications that matter to the warfighter, namely:
- Who can I talk to, and who can talk to me?
- What information can I efficiently pass and receive?
- How long does it take me to send/receive said information?
- What can the enemy do to ruin my day while I attempt the above, and what can I do to ruin his?
The legacy comms system attempted to answer the first question with a simple “Comms Type” field: comms could only talk to comms of the same type. Limitations appeared quickly: for example, we could not reflect upgrades where one comms type became interoperable with another. To fix this, we promoted the Comms Type field to proper subcomponent status and gave it a “Can Talk To” subform. Now, we can set Comms Types to understand each other (the relationship can be mutual, or one-way). This flexibility allows us to better map the complex web of interoperability (and, more critically, non-interoperability) between modern links.
To answer the second and third questions, comms entries got some extra data fields in v500: namely, a “Quality Grade” and “Latency Grade” (optionally definable in seconds). The Quality Grade describes the fidelity of information a particular comms link can pass and ranges from “General Location” to “Remote BMD” and “Full Motion Video”. The Latency Grade describes the time it takes to pass that information through a given comms link and ranges from “Slow” to “Instant”.
For example, a standard voice radio has the lowest Quality Grade, “General Location”, because radio reports are inherently inaccurate (of course, voice reports on stationary structures are significantly more accurate than, say, an infantryman reporting aircraft above); they have a “Normal” Latency Grade, where it might take, say, 10 seconds to describe the situation before passing on another updated report. Units connected solely through a voice link will have a general idea of the common operational picture, but nothing like they’d get from, say, Link 16; it might be enough to order an airstrike, but certainly not enough to launch an air-to-air missile. Conversely, a modern datalink like the F-35’s MADL has a Quality Grade of “AAW” and a Latency Grade of “Instant”, enabling it to continually pass fire-control quality data to other units on the network. Quality and Latency are both bottlenecked by the weakest link: for example, Link 11 and Link 14 can talk to each other, but though Link 11 is a “Fast” datalink, ships with Link 14 are limited by their “Slow” reception (Link 14 literally used teleprinters).
Finally, to lay the groundwork for better comms degradation, interception, and jamming, we’ve added several new flags for comms similar to those we use for radars: “Low Probability of Intercept/Detection”, “Phased Array Antenna” (e.g., MADL), “Jam Resistant” (e.g., HAVE QUICK) and “Degrades With Range” (obviously all comms “degrade with range” to a certain extent, but this is specifically for comms where the effect is pronounced and directly affects operation, e.g., LOS radios).
Tangentially related is the continued implementation of distinct GNSS interference: we have added the various GNSS systems (GPS, GLONASS, BeyDou, NavIC/IRNSS, etc. as interceptable/jammable “frequencies,” which will initially mostly affect weapons but may eventually expand to units as well.
Combined, these changes represent the first round in a new communications foundation we hope will make comms as important for planners to consider as the sensors they fuse. Communications and interoperability are a major concern for planners (see BACN, ROBE, etc.); now it will be in Command, too. (Advanced comms modelling will be an optional scenario feature.) And this is only the beginning: we’re excited for all the follow-on features this will enable, like distinct UAV GCS modelling, MUM-T, SATCOM network degradation, “player C3 node” selection (i.e., the unit(s) that orders are assumed to be coming from), and so much more.
We have backfilled the new fields for all existing comms entries and done some initial work to fill in major datalinks missing from platforms, particularly for the U.S. However, we have a lot more work to do, and we’d love to have your help filling in missing platform and country-specific links over on the public Github.
Directional comms jammers (currently not used in-sim)
Closely related to the comms overhaul is the addition of directional comms jammers. Comms jamming is not new to Command (though now it will become far more useful) but was limited to omnidirectional jamming. Many systems are increasingly able to focus comms jamming along a specific axis in order to avoid collateral “damage” and minimize the effect of jamming on friendly units; now, these systems can be properly modelled, with distinct beam dimensions that determine their axial coverage.
Hight-power microwave weapons (currently not used in-sim)
In a similar vein, DB v500 also includes enhanced modelling of “beam” weapons, specifically microwaves. Previously, microwaves were crudely modelled in a manner similar to lasers: as weapons which could only be fired at individual targets. But one of the primary advantages of microwaves is their ability to fry all electronics (notably, small UAVs) within a given swath of airspace. To better model these capabilities, we have leveraged the existing “sensor” infrastructure to give microwave weapons distinct beam width and height values (just like with directional comms jammers), as well as allowing them to benefit from phased-array designs: broadbeam microwaves can only sweep their beam towards targets and hope nothing friendly is in the air nearby, where AESA beams can precisely target multiple targets and avoid friendly fire (though AESA microwaves are just as capable of frying chunks of the airspace if so desired).
CWDB v500 content changelog: https://drive.google.com/file/d/1uupIaQ ... sp=sharing