ciribob / DCS-SimpleRadioStandalone

An open source Stand alone Radio for DCS integrating with all clickable cockpits and FC3 Aircraft
GNU General Public License v3.0
471 stars 122 forks source link

Add "Both" to Secure Radio VID Switch #607

Closed dMARLAN closed 2 years ago

dMARLAN commented 2 years ago

@syn111 (Couldn't find you on Discord so posting it up here!)

Could I suggest that the middle position is changed to a "both" functionality? As in, both COMM 1 & COMM 2 would be secured? I think it would make more sense than having 2 switch positions secure COMM 1 and real world you would be able to secure both comms (by colonizing CPHR on the UFC on both radios)

Currently: W/B (Up Position) = COMM 2 Secure VID (Middle Position) = COMM 1 Secure OFF (Down Position) = COMM 1 Secure

Suggested: W/B (Up Position) = COMM 2 Secure VID (Middle Position) = COMM 1 Secure & COMM 2 Secure OFF (Down Position) = COMM 1 Secure

Thank you!

syn111 commented 2 years ago

The reason why I didn't implement that is because the real KY-58 cannot do both radios at the same time, if I'm not mistaken.

However, if @ciribob wants a "both radios" option I can send a pull request for that.

dMARLAN commented 2 years ago

I was under the impression both COMM can be encrypted, I talked about this with a real F18 pilot a long time ago, that said it was a long time ago and I absolutely could be misremembering. I'll see if I can ask him again although he has been incredibly busy lately and not around Discord much.

Do you have any source on it not being able to encrypt both? Purely curious, I'll try to look into it as well.

Alternatively, the VID (Middle Position) could be set to secure neither as normally you would colonize CPHR on the UFC to select what to secure, setting the KY58 on the right console doesn't secure your radio until CPHR is colonized on the UFC (so it would be set to C & ON and left there)

syn111 commented 2 years ago

Both COMM can simultaneously be encrypted with DCS, but in a legacy, pre-DCS, KY-58 simultaneous reception looks impossible (the E NFM has a little more info about this, and has a paragraph specifying that "DCS [...] allows COMM 1 and COMM 2 radios to simultaneously operate in cipher mode" followed shortly after by "[...] the KY-58 is shared between COMM 1 and COMM 2 as in earlier aircraft."

As we don't have the DCS associated options available in DCS (including different fill selection for each radio), I went bare KY-58.

Rewriting the code to allow either the middle position to select none, or to select both (despite of the above), is always an option. Lets wait to see what ciribob prefers and I can send a pull request for any of those.

ciribob commented 2 years ago

Sorry I dont quite follow - if the Hornet block modelled in DCS has support for both - very happy for it to be the case as you suggest @dMARLAN

If the block modelled ultimately just uses the KY58 - then only one should be selected as the KY58 can only handle one radio at a time

From what you've both said - it looks like both should be supported?

syn111 commented 2 years ago

Yes, both should be supported in the real hornet with DCS (as in Digital Communication System).

The only thing in ED's DCSW is that we don't have DCS implemented, so implementing the both option in the middle position would be limited to both COMM 1 and 2 using the same fill, and that fill would have to be set via the KY-58 panel.

If you are happy with those limitations I'll send you a pull request.

ciribob commented 2 years ago

Ah the fill is a good point - that limitation probably doesn't make it worth it?

I've personally not seen much use of encrypted comms - but guessing its more in large squadron events?

Due to the fill - I'd prefer to leave as is - but happy to be convinced otherwise

dMARLAN commented 2 years ago

In my personal opinion limited to a single fill wouldn't be a deal breaker. Since there's not really a huge functional reason to secure comm in DCS (except in the case of a human opposing force) and is primarily an extra fun roleplay effect, I don't see it as a big deal if the same fill is used for both radios.

Also, it just "feels" better to me if 2 switches aren't identical. As in setting: {COMM 2, anything_else, COMM 1} instead of {COMM 2, COMM 1, COMM 1}.

Since this is a workaround in the first place until ED lets us colonize CPHR it doesn't need to be totally accurate anyway right?

Just my thoughts anyway, not a huge deal in the first place. As far as I'm aware, in the real world COMM 2 would rarely be secured unless say, for example, talking to a JTAC. (If secure comms were desired MIDS would often be used instead) but COMM 1 would frequently be secured for AIC comms, so being able to secure both or not isn't a huge deal breaker either.

I'm extremely happy this workaround was created in the first place, fantastic job!

ciribob commented 2 years ago

Had a long think - i'd rather leave the behaviour as is. Up being radio 2, Down or Center being radio 1.

The reason is most users wont know about this switch (it being a non standard implementation) so the likelihood is they'll leave the switch centre, which will encrypt both.

Googling around or reading the manual wont necessarily say why both are encrypted so it makes the most sense if out of the box, its either one or the other, rather than both. If they cant find the switch, they wont be able to figure out why both are encrypted, and will probably end up blasting encrypted comms everywhere.

Having the same fill is a secondary issue - and I think that does weaken the case a bit further too.

Hope thats OK with you both! Thanks for the discussion and suggestions 👍