Radios - Add a separate "signalModelLR" setting for "Long Range" radios

[mrschick]

When merged this pull request will:

• Add an additional signalModelLR setting to calculate propagation of "Long Range" Radios.

To-Do before completing the PR:

• Add the new setting and verify that the new signal calculation works;
• Allow the user to select which antennas count as "long range";
• Remove any debug outputs that are not flag-dependent;
• Document new feature;

Explanation:

I love LOS-Multipath, it's awesome to have to think about one's own positioning in the environment down to a scale of <10 meters in order to guarantee proper comms quality, it really makes playing as the radio operator even more fun.

However, when mission design requires operating on different sides of highly signal-blocking terrain, i.e: Stratis or other mountainous maps, without the presence of relaying elements, then LOS propagation models can sometimes become too much of a hassle to use.
For that reason my unit has defaulted to the Arcade signal model in order to not incur such issues when avoiding them is not possible.

As a solution, I propose the addition of a new signalModelLR setting, which can be set to a different model than the current signalModel setting and applies only to transmissions sent from radios connected to a "Long Range" antenna.
For now "Long Range" Antennas are defined in arrays with local scope within addons/sys_signal/fnc_getSignalCore.sqf, and include the following:

• Backpack Radio (PRC-77/117F, SEM70) Antennas;
• Vehicle Antennas (PRC-152 mounted to a rack will become "long range");
• Ground Spike Antennas (PRC-152 mounted to a GS with and without mast will become "long range");

This feature will allow users more freedom of mission design without having to resort to the Arcade propagation model on all radios.
For example by setting signalModel to LOS-Simple and signalModelLR to Arcade, requiring proper positioning and unit cohesion to maintain squad-level comms in hilly terrain, while allowing for terrain-independent communications on and to higher levels of command if LR-Antennas are available.

[jonpas]

We have discussed this PR internally a little bit, and we do not feel like this belongs in ACRE2. We are simulating radios to a higher degree of faithfulness where there is no "long range" or "short range". It's all physics. Arcade mode is as far as were willing to go to make ACRE2 useful in more casual communities. This however intermixes two signal models making an inconsistent environment and detracting from the overall goal of ACRE2.

In other words, this fits more in a mod or framework extending ACRE2. Signal modification can be used to accomplish this while retaining the default signal functionality where wanted.

Of course, if any additional API is required to perform anything, we are always open to add that.

[mrschick]

I understand that the arbitrary classification of some antennas as "long range" is not realistic, since they all transmit on "LOS" frequencies. But don't see how this change would be a net-loss of realism worse than what Arcade or custom signal processing already permit (with the latter taking considerably more effort to set up than just tweaking some CBA settings).

On the contrary, I think that it would cause more people to readily switch from using the arcade model on all radios, to a LOS model on most radios while just enabling arcade on some radios for gameplay reasons. Resulting in a net-increase of realism over their previous situation.

It also shouldn't change anything for those who want to keep using realistic LOS models on all radios (which is the intended default for signalModelLR).

[mrschick]

If your decision is final feel free to close this PR.
We will continue to develop this feature and use it internally in our fork 👍🏻

[jonpas]

Yeah, I believe the decision is final, as in we don't want this distinguishment in ACRE itself. Of course we have nothing against an external modification or fork doing this.

We would however be open to extending the signal API in some way that would make this easier to do on your side, potentially without a full fork (although you can already do that with a copy of getSignalCore function). Maybe some form of "set signal model override" function.

[jonpas]

If any API is wanted or thought of, best to open a new issue.