A Mine Sweeping question

[aotino]

I have a scenario I have developed that depends heavily upon mine-sweeping. After testing a small mine sweeping test scenario to practice the finer points of mine sweeping, I'm about ready to toss the main scenario out. Here are my issues. I've added 5 basic western Minesweepers in the test scenario. Before each are three basic mines - 1000lb Sea, Contact and Seabed mines. Bearing in mind that I don't want to get closer that 1nm, I begin my run with each. What ends up happening is that I launch any type of Mine Clearance weapon (Mechanical, PAP 104, EOD Team, RVP Sea Eagle, etc), and send them on their way. They all seem to travel at 1nm which in itself takes forever, but when I go into the weapons reload and magazines in the host ship, it shows that they are reloaded, but you are unable to relaunch another weapon. It ll seems like n exhaustive, time-consuming effort which would take too long within a reasonable amount of play time. Am I missing something here? I would attach is the test scenario but it won't take a .scn file extension. I'd appreciate someone telling me what I'm missing. Thanks, Alan

[Herman Hum]

Minesweeping in Harpoon is very poorly handled. The mine weapons originally put in the game do not work so work-around solutions were implemented. They are far from perfect and are simply making the best of a bad situation.

Firstly, the mines in the PlayersDB and CasoDB were simulated as 'immobile miniature-subs'. They were not intended to be equivalent to 1 sub = 1 mine because the lethal radius of the sub/mine was 1nm. Therefore, they were meant to simulate a small area with mines. The mine-sweeping tools were intentionally made to run slowly and have long re-load times to simulate the amount of time necessary to cleanse an area. Otherwise, a player can move along at very high speed and sweep quickly. The "firing rate" and re-load times for the mine-sweeping launchers is currently set for about 60mins. Even though the game may show that they are re-loaded, they require the full 64 mins or so before you are allowed to re-engage. This was my rough estimate on how long it would take to clear a 3.14nm area represented by the mine/sub.

If you do not agree with my assumptions and estimates, you can always modify the CasoDB with faster firing times and re-load rates. The engine on the sweep gear was set for 1kt speed to simulate the 1 hr it would take from firing to reach the weapon. This is all an awkward work-around simulation, but it is the best we have for Harpoon. Mine-sweeping is supposed to be a long arduous process and this was the thinking behind the arrangement.

Files can be added to this forum by first placing the *.SCN file within a *.ZIP file.

[aotino]

Hmmmm, well I certainly can't fault your logic and your solutions for the work around are very sound in recreating the best real world environment. I just have to decide whether it's worth changing my dB to make mine sweeping something a player can actually do in an enjoyable period of game play time, rather than suffering real time as it stands now. Thanks for the input Herman. I'll have to ponder this a bit. Here's acouple of questions dealing with the editor (since you brought it up.) When you say re-load times, is that what's called the ROF in the editor? I noticed that the mine sweeping equipment have ROF's of -60 in the magazines. Does that mean it takes the 60 minutes you talked about to reload? What does the ROF signify in the mounts? They're set to -128. Finally, where is the place where speed is determined for the weapons? I have no mines in any of my finished scenarios now, so would it affect the way they play now if I amended that one thing as you suggested in the dB?

Minesweeping in Harpoon is very poorly handled. The mine weapons originally put in the game do not work so work-around solutions were implemented. They are far from perfect and are simply making the best of a bad situation.

Firstly, the mines in the PlayersDB and CasoDB were simulated as 'immobile miniature-subs'. They were not intended to be equivalent to 1 sub = 1 mine because the lethal radius of the sub/mine was 1nm. Therefore, they were meant to simulate a small area with mines. The mine-sweeping tools were intentionally made to run slowly and have long re-load times to simulate the amount of time necessary to cleanse an area. Otherwise, a player can move along at very high speed and sweep quickly. The "firing rate" and re-load times for the mine-sweeping launchers is currently set for about 60mins. Even though the game may show that they are re-loaded, they require the full 64 mins or so before you are allowed to re-engage. This was my rough estimate on how long it would take to clear a 3.14nm area represented by the mine/sub.

If you do not agree with my assumptions and estimates, you can always modify the CasoDB with faster firing times and re-load rates. The engine on the sweep gear was set for 1kt speed to simulate the 1 hr it would take from firing to reach the weapon. This is all an awkward work-around simulation, but it is the best we have for Harpoon. Mine-sweeping is supposed to be a long arduous process and this was the thinking behind the arrangement.

