-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Spectrum signals can be seen outside their set range #92
Comments
@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. One can just map these to 100% and 0% contributing factor. That would make for consistent behavior IMHO. |
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%. |
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). |
@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 |
@Crowdedlight the formula looks correct to me. It is exactly in line with my comment in #92 (comment) . Dependent on the directional behavior of |
Videos I had trouble attaching in the other post. 2024-10-19_17-20-47_1.mp42024-10-19_17-20-47_1_1.mp4 |
Hmm, that is true. Although I am considering if I should cap the dir factor at |
Sounds good to me. Is also close to real antennas where there is most often a considerable back lobe. |
Yeah this second video does not appear to show behavior that closely resembles reality. The null is too wide and attenuation too perfect. |
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 |
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 😅 2024-10-20_00-57-36_1.mp4 |
Well you can't remember because it wasn't you that wrote this ☝️. 😄
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
|
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 😅 |
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. |
Changed it to easeout. Felt slightly better than linear, although not the biggest difference. But this works fine for the purpose. |
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?
The text was updated successfully, but these errors were encountered: