Matrix Games Forums

Hello Everyone

I just wanted to say and I am sorry for the delay in getting the forum open yesterday. As everyone knows its E3 week and it keeps some of us pretty jumping. We will be releasing more information very shortly on the changes you will see in HP3ANW version. This version of HP3ANW will not have any major GUI changes but will add a great new muliplayer feature. As many of you already know will also be releasing a version Harpoon Classic 2005 which we have titled Harpoon Commander's Edition. I have personally enjoyed working with Don Gilman on this project and he has a deep passion for the Harpoon series and its community and fans of the series. Don has some exciting plans and we look forward to working with him.

Matrix is also working on expand its support of the Harpoon community through our forums and making arangements for use of a scenario depot and an opponent registry. I would also like to hear any ideas the community may have in how we can better support the Harpoon community.


David

ORIGINAL: David Heath

Matrix is also working on expand its support of the Harpoon community through our forums and making arrangements for use of a scenario depot and an opponent registry. I would also like to hear any ideas the community may have in how we can better support the Harpoon community.

Can you elaborate a bit more on what your current thinking is on the Scenario Depot?

There are already a number of sites like:

Files of ScenShare

StrategyZoneOnline Archives

whereby members can post and share their own scenario files. Do you envision the Scenario depot to be controlled by members? Or do you plan to have scenarios submitted to a Matrix administrator for publication as happens on other sites like:

HarpGamer

PlayersDB Scenario Depot

[Deleted by Admins]

ORIGINAL: hermanhum

ORIGINAL: David Heath

Matrix is also working on expand its support of the Harpoon community through our forums and making arrangements for use of a scenario depot and an opponent registry. I would also like to hear any ideas the community may have in how we can better support the Harpoon community.

Can you elaborate a bit more on what your current thinking is on the Scenario Depot?

There are already a number of sites like:

StrategyZoneOnline Archives

whereby members can post and share their own scenario files. Do you envision the Scenario depot to be controlled by members?

Sorry, I guess I should have stated my preference. If possible, I would like to see something similar to the file archives supported by StrategyZoneOnline Archives

StrategyZoneOnline was originally WarfareHQ and both sites had a file archive. They were both very well done and, IMO, had their advantages and weaknesses.

Advantages of both WHQ and SZO:

1) Member control - Any member in good standing could post files
2) Download counters for every file
3) Ability to host images
4) Files can be rated by users




Specific advantage of StrategyZoneOnline Archives:

1) After-Action Reports [AARs] can be appended directly to a scenario
2) Images posted to this area are stored on an SZO server. No need to rely on third-party servers like ImageShack.
3) Larger file size allowed

[center]Disadvantages:[/center]
1) A series of related scenarios cannot be grouped together within a folder





Specific advantage of WarfareHQ:

1) Membership not required to download files
2) Ability to organize groups of files [colloquially known as battlesets]

[center]Disadvantages:[/center]
1) Smaller file limitation
2) Inability to post a message / AAR / Comment to be directly associated with a particular file due to the "thread" nature of the archive




Potential common problems:

1) Lack of file index [unless created by a member] - difficult to scan all files quickly
2) Potential abuse of rating system
3) Potential abuse by spammers


Final note:

I think that the ANW system is going to be very memory intensive. Currently, AFAIK, scenarios must always be matched with the exact same database that they were created with. Otherwise, they just won't run [CheckSum system?].

This has the potential to mean that there will be one database for each and every scenario posted. Scenario files are commonly 200kb - 300kb in size with the various databases about 600mB - 1mB in size. That's a lot of space devoted to database storage that is often unused. Seems wasteful, to me, but there doesn't appear to be any way around it.

[Deleted by Admins]

ORIGINAL: VCDH

ORIGINAL: hermanhum
I think that the ANW system is going to be very memory intensive. Currently, AFAIK, scenarios must always be matched with the exact same database that they were created with. Otherwise, they just won't run [CheckSum system?].

No and yes.

Compared to modern computer systems, H3 will run fine. While we haven't done extensive benchmark testing (this isn't Quake or Half-Life, and it will never be) there is a speed difference 3.6.3 (the current standard) and v3.7 (ANW). However I have an Athlon 2400 that runs H3 just fine. Game speed will be directly related to the number of platforms that a scenario has. There are a few other factors to take into account but the number of platforms is by far and away the most important factor.