Files can be added to this forum by first placing the *.SCN file within a *.ZIP file.

[Herman Hum]

When you say re-load times, is that what's called the ROF in the editor? I noticed that the mine sweeping equipment have ROF's of -60 in the magazines. Does that mean it takes the 60 minutes you talked about to reload? What does the ROF signify in the mounts? They're set to -128. Finally, where is the place where speed is determined for the weapons? I have no mines in any of my finished scenarios now, so would it affect the way they play now if I amended that one thing as you suggested in the dB?

There is a RoF for the mount and one for the WeaponRecord. Usually, they are the same, but sometimes they differ. When they differ, the longer time is usually applicable.

Negative numbers denote increments of 30 seconds. So, -128 = 64 minutes. Positive numbers are for seconds.

Since you have not used any mines in your previous scenarios, any changes you make in your database are unlikely to affect them.

The speed for the weapon is assigned to the #1368 Mine Disposal Gear engine component.

[aotino]

Thanks That's really helpful, although I am having trouble finding the ROF in the Weapons Record.

When you say re-load times, is that what's called the ROF in the editor? I noticed that the mine sweeping equipment have ROF's of -60 in the magazines. Does that mean it takes the 60 minutes you talked about to reload? What does the ROF signify in the mounts? They're set to -128. Finally, where is the place where speed is determined for the weapons? I have no mines in any of my finished scenarios now, so would it affect the way they play now if I amended that one thing as you suggested in the dB?

There is a RoF for the mount and one for the WeaponRecord. Usually, they are the same, but sometimes they differ. When they differ, the longer time is usually applicable.

Negative numbers denote increments of 30 seconds. So, -128 = 64 minutes. Positive numbers are for seconds.

Since you have not used any mines in your previous scenarios, any changes you make in your database are unlikely to affect them.

The speed for the weapon is assigned to the #1368 Mine Disposal Gear engine component.

[Herman Hum]

I don't know which editor program you are using. I will show both the Reimer Editor and the [in-game] H3Editor.

Reimer.gif (40.17 KiB) Viewed 25378 times

H3Editor.gif (169.53 KiB) Viewed 25379 times

[aotino]

Got it! Thanks. I am using the [in-game] H3Editor.
One other thought occurred to me that makes me hesitate in amending my dB, even though there are no minesweeping or laying activities in my previous games. There are some MCM ships that appear in some of the scenarios. Even though they only perform transit roles, I am worried that they may cause an incompatibility with an amended dB. Are my fears warranted? I would only be altering the nature of the weapons themselves, and in that only their speed and rate of fire.

I don't know which editor program you are using. I will show both the Reimer Editor and the [in-game] H3Editor.

Reimer.gif

H3Editor.gif

[Herman Hum]

If you modify the CasoDB, it will definitely cause a compatibility issue with previously released scenarios because the newly released database will have a different Signature.bin file. However, this should not be a problem as all your scenarios are re-built with the Scenario Editor prior to release in order to ensure that they match the Signature.bin file for your current database version.

Your users should never encounter loading problems like this:

Celebes Sea Slam

[aotino]

Ah okay. I think I follow, but maybe not.

It will cause a compatibility problem with previously released scenarios, such as the 5 I've released already? That would be a problem.

Yet it's not problem as all my scenarios are rebuilt with the Scenario Editor prior to release? This one I don't understand.

I guess you need to walk through this little more slowly for the village idiot here. If I do my slight amend to the dB, which will create a new Signature.bin file, will the 5 scenarios we've released together already be able to play or not? If not, then do I need to resave them and re-release them?

I'm very confused, but I'm sure you will explain how this can be possible, as you always do. I just need to grasp the concept, or more importantly, the procedure that I must follow to make this possible. Thanks Herman. Best, Alan

If you modify the CasoDB, it will definitely cause a compatibility issue with previously released scenarios because the newly released database will have a different Signature.bin file. However, this should not be a problem as all your scenarios are re-built with the Scenario Editor prior to release in order to ensure that they match the Signature.bin file for your current database version.

Your users should never encounter loading problems like this:

Celebes Sea Slam

[Herman Hum]

When ANW was released, it had a new (ridiculous) feature called the Signature function. Every database has a unique identification Signature.BIN file associated with it. This file is generated when you export the database from the Reimer database editor or when you select the Save Data Annexes command from the H3 In-Game Editor. If you change a single letter or value in your database, another Signature.BIN file must be generated as the old one will no longer function with the modified values.

