Airborn ASW Search Plan

[TEPonta]

I've mentioned this at the H.U.L.L. before, but I believe this is the proper forum to post it. When an ASW A/C is sent on a long distance patrol, it seems to stay pretty much in one spot dropping buoys at random. The 5-6-5 Distro plan (see attached diagram) was the most popular plan we used to use in these situations. The Kingpin position and Road are based on the area you wish to cover and the Spacing is based on CZ conditions in that area. I realise it's probably not practical to have an A/C in the game drop bouys at these precise locations, but I would suggest an on station Patrol be given a detection area based on such a plan. Input from the player could be limited to location and possibly the Road, or axis of the field.

 

Buddha

565Distro1.bmp

[TonyE]

Moved from Pipe Dreams forum to adhere to the rules of the Pipe Dreams forum.

 

But yes, let's get as much of that discussion, from the now defunct AGSI forum, recreated here.

[CV32]

This was interesting ...

 

NANCEE is a computer simulation program which uses convolution (or meeting) probabilities to determine which barrier type of sonobuoy pattern has the highest probability of detection for a transiting nuclear submarine. The program assumes that the optimum barrier is a straight-line one, two, or three row sonobuoy pattern containing not more than 48 sonobuoys. The barrier is centered on the submarine's expected line of transit, oriented perpendicular to the submarine's course, and placed far enough ahead of the submarine's position that all pattern sonobuoys are in the water and being monitored before the submarine enters the detection range of the sonobuoy pattern. If more than one barrier is found to have the highest probability of detection, the one with the least number of sonobuoys is selected as optimum.

 

Link

[CV32]

Thanks to Tony for finding this gem.

 

From Journal of Simulation (2006) 1, 29–38. doi:10.1057/palgrave.jos.4250003

 

"Each of the five search patterns from the National Search and Rescue Manual are described below. For each pattern, a graphic of the pattern is presented each of which indicates a commence search pattern (CSP) point ... When the point of last contact with the target involves a high degree of certainty, and the search area is large, either the parallel ... or the creeping line ... search pattern is preferred.

 

The parallel pattern is most desirable when the target is assumed equally likely to occupy any part of the search area.

 

 

The creeping line pattern ... is typically employed when the target is more likely to be in a particular end of the search area.

 

 

When the point of last contact is well known, or established within close limits, the square ... and sector search ... patterns are preferred. The square pattern is used when uniform coverage of the search area is desired ...

 

 

while the sector search pattern is used in scenarios where the target is difficult to detect.

 

 

Finally, when the target is fast moving or when a strong current is present in the search area, the barrier patrol search pattern ... is preferred (its CSP is either starting point). The barrier patrol pattern was used extensively during the actual Bay of Biscay U-boat war."

 

[wombat1417]

Great! Add it to the game!!

or at least, add it to the manual or website as an addendum.

[Stalintc]

Further to the above statements, I wanted to add something with regards to the user end of the operation, what control I feel the user may need to have over the process.

 

Workings

 

1) User decides where they would like to setup an ASW patrol

 

2) User selects the group containing the aircraft they would like to launch on that patrol.

 

3) User clicks *Launch* as normal and then is prompted for a patrol type.

 

4) User then puts radio button in what would be a fourth one, for ASW Patrol.

 

5) User is then prompted for the location of the search and would click on the map as if they were selecting a patrol destination, at the epicentre of the ASW search.

 

6) User is then prompted with a dialogue box similar to what is attached to this post asking them for the details of what search they would like.

 

7) After clicking *OK* the user is now prompted for what aircraft like they would like to assing as normal. (preferrably with only ASW capable aircraft in the list <g> )

 

Intergration into other parts of the interface

 

The above will work fine, until the player attempts to change the unit course to something else... of course the player should be entitled to do so. And perhaps there should be a button on the top bar which can re-initiate the above process. It is also inevitable on that note that the player may wish to change the location of the search, which would heighten the need for a button re-initiate the process even more. There would be no point having the feature if it could not be accessed at any time like *Attack* for example.

 

New Menu Explained

 

Here is a brief explanation of what the items in the menu in the attached image should do.

 

> Four radio buttons on right - Pass the argument to the AI as to what search pattern to use and plots a course according to this. This will affect the main part of how the AI behaves on the course too.

 

> Boundary - Define to the AI in nm how far the boundary of the search is to stretch.

 

> Sonobuoy Interval - Define to the AI how often to drop sonobuoys

 

> Repeat? - Checkbox to make the AI perform the search course, but then replot and do it again in a loop until other orders are issued.

 