Allow me to first clarify. Yes, the my statement on memory intensiveness is mis-leading. It was meant as commentary to the Scenario Archive being discussed. In order to avoid "Database Mis-Match" errors, it may be necessary to save one copy of a database to each scenario created. This happens when you build a scenario with one database and then try to run it with a different (even if only slightly changed) database. The error message is:

**** ERROR ****
WARNING! Scenario database signature does not match current database! Aborting load

Now, in response to the memory intensiveness of actually playing ANW, the statement is, once again, accurate. I was going to raise the issue in the AGSI Mantis system, but since it has already been broached, here, I hope that this forum will be suitable for discussion, too.

From my PERSONAL experience in running the exact same scenario in H3 3.6.3 and then re-running it in ANW 3.7, I have found, in my estimation, the game to run at 65% - 80% of the 3.6.3 speed. AGSI has posted in some areas that 3.7 will run at about 90% the speed of 3.6.3. I did not put on my lab coat and start a stop watch. This is purely subjective by me. However, others have noted the same sluggishness.

I know that I have only been testing Beta releases of ANW, so it is totally possible that the final product release will result in a higher speed for the game since some de-bug features will be de-activated at that point.

ORIGINAL: VCDH

ORIGINAL: hermanhum
This has the potential to mean that there will be one database for each and every scenario posted. Scenario files are commonly 200kb - 300kb in size with the various databases about 600mB - 1mB in size. That's a lot of space devoted to database storage that is often unused. Seems wasteful, to me, but there doesn't appear to be any way around it.

This is incorrect.

ANW will use what I refer to as a DB signature system. This was originally developed to prevent a scenario from using a) the wrong DB and b) the wrong version of the correct DB. Back in the day, the biggest problem facing large volume scenario designers was the lack of a dedicated utility to update scenarios to newer DB version. Several years ago, an individual created such a utility. This was later incorporated into ANW to allow users to quickly and conveniently update scenarios. To maintain this standard we included a notification in the code to tell the user of a version conflict between the DB and the scenario.

In the past, before the notification, the user would experiance funny platform preformance in scenarios. In some cases this would lead to a crash of the program because the scenario didn't have the correct information due to the differences in information.

While this does make the scenario unplayable, the solution is have the scenario author update his or her (who am I kidding....his) works using the included utility. Using this utility will only take a few seconds for each scen. In fact, even the user can accomplish this, although personally I am reluctant to do so, mainly because it's not my scenario.

With the exception of the H4DB (which is basically a modified ODB) AGSI will NOT be shipping any of the community made DBs with the game. We will be providing links to download sites and to provide greater awareness of them, but aside from that we are not getting involved. It is the responsibility of the scenario designer to make sure that his scenarios are up to date with his DB.

Herman, If you are unsure about something, perhaps it would be best if you checked with one of us prior to making a post. We appreicate your diligent efforts in informing people about the game and it's ok if you don't know something. If you don't know, ask us....that's what we're here for. Nobody is ever going to fault you for that. I'll answer any questions you have (within limits, pls don't ask me about Pro work for obvious reasons), and it'll increase everyones understanding of how the game is going to work and make the best use of our time.

You are missing the forest for the trees and burying the uninitiated with minutiae. Don't expect everyone to have an iron grasp of the game. I'd bet that many of the visitors on Matrix are coming for information and deciding on whether or not to purchase the game. Your explanation of what you expect the ANW batch re-build function sounds about right.

However, let's just take the simplest of examples, okay?

A) Newbie#1 [N1] buys ANW and tries to make a scenario for himself.
B) He uses one a third-party database (not the official DB that comes with the game)
C) He posts the scenario to the Matrix File Archive.

Now, whenever this third-party database is updated in slightest way, unless the site has an archive and keeps old copies on hand, N1 must:

1) re-load his scenario
2) update it to make it compatible with the currently posted version (either with the re-builder function or do it manually)
3) re-save it to the Matrix archive


Some sites have been known to update their databases several times every month. (some did it every few hours) Imagine N1 being forced to re-build his scenario over, and over, again. Even if the Re-build functions work perfectly as described, the mere fact that he has to constantly maintain his scenario is the crux of the matter. Anyone want this hassle?

