Not a Known ANW Issue? #08 - List Issue #117 Sonobuoy endurance display error

[rsharp@advancedgamin]

It will only attempt to drop passive sonobuoys and may RTB with active sonobuoys. It should use active sonobuoys when localizing a target.

This is a separate but related issue. Do you want the sonobuoys active announcing your TF to anyone listening or do drop short lived active sonobuoys in passive mode that? I don't have a strong grasp of actual doctrine on the issue here. Since it is doctrine the best option might be to make it yet another option.

Thanks,

[hermanhum]

ORIGINAL: rsharp@advancedgamin

It will only attempt to drop passive sonobuoys and may RTB with active sonobuoys. It should use active sonobuoys when localizing a target.

Is the use of the Active sonobuoys a recent change? This behaviour does not occur in 394. Helos on sub strike mission do not employ active buoys in the attack. I can't seem to get active sonobuoy employment in any ASW patrol mode, formation patrol, or Sub Strike mission.

ORIGINAL: rsharp@advancedgamin

This is a separate but related issue. Do you want the sonobuoys active announcing your TF to anyone listening or do drop short lived active sonobuoys in passive mode that? I don't have a strong grasp of actual doctrine on the issue here. Since it is doctrine the best option might be to make it yet another option.

Agreed that this is a separate issue. I would certainly like to see active sonobuoys employed by the AI. As it currently stands, it is a significant impediment to the AI, and AI, only. You raise a good point regarding the possibility of revealing a position through their employment, however I strongly believe that the merits outweigh any possible shortcomings.

1. In many cases, the larger and noiser units being screened within the group have already revealed their presence

2. Many navies in the world are only capable of employing active buoys. Allowing their employment would cover all the bases.

3. The current restriction only impedes the AI and has no effect on a human. AI needs all the help it can get.

[Bucks]

ORIGINAL: rsharp@advancedgamin

It will only attempt to drop passive sonobuoys and may RTB with active sonobuoys. It should use active sonobuoys when localizing a target.

This is a separate but related issue. Do you want the sonobuoys active announcing your TF to anyone listening or do drop short lived active sonobuoys in passive mode that? I don't have a strong grasp of actual doctrine on the issue here. Since it is doctrine the best option might be to make it yet another option.

Thanks,

Russell,

Even human players could use them in patrols. I've mentioned a few times during our meetings that a player may be able to "herd" a sub away from an active buoy line and therefore the HVU's they (the subs) are hunting. It may not work versus the AO it's not going to run from active buoys as far as I know but it's a valid tactic for MP. Russians would use it, sometimes simply because their passive buoys had such poor performance.

Cheers

Darren

[hermanhum]

ORIGINAL: Bucks

I've got a "feature" request in to have aircraft relieve each other "on station". That would mean a relieving aircraft would reach the patrol zone just as the on station aircraft was ready to leave. I'll make an additional note to ensure we look at the current behaviour and I'll see if I can find where it was added by searhing through Mantis.

I think that this is a prime example of how seemingly small changes can have unintended consequences.

Logically speaking, this potential new feature does appear interesting. However, if it were to be implemented, I would hope that

1) there is an option to turn it off and
2) that the default would be the pre-existing (non-replacement) behaviour.

This feature request strikes a chord because I just finished writing a scenario that is based upon current (non-replacement) behaviour and not the one requested. My scenario requires the player to time his missions for when there is a gap in the AI coverage. I know about the gap and intentionally wrote the missions to account for it.

This is not to say that such a feature is necessarily bad. However, the consequences of forcing such a behaviour on pre-existing performance as the default or sole possibility is not a good thing.

[Bucks]

So there's an issue with attempting to add realism due to a single scenario. I mean any airforce that can't plan a replacement "on station" needs some training I believe.

Just my 2c seeing as the current behaviour is flawed, I was hoping this would be accepted as an implementation of real life behaviour. maybe you could adjust your scen by reducing the aircraft availabilty or even easier set the ready times to enforce the gap in coverage.

Darren - Who believes there's more than one way to skin the proverbial cat

[hermanhum]

The point is, no one should be forced to play any way but their own. 

A system that accommodates both styles of play is the only way to go.  Changing the underlying rules after the release is not a good thing.  Hence, my suggestion to maintain the default, yet allow for new options.

[hermanhum]

I don't know how seriously AGSI is going to take this feature request, but I thought of some more potential complications and am posting them in case AGSI decides to pursue implementation.

The request was for planes on patrol to be replaced at the location before planes already on station depart and return to base.

