[Flightgear-devel] Problems with fgjs on windows xp...
Has anyone had a problem with a missing file when trying to run the joystick config in windows? (I'm running FlightGear 1.0) It got a failed to open the template.xml file. While it is there in C:\Program Files\FlightGear\data\Input\Joysticks\ fgjs fails to find it. I got around this by creating this folder structure: C:\FlightGear\Input\Joysticks\ and placing the template.xml file there. I don't know if this issue has been brought up so I decided to let someone know? -Cainan - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] fg (plib branch) crashes, probably in groundnetwork.cxx
Hi, with the plib branch (actual cvs, source and data) fg crashed here from time to time. Now I have a new (faster) PC and fg crashes much more often. It seems, that the frame rate has influence on the crash rate. Compiled with debugging information and running in the debugger I got no crash, without debugging information I get the crashes. The debugger points to groundnetwork.cxx line 935. With the osg branch I get no crashes. Maik - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Asterisk-1.4 Debian packages? Where to find?
On Jan 2, 2008 3:01 PM, Holger Wirtz [EMAIL PROTECTED] wrote: I have upgraded Asterisk to version 1.4. The conferences should now have an auto-mute feature: onlay one (the first) person can speak. Looks like something is broken, we get call rejected for some frequencies, such as KOAK or KNID tower: Selected frequency: 127.200 Airport Oakland Metropolitan Intl (KOAK OAKLAND TWR at 127.200 MHz) is in range ( 3.3 km) Call rejected by remote Selected frequency: 120.150 Airport China Lake Naws (KNID TWR at 120.150 MHz) is in range ( 1.5 km) Call rejected by remote Can you please have a look at it? Thanks. -- Csaba/Jester - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] view options
Hi,
Maik Justus schrieb am 26.12.2007 20:38:
Hi Syd,
what's about an algorithm, which checks the ratio of the screen and sets
fow to 55 for 4:3 screens and 70 for 16:9 screens? (55 / 70 = (4/3) /
(16/9) )
Maik
P.S.:
for non-physicists:
(55 / 73,333 = (4/3) / (16/9) )
Meanwhile I have a new computer wit 16:9 screen and the same problem.
I've modified the calculation in viewer.cxx as mentioned above. Syd,
please check, if this would work for you. Then we can think about, how
to implement that in a clean way (maybe we need an FG_SCALING_HEIGHT
case?). The patch is for the osg-branch, but it works with the plib
branch, too (maybe some lines offset).
Maik
Index: viewer.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/viewer.cxx,v
retrieving revision 1.27
diff -u -p -r1.27 viewer.cxx
--- viewer.cxx 5 Nov 2007 22:19:39 - 1.27
+++ viewer.cxx 4 Jan 2008 19:54:11 -
@@ -640,15 +640,15 @@ FGViewer::get_h_fov()
{
switch (_scaling_type) {
case FG_SCALING_WIDTH: // h_fov == fov
- return _fov_deg;
+ return _fov_deg/_aspect_ratio/4*3;
case FG_SCALING_MAX:
if (_aspect_ratio 1.0) {
// h_fov == fov
- return _fov_deg;
+ return _fov_deg/_aspect_ratio/4*3;
} else {
// v_fov == fov
return
-atan(tan(_fov_deg/2 * SG_DEGREES_TO_RADIANS)
+atan(tan(_fov_deg/_aspect_ratio/4*3/2 * SG_DEGREES_TO_RADIANS)
/ (_aspect_ratio*_aspect_ratio_multiplier))
* SG_RADIANS_TO_DEGREES * 2;
}
@@ -666,19 +666,19 @@ FGViewer::get_v_fov()
switch (_scaling_type) {
case FG_SCALING_WIDTH: // h_fov == fov
return
-atan(tan(_fov_deg/2 * SG_DEGREES_TO_RADIANS)
+atan(tan(_fov_deg/_aspect_ratio/4*3/2 * SG_DEGREES_TO_RADIANS)
* (_aspect_ratio*_aspect_ratio_multiplier))
* SG_RADIANS_TO_DEGREES * 2;
case FG_SCALING_MAX:
if (_aspect_ratio 1.0) {
// h_fov == fov
return
-atan(tan(_fov_deg/2 * SG_DEGREES_TO_RADIANS)
+atan(tan(_fov_deg/_aspect_ratio/4*3/2 * SG_DEGREES_TO_RADIANS)
* (_aspect_ratio*_aspect_ratio_multiplier))
* SG_RADIANS_TO_DEGREES * 2;
} else {
// v_fov == fov
- return _fov_deg;
+ return _fov_deg/_aspect_ratio/4*3;
}
default:
assert(false);
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] view options
On Fri, 04 Jan 2008 21:01:15 +0100 Maik Justus [EMAIL PROTECTED] wrote: Hi, Maik Justus schrieb am 26.12.2007 20:38: Hi Syd, what's about an algorithm, which checks the ratio of the screen and sets fow to 55 for 4:3 screens and 70 for 16:9 screens? (55 / 70 = (4/3) / (16/9) ) Maik P.S.: for non-physicists: (55 / 73,333 = (4/3) / (16/9) ) Meanwhile I have a new computer wit 16:9 screen and the same problem. I've modified the calculation in viewer.cxx as mentioned above. Syd, please check, if this would work for you. Then we can think about, how to implement that in a clean way (maybe we need an FG_SCALING_HEIGHT case?). The patch is for the osg-branch, but it works with the plib branch, too (maybe some lines offset). Maik Hi Maik , I'll try it out after work ... Currently I've added --prop:/sim/current-view/field-of-view=70 to my fgfsrc file , and that works great but Ive noticed that the fov height changes when going from windowed to maximized window ... so yeah it would be nice to at least keep that the same But I better stay out of this , I tend to jinx things ;) Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] view options
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 How does this work with windowed mode (that I always use, as maximized window, still showing the 64 pixels high KDE taskbar at the bottom, and window edges). My monitor is 4:3, but the window isn't. Regards, Arvid Norlander Maik Justus wrote: Hi, Maik Justus schrieb am 26.12.2007 20:38: Hi Syd, what's about an algorithm, which checks the ratio of the screen and sets fow to 55 for 4:3 screens and 70 for 16:9 screens? (55 / 70 = (4/3) / (16/9) ) Maik P.S.: for non-physicists: (55 / 73,333 = (4/3) / (16/9) ) Meanwhile I have a new computer wit 16:9 screen and the same problem. I've modified the calculation in viewer.cxx as mentioned above. Syd, please check, if this would work for you. Then we can think about, how to implement that in a clean way (maybe we need an FG_SCALING_HEIGHT case?). The patch is for the osg-branch, but it works with the plib branch, too (maybe some lines offset). Maik -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHfpstWmK6ng/aMNkRCjUYAJ9I/h1lTEzVwsVkBfMc1YXJbDfW+wCZAbiE ff1ucoiecbrPDlqzMLErIng= =5D9E -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] view options
AnMaster wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 How does this work with windowed mode (that I always use, as maximized window, still showing the 64 pixels high KDE taskbar at the bottom, and window edges). My monitor is 4:3, but the window isn't. AnMaster, same problem here: I guess 55° is horizontal, when the ration changes, fgfs or wich evre subsys crops the images at the top and the botom so the horizontal field is still 55°. If I'm right, I would say that with generalized wide formats, we should keep the legacy fixed field (55° * 3:4) in the vertical axis and increase the field on the horizontal axis. Alexis - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] view options
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 My resoltion is 1400x1280, but you also have to consider window borders. Not sure how large they are, however the screenshots I took at www.flightgear.org (A10-KNID-01 for example), were in maximized window. Should be possible to calculate from that. Other than that I think Alex Bory's suggestion was very good. Regards, Arvid Norlander Maik Justus wrote: Hi, it takes into account the aspect ratio of the window. If it is 4:3 everything is unchanged. If it is larger (e.g. 1024:704) you will get a higher field of view. Maybe you can try the patch (or set fov to 55/(4/3)*(1024/704) = 60 in the property tree: /sim/current-view/field-of-view) and check, if it is noticeable, and if yes: if it is better or worse than the 55. (replace 1024 and 704=768-64 with your resolution) Maik -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHfq98WmK6ng/aMNkRCtS4AJ9GTpU7v/2DeBa/DlKtod72mtjwowCfVwHl tCl63sZB5A7zfgLyEuoGH+A= =ZuoK -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] view options
Hi Arvid, AnMaster schrieb am 04.01.2008 23:13: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 My resoltion is 1400x1280, not 4:3 nor 16:9 ? but you also have to consider window borders. Not sure how large they are, however the screenshots I took at www.flightgear.org (A10-KNID-01 for example), were in maximized window. Should be possible to calculate from that. I think the borders have only very small effect to the calculation. Just try a fov of 47.5 (if your resolution is 1400x1280). Other than that I think Alex Bory's suggestion was very good. That's what the patch is doing. Regards, Arvid Norlander regards, Maik - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] all flight trims initialize to 0.0?
Hi all, I searched this list for a change to trim initialization but did not find any. This is from the plib branch, essentially V1.0. I have initial values specified in the -set.xml file for /controls/flight/elevator-trim /controls/flight/aileron-trim /controls/flight/rudder-trim which are ignored and all three initialize to zero. I tried changing the values in preferences.xml and also tried using --prop:/controls/flight/elevator-trim=-0.25 etc. but the trims still start with 0.0 values. I checked all the .nas files for the AC and they are not initializing the trims. I have no ~.fgfsrc file. What else could be over riding all the above? - Dave P. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] all flight trims initialize to 0.0?
dave perry wrote: Hi all, I searched this list for a change to trim initialization but did not find any. This is from the plib branch, essentially V1.0. I have initial values specified in the -set.xml file for /controls/flight/elevator-trim /controls/flight/aileron-trim /controls/flight/rudder-trim which are ignored and all three initialize to zero. I tried changing the values in preferences.xml and also tried using --prop:/controls/flight/elevator-trim=-0.25 etc. but the trims still start with 0.0 values. I checked all the .nas files for the AC and they are not initializing the trims. I have no ~.fgfsrc file. What else could be over riding all the above? OK, with just ,/bin/fgfs --aircraft= ... the trims are not reset to zero. I was using fgrun-1.0.0. I will look at what defaults it is using. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