Your solution: have your own database, right? [:)] Wrong [:(]

Even if he has his OWN PERSONAL database, it is not a solution. As he adds / modifies his own database, he is STILL required to update his pre-existing scenarios. Otherwise, they won't run with his latest edited version of his own database. So, in order for someone to enjoy his work, the author is going to need to save both the scenario and the database he used to create it at the same place in order to save himself all the work of constantly updating his work. That's just an immutable fact under the current ANW setup.

If you are in charge of writing the manual, you'd better get your facts straight before selling them to the public.

Mr. Heath,

This thread has been hi-jacked.

Your original intent to discuss suggestions on how Matrix can support the Harpoon community has now devolved into a discussion of how the game works.

Is there a Mod in the house that can separate this thread into two? Both ideas are worthy of discussion, but, taken together, they can be confusing.

ORIGINAL: hermanhum

Mr. Heath,

This thread has been hi-jacked.

Your original intent to discuss suggestions on how Matrix can support the Harpoon community has now devolved into a discussion of how the game works.

Is there a Mod in the house that can separate this thread into two? Both ideas are worthy of discussion, but, taken together, they can be confusing.

Please its David..... I do not mind the gamers discussing what they want. But if any as any ideas on how we can help the community please feel free to post it as well. Everyone else feel free to open a new thread if you like to really dive in the discussion on how the game works.

David

[Deleted by Admins]

ORIGINAL: VCDH

ORIGINAL: hermanhum
I have found, in my estimation, the game to run at 65% - 80% of the 3.6.3 speed. AGSI has posted in some areas that 3.7 will run at about 90% the speed of 3.6.3.

That being said, there was a bug in a previous version of the beta (early last year IIRC) that resulted in much slower progress but after bringing it up to the coders, they devised a fix for it. We certainly don't expect 3.6.3 to run at the same speed, especially with that much more code activated

Sorry, the Beta version where we observed this 'molasses-like' behaviour was with B143 or the current B144. That was well past the date you have mentioned, here.

ORIGINAL: VCDH

ORIGINAL: hermanhum

You are missing the forest for the trees and burying the uninitiated with minutiae.

Some sites have been known to update their databases several times every month. (some did it every few hours) Imagine N1 being forced to re-build his scenario over, and over, again. Even if the Re-build functions work perfectly as described, the mere fact that he has to constantly maintain his scenario is the crux of the matter. Anyone want this hassle?

ORIGINAL: hermanhum
Even if he has his OWN PERSONAL database, it is not a solution. As he adds / modifies his own database, he is STILL required to update his pre-existing scenarios. Otherwise, they won't run with his latest edited version of his own database. So, in order for someone to enjoy his work, the author is going to need to save both the scenario and the database he used to create it at the same place in order to save himself all the work of constantly updating his work. That's just an immutable fact under the current ANW setup.

Creating scenarios and databases is an investment in time and energy that that few people are able to committ to. Whether it's because they don't want to commit to that level (i.e. just want to have fun) or of real life considerations, or whatever. Speaking for myself, I enjoy fiddling with my DB and I actually feel kinda flattered when people use it.

However, to answer your question, all it takes to update a scenario is to load it in the scenario editor using the correct DB....and save it again. [Emphasis added by HH] This will generate the signature in the .scn file and allow you to play it no matter what the DB version. << snip >>

Scenario writing is a daunting task.

[/quote]

This is your opinion and your view of how scenarios are or should be made. Not everyone shares that same view. Players should not be scared into believing that if they do not commit their lives to a game that they are unable to design or create scenarios. Anyone want to test out the capability of SSK Scorpene vs. DDG Arleigh Burke? Just do it! It doesn't take a rocket scientist to set it up. [;)]

However, thank you for confirming what I have been trying to say all along! [I have added the emphasis to your words.]

Every scen needs to be constantly updated by:

1) opening it
2) re-saving it
3) re-posting it

Doesn't this sound awkward and onerous to anyone out there?

Now, back to the original theme of this thread: Matrix Scenario archive

