Changing jammers to use effective and falloff radius and simple jamming support for ACRE2

[Crowdedlight]

This PR includes:

• simple support for jamming ACRE2 radio comms (#39)
• Changing jammers to use effective and falloff radius in an effort to be easier to manage for mission-designers/Zeus.

The new jammer radius has the goal of setting an effective radius, where the jam will be 100% as soon as you are inside it. And a falloff radius, which will be the distance from effective_radius and out. In the falloff radius, the jamming will go from 100% to 0% jamming with a linear function. This should make it easier to design when you want 100% jamming and when you just want to see a linear effect/increase.

The markers for zeus has the falloff as yellow when activated, and the effective radius as transparent red.

TODO

• [x] Test on dedicated server for TFAR and ACRE2
• [x] Test on hosted MP TFAR
• [x] Test on hosted MP ACRE
• [x] Update wiki with this change and graphic of how the radius works.
• [x] Test both markers updates when jammer moves
• [x] Test drone AI jam behaviour on dedicated
• [x] Test player noise and jam dc on dedicated
• [x] Final code-review for myself to ensure no odd changes got into it

This PR is a blocker for #80.

[Crowdedlight]

@b-mayr-1984 Do you see any issues with this change to effective and falloff radius for the jammer setting and your usecase?

[b-mayr-1984]

@b-mayr-1984 Do you see any issues with this change to effective and falloff radius for the jammer setting and your usecase?

Well you know that I always sing the song of realism but I guess there are virtually no players out there that wouldn't prefer your easy to explain, easy to understand approach over realism. 😅

But then I recommend that you change the interpolation of the film grain _sharpness as well to fit your new logic. You then don't need to consider the distance between drone and pilot anymore (#sadsimulationistsounds) if it is all dependent on radii.

[Crowdedlight]

But then I recommend that you change the interpolation of the film grain _sharpness as well to fit your new logic. You then don't need to consider the distance between drone and pilot anymore (#sadsimulationistsounds) if it is all dependent on radii.

Wouldn't the grain still work with this? The only difference being that the distance2killzone, would be distance minus effective radius. So you take the distance to the effective radius, as that is your new kill-radius border.

private _distDrone2killRadius = _distDroneToJammer - _radEffective;
private _distDrone2pilot = _drone distance player;
private _sharpness = [0, 4, _distDrone2killRadius/_distDrone2pilot] call BIS_fnc_lerp;

That would still give you 100% jammed inside the the kill-radius (effective radius). I assume the problem would be that you would still see some noise if you are outside the falloff zone, depending on how far the drone are from effective radius, compared to player?

Might be able to keep that _distDrone2killRadius/_distDrone2pilot relationship but adding a check that says if drone is outside _radEffective + _radFalloff range, then it doesn't apply any noise. But as soon as within the falloff radius, it uses that calculation for noise?
Not completely the same though.

[b-mayr-1984]

That would still give you 100% jammed inside the the kill-radius (effective radius). I assume the problem would be that you would still see some noise if you are outside the falloff zone, depending on how far the drone are from effective radius, compared to player?

Correct

Might be able to keep that _distDrone2killRadius/_distDrone2pilot relationship but adding a check that says if drone is outside _radEffective + _radFalloff range, then it doesn't apply any noise. But as soon as within the falloff radius, it uses that calculation for noise? Not completely the same though.

I don't recommend to do that, because it would introduce a special case for drone jamming, thus making your mod less consistent.

The distance ratio between any type of jammer and any type of Receiver-Transmitter-link is always a factor in the real world. Not just for drone jammers.

If your intention is to clean that up and make it easier to predict I recommend to do it for all jammers (incl. drone jammer that shouldn't have its special case) In case you want to keep the logic with the drone pilot somehow IMHO also the other jammers should take the distance between Tx and Rx into account.

[Crowdedlight]

I don't recommend to do that, because it would introduce a special case for drone jamming, thus making your mod less consistent.

The distance ratio between any type of jammer and any type of Receiver-Transmitter-link is always a factor in the real world. Not just for drone jammers.

If your intention is to clean that up and make it easier to predict I recommend to do it for all jammers (incl. drone jammer that shouldn't have its special case) In case you want to keep the logic with the drone pilot somehow IMHO also the other jammers should take the distance between Tx and Rx into account.

That is a good point. My intention was indeed to try and clean it up as the current implementation, for radios especially, is hard to use as the "strength" is kinda arbitrary and figuring out when a player would get completely jammed was inconsistent.

Although the implementation in this PR would at times also have short-range be jammed before reaching the center of the circle, as I only have one dial to turn in TFAR, which covers both SR and LR radios.

I don't seem to have any way to get whoever is the sender of a radio message, so it would be hard to take into account the distance from sender to receiver when calculating the jamming. Which is kinda annoying as it could have been nice to be able to have less jamming effect for people standing 10m from each other inside the jammer-radius, then people outside trying to communicate into the jammed area.

I will follow your recommendation for consistency. If it's possible to get the recipient for radio messages in the future I am not against changing calculations to also take distance from the recipient into account.

[Crowdedlight]

Note to self. Implemented handling to support jammer spectrum signals for both drone and radio jammer. Will sweep the entire spectrum of the type, and thus show a sweep in jammer frequency, and a sweep in entire radio comms frequency span if both is enabled.

However activating that causes following issues:

1. due to the big increase in frequency span going from 7 to 359, even at incrementSpeed of 50, it still "felt too slow". Although might be fine.
2. Multiple signals on same object makes the zeus text be on top of each other and be impossible to read. Ideally you would want them spaced apart, or aggregated so its a single line showing array of "signal types" too.

Tracking future updates that could solve this in #83

For now and this PR, the code is commented out and both radio and drone jammers will show the sweep on the 433-440 frequency span.