> Use dipping sonar - Checkbox to make the AI stop at intervals to use its dipping sonar (providing it has one)

 

[TEPonta]

Further to the above statements, I wanted to add something with regards to the user end of the operation, what control I feel the user may need to have over the process.

 

Workings

 

1) User decides where they would like to setup an ASW patrol

 

2) User selects the group containing the aircraft they would like to launch on that patrol.

 

3) User clicks *Launch* as normal and then is prompted for a patrol type.

 

4) User then puts radio button in what would be a fourth one, for ASW Patrol.

 

5) User is then prompted for the location of the search and would click on the map as if they were selecting a patrol destination, at the epicentre of the ASW search.

 

6) User is then prompted with a dialogue box similar to what is attached to this post asking them for the details of what search they would like.

 

7) After clicking *OK* the user is now prompted for what aircraft like they would like to assing as normal. (preferrably with only ASW capable aircraft in the list <g> )

 

Intergration into other parts of the interface

 

The above will work fine, until the player attempts to change the unit course to something else... of course the player should be entitled to do so. And perhaps there should be a button on the top bar which can re-initiate the above process. It is also inevitable on that note that the player may wish to change the location of the search, which would heighten the need for a button re-initiate the process even more. There would be no point having the feature if it could not be accessed at any time like *Attack* for example.

 

New Menu Explained

 

Here is a brief explanation of what the items in the menu in the attached image should do.

 

> Four radio buttons on right - Pass the argument to the AI as to what search pattern to use and plots a course according to this. This will affect the main part of how the AI behaves on the course too.

 

> Boundary - Define to the AI in nm how far the boundary of the search is to stretch.

 

> Sonobuoy Interval - Define to the AI how often to drop sonobuoys

 

> Repeat? - Checkbox to make the AI perform the search course, but then replot and do it again in a loop until other orders are issued.

 

> Use dipping sonar - Checkbox to make the AI stop at intervals to use its dipping sonar (providing it has one)

 

 

That looks as good (or better) than anything I could come up with. I would suggest adding MDR to the Weather Conditions report for any point to enable the player to determine buoy spacing for his plan. Layer pepth would be helpful as well.

 

Buddha

[TonyE]

Ok, now refine it guys, what's wrong with that picture (think aligning the search). Buddha's 5-6-5 distro isn't specifically mentioned, should it be?

 

How does the AI side decide which methods it should use?

 

How does this influence scenario design, what does the scenario designer have for choices, etc...

 

 

Keep working it guys.

[TEPonta]

The Distro field should be fairly easy to implement, speaking as a non-programmer of course. Kingpin, Road, and Spacing would give you a rectangular area covered by the field. The only other hangup I can see is that CZ conditions would need to be included in the Weather Report for the area, as well as the MDR I mentioned earlier to determine the area covered, based on spacing. Road is determined by the expected line of approach, or ASW Threat Axis.

 

Buddha

[Stalintc]

what's wrong with that picture (think aligning the search).

 

Ok I have now added what I think would be a solution to aligning the search, this is basically a ring of radio buttons around a circular image that depict the general direction of the search pattern.

 

So for example the player wants to do a parallel search pattern in the direction of 270, the player would then click in the radio button next to 270 select the other partticulars including the radio button for parallel and then OK to begin the search.

 

The radio buttons around the circle will basically tell the AI want direction to plot in, but I personally think that insted of exactly 270 etc etc there should be a percentage of variation in the direction that the AI actually uses just so its different everytime, because real life is not always that exact.

 

Here are some examples of different layouts to this affect...

 

 

 

The second image is depicting the same window idea but with radio buttons for the ranges. However I personally believe it makes the box more cluttered than it should be. And should the user not be able to designate their own ranges and intervals?

 

How does the AI side decide which methods it should use?

 

If the enemy AI or formation AI were to decide which method to use, it should base its opinions on what it knows from the battle picture.

 

Perhaps this simple set of rules below could be expanded but please do have your say on it:

 

Parallel:

 

- No current unknown or known enemy sub contacts are within 100nm of the formation.

 

- No contacts that have been recently lost were within 100nm of the formation.

 

Creeping:

 

- No current unknown or known enemy sub contacts are within 100nm of the formation

 