The only way to avoid constantly re-loading, re-saving, and re-posting any scenario is to save the database and the scenario at the same time. This will eat up a lot of storage space and should be a consideration for Matrix plans.

You think that this is criticism. This is simply a statement of fact. The game will be published however AGSI and Matrix see fit. It is only fair to tell potential players what they might be getting before they drop their hard-earned money.

If I knew that I would have to eventually:

1) manage a forum,
2) set up a separate web site, and
3) develop and maintain the PlayersDb in order to enjoy this game,

I would have thought long and hard before ever purchasing it in the first place.

Regarding the "plans" (and the community too), I would suggest the creation of a sub-forum for "bug reports and tech assistance" like the one already running for War in the Pacific (tt.asp?forumid=128). I found that one *very* useful while playing WitP.

ORIGINAL: hermanhum
Sorry, the Beta version where we observed this 'molasses-like' behaviour was with B143 or the current B144. That was well past the date you have mentioned, here.

I have experienced no apparent slowdown on my computer. I even played some mid-sized MP scenarios on my puny 233MHz laptop.

ORIGINAL: hermanhum
This is your opinion and your view of how scenarios are or should be made. Not everyone shares that same view. Players should not be scared into believing that if they do not commit their lives to a game that they are unable to design or create scenarios. Anyone want to test out the capability of SSK Scorpene vs. DDG Arleigh Burke? Just do it! It doesn't take a rocket scientist to set it up. [;)]

However, thank you for confirming what I have been trying to say all along! [I have added the emphasis to your words.]

Every scen needs to be constantly updated by:

1) opening it
2) re-saving it
3) re-posting it

Doesn't this sound awkward and onerous to anyone out there?

Mismatching databases and scenarios have always been one of the prime sources of all kinds of weird issues and problems people experience with Harpoon 3. Because of this scenario writers and database authors have always gone through great lengths to ensure that scenarios posted to the various sites include information about the exact database they are to be used with.

Because of all these problems, a way to detect mismatches between the database and scenarios has long been very high on the "wanted list" of the community and so a signature system was implemented in ANW.

In order to offset any additional maintenancework, the improved ANW scenario editor gives the scenario writers and database authors all the tools they need to easily maintain even a large number of scenarios and keep the scenarios current with the latest database version. Casual players that want to experiment with creating their own scenarios will only be affected when they update the database in which case they can also use the scenario editor to quickly bring all their scenarios up to speed.

We feel that the benefits of eliminating errors caused by DB/Scenario mismatches far outweigh the additional maintenance (which most Scenario sites have been doing for a long time anyways) especially with the new batch rebuilder included in the scenario editor.

Cheers,
JP

ORIGINAL: jpkoester1

ORIGINAL: hermanhum
However, thank you for confirming what I have been trying to say all along! [I have added the emphasis to your words.]

Every scen needs to be constantly updated by:

1) opening it
2) re-saving it
3) re-posting it

Doesn't this sound awkward and onerous to anyone out there?

Mismatching databases and scenarios have always been one of the prime sources of all kinds of weird issues and problems people experience with Harpoon 3. Because of this scenario writers and database authors have always gone through great lengths to ensure that scenarios posted to the various sites include information about the exact database they are to be used with.

Because of all these problems, a way to detect mismatches between the database and scenarios has long been very high on the "wanted list" of the community and so a signature system was implemented in ANW.

In order to offset any additional maintenance work, the improved ANW scenario editor gives the scenario writers and database authors all the tools they need to easily maintain even a large number of scenarios and keep the scenarios current with the latest database version. Casual players that want to experiment with creating their own scenarios will only be affected when they update the database in which case they can also use the scenario editor to quickly bring all their scenarios up to speed.

We feel that the benefits of eliminating errors caused by DB/Scenario mismatches far outweigh the additional maintenance (which most Scenario sites have been doing for a long time anyways) especially with the new batch rebuilder included in the scenario editor.

The Mis-Match problems have been extensive and AGSI has taken steps towards rectifying the situation. Absolutely.

However, I don't think that the measures taken actually solve the problems. Some are alleviated, but the solutions also create a myriad of additional concerns as aforementioned.

For example, when you say,

Casual players that want to experiment with creating their own scenarios will only be affected when they update the database in which case they can also use the scenario editor to quickly bring all their scenarios up to speed.

