Spectrum signals can be seen outside their set range

[Crowdedlight]

Due to how we calculate signal strength, and not checking if outside max range of the signal-source, then we always get some base strength even when outside the range, due to the high weight we give direction versus range.

signal source 5km away, with signal set to 3km range.

But can still be picked up by player 5km away.

This could also be part of why we found it hard to figure out how far away enemies were in the last event @b-mayr-1984 It would have been rather unreliable in judging distance, but good at judging direction.

I believe a fix would be to not show any signals that is outside the signal range, just skip those. But might also want to slightly adjust the function to lower the weight slightly for direction, so its easier to judge range?

[b-mayr-1984]

@Crowdedlight so far I wasn't exactly sure what your intended behavior is.

If it was up to me I would probably treat both direction and distance as 2 parameters that each scale the displayed level between 0% and 100%.

Meaning the range of the signal determines the falloff via distance. At 0m distance you get 100% as contributing factor. At distance==range you get 0%.

Same contribution behavior then for direction. The vector difference is always between 0 and 2. https://github.com/Crowdedlight/Crows-Electronic-Warfare/blob/main/addons/spectrum/functions/fnc_calcSignalStrength.sqf#L21

One can just map these to 100% and 0% contributing factor.

That would make for consistent behavior IMHO.

[Crowdedlight]

Yeah, was thinking towards the same lines. Originally I had higher weight on direction to ensure you could still direction find, even if you were 5m away from it. But the way I originally made it is a bit of a round-about calculation.

Will probably test out having range and direction contribute as you describe. might have to make it be 50% each, so being right next to it still allows to direction-find, with combined being max of 100%.

[b-mayr-1984]

might have to make it be 50% each, so being right next to it still allows to direction-find, with combined being max of 100%.

Sounds to me you are thinking of 2x contributing values that you then add up.

I had 2x factors in mind (that are between 0 and 1) which are simply multiplied together (then still between 0 and 1). This does also allow for DFing at all times (but also homing in at all constellations). The resulting factor is finally multiplied with the transmitters maximum possible signal level.

[Crowdedlight]

@b-mayr-1984 If you got a moment at some point, could you give a bit of feedback on this. I tried to implement it, and it seems to work alright.

distance and direction factor is calculated between 0 and 1, and then combined with:

// the -100 is required as it has to return `-100` for minimum strength, and `0` for maximum strength. (It is in dBm)
private _sigStrength = -100 + (100 * _distStrength * _dirStrength);

Although it means that if you stand right next to the signal, but look directly opposite of the source, you will see no signal, as the direction factor is 0, thus pulling the distance factor to 0. While even if you have a fairly directional antenna, if you are standing right next to the signal, you should probably see at least a little indication. (And even if you don't irl, you probably should in-game)

The current code is on the calc_sigs branch: https://github.com/Crowdedlight/Crows-Electronic-Warfare/tree/calc_sigs

[b-mayr-1984]

@Crowdedlight the formula looks correct to me. It is exactly in line with my comment in https://github.com/Crowdedlight/Crows-Electronic-Warfare/issues/92#issuecomment-2130907704 .

Dependent on the directional behavior of _dirStrength the Null angle at the rear might only be very very narrow. In combination with players likely moving the antenna around I don't see a problem in practice.

[Crowdedlight]

Videos I had trouble attaching in the other post.

https://github.com/user-attachments/assets/edd878ee-742f-41f4-ba0b-db6520c02bbc

https://github.com/user-attachments/assets/f7e0926b-0d1b-4ecc-a22f-cafb7e82d9b3

[Crowdedlight]

@Crowdedlight the formula looks correct to me. It is exactly in line with my comment in #92 (comment) .

Dependent on the directional behavior of _dirStrength the Null angle at the rear might only be very very narrow. In combination with players likely moving the antenna around I don't see a problem in practice.

Hmm, that is true. Although I am considering if I should cap the dir factor at 0.1 instead of 0. So there would always be a bit of signal if you are within the distance factor.

[b-mayr-1984]

Although I am considering if I should cap the dir factor at 0.1 instead of 0. So there would always be a bit of signal if you are within the distance factor.

Sounds good to me. Is also close to real antennas where there is most often a considerable back lobe.

[b-mayr-1984]

2024-10-19_17-20-47_1_1.mp4

Yeah this second video does not appear to show behavior that closely resembles reality.

The null is too wide and attenuation too perfect.

[Crowdedlight]

Jup. going to play around with the lower bounds of direction factor. Will try to play around with it and see if I can get it to a better state

[Crowdedlight]

With capping the minimum direction effect at 0.15. Seems to work better. The "null" angle is still fairly high compared to typical backlopes. I believe that comes from how the difference in direction is calculated using the vector magnitude.

private _dirDiff = vectorMagnitude (_trackerFacingDir vectorDiff _dirTargetFromTracker);    // returns values between 0 and 2 (when input vectors are normalized, such as here)

I can honestly not remember why I did it like this, and I could maybe get a smaller null angle if I manually calculate the difference without normalizing it to 0-2 first, and then convert that to 0-1 range 😅 But not sure how much of a difference it would give in the feel of the direction finding.

https://github.com/user-attachments/assets/fb0cbf33-5e18-4f52-b98d-6e3886939b5e

[b-mayr-1984]

private _dirDiff = vectorMagnitude (_trackerFacingDir vectorDiff _dirTargetFromTracker);    // returns values between 0 and 2 (when input vectors are normalized, such as here)

I can honestly not remember why I did it like this,

Well you can't remember because it wasn't you that wrote this ☝️. 😄 That line is from one of my PRs.

and I could maybe get a smaller null angle if I manually calculate the difference without normalizing it to 0-2 first, and then convert that to 0-1 range 😅 But not sure how much of a difference it would give in the feel of the direction finding.

The 0-2 comes from the range of vector differences one can get in the unit circle (or unit sphere in our 3D case). The point in time when you do the normalisation will not effect the outcome.

If you want to tweak the behavior I think it is best to tweak the interpolation/mapping from 0-2 to the target range of 0 to -100.

Maybe check if putting BIS_fnc_easeOut (or one if its siblings) back in, will give you a better result than your change to linearConversion. https://github.com/Crowdedlight/Crows-Electronic-Warfare/blob/1bc91697ba3df59e83edcb1eb2e69054d0908f8a/addons/spectrum/functions/fnc_calcSignalStrength.sqf#L32

[Crowdedlight]

I can honestly not remember why I did it like this,

Well you can't remember because it wasn't you that wrote this ☝️. 😄 That line is from one of my PRs.

Now that shows how good my memory is. You are of course correct! :D

Will try to check out easeOut or one of the other non-linear options fit better. I think I need to look up their curves though, as I can not remember the difference between EaseOut/In, Belzier etc. which makes it hard to visualize the effect in my head 😅

[b-mayr-1984]

Will try to check out easeOut or one of the other non-linear options fit better. I think I need to look up their curves though, as I can not remember the difference between EaseOut/In, Belzier etc. which makes it hard to visualize the effect in my head 😅

I couldn't find curves.

The way I tinkered around with it, to choose something appropriate, was using the watch feature of the advanced developer tools to directly see the impact of different interpolation functions on the side of the screen. This gave me a feel for the curves.

[Crowdedlight]

Changed it to easeout. Felt slightly better than linear, although not the biggest difference. But this works fine for the purpose.