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.

“Refuge in audacity” indeed…

June 14, 2010 · Posted in Copycats, Uncategorized · Comment 

It has come to our attention recently that Herman Hum and his usual assortment of consorts have once more began beating to pulp the dead horse of ID changes in the DB2000 database and how these were supposedly part of a “grand conspiracy” within the ex-Harpoon HQ. Typically their allegations are accompanied by links to discussion forums such as these:

So, a quick recap for the sake of latecomers…

Between 1999/2000 and 2006/7, the DB2000 and the other databases & scenarios hosted at the Harpoon HQ were the premier third-party content for the Harpoon 3 simulation, and formed a key pillar of the franchise’s resurrection from obscurity. No need to repeat the accolades bestowed upon their creators or praise their level of quality any further; referrers such as Sir John “Sandy” Woodward, “Sharkey” Ward or the Australian DoD should suffice.

One of the reasons for the tremendous success of these DBs and their associated scenarios was the constant stream of updates applied to them. As soon as a new piece of information about some technical detail or OOB change was made public, all relevant DBs and scenarios would be promptly updated and re-released through the HHQ site.

Inevitably, this often meant breaking changes. Deleting a radar here, adding a torpedo tube there, swapping MiG-29As for MiG-29Cs, things that can easily lead to DB & scenario mismatches if the DB/scenario author is not careful enough. Yet the HHQ content producers managed to maintain four databases and hundreds of scenarios without any problem, for years.

Because maintaining a scenario through successive DB updates is a tricky and often tedious business, external authors utilizing the HHQ databases in their scenarios were regularly invited to have their creations hosted & maintained by HHQ personnel. This ensured that their scenarios were never left behind and outdated as the HHQ’s accurate, detailed datasets moved forward. Even authors that preferred to host & maintain their scenarios on their own maintained a close cooperational relationship with the HHQ in order to ensure their works remained up-to-date.

When Herman Hum entered the H3 scene in 2003/4, he was using the DB2000 for his scenarios. He was banned from the HHQ forums for very much the same reasons he has been banned from the HarpGamer & MatrixGames forums (UPDATE: Twice) and he chose to maintain his scenarios on his own, trying to catch-up with the DB2000 updates at every turn. At some point he started falling behind, and this was manifested as reported crashes in some of his developmental scenarios.

For which of course(!) he immediately and loudly blamed the DB2000 and the Harpoon HQ.


Neutral third-party observers who did not share Herman’s anti-HHQ zeal were quick to state the patently obvious:

If not for our scenario authors, Harpoon would have died a slow painful death. He has sacrificed a good portion of his waking hours taking the DB2000 from a simple collection of fixes to the ultimate database for Harpoon3. He is not a publisher. He is a private individual who took it upon himself to give more than pretty much anyone else in this community. That is just a character testimonial.
As far as my opinion on DB2000, it is the scenario author and the people who contributed to it. He gives proper credit to the people who contributed. He pretty clearly states that if you use DB2000 without putting the scenarios on HarpoonHQ, you will have problems. Why someone would not want to do that is not something I cannot understand, but its is pretty clear. This is not a software developer making changes. This is someone’s hobby and he can do with it what he likes.


If you have a problem with the database developer, take it up with him personally. As far as I know, the folks working on that database have put in literally thousands of hours to make it a comprehensive and accurate database. A database, by the way, I have never had any problems with. As a completely neutral observer and someone that was ignorant to the fact there was even any internal dissension in the Harpoon community, this whole thread is a not too clever attempt to discredit the database and it’s developers.

(These posts BTW are in the very threads that Herman & co consider as their main argument! Nice job digging your own grave folks….)

Now, the intentions of Herman and his chorus were clear enough. But what about the technical merits of their allegations? It is true that successive versions of the HHQ databases feature various changes in the dataset, including component IDs. However these never posed a problem either for the HHQ crew or for the third-party creators using the DB2000. So what went wrong with Herman’s scenarios?

To answer this, we must go back to 2003/4.

