Tiny’s big brother: Command PE v2.2 now available

March 6, 2023 · Posted in Command PE · Comment 

It’s been a freakishly busy 12 months! Since the release of CPE v2.1, the Command dev team has been tirelessly working on assembling the next major update for Command PE, and now the day has come: Command PE v2.2 is available for download.

Phil Gatcomb has made a new series of tutorial videos detailing some of the new features (also present in CMO); watch them HERE.

A release every bit as gargantuan as its War Planner/”Tiny” stablemate on the commercial CMO side, the v2.2 update includes a massive range of groundbreaking new features as well as myriads of less major improvements and additions. Pro users who also dabble on the commercial version will likely recognize many features that debuted on the War Planner launch, but the update also introduces several additions exclusive to the professional edition.

Some of the hottest new features include:

Amphibious Planner & 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. The brand-new Amphibious and Operation planners make this, and much more, a reality. The amphibious and operation planner, together with the serial editor, form a set of common-oriented tools that allow you to orchestrate complex, multi-layered operations (including, but not limited to comprehensive amphibious landings) and execute the different phases of an operation at different time points or based on customized conditions.

Multi-Domain Strike Planner: Coordinate massive, complex strike missions with time-on-target, complex flight plans (incl. in-flight refueling), multiple attack patterns and multi-domain strike combinations.

Cargo 2.0: Command’s existing cargo system was hitherto geared more towards the transfer of combat forces & personnel rather than materiel. This changes radically with Cargo 2.0. You can now 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 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.

“Double-flame” mode (5-sec sim timeslice): “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. And it manages to do so without the wierd bugs and repercussions normally (and wisely, from hard-won experience) associated with excessive time-slice sizes.

3D signature splat: We have a separate article for this addition, and for good reason. This brand-new mechanics override allows precisely specifying the per-angle signature (any type) of any given platform, both on azimuth (horizontal plane) and elevation (vertical plane), offering a true 360-deg signature sphere. Furthermore, it can directly use AFSIM-format signature tables. Not every pro user needs this, but to those who do: You’re welcome.

Intermittent EMCON: This band-new feature allows controlling the behavior of emitting sensors so they emit in intervals instead of only continuously or never. Radars and other active emitters no longer have to strictly choose between active and silent: You can now blink, and schedule exactly how to. No scripting necessary! (But scripting is still a very powerful option).

Palletized weapons: 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).

Custom Environment Zones: 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.

One-click License Revoke: The license-revoke procedure has been further automated, allowing you to revoke the license on any existing machine, and re-apply it on another system, without any intervention by Matrix personnel.

