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

March 14, 2016 · Posted in Command · Comment

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

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

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.

(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 :))

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.

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

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:

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:

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

The great leaps of v1.11: Pier operations

March 12, 2016 · Posted in Command · Comment

Pier Operations

You asked for it, so here it is!

Ships have had the ability to dock with designated parent ships and facilities ever since the beta days of Command, but their ability to be serviced while docked was very limited. This changes with v1.11: Proper refuel, re-arm and repairs are implemented.

Pier facilities now extend passable “pier lane” areas around them that allow ships to navigate to pier areas even slightly inland (similar to canals). This allows true-to-life positioning of pier facilities without having to flatten the terrain data around them in order to make them accessible.

The light-shadow polygon is the “pier lane” area projected by the multiple pier facilities inland. Ships and submarines can freely traverse this area (even though terrain is nominally present) to navigate in and out of the piers.

Once a ship docks to a pier (or parent ship), the process of refuel, repair and replenishment begins. Both refueling and rearming happen at faster rates than on UNREP hookups as the docking condition allows for a stabler environment and more extended facilities and tooling. In addition, while a ship underway can perform repairs only to minor component damage and cannot repair structural damage, docked units can perform repairs on medium- and heavily-damaged systems, and can also repair their structures.

Replenishment rates have been given a thorough overhaul in v1.11, both for pierside and UNREP modes. Light weapons can be loaded quite fast as before, but heavier weapons (particularly heavy gun shells or large bombs, missiles or rockets) can take hours to transfer and load.

Readying a ship for redeployment differs from aircraft turnaround in a number of ways. Ship preparation typically takes far longer than aircraft (except for very small boats), and in contrast to an aircraft, a ship is perfectly able to put to sea again while still in far from optimal condition. Accordingly, the player can order one or more ships to redeploy while they still have damage, or miss weapons and fuel.

This sounds simple enough for manual control, but what about AI control? How do AI-controlled ships decide when to disengage from frontline operations and when it makes sense to stop repairs etc. and re-deploy? To enable the AI to make reasonable decisions, a new set of doctrine settings (Withdraw / Redeploy criteria) are added:

The status of each of those aspects is continuously tracked and evaluated against the doctrine threshold and a ship will withdraw from its mission if any of the withdrawal criteria are reached. Conversely, while docked, these criteria are regularly checked and a ship is allowed (by the AI) to re-sortie only if everything is “green across the board”. The player of course can still order nay ship to sail immediately regardless of its condition.

These new settings allow tailoring the withdraw and redeploy behavior of a ship to its unique strengths / weaknesses as well as to the needs of her mission tasking. For example an anti-aircraft escort may be set to ignore depletion of its offensive weapons, fuel and any damages to itself and withdraw from the line only when its defensive (AAW) armament is depleted. Conversely, a sensitive high-value unit may be configured to withdraw immediately on the first scratch of damage.

Busy day at Norfolk. Both the frigate and the fast attack sub are fine on damage and fuel, but both are short on ammo. Will you wait for them to re-arm (which may take a while!) or flush them out to sea immediately? Choices, choices…

The redeployment criteria allow the player (or scenario author) to make his own decisions on how “ready” he wants his ships to put out to sea again: Does he wait until every last bit of ammo is restocked? Is it enough to repair damage and get refueled? Remember, while your ships are in port they are not out to sea and the enemy gets a free pass. Obviously there is no single “best” answer, and the theater/operational exigencies (as well as time pressure) are likely to force the player to make decisions that he is not entirely happy with. Real-life ops are very often a compromise, and Command reflects this.

The implementation of pier ops in Command, even in its “raw”, unpolished form in v1.11, is a huge step forward in expanding the scope of the game into the theater/strategic scale. Numerous players have asked for the ability to fight out to air and sea, then get their forces back in port and repair/ready them as possible, and get out there to fight again. v1.11 is the answer to their prayers. We hope implementing this along with our substantial lua scripting and event editor features will encourage editor’s and players to explore longer duration scenarios.

Tags: no tags

The great leaps of v1.11: AGL altitude settings, stores jettison and mission player feedback

March 9, 2016 · Posted in Command · Comment

Above Ground Level (AGL) altitude settings

Further preparations have been made for the startup of the Advanced Strike Planner project. Command v1.11 adds an Above Ground Level (AGL) altitude setting, in addition to the existing Above Sea Level (ASL) setting, to enable terrain-following (i.e. ride altitude) for aircraft equipped with terrain-following and terrain-avoidance radar. Currently, this distinction is only made in the Speed/Altitude window but it will be a important feature in the Advanced Strike Planner.

(Click on image for full view)

In addition, all weapons have had their weapon release parameters updated in database v441. The minimum and maximum release altitudes may be AGL or ASL, or both. For example, the firing parameters could require the aircraft to fly at minimum 1000ft above sea level (ASL) and also have minimum 200ft ground clearance (AGL).

Stores Jettison

This has been a popular user request and especially after we introduced the weight-dependent aircraft performance tweaks in v1.10. Aircraft will now jettison their A2G stores when evading an attack (if the relevant doctrine setting is set to YES). This is accompanied by a relevant message detailing the stores ejected.

The jettison check is made every 5 seconds (it takes a few seconds to do this in the cockpit), so there is a chance that an aircraft that is caught by surprise will have no time to jettison its stores before the missile impact happens. Also only external stores can be jettisoned (we have no knowledge of internal stores being ejected in combat).

The current implementation has a known issue: Conformal Fuel Tanks (CFTs), like those on the F-15E and numerous export F-16s, are treated like drop tanks and thus jettisoned (in RL they cannot be ejected). We plan to address this in the future.

Mission player feedback: “Why aren’t my strike aircraft taking off!?”