Every scenario made with ANW and HUE remembers the Signature.BIN file from the database when it was created. This means that the scenario can only be played with that specific database. When you modify the database, you generate a new (different) Signature.BIN file for it. The scenario cannot be played with the new (modified) database because it is looking for the former (original) Signature.BIN file.

The scenario can be re-set to work with the new Signature.BIN file and modified database. The way to do this is to open the file with the Scenario Editor and simply re-save it. This will re-synchronize the scenario with the new Signature.BIN file and can now be played with the newly modified database. Therefore, after you modify your database and generate a new Signature.BIN file, open each of the five previously released scenarios in the Scenario Editor with the new database. Then, re-save them and they will now function as before, but with the newly modified database.

In short, it is not a big problem to ensure your five previously released scenarios work with your revised database. This cockamamie signature function is just a ridiculous creation from AGSI and simply complicates things while not solving any underlying problems. AGSI are the true village idiots in this instance. And, it is unbelievably buggy in the HUE 3.10 version.

[aotino]

Thank you Herman. That was an excellent and clear explanation. If I do this, would I re-release the five previous scenarios with the modified dB after updating them?

When ANW was released, it had a new (ridiculous) feature called the Signature function. Every database has a unique identification Signature.BIN file associated with it. This file is generated when you export the database from the Reimer database editor or when you select the Save Data Annexes command from the H3 In-Game Editor. If you change a single letter or value in your database, another Signature.BIN file must be generated as the old one will no longer function with the modified values.

Every scenario made with ANW and HUE remembers the Signature.BIN file from the database when it was created. This means that the scenario can only be played with that specific database. When you modify the database, you generate a new (different) Signature.BIN file for it. The scenario cannot be played with the new (modified) database because it is looking for the former (original) Signature.BIN file.

The scenario can be re-set to work with the new Signature.BIN file and modified database. The way to do this is to open the file with the Scenario Editor and simply re-save it. This will re-synchronize the scenario with the new Signature.BIN file and can now be played with the newly modified database. Therefore, after you modify your database and generate a new Signature.BIN file, open each of the five previouslIy released scenarios in the Scenario Editor with the new database. Then, re-save them and they will now function as before, but with the newly modified database.

In short, it is not a big problem to ensure your five previously released scenarios work with your revised database. This cockamamie signature function is just a ridiculous creation from AGSI and simply complicates things while not solving any underlying problems. AGSI are the true village idiots in this instance. And, it is unbelievably buggy in the HUE 3.10 version.

[Herman Hum]

If I do this, would I re-release the five previous scenarios with the modified dB after updating them?

After you modify your database, update your scenarios by re-opening/re-saving them with the new database. Then, post the newly modified database and the associated scenarios to this thread so that they can be added to the Library installation file for release.

[aotino]

When you initially instructed me as to the joys and pitfalls of developing one's own dB, I took what you said very seriously and promised myself that I would not amend the dB once I relesed it, and I still believe and uphold that. I've been very careful that , once set, I would work within the parameters of choices I had with my dB. I have been completely satisfied and continue to be so with what those choices have been in my dB. However, I must say the mine-sweeping thing really had me handcuffed. By slightly altering it in the mnner as I have discussed with you just adds a whole other dimension to my scenarios that I was counting on when I first began the long-term planning of the campaign and battleset. Once again, if I move forward with this, I take it very seriously that this is not something I would want to do again - that I should even be doing in the first place if for no other reason as to maintain a strict discipline to the policies of Harpoon. I will think over all my choices carefully before I make this amendment as I must consider it the last one I do as I get further into designing this campaign.

As I've said before, thank you for your guidance. You are a fantastic instructor and mentor in this endeavor, and I am indebted to your kindness and help.

Warmest regards, Alan

If I do this, would I re-release the five previous scenarios with the modified dB after updating them?

After you modify your database, update your scenarios by re-opening/re-saving them with the new database. Then, post the newly modified database and the associated scenarios to this thread so that they can be added to the Library installation file for release.

[aotino]

Herman,

