Airborn ASW Search Plan

[mack]

1) I'd just pick a side at random maybe.

3) Okay

[CV32]

1) I'd just pick a side at random maybe.

 

I suppose it would make sense to either tackle the side closest to you (i.e. in order to establish the barrier rapidly) or, alternatively, the one furthest away (i.e. so that you know the sub is at least somewhere you and the distant barrier).

[Akula]

1) I'd just pick a side at random maybe.

 

I suppose it would make sense to either tackle the side closest to you (i.e. in order to establish the barrier rapidly) or, alternatively, the one furthest away (i.e. so that you know the sub is at least somewhere you and the distant barrier).

 

That may not be such a great idea, I've often seen uncertainty zones that would be the equivalent of several thousands of miles. The inside edge can also be very very far from where the ship/sub actually is. Basically we need to make a maximum uncertainty box size on it to prevent the AI from doing something foolish.

 

Sort of like this

 

If possible range is >=X then do not intercept

If Possible Range is <=X then intercept

 

or some such.

[CV32]

Basically we need to make a maximum uncertainty box size on it to prevent the AI from doing something foolish.

 

Of course. There is a point at which laying sonobuoys or dipping your sonar would be a meaningless exercise.

[CV32]

Search theory and big data: Applying the math that sank U-boats to today's intel problems (DefenseNews)

 

Most relevant excerpt:

 

Search theory tries to improve your odds by showing you which areas are more or less likely to contain your target. Here’s a taste, for the mathematically inclined: The “random search formula,” one of the bedrocks of the doctrine, represents time required to cover an area as l = VW?/A. A is the area of territory to be covered, visualized as a rectangular grid on a map. The reciprocal of lambda (l), seen as VW?, represents the length of time required to cover A once.

 

Then take the next formula, where your final probability of detecting a target is represented as PD. Plug your values into the formula PD(t)= P(T=t) = 1- exp(- lt). Here the lower-case t represents your time to locate the target. Upper-case T is a random variable.

 

And theoretically, you’ll have your probability of finding the U-boat, in a particular period of time.

[Grumble]

Thanks Brad for posting here, I might never have looked this way otherwise!

 

Interesting topic ... kind of sad to read all the bright ideas, enthusiasm and collected know-how that was then never implemented.

This is the problem, right, what can be implemented within the constrains of the budget.

 

Accepting resource limitations I would start from what is achievable, thus look at reusing existing code and avoid GUI modification as much as possible. Something that can be added with just a few brush strokes (assuming here this topic is still some kind of pipe dream for the code and not about theoretical ASW methodology )

 

So here is my budget version of revitalizing long distance ASW patrols.

1. We want long distance ASW patrols execute a search pattern instead of just loitering in place
   1. Lets achieve this by reusing the code of the uncertainty region ASW search. Limit the required additional code to just "generating" a constant, uncertain, sub contact exclusively for the ASW patrol a/c. E.g. "feed" the ASW patrol with contact/target data as if there was a sub contact on the patrol destination.
   2. As an alternative approach consider generating a general, constant, neutral, uncertain contact for the patrol location. This would even have the benefit of the patrol area showing up on the screen. A player could live with this false contact I expect, the bigger question is how hard it is to convince the AI to ignore such an artificial contact?
   3. Point is, hopefully either of these approaches (or something similar Tony proposes) would allow code light enough fit even for a debug build.
2. Orientation of region: could be constant North-West or based on the patrol route, whichever is easier to code. Square too.
3. Size of the region: Calculated from the number of sonubuoys carried by the patrol a/c(s).
   1. The goal is to have an area just large enough for the patrol be able to complete 1 cross pattern with the available sonubuoys.
   2. Actually it would be better to complete the pattern with 90% of the buoys and then switch to loitering, e.g. preserve 10% buoys for investigating a real contact. This, however, might require code too heavy for the budget.
   3. Even if we can't switch the patrol mid-flight to loiter (within budget) and thus it is bound to exhaust it's store of sonubuoys, it will keep criss-crossing the patrol area and scan it with MAD. This is still far superior ASW behavior compared to the current one.
   4. The player has some control over the size of the patrol area. He/she can group more a/c-s to multiply the number of sonubuoys thus increase the patrol area.
   5. Have a default constant sonubuoy number for ASW a/c without sonubuoys. Though atypical for long range ASW, but the Naval EH.101 Merlin comes to mind without buoys and with range that might just be enough to be useful in this role.
