Georgian War report: “The Tanks of August”

August 14, 2010 · Posted in Uncategorized · Comment 

The_Tanks_of_August_map_sm The Center for Analysis of Strategies & Technologies, a Moscow-based think tank, has published a comprehensive report on the 2008 conflict in Georgia, aptly named “The Tanks of August”.

According to the report’s description:

The first essay looks into the transformation of the Georgian armed forces under President Mikhail Saakashvili and details Tbilisi’s key preparations for the war.

The second and central essay offers a detailed timeline of the hostilities. It draws on a wide range of sources, from official chronicles and statements to recollections of the eyewitnesses on both sides and Internet reports. The timeline contains detailed descriptions of all the key combat operations and episodes during the war.

The third essay analyses Georgia’s efforts to rebuild its military machine since August 2008, as well as the existing military situation and the balance of power in the region.

The four remaining chapters look into several individual aspects of the Five Day War, including combat losses on both sides, Russian aviation losses, and the post-war deployment of Russian military bases in Abkhazia and South Ossetia, now recognized by Moscow as independent states.

The Annex details in chart form Georgia’s procurement of heavy arms and military equipment in 2000-2008.

The report can be freely downloaded from the CAST website, here.

Tags: ,

Red Pill screenshots #8: Choose your weapons

August 5, 2010 · Posted in The Red Pill · Comment 

Time has flowed since our last update on the development of Red Pill, and things have moved forward on multiple fronts. We are currently integrating an improved ESM model, a brand-new jamming model (hint: no paper rules to conform to), a new sonar model, a new relief map layer, a high-resolution coastline layer, improved guidance for datalinked weapons, much improved weapon endgame calculations including generation-based seeker-vs-countermeasure/decoy comparison and lots more.

For the moment, though, let us look into some of the weaponry management features present.

RP1

In this example, a US destroyer has taken station in the entrance to the Hormuz straights and is preparing to attack the airfield & related facilities at Bandar Abbas. (Click to enlarge)

In addition to enabling a unit to engage targets freely on its own, Red Pill offers a manual weapon assignment window, similar to those found in legacy wargames. We have already mentioned that Red Pill allows the modeling of installations as large complexes of discrete facilities instead of monolithic units, so in this case the player can choose in detail which structures of the airbase to attack, and optimally match available weapons to targets (e.g. Tomahawks with penetrator warheads to the most heavily-armored shelters).

One of the most important improvements in this functionality is the ability to create so-called “Deferred” weapon allocations.

A deferred allocation is one that cannot be executed at the moment (for any number of reasons, for example if the target is currently out of range for that weapon), but will trigger automatically once the launch conditions are met. In this case, we can instruct the US destroyer to attack the facilities at Bandar Abbas either with its Tomahawk missiles or using its main gun. In the former case, the attack can be executed immediately (but not necessarily; see below). In the latter case, the gun rounds assigned for the attack will be fired once the destroyer gets within range of the targets.

Deferred weapon allocations are particularly useful for planning coordinated attacks, as they allow precise per-unit target distribution and weapons assignment: Instead of simply directing an F-16 flight to attack a surface group and hope they do their best (which works too, BTW), you can instruct Falcon #1 to fire two HARMs at the cruiser, Falcon #2 & #3 to engage the two destroyers with Harpoons, and Falcon #4, #5 & #6 to follow-up with LGB attacks on the smalller ships. In legacy wargames, such targeting flexibility was available only to human players and only once the attacking units were within weapons release parameters; Red Pill gives this ability to human and AI-controlled sides equally, and makes it available at any point in the scenario, from the initial strike planning all the way to weapons release.

Deferred allocations also have two other abilities that currently exist in code but are not yet supported by the UI (they will be, at a later point):

  • The ability to specify a Time-On-Target (TOT) value. The “staff AI” will then adjust the launch time of the weapons so that they arrive at the target at the specified TOT.
  • The ability to define a plotted course for the weapons (only for weapons that support waypoints). Combined with the TOT functionality, this enables an extremely comprehensive attack plan that can overcome even highly capable defences.

RP2
This is a shot from “Battle of Dong Hoi”, a scenario based on the like-named confrontation of the Vietnam war. The cruiser Oklahoma City is engaging incoming MiG-17s with her Talos missiles, and we have opened the Weapons window to observe how the crew is reloading the missile launcher. Notice the tick-mark on the “Reload Priority” column, for the RiM-8G weapon. This specifies that we explicitly instruct the crew to give priority to this weapon when reloading.