Mission Editor 2.0 introduced in Command v1.07 was a significant step forward in mission planning capabilities. However, many users felt that the built-in flightplan generator wasn’t too forthcoming with the reasons why a mission would refuse to launch. Is the target out of range? Have we run out of aircraft or targets? Is it due to a lack tankers? Something else?

Command v1.11 solves this by giving a lot more feedback. If a strike mission fails to launch it will tell the player the exact reason, and in most cases also give advice on how to solve the problem. So keep an eye on the message log, and you may see something like this:

Tags: no tags

The great leaps of v1.11: Massive refuelling improvements

March 7, 2016 · Posted in Command · Comment

Massive Air-to-Air Refueling (A2AR) improvements

Air-to-air refueling (A2AR) has been given a complete overhaul. There are significant improvements to the AI’s decision making processes and it is a lot smarter about when and where to refuel. Furthermore, the player is given the ability to manually select which tanker(s) to refuel from, and there are additional options in the Mission Editor to control tanker usage. Tankers will also tell the player which receivers are currently queued for refueling, and display the number of aircraft served thus far. Further super-specialized A2AR improvements are planned for integration into the Advanced Strike Planner, such as ‘refuelling waypoints’, but we believe the current tanker functionality will satisfy 99% of Command players’ needs.

Many players have told us the thing they have missed the most is the ability to manually select which tanker their aircraft should refuel from. You now have three choices:

– Automatic, which is the same behavior as earlier, i.e. the AI picks the most suitable tanker based on remaining fuel and shortest rendezvous time.

– Manual, simply click on the tanker you want to refuel from.

– From mission, pick the most suitable tanker from the tankers assigned to the specified support or ferry mission.

(Click on image for full view)

The improved Mission Editor has several new settings for configuring tanker usage. A new window called the ‘Tanker Planner’ allows the player to set the conditions for when tanking should be attempted when the aircraft are in the air, and also set launch conditions for the mission itself. The parameters are as follows:

Use nearest tanker with enough fuel to serve receivers: Airborne receivers assigned to this mission will pick the most suitable tanker based on remaining offloadable fuel and shortest rendezvous time.

Use tankers assigned to specific missions: Limit the tanker pick to those assigned to given missions only. When combined with the new mission Startup and Termination functionality along with the Support Mission ‘One refueling cycle’ and ‘Number of receivers’ limitations (explained below), the player now has the ability to do pretty detailed tanker planning.

Mission planning details – Minimum number of tankers needed: Specify the minimum number of tankers needed to launch this mission. In some cases, especially for larger air strikes, you may need a minimum amount of fuel (2,000,000 lb, hah!) and this setting allows you to postpone strike missions if the tanker requirements cannot be met.

Mission planning details – Minimum number of tankers airborne: Same as above, but specifies the minimum number of tankers that have to be in the air rather than just available.

Mission planning details – Minimum number of tankers on station: This is a further refinement of the above settings and specifies the number of tankers that must be on-station. It only applies to tankers assigned to support missions. Ferry missions are ignored.

Mission planning details – Launch mission without tankers in place (Extremely risky!): The description says it all. In some cases it is desirable to launch a mission without having tankers within tactical radius of the target. Especially in high-threat environments. This setting allows the player to override all built-in safety measures and just launch the strike aircraft regardless of tanker availability at the moment. The aircraft will of course attempt to refuel when airborne, however on the ingress leg they will only attempt to hook up with tankers ahead of them, not behind. Thus it is up to the player or scenario designer to make sure tankers get into position before the receivers run out of fuel and crash. (Dev note: on the return leg, strike aircraft will also look for tankers behind them so the requirements are not so strict there).

Mission execution details – Maximum number of receivers in queue per tanker: In order to prevent one tanker from accepting too many receivers, the player can specify the maximum number of aircraft to send to each tanker.

Mission execution details – Receivers start looking for tankers when down to X percent of mission fuel: By default, strike aircraft will start looking for tankers when down to 85 percent of mission fuel, and aircraft on patrol missions will attempt to refuel when reaching 60 percent. This works well in most cases. However, sometimes it is desirable to delay the search for tankers, and this is a super-nerdy way of doing just that. The setting works for all mission types including Ferry missions. A prettier way to do it is to use the setting below:

Airborne receivers can book tankers within…: When aircraft are down to the fuel percentage specified above, they start looking for tankers. The default is to pick a tanker within the receiver’s tactical range (i.e. strike radius multiplied by two, minus fuel already burned), but the player can also decide that aircraft should only look for tankers within a certain radius.

(Click on image for full view)

It is our experience that most players use Support Missions for tanker stations. In order to improve tanker ops flexibility and realism, Command v1.11 adds user-configurable mission termination time (in addition to mission activation time found in earlier versions of the simulator). This allows the player to minimize the tankers’ exposure to threats by de-activating the mission and force them to go home. In addition, the updated Mission Editor adds the ability to make tankers return to base when they have conducted one refueling cycle, or when a specified number of receivers have been served:

Tankers return to base after one refueling cycle, when queue is empty: Tankers will remain on-station for as long as there are receivers in the tanker’s receiver queue. The tankers will accept refueling requests from additional receivers for as long as there is enough fuel, and once all aircraft in the queue have been served the tankers will return to base. This ensures the tankers will only stay on station for as long as they are needed.

Tankers can refuel maximum X receivers, rounded up to nearest flight: Tankers will serve a limited number of receivers. This is especially useful when each tanker carries limited amount of fuel, e.g. when using buddy refueling or when refueling strategic bombers. The number is rounded upwards to the nearest flight. I.e. if the maximum number is six receivers, the tanker will accept two flights of four receivers each. This option can be used in combination with the above setting to create very flexible mission termination conditions.

(Click on image for full view)