1) That sounds as though the replacement plane arrives just as the plane on station departs. However, a more conservative user might want the replacement plane to arrive even earlier. I think that it would be a reasonable expectation. If one user can specify that a plane on station be relieved on station, another should be able to determine when it is replaced. That way, a replacement plane arrives while the plane on station still has 5%, 10%, 15% (or whatever) discretionary fuel remaining.

2) A problem might also arise if the plane never reaches the station. One technique used in Patrol missions employing reference points is to place the reference point beyond the actual range of the plane's fuel.

For example, a plane might have a range of 100nm but the ref pt is placed 200nm. This technique is commonly used to keep the plane flying in one direction towards the patrol zone to its maximum range. If it detects something along the way, it still reacts. Problems may arise if the plane never reaches the Ref Pt since it would not be possible to calculate the replacement launch.

These are just two more possibilities. I'm sure that more exist.

[rsharp@advancedgamin]

Nice discussion going on here so I'll try to not ruin it. I have been considering the issue for some time as I consider the behavior unrealistic as well.

1) Any change in mission replacement will be implemented as a configurable option on a per-mission basis. Pretty much my default move at this point when changing mission behavior. This dodges several potential problems.

I like the idea of making the parameter based on discretionary fuel, fuel remaining beyond what is required to make it home. I believe the current (and possibly default) setting would be 0%.

2) dunno about every little odd behavior used in every scenario but hopefully maintaining the current behavior as the default would dodge these sorts of issues.

Also, I'd see an issue where there are a mix of craft in play. So maybe the replacement craft is not as fast or has less range than the craft it is replacing. The 1/3rd mission behavior also complicates things.

Thanks,

[YankeeAirRat]

Have either of you tried to create a sonobouy as a torpedo? Make it go slow (<1kts) and don't give it a warhead. Only authorized targets would be submarines. I know this isn't realistic but that might give it the station time we are looking for and give it the ability to burn the fuel, plus this might simulate bouys being affected by the currents.

[hermanhum]

Unfortunately, there are several problems associated with that idea.

Firstly, the AI would be unable to use the proposed new sonobuoy-torpedoes while it does ASW searches or Formation Air Patrols. Players could certainly launch the buoys on BOL, though.

Secondly, it does move. Sooner or later, you might drop a sono-torpedo next to a sub that might only be doing 1kt or motionless and then it will hit the target.

Thirdly, once a torpedo hits the water, you lose contact with it. I've tried to put various communications devices on them (i.e. control wires and sonobuoy datalinks), but the helos that launch them cannot control them.

Fourthly, it's pretty much a cosmetic problem. This endurance display was the same one available in both H2 or H3. And, it only gives the same incorrect and non-essential information in ANW. It doesn't affect the real endurance or performance of the sonobuoy.

Always good to see others trying to think 'outside of the box', too. It's how Freek dreams up so many different scenario ideas and techniques.

[FreekS]

Yankee,

I suspect that would not work as the torpedoes are underwater and thus not in communication with the helo or MPA. They would therefore not pass their detected targets on to the mother vessel for prosecution.

PDB in the past modeled mines as torpedoes, which worked fairly well, except you had to find a way to insert them into a scenario as the designer which proved to have more disadvantages than advantages.

rsharp.

I did not understand your answer. I don;t think there was anything wrong with buoy-dropping helos laying string after string on pre programmed areas around the formation and relieving themselves when out of buoys. I still don;t understand why the bahaviour was changed to what it is now.

Freek

[hermanhum]

ORIGINAL: FreekS

PDB in the past modeled mines as torpedoes, which worked fairly well, except you had to find a way to insert them into a scenario as the designer which proved to have more disadvantages than advantages.

Sorry, that's incorrect. The Y2kDB tried that arrangement and it had all kinds of problems. The biggest problem was the fact that the minesweepers were virtually invulnerable to the mines. Not a bad thing, but that also made the minesweepers invulnerable to ALL torpedes (including Mk 48s!).

[FreekS]

ORIGINAL: hermanhum

Sorry, that's incorrect. The Y2kDB tried that arrangement and it had all kinds of problems. The biggest problem was the fact that the minesweepers were virtually invulnerable to the mines. Not a bad thing, but that also made the minesweepers invulnerable to ALL torpedes (including Mk 48s!).

Apologies for crediting PDB with an innovative Y2K feature! You are right that the anti torpedo weapon on the 'mines' made the minesweepers invulnerable to real torpedoes, but it did work and I remember flooding the Persian gulf with floating mines.

Feature request: Mines with their own mine symbol!

Freek

[hermanhum]

A mine symbol already exists and AGSI claims that they are working on mines in Harpoon Pro as a future enhancement:
http://www.computerharpoon.com/products ... 3-pro.html