As previously mentioned, keeping hundreds of high-quality scenarios up-to-date as their underlying database constantly evolved was no picnic. To help with the maintenance, a scenario author developed a highly-customized version of the H3 ScenEdit application called the Scenario Batch Rebuilder (SBR). The SBR used custom script files to easily and accurately rebuild scenarios after each DB update, making the process significantly more efficient. With the help of the SBR, the ID-swaps and all other types of DB changes simply did not affect scenarios negatively. The proof of this was manifest in the complete absence of problems in HHQ-hosted scenarios.

This point bears repeating: ID changes were happening in the DB2000 all the time, with no resultant problems at all. Not a single DB2000-based scenario hosted by the HHQ was adversely affected. This fact has never been disputed even by Herman and his supporters.

Herman realized that, when it came to keeping up with the relentless pace of evolution of the DB2000, the SBR made things easier for the HHQ and their friends, and harder for him. Getting his hands on this tool would not be easy, since the SBR had been developed under an exclusive agreement with AGSI; HHQ members were the only ones who could legally use it.

Herman eventually managed to sweettalk/con one of the HHQ crew into giving him an early “beta” version of the SBR. He immediately set out to use it on his scenarios under development. However, it soon became obvious to him that, rather than a push-button magic tool, the SBR was a complex semi-automatic instrument that required intricate knowledge of its internal operation to work properly; this wasn’t a script-kiddie toy. Herman’s scens began to crash spectacularly.

Out of ideas, Herman contacted the HHQ blaming changes in the DB2000 for the problems in his scenarios (not mentioning that he had used the beta-SBR on them). The HHQ crew offered to examine them to find the cause of the problem and determine if there was indeed a problem in the database (after all, no-one is infallible). The few samples sent by Herman all shared one characteristic: They had been tampered with the beta SBR.

(Unknown to Herman, usage of the SBR leaves a permanent “electronic fingerprint” on the scenario file; a specific combination of data that is practically impossible to create under any other circumstance. This was verified independently at the time by AGSI staff. There is simply no doubt Herman did this.)

The HHQ crew confronted Herman privately with this evidence and asked him to stop using the SBR – both because it was illegal and also because it was the cause for his scenario troubles. They also asked for more samples. Herman, not expecting to be caught red-handed using the stolen SBR, refused to provide any more samples and terminated private communications. Shortly afterwards, threads started by Herman and his friends began to pop up all over the wargaming forums, blaming the DB2000 changes for the massive problems in his scenarios.

So let’s do a quick sum-up of the facts:

  • Herman stole a product that he was not permitted to acquire or use.
  • When he failed to use it properly, he blamed of mischief the people that warned him not to use it.
  • When his SBR theft was uncovered, he repeated (ad nauseam…) his “Evil HHQ sabotaged the DB2000!” accusations in public.

All together now…

double facepalm

Of course, in retrospect, Herman & crew’s insistence on these “interesting” allegations makes perfect sense. Consider that shortly after these charges surfaced in public the so-called PlayersDB, a blatant copy of the DB2000, was released by Herman and his friends. By Herman’s point of view, what better way to justify such an obvious IP theft than to claim you are the unfairly persecuted underdog: “We created the PDB because the HHQ people were sabotaging us through changes in the DB2000!” (…the very same changes that nobody else was affected from). We are not making this up, folks.

So, little David fighting against Goliath and all odds? Or a scarcely believable combination of gall, stupidity and indecency? Let anyone with a sane mind be the judge.


UPDATE 1/26/2012: Herman has discovered YouTube (good for him), and has been posting “proof” videos demonstrating how one can crash a scenario by moving from one DB2000 copy to another. This reminds us of some folks driving a Volvo right through a brick wall and then photographing themselves beside the wreckage as “proof” that Volvos are unsafe cars. Amusing? For a while. Credible? Not really.

We are sorry to burst Herman’s bubble but Harpoon users play actual scenarios, not contrived YouTube videos. And for anyone keeping score, the number of scenarios hosted by the HHQ/WS and misbehaving as a result of DB changes is…. wait for it… ZERO.

Well, at least Herman now knows how to use YouTube. That’s got to count for something.

Red Pill screenshots #7 – Bits and pieces

June 14, 2010 · Posted in Command · 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…