In legacy air/naval wargames, reloading the desired weapon in a multi-weapon mount/launcher can be a chore. If the AI crew happens to load the weapon you actually want, you are in luck. If they don’t, you have to be constantly on your toes and manually load the desired weapon each and every time the mount is available for reload, swapping out the undesired already-loaded weapon(s) if necessary. This can range from annoying (missiles) to a downright infuriating clickfest (gun rounds, particularly on small/medium calibers). The need for constant manual intervention also means that the AI (friendly and enemy alike), if left on its own, is likely to make some very stupid weapon choices for the given tactical situation.

Red Pill overcomes this serious problem with a two-pronged approach: smarter AI-managed weapons reloading, and explicit reload priority.

The “AI crew” in Red Pill considers carefully which weapon to load on a mount given the tactical situation and the unit’s primary target/threat. It attempts to decide the most suitable weapon for the desired target and loads this weapon if possible. The factors affecting the suitability of weapon for a target are numerous: the target’s type, its physical size vs. the weapon’s accuracy, its armor level (if identified) vs. the weapon’s warhead & fuzing type, its speed and maneuverability, whether it is within launch range for the given weapon etc. As an example, airburst gun rounds and missiles fitted with fragmentation warheads are an excellent weapon against air/missile targets and small, fast surface craft (like pirate dhows, for instance) but a poor choice against armored warships or land facilities.

The explicit reload priority feature is useful in cases where the player (or scenario author, arranging AI-controlled forces) wishes to override the reload decisions of the AI crew and maintain a specific weapon loaded on a mount. This includes unloading non-priority weapons and swapping them with prioritized ones if necessary. Once the preferred weapon is no longer available, the crew will load non-priority weapons on its own as usual. Multiple weapons per mount can be designated for reload priority; in this case the crew attempts to balance their quantities on the mount. In the above example, we could have tick-marked both the RIM-8G and the RIM-8J version of the Talos, and the crew would strive to keep one of each loaded on the rail launcher.

Let us look at a practical example where these features are combined, and their benefit:

RP3
Here we have an Indian Kilo-class submarine and three unknown surface contacts. The Kilo has a mixed torpedo loadout at the moment, two wake-homers (suitable only for surface ships) and four dual-purpose torps. Notice that we have specified one of the dual-purpose torpedoes to have reload priority on the last torpedo tube; this is to ensure that the sub always has a snapshot counter-fire capability if it detects an incoming torpedo or enemy vessel at close range.

Now if we direct the sub to attack any of the three surface ships, the AI crew will swap out the dual-purpose torpedoes (EXCEPT the one we specified as having priority!) and load dedicated anti-surface weapons in their place: Wake-homing torpedoes and SS-N-27 cruise missiles. If the tactical situation changes and an enemy submarine becomes the primary concern, the crew will swap out any anti-surface weapons from the tubes and reload with dual-purpose or ASW-only weapons.

In conclusion, the new weaponry management features in Red Pill lead to both significantly less micromanagement for the human player’s forces (goodbye clickfests), and a much more capable AI-controlled adversary that exploits his weapons to the full.

Tags: no tags

Matrix to release combined ANW/HCE pack

June 18, 2010 · Posted in Harpoon 1 (Classic), Harpoon 3 · 10 Comments 

As announced yesterday at the Matrix forums by Erik Rutins:

Harpoon: Ultimate Edition and Our Philosophy

There has been a great deal of discussion, debate and argument over the past, present and future path of the Harpoon simulations on the computer. Here at AGSI and Matrix, we’ve listened to what has been said. Thought long and hard about the issues raised, and made some decisions regarding Harpoon’s future that will hopefully make all fans of the series happy, both those who have played it in the past and those who still play it. We hope that explaining the philosophy behind our decisions will help clear the air and remove some of the confusion and misinformation that has been part of the complex history of these games. The new "Harpoon: Ultimate Edition" which is due to be released this summer will be the realization of these decisions and this philosophy and we hope that it will serve the existing community well, and continue to attract new naval warfare fans to Harpoon.
We will be releasing a great deal more information on Harpoon: Ultimate Edition over the next month, but here are the highlights. Harpoon: Ultimate Edition will include both a new version of Harpoon 3 Advanced Naval Warfare and a new version of Harpoon: Commander’s Edition. These will be together in one package at a price below the current combined price of both games. In addition, to celebrate the 20th Anniversary of Harpoon and to give fans who still enjoy playing the older versions a great archival edition, we will be including every previous version of Harpoon that we have access to in this package. That means over 20 classic versions of Harpoon, including Harpoon 3 (v3.6.3) and many previous versions of Harpoon Commander’s Edition / Harpoon Classic. This will allow players who have databases or scenarios tied to these older versions to continue to enjoy them for years to come, and it will also allow new players who purchase the Ultimate Edition access to this rich older content. We believe this comprehensive bundle, unlike any that has previously been released for Harpoon on the computer, represents a digital history and "Collector’s Edition" of Harpoon that every Harpoon gamer will want to have on their shelf for years to come.