This can be quite discouraging to new designers trying to enter the field. Who wants the hassle of getting into scenario design if you are going to have to constantly maintain them?

Of course, they could go through the effort, post it, and share with a few friends before abandoning it as the database it relies upon changes. This is a loss for the entire community.

Should interest in scenario designing require the participant to commit himself for life to a game?
Or, do new designers require control of their own database in order to maintain some semblance of order?

The ANW ScenEdit does appear to be much more forgiving on some mis-match errors. That's good! [:)] At least it doesn't crash outright. However, the manner in which they are handled may be less than ideal.

Signature solution:

The 'signature' solution whereby every scenario is matched with its originating database is one of these bittersweet examples.

Instead of having a signature arbitrarily generated for every database, why not have it generated according to the NAME of the database, instead?

Let's take the PlayersDB 5.9.7, for example. So long as the Db author chooses to save a new version using the old name, he is, essentially, already guaranteeing that any changes that he may have made are either cosmetic or inconsequential. (i.e. spelling errors) When there is something that might be considered a major change, he could release a new version number i.e. PlayersDB 6.4.9

Since all of the major DB designers appear to use similar naming/numbering schemes, could this work? i.e. ADB v1.0.0, ColonialDBv1.8, DB2000v6.5.31 They all sport new version numbers when significant changes appear. I don't think that this will solve all of the problems. It is a half-measure, but it might save some folks from the hassle of changing their scenarios on a weekly basis. I believe that there are better solutions, but it appears as though AGSI has already chosen to implement this feature in this manner.

Also, instead of showing the following error message and aborting, could this be made into an optional window? i.e. "Do you wish to continue?" The act of catching the mis-match is definitely a step in the right direction. [:)]

**** ERROR ****
WARNING! Scenario database signature does not match current database! Aborting load

How about trying:

**** ERROR ****
WARNING! Scenario database signature does not match current database!
Previous signature: PlayersDB-v5.9.7
Current DB loaded: PlayersDB-v6.4.9
Do you wish to continue loading?

Batch Re-builder and Weapon Edit function:

There don't appear to be any instructions on how to use these new functions so they are difficult to evaluate. Are there any sample files or instructions available anywhere for testing?



[center]Two fundamental Re-Build Problems:[/center]

Take this example.

SCEN is built with DATABASE0.
SCEN consists of one AIRCRAFT from DATABASE0 on a base.
This AIRCRAFT has a choice of loadouts from DATABASE0.
The loadout selection is: AIM-120, AIM-9M.
SCEN has the aircraft loaded with AIM-120.

Okay, that is the starting situation. Now, here is the change:

DB author decides that AIRCRAFT never carried the AIM-120 and thus removes it from the loadout selection for AIRCRAFT. The revised database is saved as DATABASE1.

How will this affect SCEN?

Under 3.6.3, when SCEN is opened in the ScenEditor with DATABASE1, the designer will have no idea that this change has occurred. There is a painful and awkward process to see that this change has occurred, but it is not easy to use.

Under the ANW ScenEdit, it is easier to identify the change, but not by much. The designer still needs to go through and manually identify it and then take corrective action. But, an improvement is still positive even if it is relatively minor. [:)]

From my rudimentary tests with the Batch Re-build function in the ANW SE, I could see no other way that this very common and very basic problem is dealt with. Am I missing something?




Take this second example.

SCEN is built with DATABASE0.
SCEN consists of one FACILITY from DATABASE0.
This FACILITY has identification number 1000 in DATABASE0.

Okay, that is the starting situation. Now, here is the change:

DB author decides to delete FACILITY #1000 from DATABASE0. The revised database is saved as DATABASE1.

How will this affect SCEN?

Under 3.6.3, when SCEN is opened in the ScenEditor with DATABASE1, it will crash if the designer tries to re-save the file.

Under 3.6.3, when SCEN is started with the Game Engine and DATABASE1, it may or may not crash, outright.

Note: If FACILITY #1000 had been AIRCRAFT #1000, instead, many other weird and wonderful problems would have been apparent in 3.6.3