[Bucks]

Thanks Herman,

Response and preliminary notes below:

ORIGINAL: hermanhum

I don't know how seriously AGSI is going to take this feature request, but I thought of some more potential complications and am posting them in case AGSI decides to pursue implementation.

The request was for planes on patrol to be replaced at the location before planes already on station depart and return to base.

1) That sounds as though the replacement plane arrives just as the plane on station departs. However, a more conservative user might want the replacement plane to arrive even earlier. I think that it would be a reasonable expectation. If one user can specify that a plane on station be relieved on station, another should be able to determine when it is replaced. That way, a replacement plane arrives while the plane on station still has 5%, 10%, 15% (or whatever) discretionary fuel remaining.

2) A problem might also arise if the plane never reaches the station. One technique used in Patrol missions employing reference points is to place the reference point beyond the actual range of the plane's fuel.

For example, a plane might have a range of 100nm but the ref pt is placed 200nm. This technique is commonly used to keep the plane flying in one direction towards the patrol zone to its maximum range. If it detects something along the way, it still reacts. Problems may arise if the plane never reaches the Ref Pt since it would not be possible to calculate the replacement launch.

These are just two more possibilities. I'm sure that more exist.

You have known or unknown transit times to the patrol zone. The basis of my request also contained some patrol zone considerations... I'd suggested a central point as the known position of the RTB aircraft could never be known. Therefore the TTLRA (Time To Launch Replacement AIrcraft) would be a floating value that the GE would have to constantly calculate. Or it would still have to calculate a time based on say using a central point in the Patrol Zone.

As stated above the TTLRA (Time To Launch Replacement AIrcraft) is calculated/updated based on the current position in relation to its Base, fuel remaining & fuel required to RTB or Bingo value of the currently active (in flight) aircraft. The position of a reference point is simply not used to calulate RTB is it? The mission you described with "out of range" Reference Point characteristics function and return a valid RTB value already, correct? RTB is calculated in relation to the distance the aircraft is from it's base, "need to go home now or we're swimming..."

To implement the launch to replace aircraft behaviour, the GE now has to allow for a, "transit to station time" allowance. So the Launch time is the inflight aircraft's RTB value x2. You could also define it as the geographical centre of the Patrol Zone as well and since the GE would have this as a value for Patrol missions coded to be calculated when a mission is created, surely a variability system like that for sensors would allow early or late launch of follow up aircraft within the known transit time?

i.e. If Transit time is 100 mins, and you want it there half an hour early you would set -30 (minutes) and the aircraft would launch the specified time (30 minutes) early. +30 would be half an hour late, use % to simulate hold-ups at the airbase, slow/fast reactions, poor aircraft turnover etc etc.

I didn't just dream it up Herman seriously, I've done a little consideration of what's happening and how to approach it. You should see the movies in my head mate...[X(] (Poor self effacing joke, only aimed at myself)

Cheers

Darren

[Bucks]

ORIGINAL: YankeeAirRat

Have either of you tried to create a sonobouy as a torpedo? Make it go slow (<1kts) and don't give it a warhead. Only authorized targets would be submarines. I know this isn't realistic but that might give it the station time we are looking for and give it the ability to burn the fuel, plus this might simulate bouys being affected by the currents.

G'day Yankee,

Yeah I've tried. When the fuel value for sonobuoys was added I decided to look at a drifting mine type weapon based on the sonobuoy. Tried this as a mine, propulsion systems can be added to sonobuoy weapons, but the GE is not coded to implement movement of this weapon type. Drift was something else I was thinking about in general, although I'd never asked Russell about the requirements for sonobuoys to be "set in place". There may be a sensor, comm or propulsion issue. For instance fuel now represents lifetime for sonobuoys having an engine for propulsion may cause a conflict in fuel values, types and useage rates.