4. Player control over the ASW patrol behavior
   1. To keep it within budget I propose to accept that all patrols, which have only ASW loadout a/cs in them, patrol as this.
   2. If the player prefers to have an old style patrol, e.g. one which just loiters to be available to assist to investigate contact's of others with full supply of sonubuoys he can select a non ASW loadout (many maritime patrol a/c have Standoff or Guided loadout with full complement of torpedos and buoys) or group one ASW with a non ASW a/c. Admittedly a compromise but we have a budget.
   3. Should the budget allow it, add a "Lay a pattern" checkbox to the patrol launch window for ASW loadouts.
5. Once we have this in place, it is important to keep on dreaming how to make an optimal implementation, incorporating all the great ideas and breadth of knowledge collected in this topic!

[TonyE]

Don't forget the groundwork donaldseadog has been establishing with http://harpgamer.com/harpforum/index.php?/files/file/809-toolbox/ . Source code at https://tarzan.tgp.net:8443/svn/StratsimsOSS/HC/ExportDLLs/lazGUI/branches/ToolBox/ (to someday be moved into a more sane location). IDE and such is http://harpgamer.com/harpforum/index.php?/files/file/763-codetyphon-lazarus-programming-tool/

 

Any intrepid programmer can help make it happen, I've been exposing the guts of the game as time permits and with the limited interface so far Don has added an initial ASW patrol pattern.

[donaldseadog]

It stumbles with lack of bouy drops or dipping sonar but if your aircraft is MAD equipped I've gotten some OK results.

The IDE is pretty easy to use saying that as someone who hasn't produced code for >30 years and has forgotten the little I knew.

There is lots of scope for getting this nailed I think.

...and with more experienced people at it I think Tony might find more time to add to the exportDLL capability

[TonyE]

There is lots of scope for getting this nailed I think.

...and with more experienced people at it I think Tony might find more time to add to the exportDLL capability

Don, you've done better than I could have imagined when we started. Once I get this work project out the door I should have slightly more time (eta end of July). More people using the ExportDLL capability would certainly be good though for building libraries of functions and for introducing object-oriented concepts to hide the ugly pointers and linked lists and such.

[Grumble]

Don, I was to learn from your code how to drop sonubuoys, but they don't do that with the Toolbox patrol, right? So the a/c flies the ExportDLL plotted route and MAD might detect subs, but sonubuoy dropping is not implemented yet, yes?
Just checking I'm not overlooking something.

It stumbles with lack of bouy drops or dipping sonar but if your aircraft is MAD equipped I've gotten some OK results.

Ideally we could emulate the drop-buoy event, just as if the player would hit '.'
or, somewhat cumbersome, but it is possible to plot a course which drops a buoy at the end of each leg, if you add both a loiter and a cruise order for the waypoints.
However for this we would need to create pathEvents, which is only a stub Pointer in THCPathRec,
only the comment tells that it would be a HarpoonEventPtr, but that Type is not included with the TypeDefs we have for ExportDLL.

Tony,
is this possible to access HarpoonEvents from the DLL?
In general would of course be the best but for ASW a purpose-built drop-buoy/turn on dipping sonar trigger or being able to add stop&go pathEvents could be a serviceable solution.
Or any other way to drop buoys from the DLL?

[TonyE]

Grumble, you aren't overlooking anything yet. I'm tentatively planning most of my Harpoon time the next few weeks to go towards the ExportDLL interface so some of these capabilities will start cropping up.

 

See also http://harpgamer.com/harpforum/index.php?/topic/20881-exportdll-interface-task-list/

[Grumble]

Wonderful, thanks.

[digitalman]

Lots of great ideas here. It looks like the game has many limitations when compared to real life sub hunting.

 

I can accept that this is a game and when conducting short range sub search missions I am happy to use the formation editor as the aircraft will quite happily fly round and drop sonar buoys as long as the fuel and stores remain.

 

However, on long range missions the limitations of manually inputting a search pattern but only having to rely on a MAD contact are frustrating.

 

Would it not be possible just to either 1 extend the formation editor boundaries, not ideal as very long range areas would be massive but the asset would fly randomly round and drop buoys and also have the MAD contact possibility or 2 to have a button to drop the sonar buoys in a stick, say 1 per minute, which for an aircraft travelling at 300mph would leave a space of about 5 miles between each buoy.

 

With option 2 you could then detach an ASW asset away to a distant point, manually allocate a search area using the regular set course, set the speed and height of the asset and then click drop stick, you could possibly manually adjust the number of buoys in a stick, say from a minimum of 5 to a maximum of 15.

 

Just my thoughts on enhancing the game without trying to be too technical.