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

March 14, 2016 · Posted in Command

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