search

Crowdedlight / Crows-Electronic-Warfare

Arma 3 Mod that enables electronic warfare features such as Radio/Drone jamming and spectrum signal tracking
https://crowdedlight.github.io/Crows-Electronic-Warfare/
Other
17 stars 6 forks source link

fail to jam when another drone in range but far away #59

Closed b-mayr-1984 closed 3 months ago

b-mayr-1984 commented 5 months ago

The current implementation of the loopFreq forEach-loop in fnc_spectrumDeviceMouseDown.sqf can't currently handle multiple drone type signals (and probably neither other types) in the same selected frequency range simultaneously. (see https://github.com/Crowdedlight/Crows-Electronic-Warfare/blob/main/addons/spectrum/functions/fnc_spectrumDeviceMouseDown.sqf#L48-L129)

The reason is, that breakOut "loopFreq"; is called when the first beacon in the selected range is found. But the first beacon might not be the signal we see in the Spectrum Device.

This leads to frequent ERROR: Too weak Signal messages at the player side, that probably don't make sense to them. In the example below a drone that one directly stands in front of can't be jammed. image

When digging into the problem I found that loopFreq is probably exited because it found a drone that is >10km away and is thus a) not visible in the spectrum and b) below the threshold of -40 dBm for a signal that can be jammed (this leads to the ERROR: Too weak Signal messages).

Here is the output from { diag_log str _x } forEach crowsew_spectrum_beacons; at the time when I took the screenshot. It shows the likely problem.

 1:49:38 "[2c416ed2040# 1675100: uav_01_f.p3d,434.157,300,""drone""]"
 1:49:38 "[B UGV 1:1,435.898,300,""drone""]"
 1:49:38 "[2c4131c4080# 1675101: uav_01_f.p3d,435.42,300,""drone""]"   <<< this drone probably makes us leave loopFreq
 1:49:38 "[B UGV 2:1,438.106,300,""drone""]"
 1:49:38 "[2c416ed2040# 1675100: uav_01_f.p3d,434.319,300,""drone""]"
 1:49:38 "[B UGV 3:1,433.806,300,""drone""]"
 1:49:38 "[2c4131c4080# 1675101: uav_01_f.p3d,433.957,300,""drone""]"
 1:49:38 "[2c4ad06c080# 1675122: ugv_01_f.p3d,433.981,300,""drone""]"
 1:49:38 "[2c28d084080# 1675134: uav_01_f.p3d,438.07,300,""drone""]"
 1:49:38 "[2c2a823c080# 1675135: ugv_01_f.p3d,437.673,300,""drone""]"
 1:49:38 "[2c2bf3b6040# 1675136: uav_01_f.p3d,439.368,300,""drone""]"
 1:49:38 "[O UGV 1:1,439.494,300,""drone""]"
 1:49:38 "[O UGV 2:1,438.986,300,""drone""]"
 1:49:38 "[O UGV 3:1,434.017,300,""drone""]"
 1:49:38 "[O Alpha 4-2:2,436.328,300,""drone""]"
 1:49:38 "[O Alpha 4-3:2,435.37,300,""drone""]"   <<< this is the drone from the screenshot above
 1:49:38 "[O Alpha 4-4:2,439.912,300,""drone""]"
 1:49:38 "[O Alpha 4-5:2,438.627,300,""drone""]"
 1:49:38 "[O Alpha 4-6:2,435.733,300,""drone""]"
 1:49:38 "[O Bravo 1-1:2,435.213,300,""drone""]"
 1:49:38 "[O Bravo 1-2:2,433.444,300,""drone""]"
 1:49:38 "[O Bravo 1-3:2,437.609,300,""drone""]"

Suggested redesign:

b-mayr-1984 commented 4 months ago

I started to have a look at this.

Now I realize that the suggested redesign with being able to deal with multiple signals at once (e.g. jamming all of those) is not as easy as it sounds.

If the beacons in range are of different type then it gets really messy. Could be a wild mix of jamming, listening in TFAR comms and just radio chatter. I can't even tell what I want the defined behaviour to be then with the spawned function that heavily relys on _timeActive.

long story short

I don't recommend to enable effect on multiple signals simultaneously because it would require a) a decision on what shall happen then b) a considerable re-write of fnc_spectrumDeviceMouseDown.sqf

new recommendation

Search for the strongest signal in _frequencies and act on this strongest signal only. (as opposed to the current logic where the first match in the list wins)

This approach is considerably easier and leads to consistent behaviour for the players. If multiple signals overlap in frequency the players can select between those then by simply orienting the antenna to the different signals.

Still this approach falls short when one object is e.g. both a drone and a chatter object and if those beacons use the same frequency. Then the players would not be able to select by means of antenna orientation. (but that's quite an edge-case)

Crowdedlight commented 4 months ago

Still this approach falls short when one object is e.g. both a drone and a chatter object and if those beacons use the same frequency. Then the players would not be able to select by means of antenna orientation. (but that's quite an edge-case)

hmm. A possible way to deal with affecting multiple drones if signal is high enough, is to check if the jammer antenna is used, as then TFAR traffic wouldn't work etc. But that then limits us severely if/when new functionality is wanted for different types.

From a gameplay perspective, I think your suggestion of taking the strongest signal, instead of the first is the best one. Gives more consistent behaviour and it is easier for a player to expect the strongest signal to be active selection. Ideally the "zoom" function should help select frequency, but I do know that if they are right on top of each other, there is zoom issues.

b-mayr-1984 commented 4 months ago

Fixed in 1696854fbc7c2a593eddbf900848aac0f08da996.

  1. Previously mentioned forEach loop with scopeName "loopFreq" has been removed.
  2. It is now replaced with the search for the strongest signal (using BIS_fnc_sortBy and FUNC(calcSignalStrength)).
  3. Then instead of iterating in the loop we operate on the first member of _frequenciesSorted only.

Tested with both chatter and drone types of signals. image