#1110 --FOV doesn't always override preferences.xml and aircraft-set.xml values

[Anonymous]

Originally created by: nmac... (code.google.com)@iburst.co.za
Originally owned by: NasalMusician

*What steps will reproduce the problem?*
1. Set prop:--FOV= any arbitrary value
2. Run FG
3.

*What is the expected output? What do you see instead?*
Should be --FOV value. Depends on Compensate for widescreens is on or off whether it works.

*Any output in the console (black window)?*
No

*What FlightGear version are you using (when using GIT version, please
mention date)?*
Any version after Compensate... was implemented.
*What operating system and graphics card?*

*Please provide any additional information below or as attachment (Avoid
expiring external links, such as to imageshack/pastebin/...).*
See topic http://flightgear.org/forums/viewtopic.php?f=25&t=19851&p=182654#p182654

[Anonymous]

Originally posted by: gijsrooy

(No comment was entered for this change.)

Labels: Nasal
Cc: alexis.b...@gmail.com
Status: Accepted

[Anonymous]

Originally posted by: nmac... (code.google.com)@iburst.co.za

Using --fov set to a value starts up FG with that FOV in the cockpit. However, it doesn't set default-field-of-view-deg, so resetting the view goes back to the defaults.

That is the core of the problem: default-field-of-view-deg. This is also not set by preferences.xml and aircraft-set.xml. See Issue 1111.

[Anonymous]

Originally posted by: NasalMusician

​​Regarding comment #2: What is the real issue here​? I *think* that --fov just sets the current fov for the default/cockpit view? (I haven't used it and can't look into it right now.) I don't even think that it should be supported anymore if it does that. (A test for that: without widescreen compensation and with --fov=something, does view.resetView() change the FOV? If it does, that proves my point: it doesn't actually become a persistent setting, which I don't think is desired behavior.)

Another question, regarding the original post​​​: wouldn't we rather have widescreen compensation off with --fov= anyways? It will end up screwing up the actual FOV.

I have a merge request which fixes the compensation functionality to use /sim/view[n]/default-field-of-view-deg instead of the previous assumption of 55º. It also keeps "on top" of the current FOV's assumed aspect ratio, i.e. switching compensation on/off will immediately change the FOV. Will this at least help the issue here?

If Alexis is watching (and for others who might know): my merge request FGDATA #225 fixes a lot of features, but I need to know whether the compensation function (view.screenWidthCompens.calcNewFov) is correct enough. It mathematically fits the requirements (I have identities I need for scaling the current FOV properly) and it makes sense to me, matching the original description ("keeps an equivalent 4:3 zone centered on the screen"), but it yields slightly different numbers versus the old version. Is there a rationale for the old one's algorithm? (If I don't get a response I will go ahead and commit it.)

Owner: NasalMusician
Status: Dev

[Anonymous]

Originally posted by: alexis.b... (code.google.com)@gmail.com

No problem with me, the original proposal wasn't meant to be perfect.
ATM, I haven't the possibility to review your changes, lake of time... So feel free to commit them. I hope I'll could check them latter when I'll have a running setup.
Thx a lot.

[Anonymous]

Originally posted by: NasalMusician

Thanks, Alexis! I pushed that merge request, see https://gitorious.org/fg/fgdata/commit/f8286ddcea2350e70aabc8d62d575b0a762976c3

[Anonymous]

Originally posted by: gijsrooy

(No comment was entered for this change.)

Labels: Milestone-3.0
Status: Fixed