As far as our philosophy, AGSI’s and Matrix’s position on the Harpoon simulations is simple. They are computer implementations of the Bond/Carlson Harpoon system models (aka the Admiralty Trilogy models). Bond and Carlson also have tabletop miniatures implementations of their models. When Harpoon was first coded in 1987-1989 AGSI tried to follow the 3rd Edition of those rules as faithfully as 8088 CPU’s and 640k of RAM would allow. Many of the missing pieces have been added over the twenty years since then and the Harpoon Commander’s Edition actually includes elements of the 4th edition models.

Harpoon 3 was born of Harpoon II written in 1994-1995 by a previous team of very skilled programmers. However, they didn’t have a lot of former Naval Officers on their team and they didn’t ask Bond or Carlson a whole lot of questions. Since regaining control of the property in 2000, AGSI has been steadily correcting course and bringing the Harpoon 3 product closer and closer to the 4th and now 5th edition of models. We believe that we are uniquely positioned among all naval simulations in this regard by having official access to the Bond/Carlson modeling concepts and experience, which means that we are able to bring you the state of the art in naval warfare simulations at the unclassified level.

There are some people in the Harpoon community who don’t like change; they are content with what they have and they want to hold onto their contributions. That’s their privilege and in fact by releasing the Ultimate Edition, we are making it easier than ever to play the version of Harpoon that you prefer. But, we want to make it clear that we aren’t going to sit still when the state of the art is advancing. Harpoon 3’s primacy is in the modeling and that is only true because it is the Bond/Carlson models. This is why military professionals around the world have used the product for training, education and analysis.

We believe that continuing to improve the fidelity of the simulation and continuing to advance the state of the art for computer Harpoon is the best way to serve our customers. Harpoon on the computer should always look forward and continue to improve along with the latest improvements and updates from the system models, rather than look back. We give credit to Harpoon’s past on the computer, but its future is not in backwards compatibility, but rather in continuing to improve along with the authoritative state of the art models from Bond and Carlson that are simply not available anywhere else.

Given this philosophy, we will still place a high value on feedback, and we always appreciate valid defect reports (aka bugs). However, because of Harpoon’s complex history there are many issues that are specific to older databases or scenarios not of AGSI’s or Matrix’s making that haven’t kept up with the modeling changes. We are responsible for the official databases and scenarios, and for informing the public regarding what changes each update entails. Third party designers are responsible for their own scenarios in this regard. If we have to choose between improving the simulation or maintaining backwards compatibility with third party data and scenarios, we will choose the former. We realize some fans of Harpoon may prefer to stay with older versions for whatever personal reasons, which is part of why we decided with the Ultimate Edition to include as many of the older Harpoon versions as we could fit into a single release. This allows us to meet the needs of both parts of the community – those that want the simulation to advance and those that want compatibility with older databases and scenarios.

It’s also worth noting that in the past, we have heard a great deal from people who have never been to sea, who have never been trained as naval (or air) professionals, have never programmed or created a full database, with strongly worded opinions on how our simulation is supposed to behave. While constructive feedback from our customers is always welcome, we believe that the work by Bond and Carlson should be our guide in terms of how the simulation should work. As many Harpoon fans are aware, this community has seen some very unfortunate events in its history that have given rise to online flame wars, personal attacks and questions of intellectual property; both between community members and in terms of some copyrighted materials. We hope to see the end of this with the steps we are taking for the Ultimate Edition release and for the future of Harpoon. We want to make it clear that we will not accept non-constructive feedback on our official forums in the future. However well intended or misguided, this has caused harm to the game and the community and we will not allow that to continue.