- Contacts have been recently sighted with 100nm of the formation and contact has been lost. (since the end of patrol pattern should be where the sub contact was last detected before it was lost.

 

Sqaure:

 

- A known enemy sub contact is within 100nm of the formation but not fully localised. (No fix on unit XXX) Assuming unit is from the opposition and this known to the AI

 

Sector

 

- An unknown sub contact is within 100nm of the formation but not fully localised. (No fix on unti XXX) Assuming unit is difficult to detect because it is not yet classified

 

Now this leads us onto the aspect of how does the AI decide what ranges and intervals to use for its searches to complete the above dialogue box as if it were human.

 

I know not what the limitations of coding the AI are, but in order to keep it simple I believe the AI should be able to pick a random number between X and Y. I dont see the AI gaining much benefit from deciding how the search ranges are to be conducted for the work involved in making it decide. I'm sure others have opinions and ideas on that and I would encourage you to share them, because reasoning this for the AI has me baffled.

 

However when we talk of what direction or *road* the AI selects for its search pattern, I believe the AI should be able to select this based on the current bearing of the ambigous contact. But if no contact is known, this I believe should also be somewhat randomised.

 

How does this influence scenario design, what does the scenario designer have for choices, etc...

 

I have very little experience with scenario design and I only use the editor to knock out small test scenarios, so I dont think I can answer this fully and accuratley, but I will reply on what I understand of the process.

 

If the AI is capable of thinking for itself with regards to ASW it should then reduce by a margin the amount of work the scenario designer needs to do setting up patrols for the AI.

 

But perhaps also the scenario designer should also be allowed to still manually set those patrols up, because he\she may still want to have that higher likelyhood that the players submarine assets will be picked up. Handing off responsibility to the AI while still regaining control is the road to flexibility with scenario design. "You can do it if you need to, but you dont have to" approach to scen design.

 

However I do believe that if the AI was capable of doing this well, we would see a higher trend of random and differing results each time a scenario is played. That in my opinion is the backbone of what makes a scenario great, is that it never plays the same way twice. Making the AI do more of its own chores well increases this effect to a huge degree.

 

Perhaps this could be better answered by our resident scen design veterans <g>

 

Anybody have any further thoughts? speak up!!

[TEPonta]

When designing a scenario, I think the easiest way to order a field would be to order the ASW A/C to launch and provide the ability to specify ASW patrol, along with the normal options now available. The patrol area could then be defined in a manner similar to defining the area for an "On Station" victory condition. Some limitation would have to be placed on size of the area.

 

Buddha

[CV32]

More useful material:

 

The Diesel Submarine Flaming Datum Problem, by Alan Washburn and Ryusuke Hohzaki

[Akula]

StalinTC,

 

I'm just wondering how do you plan to keep the AI from scheduling ASW patrols over land? I'm sure there is going to have to be some kind of flagging system that tells the AI 'Hey Stupid, you can't find submarines in a cabbage patch!'.

 

Now then, as far as scenario designers are concerned, simply brining up the interface in the SE at the patrol start point and letting us edit in the patrol zone is easily acceptable. Scenario authoring is a ton of clicking as it is, a few more won't matter. The problem is going to come in to the AI actually having to decide for itself, or for older official scenarios (unless someone is brave enough to redo all of them).

[mack]

I'm going to ask for a perhaps more practical idea, but could the game engine be modified so that:

1) A plane/helo attacking a yellow/uncertain contact will drop his sonobouys at the edge of that field, rather than as a "cross" inside that uncertainty diamond, and once that field is established, then start dropping buoys inside.

2) Plane ASW formations with more than 1 aircraft would sent the 2nd aircraft to the "end" of the diamond so they could cover the whole diamond earlier, for example Plane 1 drops on the 1st and 2nd sides, Plane 2 drops on the 3rd and 4th sides, then they work on the middle. As it stands any ac that join a search will cover the exact same ground as the first have.

3) The ability to drop torpedoes without having a target, that would work on a snake or circle search pattern. Many patrol craft carry 6+ torps, and I wouldn't mind wasting one for the chance to aquire a target that might have to rev to flank speed and give away it's position to my patrol.

[CV32]

I'm going to ask for a perhaps more practical idea, but could the game engine be modified so that:

1) A plane/helo attacking a yellow/uncertain contact will drop his sonobouys at the edge of that field, rather than as a "cross" inside that uncertainty diamond, and once that field is established, then start dropping buoys inside.

 

Sounds like you're advocating a barrier line of sonobuoys to start. But which of the four sides of the uncertainty zone would the aircraft tackle first?

 

3) The ability to drop torpedoes without having a target, that would work on a snake or circle search pattern. Many patrol craft carry 6+ torps, and I wouldn't mind wasting one for the chance to aquire a target that might have to rev to flank speed and give away it's position to my patrol.

 

Torpedo seeker acquisition zones are much shorter ranged than that of the typical sonobuoy or dipping sonar. Dropping a torpedo without a definite, localized contact would serve no purpose. Even with better modeling of search patterns.