I'd developed a mine system some years ago when it was possible to have facilities placed "underwater". It's in the HUD3 still (I don't delete much) in the following form:

Installation Annex

ID Name
87 Mine Field 30nm N/E#

It consists of 16 Facilities, 1 HQ - Comm Center & 15 TST - Mine Launchers (TST = TEST Platform)

I'd set the Latitude and Longitude offsets to 2 mins North and 2 mins East (2mins = approx 2nm) from the point of placement on the map for the 15 "Mine Launchers". Since the Installation offset overcame ground facilities in water issues (illogical), I'd developed what seemed almost a passable minefield system.

You can still test it out on land, not many subs on land though or ships... You'll at least see where I was going with it. Make sure you hit F8 and display range rings etc. It was possible to unload these to allow gaps and I suppose in hindsight with boarding available in the near future, minesweepers could have "boarded" the facilities and once the facility is declared captured. You've cleared a "mine".

Cheers

Darren

[Bucks]

ORIGINAL: hermanhum

A mine symbol already exists and AGSI claims that they are working on mines in Harpoon Pro as a future enhancement:
http://www.computerharpoon.com/products ... 3-pro.html

Thanks for the advertising Herman. Sorry, the Game Version again? Harpoon Pro

Anyway there's stuff like that (Pro Version/different business model, different customers & nothing to be concerned about) and then there's the much closer 3.10 features for the Public ANW. Again an update to the game, and easily purchased through Matrix Games in the current 3.9.4 release version.

There's even another symbol in your pic Herman that's not used, that's possibly more closely tied to past enhancements that could be applied to expand on them again - (low development cost/basic mechanics work now/concept proved in HUD3/possible minor GUI change only required). At the same time scenario concepts expand and another feature fed back to the Pro version that funds the big improvements (New GUI etc).

If you would like to see a Pro feature included in ANW do you have a source of funding available? Nearly all major upgrades to the game have come from Military (Depts of Defence & Contractors) contracts. Where possible these paid for "from outside" features are able to be fed back to your version of the game. Aussies paid for us to be able to play a human at last, so people's taxes in a country far far away contributed to your enjoyment of Harpoon.

As always Herman if you would like to discuss your suggested approach to the implementation of a mine weapon and/or modelling please feel free.

Some possibilities include:

The individual "mine as a weapon" model - lots of entities for the GE to track

OR

The positioning of a minefield as a modification of the current Threat Poly code?

The second concept would allow for the creation of a large area minefield without the GE having to "keep track" of 1000's of mines/weapon entities.

For example a zone could be created using the threat poly feature or modification thereof and the ability to add values and for example these could involve some of the below considerations:

- Minefield Density or Strength
(Used by Minesweepers to calculate minefield clearance times and probablity of an enemy ship within the minefield triggering a mine detonation)

- Minefield Detection Value
(Used by minesweepers or in the case of surface mines visually for detection of current position being a minefield. May not have to default to automatic detection on detonation if field is below X strength, submerged mines etc.)

- Minefield Type
(Types of mines laid in Minefield zone. Eg. Types - ASW, ASuW & Captor. Triggering Options - Magnetic, Accoustic & Combination mines, many possible combinations.)

- GE
(Additional Code? - Also Calculates a "time to fill" based on Density or Strength value. Requires application of a weapon "logistics counter" to be expended and fill the minefield to its maximum strength.

With?

A Platform Flag and associated Database fields to allow for "Clearance Rate" for Minesweepers, and "Laying Rate" for Minelayers. Therefore no new Vessel type is required values applied to correct ship entries in each Database.

Without each mine requiring clearing, the same results can be achieved using these suggestions.

Placement of ships capable of Sweeping have to remain within the zone they are attempting to clear for defined times to ensure clearance.

The same poly representation could be used in reverse. You discover a field, draw a poly of the channel you want to clear and are then required to place Sweepers within that zone. Once cleared ships move through, your poly zone/channel free of mine damage or with a very minor "missed/random mine" chance of detonation post clearance.

Unit display possibly shows "time to clear" and the code uses set values for detonation chances with known Published modifiers etc for Database and Scenario designers to apply as they see fit.

Cheers

Darren

[FreekS]

Hi Bucks,

I've had a perfectly functional minefield in my Approach scenario (3.6 only). It used a nav zone to draw the 'minefield' and then used patrolling AI-controlled invisible planes to drop torpedo's on any ship inside the minefield. The planes could not get out of the (air) nav zone. I even had a 'safe channel' through the minefield (patrolled my minesweepers) and the player was supposed to be smart enough to follow the minesweepers with his small convoy through the safe channel. Ah, those were the days......

Freek

[hermanhum]

The scenario used a simulated minefield through the use of an aircraft unit to drop torpedoes.&nbsp; It was fun to play, but such a mine representation has problems and limitations of its own.&nbsp; For example, there really wasn't any way for the minesweepers to actually 'clear' the mines except by showing where the minefield was and then avoiding it altogether.&nbsp; Of course, that was the whole intent of the scenario (and well done).&nbsp; However, as a basic weapon implementation, I think it far too limited for overall general use.&nbsp;

I considered 'airborne mines' as a potential implementation for the PlayersDB, but decided against it because they could not be swept.&nbsp; Instead, I selected the 'sub-deployed mines'.&nbsp; They have their own limitations, but at least they can be detected and swept.

[Anonymous]

[Deleted by Admins]