I made the amendments to the dB, and saved all scenarios built under the Caso dB. For purposes of the way I'd like my games played, I changed all ROF to -10, or 5 minutes according to your calculation rate. I gave all mine-sweeping weapons' propulsions a 10nm speed. I altered some of the weapons effective ranges, while keeping others the same. The results are thus - I re-tried the Mine Sweeping Test Scenario I built, and everything looked good. The weapons I released worked with the new ranges, and all ran at the prescribed 10nm/hr. The problems started once again where I attempted to reload the launchers from the magazines. When I transferred the weapon from the magazine, it showed up right away in the launcher. However, even after 5 minutes, they did not become available to use in the weapons launch window. I retraced all my amendments to the WEAPONS RECORDS and MOUNTS in the dB Editor, and all looked good with the ROF's.

However I did some further checking in the Editor and would like to know if they also need to be amended to make this work. In the EDIT>LOADOUTS I noticed two entries that seemed relevant - MCM EODTeam with a READY TIME of 240min, and an MCM Mine Clearance [Mechanical] with a READY TIME of 240min. Do these need to be changed, and how? Secondly, I looked into the EDIT>MAGAZINES and noticed several entries in two groups. The first group had a number of items that were headed with MCM RVP's (Mk5 PAP 104, Sea Eagle, Pinguin etc) with ROF's of -60, and the second group of Mine Clearance Gear with ROF's of -20. You didn't mention the magazines or loadouts as things to edit, so I was wondering if these need to be amended as well?

Lastly, even after launching the first weapons and having them track perfectly to the targets, not one of them destroyed a mine. I think I need these weapons to be pretty much 100% effective, if possible in my scenarios. Is that possible, and how do I make that happen?

YoU were right about the mine issue being tricky in the game.

Thanks, Alan

[Herman Hum]

I made the amendments to the dB, and saved all scenarios built under the Caso dB. For purposes of the way I'd like my games played, I changed all ROF to -10, or 5 minutes according to your calculation rate. I gave all mine-sweeping weapons' propulsions a 10nm speed. I altered some of the weapons effective ranges, while keeping others the same. The results are thus - I re-tried the Mine Sweeping Test Scenario I built, and everything looked good. The weapons I released worked with the new ranges, and all ran at the prescribed 10nm/hr. The problems started once again where I attempted to reload the launchers from the magazines. When I transferred the weapon from the magazine, it showed up right away in the launcher. However, even after 5 minutes, they did not become available to use in the weapons launch window. I retraced all my amendments to the WEAPONS RECORDS and MOUNTS in the dB Editor, and all looked good with the ROF's.

There is also an RoF (re-load rate) assigned to the various magazines. You most likely forgot to change this value. It controls the rate at which the weapon moves from the magazine to the mount/launcher. Be careful to note that there are two RoF values; one for the Magazine and one for the individual Weapons Record for the MCM device within the magazine. If they differ, the longer one is likely applied. Dual RoF rates are also found in the Mounts table.

However I did some further checking in the Editor and would like to know if they also need to be amended to make this work. In the EDIT>LOADOUTS I noticed two entries that seemed relevant - MCM EODTeam with a READY TIME of 240min, and an MCM Mine Clearance [Mechanical] with a READY TIME of 240min. Do these need to be changed, and how? Secondly, I looked into the EDIT>MAGAZINES and noticed several entries in two groups. The first group had a number of items that were headed with MCM RVP's (Mk5 PAP 104, Sea Eagle, Pinguin etc) with ROF's of -60, and the second group of Mine Clearance Gear with ROF's of -20. You didn't mention the magazines or loadouts as things to edit, so I was wondering if these need to be amended as well?

The Ready Time in the Loadouts component table determines the the amount of time between aircraft sorties. This is similar to RoF, but not quite the same. The MCM helicopters use this value to determine how long they need to re-arm before flying a second counter-mine mission.

If the Magazine re-load times/RoF values are only -60, this means that the weapons will fully re-loaded into the mounts within 30 minutes. IIRC, the Mine clearance gear was given faster re-arm values since it was set to be the more traditional broad area mine-sweeping instead of the more specific mine-hunting technique.

Lastly, even after launching the first weapons and having them track perfectly to the targets, not one of them destroyed a mine. I think I need these weapons to be pretty much 100% effective, if possible in my scenarios. Is that possible, and how do I make that happen

There can be many explanations for your observed behaviour. When de-bugging, it is a good idea to return to the last point where everything worked. I believe that the MCM devices worked for the PlayersDB and CasoDB. Then, make small changes until you get to your current situation. Somewhere along the line, you have introduced an error.

It could be something such as your increase in RPV Engine speed using up more fuel or some other minor detail. Go back to the state where things certainly worked and make small advances to discover the problem.