As far as the User Interface goes and overall game functionality – we really do want useful feedback and ideas. We want databases, scenarios, and artwork. Our new encryption feature will help protect an author’s investment in their database work, so that there should be no future concerns about data being stolen or "borrowed". We can also add scenario encryption if need be (ditto for original artwork).

Now as far as defects are concerned, there is a right way and a wrong way to report these. First, due to our limited resources and the seemingly endless permutations of data and game engines once third party databases and scenarios are added to the mix, we will automatically reject any claimed defects on our sites if they are not reproduced in the ANWDB or the HUD3 databases. We will take responsibility for correcting those defects that can be reproduced in one of the two aforementioned databases with the latest official release. We reserve the right to reclassify defects into bugs (something we’ll prioritize for fixing), feature requests (stuff that folks want but the game doesn’t currently have), user knowledge (i.e. user doesn’t understand how the model works) and unsupported functionality (a user who does something with the game or scenario editor that we hadn’t thought of and thus hadn’t tested).

Secondly, to report a defect, we kindly request that you use this template. If you are consistent in the quality of your reporting we will set you up with direct access to our web based bug tracker "Mantis".
1. Database name and version
2. Scenario name
3. Screen shot(s)
4. Expected behavior
5. Witnessed behavior
6. Desired behavior
7. Notes
8. Any saved games, scenario files, and logs zipped up and emailed to us can only help.

Generally speaking, the operating system or computer configuration has nothing to do with how the simulation runs, so these are not crucial details for our purposes.

Allow us to explain how this works. First, we have very limited resources due to the very small audience of bright people who really understand modern air/naval warfare and buy a Harpoon product every few years. As a consequence, our underpaid programmer(s) really don’t enjoy hunting through 15-year-old C++ code originally written by a previous development team on a death march without a clear report to guide them. They would rather be adding new features and functionality. So, the clearer the report, the easier it is to reproduce the defect, the more likely it is that it will be found and fixed. At the end of the day we only have so much time.

This also goes for our forums. As we explained above, we will no longer be accepting lists of bugs related to third party unofficial databases or scenarios. If you find an issue, please duplicate it with an official database and scenario before reporting it and please report it as noted above. Otherwise, you’ll have to seek out the owner of that third party product for assistance.

We want to provide the best possible simulation given the resource limitations. If you want to help, work with us, not against us. We have a long history of volunteers making a positive difference, politely and professionally. Our volunteers have received written credit, some swag, bragging rights, and a few even made some beer money for their efforts. We need scenario authors, database editors/authors, artists, testers and maybe some day, investors. Part of our philosophy and the policy stated above is to give credit to, and work with the members of our community who have put in their time to support Harpoon and who are willing to work with us as we continue to improve.
Thank you for reading this long post and we hope that you at least understand the basis for our decisions. And for those who agree that we are on the right track, there is still plenty of work to do. We believe the new features and content in the upcoming Harpoon: Ultimate Edition, which we will be providing much more detail on in the next few weeks, will open up new avenues in your air/naval simulation experience.

Tags: no tags

Red Pill screenshots #7 – Bits and pieces

June 14, 2010 · Posted in The Red Pill · Comment 

 

The summer season is well in effect, and it’s time for some new Red Pill screenshots, showcasing different features & functionality offered by the new air/naval wargame. (Click each for full size)

Untitled1 Untitled2 We have been working lately to incorporate a higher-resolution vector layer for coastlines and borders. This should match the detailed data already offered by our raster layers and allow us significant near-coast refinement for littoral operations such as amphibious landings, mine warfare, piracy & policing operations etc. This is a side-by-side comparison of our current vector set and the proposed new one, using the Hormuz straits as reference.

Untitled3  Adding units to a scenario in legacy air/nav wargames can often be a tedious process because of the time needed to find a specific unit class and the limited copy/move functionality. The “Add Unit” dialog in Red Pill offers a keyword-based filter that allows easy, fast location of the desired unit class. Copying or moving an existing unit is also a single keystroke away.

Untitled4 This is another huge time-saver for scenario authors. You can import and present geo-referenced images (e.g. from Google Earth as in this case) directly into the game map and use them both for unit construction and normal gameplay alike. In this case we have imported an overhead image of the Natanz nuclear complex and we are using it to construct a highly-authentic representation of the facilities in the area (notice the “Nuclear Power Station” structure already placed). The same method can be used for constructing airbases, port complexes, SAM sites – any multi-unit installation that requires high precision on the placement of its components in order to model faithfully. Once in place, any such installation can be exported to a file and re-used in any other scenario.