Benchmark mode: If you are familiar with Monte-Carlo analysis using CPE, then this new feature can best be described as “Monte-Carlo without any data export”. 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. (By default, the execution is run using fine-grained pulse mode (i.e.. 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.

Barks & slug-trails: Barks are short text notifications that can be set to appear, briefly, anywhere on the map. 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.

“Slug trails” are a UI/map feature familiar to anyone with past experience with air-traffic control radar screens, sonar tactical consoles etc. They essentially display the past known locations of a given unit or contact in order to provide better context for their movement.

IRST/FLIR 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).
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.
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.

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

HGV improvements: Hypersonic Glide Vehicles (HGVs) can now have a waypoint/dogleg course assigned when launching them, with one or more waypoints. This reflects one of their core advantages compared to ballistic missiles. The trajectory profiles of HGV has also been improved, with updated information assembled from public sources about the typical boost, re-entry and glide portions of HGV employment.

Revised 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. For more details see the paragraph “Overhauled Reaction Times” on this post.

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

Ground logistics improvements: As part of the Cargo 2.0 changes, both the UI and underlying mechanics for the replenishment of ground forces have been improved. Distinct ground units are now fuel-limited and will stop dead in their tracks if they are not properly refueled. Both fuel and munitions can be replenished by dedicated resupply trucks included in the database, and the unit-context menu (aka right-click menu) includes a host of new options for selecting which stores to restock in priority, as well as to select which provider to actually use for the replenishment rendezvous.

Improved torpedo evasion: 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.

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 and on the throttle/altitude window. 

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.

New event-export event type – Cargo transfer: The event-export framework can now track and export all cargo-transfer operations being performed during a simulation. For details see the “Event Export” section on the CPE v2.2 manual.

Complete sensor detection reports: Perplexed as to why a given sensor detection failed? CPE now offers the ability to deep-dive into the detection process and examine each step and factor individually, to better understand which steps succeed and which fail into any detection attempt. A powerful but also CPU-expensive new feature that definitely demands wielding with caution, and using in moderation.

Expanded Lua event hooks: More hook types related to sensor checks and contact updates (in both on- and off-grid communications states), offering even greater mechanics-override functionality through this powerful framework.

All the content & database updates of CMO: All official scenarios (incl. DLCs) have been rebuilt in the latest DB releases and tweaked. This includes various fixes for reported issues. In all the scenarios the WRA firing ranges for AAW missiles have been adjusted to No-Escape Zone (NEZ) by default. Practically this means that units will delay their AAW shots until they estimate that the target cannot outrun the missile.
The very latest (v498a for the DB3000 and v498 for CWDB) revisions of the official databases have also been included; their miles-long changelog is available in the CMO War Planner update release notes.

The CPE development team is already busy assembling the follow-on update releases for CPE, featuring even more advanced features and major upcoming architectural upgrade. As always, stay tuned for more news.

Tags: no tags

When high fidelity counts: 3D radar splat in Command PE

March 6, 2023 · Posted in Command PE · Comment 

The new v2.2 update of Command PE is a truly massive release, as it includes all the latest additions of the commercial massive “War Planner” update, plus some new features which are exclusive to the pro edition. One of the most exciting new features has arguably one of the blandest names possible: 3D radar splat. Let’s have a look at why we are so electrified about this addition.

By default, Command abstracts the radar signature (and other sensor signature types) of any given unit into a six-sided distribution: front, sides, rear and top/bottom. This is an example from an F-16A database entry:

(RCS values are in dBSM)

This arrangement allows modelling a wide array of different common signature combinations. Some examples:

While this degree of fidelity is perfectly adequate for the commercial version of Command, professional users sometimes need something more detailed. Why? Because real-world signatures are far more complex than that:

(If you didn’t already know why they’re called “splats”, now you do)

Not only is the angle-dependent signature value more finegrained depending on the azimuth angle, but the value also varies both on the horizontal and vertical axis. This is an example of the estimated RCS values (L-band) of the F-16A on the frontal aspect, dependent on azimuth and elevation:

With this in mind, we set out for a way to properly model this variance. Thankfully, an industry standard of sorts already exists: AFSIM, a modeling & simulation suite, tackles this very challenge by defining a file format for representing signature values on both dimensions. We paralleled this format & structure for CPE and further extended its potential application to any sensor signature type, instead of just radar. This makes it very easy for clients who already use such files in AFSIM to also use them in CPE without any internal changes.

The key is using a two-dimensional table of values, with the rows and columns delineated by the respective azimuth and elevation samples, and the matching value samplings within the table. As often, a picture speaks a thousand words:

Using this already-established format, CPE now allows modelling in great detail the aspect-dependent signature values (any valid signature type) of any aircraft. This is implemented as an optional mechanics override, and the splat files are per-DBID, so a user can mix-and-match his highly-detailed splat files for the aircraft(s) of interest, together with the existing 6-side format that Command’s database offers for all other aircraft.

The new 3D radar splat and many more new features are part of the new CPE v2.2 update, which has just been released.

Tags: no tags

Back in Quantico: The 9th Command-PE User Conference & Training event

October 11, 2022 · Posted in Command PE · Comment 

It was great to be back!

Matrix Games, LLC hosted the 9th Annual Command: Professional Edition User Conference & Training event at X-Corp facility next to Marine Corps Base Quantico, from 19-23 September 2022. The event was organized with the full support of Luis E. Velazquez, Chief Technology Officer (CTO) at United States Marine Corps, and in close coordination with the USMC, and run throughout the week, focused on helping the defense community get the most out of the increasingly powerful and diverse Command-PE software suite.

As with previous events, this too boasted a diverse array of participants with more than 30 agencies & organizations from the US DoD and NATO allies as well as the defence and related private sector. It included presentations and training sessions by Matrix Games in additions to guest presentations by numerous users highlighting their use cases of employing CPE for their specific needs. Participants had front-row seats to the comprehensive analytical, wargaming & training capabilities of Command-PE, interacted directly with core members of the development team and exchanged experience and tips with other operators of the software.

For a change of scenery, the next CPE event will be held in 2023 in Italy. See you all there!






Tags: no tags

Nerf Wars: On downgrading Russian systems & units in Command

October 3, 2022 · Posted in Command, Command PE · Comment 

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.

Tags: no tags

Command PE 2.1 has been released

March 10, 2022 · Posted in Command PE · Comment 

It’s finally here! Ever since the original release of v2.0, we have been putting together the next major update for Command PE, and the day has come: Command PE v2.1 is now available for download.

Phil Gatcomb has made a new series of tutorial videos detailing the most important new features, watch them HERE.

True to the spirit of every Command release, v2.1 is jam-packed with new features and enhancements straight from user feedback and requests. The full release notes are available HERE.

Some of the hottest new features include:

  • New feature: Lua Event-hooks. It is now possible to extend and even override built-in simulation events by using Lua scripts and hooking them up to these events. This brand-new feature was showcased at our most recent user conference and easily turned heads, with good reason: It makes implementing mechanics overrides easier than ever, and with absolutely no involvement needed by the CPE development team (particularly useful for sensitive or proprietary models/data).
  • New “Interactive Analysis Settings” window. Interactive analysis settings can now be configured on-the-fly, without having to restart the application for the changes to take effect. Big boon for analysts!
  • New simulation feature: Radar resolution cell. (See this page for background). If multiple units are located within the resolution cell, the radar will detect only one of them. This feature confers an extra advantage to higher-frequency radar systems, as they are better able to distinguish between closely-clustered targets.
  • New simulation feature: Radar vertical scan angle limits. Radars can only look up/down to a maximum of 30 degrees. This restriction severely curtails their ability to search for targets high above or well under them, and has indeed been used and exploited historically (example). There is an exception, however: Phased-array radars can scan upwards close to the vertical limit.
  • New simulation feature: Phased array off-boresight gain reduction. Phased-array radars (PESA/AESA) suffer from gain degradation (hence effective range reduction) when attempting to detect targets far off the antenna boresight, both on the horizontal and vertical plane. This schematic shows the coverage difference between a mechanical-scan set (APG-68(V)9) and two AESA radar options for the F-16:

    Note the severe drop on high off-boresight detection range on the two AESAs because of the gain reduction.This severe reduction in effective detection range can cause problems when cranking during BVR engagements, as the target is placed at the problematic “edge of scan envelope” area. To compensate for this, phased array-fitted aircraft now crank much more conservatively (less divergent from true bearing to target), in order to keep tracking the target.
  • New simulation feature: Daisy-chain weapon datalinks. Weapons can now directly connect to each other instead of always connecting to a firing/guiding platform. This behavior can be used by weapons to model comms extension, contact sharing etc.
  • New simulation feature: Loitering weapons. Two types of loitering weapons are modelled; aerodynamic and parachute. Loitering weapons can be fired either directly against a target (as standard non-loitering weapons) or BOL-fired (Ctrl+F1) into a set of coordinates and then hunt for a target either autonomously or under direct control, depending on their communication status.
  • Significant changes to sonar model. We have previously described these changes as part of the CMO v1.03 update, and they have now been absorbed into CPE as well.
  • Wholly-reworked ballistic missile trajectory model. The BM model now uses true Keplerian equations resulting in highly-accurate trajectory profiles for each range segment (minimum-energy trajectory is assumed). This is particularly visible in intermediate- and long-range ballistic shots.
  • New facility type: Surface (flat) & underground. This type represents facilities that reside primarily underground while still being partially surface-accessible (and thus attackable). Such facilities include ballistic missile silos (and old Nike-Hercules!), command / LCC bunkers and retractable forts & coastal defences (e.g. ERSTA). This type of facility can be damaged/destroyed in two ways: Direct hit on above-ground surface, or transmitted shock from underground detonation (e.g. MOP, B61-11, BLU-109/113 near-miss) or a VERY powerful surface burst (e.g. B53 laydown).
  • Ground units now have fuel records and can refuel & replenish. If they run out of fuel, they are immobilized until they can refuel. They can also request replenishment, for both fuel and ammo/stores from suitable providers (e.g. fuel-bowser trucks or ammo carriers). If they can move to the UNREP vehicles on their own they will do so; otherwise the UNREP vehicles will rendezvous with them.
  • Revised Mission Editor layout. The Mission Editor window layout has been revised, with the unassigned and per-mission assigned units windows now stacked vertically (on top of each other) instead of horizontally side-by-side. This makes it easier to read the full unit names (which may differ only towards their ends) as well as supplementary per-unit information (loadout, status etc.). In addition, the panels now include per-category filter buttons that allow displaying only the selected types of platforms:
  • Redesigned Message Log window. The Message Log window has been redesigned to be easier to interpret. Instead of grouping the displayed messages by type, messages to be displayed can now be filtered in/out by individual type, by toggling the buttons labelled with their respective type. In the example below, all message-type buttons are green, which means that all types are enabled for display:

 

  • New UI feature: Quick manual weapon allocation. While having an own-unit selected, shift + right-click on contact, and select “Engage with:”. This will present a submenu with all suitable weapons to engage with:

    The right-click menu has also been enriched with additional options, such as:

    • Drop Target
    • Investigate (ie. manouver to intercept & identify but do not engage)
    • Refuel To Tanker
    • Join Group As Escort (for aircraft only)
    • RTB
    • Assign New Home Base
  • In WEGO-MP mode, clients are automatically able to use custom databases regardless of their license tier. Furthermore, if the server uses a custom database, this is automatically distributed to new MP clients as they connect to the running session. This greatly simplifies the setup for starting up new MP sessions.
  • Load/save Doctrine & ROE templates. You can now load/save doctrine/ROE templates in XML format through the GUI (“Doctrine/ROE” window, “General” tab):
  • You can now change the side of any existing unit. This is supported both by the GUI and also through scripting.
  • Updated database releases (v492), with hundreds of additions and changes.
  • Dozens of other tweaks & additions big and small, based on the feedback that the development team receives from the professional user community on a daily basis.

With v2.1 out in the wild, the dev team is now free to merge several currently-in-development major new features into the main development branch, so you can update even more on the next update release. Stay tuned!

 

Tags: no tags

Next Page »