With the ANW ScenEdit, the fact that the scenario doesn't crash outright is cause for celebration! However, as with the previous example, I could see no way to readily identify this shortcoming within ScenEdit. What happens is that the facility appears to run in the game as an 'empty box' / black hole [colloquially known as a "Void Unit"].

Overall, there are definite improvements in the impending ANW release. Even if one fellow describes it as "three steps forward and two back", it is still an improvement and worthy of recognition.

ORIGINAL: Vincenzo Beretta

Regarding the "plans" (and the community too), I would suggest the creation of a sub-forum for "bug reports and tech assistance" like the one already running for War in the Pacific (tt.asp?forumid=128). I found that one *very* useful while playing WitP.

This will be done once the game is released.

David

I hope you guys come up with a solution to the 3rd party scenarios that is transparent and simple to use for new users.

Like a lot of guys over in the "Introductions" thread, I cut my teeth on the Amiga version of Classic Harpoon. Played it to death actually. Unfortunately, technology marches on and I had to upgrade to an IBM PC so I picked up a 2nd hand copy of Harpoon 2 (way... past it's release date) which I still have installed on the machine I am typing this on.

Playwise, it was a huge improvement on the original but I could never get into the supplied scenarios (one Korean and a few South American skirmishes). I tried to downloading a few interesting looking scenarios and databases but to this day I have never gotten any of them to work. (I had just started night school and really didn't have the time to do much mucking around).

Your explanations above have been very enlightening as to what was going on but I feel that this remains an issue if you want to attract and retain new devotees.

What ever you end up doing, please make it simple for the casual downloader to load and run additional scenarios. Longevity of the game depends on it as well you know.

You are EXACTLY the kind of person who should be involved in these discussions!

Please continue to point out whenever you feel the discussion getting too complex and ask lots of questions. I've tried to keep the explanations as basic and simplistic as possible in order not to confuse those not already familiar with the Harpoon 3 system.

From my perspective, I am asking to keep it as easy as possible for fellows like yourself.

Please stay involved and keep us on our toes. If you don't understand something, there's probably going to be 20-30 others in the same boat. Don't let us take anything or anyone for granted.

ORIGINAL: Reg

Like a lot of guys over in the "Introductions" thread, I cut my teeth on the Amiga version of Classic Harpoon. Played it to death actually. Unfortunately, technology marches on and I had to upgrade to an IBM PC so I picked up a 2nd hand copy of Harpoon 2 (way... past it's release date) which I still have installed on the machine I am typing this on.

Forgot to mention:

I know that this is the Harpoon3: ANW section, however, for you guys who have played Harpoon Classic before and are anxiously awaiting the release of ANW, you can pass the time with the demo version of Harpoon Classic Gold available from AGSI. It's free and has about 25 scenarios that you can play. This is by no means an attempt to compare the games or to get anyone to choose one over the other. I own both and enjoy both, equally.

Never really had a huge problem with managing scenarios in two years of testing. It really is an easy process.

1. Make your db changes.
2. Save your db
3. Batch rebuild all of your scenarios so they match the database.

Now the nice thing is when you load a scenario the game will make sure you have a match. Anyways hope this helps[:D]

ORIGINAL: mikmyk

Never really had a huge problem with managing scenarios in two years of testing. It really is an easy process.

1. Make your db changes.
2. Save your db
3. Batch rebuild all of your scenarios so they match the database.

Sorry, but that is way oversimplified.

Like saying, "a marathon is easy because all you do is put one foot in front of the other."

Allow me to add a few steps to your process:

4) Hunt down the effects the revised Db has on your file. Changes to things like weapon ranges, etc play a major effect on your scen. Also, some weapons / ships / etc, may have been totally deleted.

5) Make substitutions for any / all effects incurred. This can sometimes lead to hundreds of changes within one scenario file.

6) Check your aircraft as some of them may now be unarmed due to changes made. Re-arm as necessary.

7) Now check missions and orders for the effect your db changes have on them

8) Check ViConds for any effects on them

9) Check scenario balance

10) Ensure that weapons are available due to all the changes

11) Check timing. A plane might move faster in the new database. The new characteristic may throw off Time-over-Target strikes

12) Re-post scenario to your favourite archive.

13) Repeat steps 4 through 11 for every scenario you wrote.

I know that I missed some steps, but I think I got the most important ones.