@Atlas
Hi Atlas. Look, it’s very simple; I change my hardware only when it becomes obsolete, or in any other way no more compliant with my needs, or broken; till now my monitor 5:4 made its way very well and with full satisfaction to me. Besides that, I do prefer an image or a page which develops vertically, more than I could like an image or a page which develops horizontally; not to say that the first resolutions with a 16:9 ratio had a lesser number of pixels on the screen than the classical corresponding resolution in the 5:4 format.

Bye!
The Fish

@Ferde
Hi Ferde, great news, thank you very much. Meanwhile I am preparing all the stuff that I need for a brand new installation of Debian (I’m going to use the release 12.8.0), so to have also a recent version of Wine; after that, I will try to install Falcon BMS following the instructions I received here in this discussion; unluckily, for me it is a matter of very long time because I do not have much spare time to spend on it.
But, tell me please: do you operate as root in your Linux? Or have you created a normal user without root privileges, using it also for Falcon BMS?

Bye, and…“thanks for all The_Fish”.

@Seifer
Everything is working without any new problem for me, in SP mode; I mean: the problems are exactly the same as before the update, very minimal.

Thanks.
The Fish

@Atze-0
Thank you very much for your quick answer, Atze-0; at this point, listening to what you are saying to me I’m beginning to suspect that the problem arises in the layout format of my monitor, I mean 5:4 ratio; probably with a different format, 16:9 for instance, the result could be better because of a better proportion of the characters composing the text. I will try to find someone who could lend me another monitor just to check and after that I will consider a new monitor purchase. I’ve already tried the different possibility for the visualization (windowed and windowed borderless), but apparently nothing changed.

But I am also wondering if there could be some kind of option, possibly on the command line of the launcher, or in some other way, to specify the ratio of the output, so that it is possible to adapt the proportions used in the UI of the simulator to the specific ratio and proportions of the monitor in use.

Anyway, if a resolution is listed among the possibile choices presented by the program, I think that the ratio implied in that resolution should also be managed correctly and automatically by the program itself in building the user interface, don’t you?

Thank you so much for your support, pilot; fly high and have fun as much as you can.
The Fish

@airtex2019
Thanks to you all, guys; at this point I am considering to buy a new monitor just to be able to employ a resolution of 1920x1080 and see what happens. I do not like that much this ratio, I mean 16:9, I do prefer 5:4 much more, instead; but evidently there is no choice, time arrived for me too to change my habits, at last…

All the best!
The Fish

@MaxWaldorf
Very dear Max Waldorf, I tried what you suggested to me, but the result was even worse than the problem I was looking for to resolve. If I keep set to 0 the parameter “ScaleUIMode”, what I obtain is that the dimensions of the UI are always the same, they do not change whatever value I choose for the parameter “ScaleUIFactor”, and these dimensions are so big that the UI goes far beyond the right (and a little far beyond the lower) borders of my screen, so I am only able to see its top-left part and, as I was saying, this happens no matter what is the value I choose for the parameter “ScaleUIFactor” (I tried a value of 1.0, a value of 1.5, a value of 0.8, a value of 0.5, a value of 0.3); even another problem arises: if I press ALT+ENTER the low border of the UI becomes visible, but the position of the clickable areas on the screen does not correspond anymore with the position of the voices of the UI menus, in fact it is necessary to click not over the voice of interest, but below it to activate it; besides that, the UI itself is anyway not well contained within screen limits.
If I put a value of 1 for the parameter “ScaleUIMode”, I can obtain some changes in the UI modifying the value of “ScaleUIFactor”, but not in its dimensions, only in the fact that the texts become more unreadable.

Here are some specific tests and results I obtained:

1. 1st case - exactly the same settings proposed by you: the UI become much bigger and go beyond the right and the low borders of the screen, becoming unusable. If I press ALT+ENTER the low border (only the low border, not the right, which remains far beyond the screen) become visible but there is no more alignement between the clickable areas of the menu and their corresponding graphic representation on the screen (it is necessary to click below the desired menu voice on the screen to obtain the corresponding action).
2. 2nd case - UIfactor = 1.0: exactly the same results as those in the 1st case. Also, the dimensions of the UI are the same as those in the 1st case.
3. 3rd case - UIfactor = 1.5: exactly the same results as those in the 1st case. Also, the dimensions of the UI are the same as those in the 1st case.
4. 4th case - UIfactor = 0.5: exactly the same results as those in the 1st case. Also, the dimensions of the UI are the same as those in the 1st case.
5. 5th case - UIfactor = 0.3: exactly the same results as those in the 1st case. Also, the dimensions of the UI are the same as those in the 1st case.

After these trials, I tried the same again, but posing a value 1 in the option “ScaleUIMode”; here the results:

1. 1st case - UIfactor = 1.0: the result is an UI with exactly the same dimensions as it had in its default, i.e. before I started to try to solve the problem of unreadable texts; thus, it is completely and well contained on the screen, but the text become even worse and more unreadable.
2. 2nd case - UIfactor = 1.5: exactly the same results as those in the 1st case. Also, no variations in the dimensions of the UI.
3. 3rd case - UIfactor = 0.5: exactly the same results as those in the 1st case. Also, no variations in the dimensions of the UI.
4. 4th case - UIfactor = 0.3: exactly the same results as those in the 1st case. Also, no variations in the dimensions of the UI.
5. 5th case - UIfactor = 0.8: exactly the same results as those in the 1st case. Also, no variations in the dimensions of the UI.

So, sic stantibus rebus, I will be obliged not to move beyond version 4.37, sadly.

Just another thought about the idea (good, indeed) of using a scale factor to address possibile issues emerging with the UI in “your” future releases: I think that it could be more useful to provide two separate scaling factors, instead of only one: one factor for the width and one for the height; in this manner it will be possible to act independently on the two dimensions of the UI, solving issues about the ratio of the screen and of the graphic resolution.

As usual, a lot of thanks by me for you all, great guys!

The Fish

@Atlas
Hi Atlas, what you tell me about the TrackIR are exactly the reasons for I never decided to buy one, thank you so for giving me this confirmation. About VRs, instead, they are too expensive for me, simply…

On the rest, it is not a matter of positioning the SA bar, but of the fact that the SA bar is not a bar at all; I mean, it is simply a small and almost unreadable square with a kind of ADI which does not tell you anything effective on subjects like your position in the air, your attitude, your position towards the enemy’s one, and things like these; in the past this function was really useful because it was a kind of true lateral bar where a mark indicated continuously the direction of your sight and, thus, also of your enemy referred to the nose and the HUD of your jet.
I will try to make some practice to see if I will become proficient in using the new SA bar as I was with the old one, but it is not very easy…

Bye.
The Fish.

@Atlas
I Atlas, here I am again. I tried at last a monitor 16:9 with a resolution of 1920x1080; well, obviously better, no doubt, but I continue to prefer a 5:4 ratio. Anyway, all the problems with the readability of the UI texts are completely solved at a resolution of 1920x1080, as Max Waldorf said.

All the best, always.
The Fish.

@airtex2019
Very quick answer, great! Maybe, it could be a good idea to give the SA Bar two indipendent indicators for the double engines airplanes, 'cause on those planes it is possible to manage every single engine indipendently.
Thanks, as ever.

@Seifer
Everything is working without any new problem for me, in SP mode; I mean: the problems are exactly the same as before the update, very minimal.

Thanks.
The Fish

Hi everybody,

is it correct that I do not find the F15E, but only the F15C to choose in the dogfight section of the main menu? And if so, where is it possible to try the F15E? Only in TE, or in campaign, maybe? Or only in certain theatres? I am using the standard one, i.e. the Korean Theatre.

Many thanks, as always.