Untitled5 This is an example of installation import. Each record can include supplementary information such as creator comments or time-range of validity so that the scenario author can decide whether to use it or not. The installation components are also listed in detail.

In this case we have selected 2 airports for import. An installation creator can choose to either store one installation per record (e.g. an airbase) or alternatively include all instances of an installation type in a single record (e.g a country’s entire air-defence network). This allows great flexibility in creating, storing and sharing installations for use in scenarios.

Untitled6Bushehr airbase in detail. Group-view is selected for the map display, hence the airbase objects appear “ghosted”. The unit-status window has a “Group composition” option that presents a summary of the unit types comprising the base (this is also handy for quickly checking e.g. the ship types & numbers in a CVBG or convoy).

The “Air Facilities” portion of the Air Ops window presents the state of air operations in the base in a facility-centric manner. We can examine in detail which aircraft is placed where and what is present status is. We see that an F-4E is using a runway access point (typically a taxiway) to proceed towards one of the runways and take off. Access points such as taxiways (and elevators in aviation ships) are by far the weakest link, and their damage/destruction is the most cost-effective way of disrupting, or even grinding to a halt, ongoing air operations. We will probably need to devote a future article exclusively to this aspect of air ops.

Untitled7 An Australian Adelaide-class (modernized Perry) frigate is facing off two hostile aircraft with her SM-2 missiles. The sensors window is open, displaying the frigate’s sensor status. The dotted red line is the SARH illumination for the SM-2 missiles provided by the frigate’s STIR radar. Notice that only the STIR and the SPS-49 search radar are currently active.

A frequent answer to the common question “Why is my [ship/aircraft/SAM site/etc] not shooting at [some target]?” is that all engagement/illumination channels are currently in use. In legacy air/nav games this is difficult to demonstrate and visualize. Red Pill makes this easier by clearly displaying which sensors are active and which targets are being illuminated for engagement. In this case, the only available SARH illuminator (the STIR radar) is being used to engage the first aircraft, so the second one cannot yet be engaged.

Untitled8A player favorite: buddy-lasing. The AV-8B Harrier on the bottom of the map has launched two AGM-65E laser-guided Maverick missiles and sharply turned southbound to avoid the target’s terminal defences. A nearby orbiting F-117A takes up the responsibility of providing laser illumination (notice the red line) for the terminal homing phase of the missiles. This is done without any manual user intervention. Scratch one C3 bunker!

More to follow soon…

Tags: no tags

Armored Brigade – New versions out

May 27, 2010 · Posted in Armored Brigade · Comment 

t-72_tank Two new versions out this awesome tactical land combat game have been released back-to-back:

==Version 0.682==
- Unit movement is smoother. When a unit is ordered to
stop, it stops right away.
- When "Defence" in the Battle Generator is
"Dug-in+Fortified", the scenario attacker receives less
purchase points than before.
- Artillery and mortar shells are less likely to cause terrain fires
- New tree graphics (Thanks to Käki)

==Version 0.680== * Fixed: Anti-air and indirect fire muzzle flashes could not be detected * Fixed: The distance between muzzle flashes and the observer was calculated incorrectly * Fixed: Some muzzle flash graphics were missing * Fixed: The pre-game menus use now non-transparent buttons and logo, this should fix the graphics issues on some graphic cards. - The AI opponent can use mortars to fire illumination at night - Casualties have a much higher effect on the victory points. This way the battles should be less "fight till death" type, because high casualties end the battle earlier - Command delays are halved when using formations (Including for mortar fire mission, nearby HQ units reduce the mortar adjust delay as before) - Maps have small patches of water and more streams/rivers - Urban areas have less buildings, so vehicles and the AI should not get stuck that often - If the scenario defender loses an objective, and then reoccupies it, he will receive only half of the victory points from that objective, and the attacker receives the other half (The objective turns orange) - Aircraft treat all ground targets as "unknown", and thus won't always attack the most valuable detected enemy unit - If an artillery target is out of the normal TRP radius, but closer than 2x the normal radius, the delay is slightly shorter. In previous version the same effect could be achieved by setting the fire mission within a TRP radius, and then adjusting it further away from the TRP - Rescaled all MT-LB images and the PT-76 turret images. Modified the water and jungle tree graphics.

Get the new versions here.

Tags: no tags

Next Page »