Freq axis slightly broken after zooming in

[b-mayr-1984]

When searching the spectrum one can zoom in to the highlighted frequency range using the middle mouse button.

The result is a higher spectral resolution.

Once being in the zoomed in state the mouse-wheel-up and -down actions are restricted to move the higlighted spectral range only within the shown boundaries of the spectrum analyzer display.

So far so good.

When one takes control of a drone turret, whilst being in this zoomed in state, the boundaries for the mouse-wheel-up and -down actions are then a bit broken.

The screenshot below shows the highest frequency I was allowed to select when being in the broken state.

Reseting the frequency axis of the spectrum analyzer with Shift+middle mouse button works as a workaround though.
So I consider this just a minor issue.

[b-mayr-1984]

Additional info:

I get the same buggy state if I zoom in twice with middle mouse button (and don't do anything with the drone at all).

This leads me to believe that the problem in connection with the drone turret might lead into the same exact same error state because for this I also use the middle mouse button to navigate the vanilla action menu.

[Crowdedlight]

As I recall this is a bug with the view and zooming in. As each zoom changes the axis limit. So if you zoom too far in you hit an area where you indeed can't scroll over to view as it fails to stretch the current view to the entire screen.

I can't remember the specifics of it exactly, but I remember I tested that bug and didn't have a good way to solve it. As it only happened if you zoomed multiple times in. I decided to leave it in as you had the keybind to reset the view.
It might be a limitation of the spectrum screen view, and how much I am trying to scale the axis.

[Crowdedlight]

Would it happen in practice? Not sure how much you would click the middle mouse button when in screen view, as you are kinda locked to the screen at that point and dealing with that one.

If you have any good ideas for solving it or working around it, feel free to post them :)

[b-mayr-1984]

Would it happen in practice?

Dependent on the amount of jammable drones being used it happens rather quickly. Here I had just 4x such drones.
With the randomly assigned RC frequencies I had 2x of them overlapping (see the slightly wider spectral peak in the screenshot below).

After zooming in the cause for the wider bandwidth occupation was clear. It was actually 2x different drone signals.

In my game mode there are even more drones being used simultaneously. So zooming in can be necessary quite often.

Not sure how much you would click the middle mouse button when in screen view, as you are kinda locked to the screen at that point and dealing with that one.

As you have shown in your Youtube videos one can zoom back out to factory default using Shift+middle mouse button which also works as a workaround for the problem.

If you have any good ideas for solving it or working around it, feel free to post them :)

A workaround I have stated above. I will let you know if I find a fix though. 🙂

[b-mayr-1984]

I just realized that one does not even need to zoom in twice.

A single zoom in is enough to get the inconsistent behaviour.

1. default zoom level (2x transmitters are in the selected range)
   
2. after 1x zoom in event the selected area is inconsistent with the max frequency of the x-axis.
   

When I do further testing with an antenna that has a wider frequency range the problem does not show in the first few zoom levels but only later.
Because of this and from further testing I currently suspect that the problem is a rounding bug somewhere in BI code and has nothing to do with your mod.

[b-mayr-1984]

When I do further testing with an antenna that has a wider frequency range the problem does not show in the first few zoom levels but only later. Because of this and from further testing I currently suspect that the problem is a rounding bug somewhere in BI code and has nothing to do with your mod.

I wrote a ticket for this in BI's feedback tracker:
https://feedback.bistudio.com/T178445

For the time being I think we can only:
a) wait until BI fixes it (can take years for some tickets 😅)
b) prevent the crowsEW from ever needing to zoom in to a sub-MHz frequency range (e.g. by preventing the frequency randomizer from putting signals so close to each other)

[Crowdedlight]

Good catch and good point. I know Dedman and others are still working and dealing with A3 stuff. But unsure if something like this would have any kind of prioritization as you say.

I think it would probably be a good way of handling it to force an offset between existing signals. Something like picking a random frequency within scope, checking distance to nearest, move in the opposite direction until offset away.

I'll have a look at including that in the next update. Need to finish the 3D model I made for Landrics PR so that can get merged in too.