Hi all,

is it only an impression of mine, or it could be true that the gunsight of the F/A18 used for dogfighting is much less precise than the one of the F16 and the one of the F15? And if so, could it be maybe because for the computation of the bullets trajectory the gun is wrongly consider in the same position as the one of the F16, instead of being considered in the central position of the nose of the plane slightly below the canopy, like it should be for the F/A18?

@airtex2019
Very quick answer, great! Maybe, it could be a good idea to give the SA Bar two indipendent indicators for the double engines airplanes, 'cause on those planes it is possible to manage every single engine indipendently.
Thanks, as ever.

Dear all, I am experimenting some minor problems using the SA Bar with planes different from the F16; when I use F18 or F15, the indicator line which should indicate the position of the throttle gives instead the position of the left rudder. Presently, I am using a joystick with throttle and one of the two analog lever of a separate gamepad for the rudder. Thank you in advance.

@Ferde
Hi Ferde, great news, thank you very much. Meanwhile I am preparing all the stuff that I need for a brand new installation of Debian (I’m going to use the release 12.8.0), so to have also a recent version of Wine; after that, I will try to install Falcon BMS following the instructions I received here in this discussion; unluckily, for me it is a matter of very long time because I do not have much spare time to spend on it.
But, tell me please: do you operate as root in your Linux? Or have you created a normal user without root privileges, using it also for Falcon BMS?

Bye, and…“thanks for all The_Fish”.

@airtex2019 said in FOV Problem upgrading from U4 to U5.:

@The_Fish Due to some internal code-changes to make VR and non-VR more aligned, the way FOV is calculated has changed.

You’ll just have to recalibrate to find a new suitable value. I don’t think it’s as big a diff as 80->120… iirc I went from 90 to 110. But ideal fov may vary depending on head position… maybe monitor aspect ratio, etc.

Add these lines to your Falcon BMS User.cfg … adjust to taste.

set g_fDefaultFOV 120.0
set g_fNarrowFOV 60.0 // for the ‘FOVToggle’ (Look Closer) callback

set g_fMinimumFOV 30.0
set g_fFOVIncrement 5.0
set g_fMaximumFOV 120.0

Thank you very much, Airtex, you have been really quick and effective, I’ll follow your suggestions.

The Fish.

Dear Sirs,

just to report a problem I found after having updated from U4 to U5 my installation of BMS 4.37. I use a FOV set to 80 degrees, I set it with the configuration tool Config.exe accessed via the dedicated icon in the launcher and everything was good before the upgrading, but after having applied the upgrade (I have done this from the launcher) the FOV presented to me inside the cockpit was narrower than before; entering the configuration tool as usual I saw that nothing was changed, the FOV was still 80 degrees, but in the game it was not like it appeared before; just to make some trial I set the FOV to 60 degrees and found again no differences in the FOV in the cockpit, no change at all, thus it looked like the FOV was sticky to 60 degrees, even if I set it to higher values. Going on with the trials, I liked to try values beyond 80 degrees, but I found that the configuration tool does not permit such values; having saw that, I searched my Falcon BMS directory tree to see if there was a file containing all the parameters managed by the configuration tool and I found it; inside it I have modified manually with an editor the value of the FOV, using a value of 120 degrees; with this value it seems to me that the FOV in the game turned to the aspect it had before the upgrading; well, I am not really sure that it is exactly the same because I have no way to make a real confrontation, but what I can say is that presently with 120 it is quite similar if not exactly the same as it was before with 80. But the question remains: why the value of 120 produces the same effects done before by a value of 80? And again, why now a value of 80 does not produce any change in respect of a value of 60 and I have to use a value of 120 to increase the FOV?

Many thanks and all the best.
The Fish

@tl67000
Thank you. It looks a little complex, but I will give it a try on a Debian.

Hi there, does anyone know if there is some possibilities to use Falcon BMS under Linux?

Thanks you very much!
The Fish