Add Uri´s HOUND to ATRM - enabling enhanched SEAD TTPs

[hbjonsson]

Hound system triangulates positions of radars. It does this by taking bearing readings at set times, while recording the platform position. using these plotted data points system can estimate the position. the more points you have, with greater intersection angles between them, there is a better chance of estimating the position correctly.

Further Information about the script is here: https://github.com/uriba107/DCS-Hound/blob/main/README.MD

it is compatible with all the frameworks we use.

I believe introducing this would have minimal impact on ATRM. There are various options available for tweaking but for now I would suggest suppressing text readouts and using SRS SimpleTextToSpeech ( provided with SRS ).

I propose adding two flying ELINT platforms that are intialized on demand via the AWACS+TANKERS menu called AWACS Tankers & ELINT. Accessing this menu will enable the user to spawn one or two ELINT platforms - SCULLY on 310.00 AM and VACUUM on 315.00 AM. They utilize the NATO Lowdown format in the form of a rolling atis, and then provide a 5-line to the desired SAM on demand. Utilizing Hound we could further enhance our SEAD TTPs with support of real world ELINT assets that would most likely be operating with SEAD/DEAD platforms, e.g. RC-135 Rivet Joint or EC-130 Compass Calls.

The units follow the same logic as our AWACS platforms and RTB when low on fuel.

I believe using these in ATRM would be a stepping stone to utilizing these assets in future ops as well as paving the way for custom developments we may wish for by the developer of this system.

I have created a test mission on the server called ATRM_2.7.0.425_Jester_hound_01.dev.miz which works as intended and can generate a PR as required.

[132nd-Professor]

Excellent initiative! This will surely help advancing our SEAD and DEAD capabilities further.

I have a couple of questions:

• which range do you have in mind for this feature?
• will this make use of existing SEAD taskings or will this require new scenarios?
• I agree on suppressing the text readouts.
• if the TTS system is the same as for the ATIS, and uses the Google API, @MartinCo will likely see some increased costs, since we use his API token for billing. (He was so kind to support us here) We should make sure the costs do not go through the roof unexpectedly.
• Since you based your commits on HEAD, I think it would be good to run the next training off of your dev version. As you said, this should integrate nicely with MOOSE and the other scripts, yet I think some test for unexpected side effects would be good before merging a PR.

[hbjonsson]

Thank you.

Which range: Had planned to have them support the MOA4/R12 complex IVO AWACS track by MOA2. Currently the system does not support limiting the scope of ELINT sniffing to a specific AOR but the developer plans on adding this feature. So anything that the platforms detect, will be reported, as well as shown in an ellipse on the map by way of markers, this can be disabled if needed. The platforms can easily be moved around as needed on a mission by mission basis ( i.e. think like relocating tankers ).

Existing SEAD: No impact to any scenarios and does not require new scenarios. This is a pure "information service". However it could affect scenarios which rely on a trainee being completely in the dark about certain SAMs, in which case it might be wise to simply not activate the platforms ( like you would when you do not want AWACS coverage for example). However I foresee that there may be a situation where one scenario is being driven somewhere else - utilizing the hounds, and thus affecting another scenario elsewhere where people want to be in the dark - in such a case I´d recommend we turn of the markers, thus the only way to get intel you would not otherwise have is to tune into their frequency and listen.

Good point on the TTS system - it uses SRS SimpleTextToSpeech - @martinco provided the API credentials. It is working but I have no way of monitoring costs or scoping the potential impact. I trust that @martinco has means of keeping an eye on this? The lowdown is basically a rolling "atis" but with SAM info. For ATRM there is only one "ATIS" frequency planned. The other frequency is a SEAD controller who gives a warning and/or a 5-line on request - not a rolling atis format.

Concur on a training-night "test - this seems logical :-)

[132nd-Professor]

o anything that the platforms detect, will be reported, as well as shown in an ellipse on the map by way of markers, this can be disabled if needed.

I see how that would be useful in some scenarios, yet possibly intrusive in others. I would recommend disabling this by default, so that other flights are not disturbed more than necessary. (I think of 2FLUGs with hidden SAMs, where you really do not want to give away the surprise).

Then I do not see any further issues. I will try to give a quick look at the code when I can, but can't promise right now that I will get to it soon.

Thanks for your work, Jester!

[132nd-Professor]

Once the PR is merged, please update the briefing page accordingly.

[hbjonsson]

Roger wilco @132nd-Professor - i´ll make neccesery changes so that markers are initially disabled before making a PR. They can be re-enabled via F10 menu in later iterations. Thanks for the prompt responses and review.

[132nd-Entropy]

can this be closed?