Re: [Flightgear-devel] BUG(?) with broken artificial horizon in c172p
AnMaster wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 After a report from a windows user about broken artificial horizon after a roll in c172p and SenecaII (using 1.0), I tried this. I do not know if it is a feature or a bug, but after a roll in c172p the artificial horizon is indeed no longer correct, but pointing some 30 degrees bank to either side as upwards. I can reproduce this with c172p cvs version in both plib and osg branches. I did not manage to reproduce it using SenecaII, but maybe it changed since 1.0 release. This sounds like a toppled gyro to me - does it slowly right itself if you maintain level flight? Jon - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] BUG(?) with broken artificial horizon in c172p
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Jon Stockill wrote: AnMaster wrote: After a report from a windows user about broken artificial horizon after a roll in c172p and SenecaII (using 1.0), I tried this. I do not know if it is a feature or a bug, but after a roll in c172p the artificial horizon is indeed no longer correct, but pointing some 30 degrees bank to either side as upwards. I can reproduce this with c172p cvs version in both plib and osg branches. I did not manage to reproduce it using SenecaII, but maybe it changed since 1.0 release. This sounds like a toppled gyro to me - does it slowly right itself if you maintain level flight? Jon Indeed it does reset, after about 10 minutes flying. So intended feature then? Regards, Arvid Norlander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHjgjCWmK6ng/aMNkRCgEqAJ4+6MFwebokNEcKGKg/aFt08iBWmQCfQmf3 2asG8+1FmGbRzRGcKgsUUjQ= =Ff7g -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] BUG(?) with broken artificial horizon in c172p
AnMaster wrote: Indeed it does reset, after about 10 minutes flying. So intended feature then? Yes - the instrument should be caged before attempting aerobatics. Same for directional gyros I believe. Jon - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] BUG(?) with broken artificial horizon in c172p
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 After a report from a windows user about broken artificial horizon after a roll in c172p and SenecaII (using 1.0), I tried this. I do not know if it is a feature or a bug, but after a roll in c172p the artificial horizon is indeed no longer correct, but pointing some 30 degrees bank to either side as upwards. I can reproduce this with c172p cvs version in both plib and osg branches. I did not manage to reproduce it using SenecaII, but maybe it changed since 1.0 release. Regards, Arvid Norlander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHjgGxWmK6ng/aMNkRCkfDAKCUs1Qhw1kAmCeNduNTaNw3aJpM8gCfYrP2 HuAa1CcdDDcLoe0wlNAHfwk= =NVzw -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] vsi-6 / Aerostar changes
Hi All, I've been tracking down why the VSI on the pittss1c has stopped working. It uses the Aircraft/Instruments-3d/vsi-6/vsi-3d.xml model. Looking at the change log, there was a change in the property it uses from /instrumentation/vertical-speed-indicator/indicated-speed-fpm to /instrumentation/inst-vertical-speed-indicator/indicated-speed-fpm 3 weeks ago. Unfortunately, the latter property doesn't exist for the pitts model. Syd - you did this as part of a bunch of changes to the Aerostar, presumably to make the needle more sensitive. From a cursory glance at the Aerostar, I haven't been able to work out what you did exactly, but it would be good to make it more generic so that the instrument can be used in other aircraft again. Could you post some instructions, or even better, update the instrument so it is self-contained? Thanks -Stuart __ Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] Need help with OSG model loading in fgrun
Hi, I am migrating fgrun to use OSG to preview aircrafts. The integration of the osgViewer classes inside fltk went flawlessly. Then I copied the sgLoad3DModel from simgear/scene/model/model.cxx. The problem I have is that it seems that axis Y and Z are inverted for AC3C models. It is very visible ( and annoying ) when models have submodels, since model orientation doesn't match model placement from the .xml file. As an illustration, look at the image below ( from Emmanuel Baranger ) : http://frbouvi.free.fr/flightsim/fgrun-YZ-axis.png I copied verbatim the code in Simgear, so I want to ask to OSG specialist what can explain that. Is there some preample code I should call before loading models ? People wanting to try can extract the osg_migration branch of fgrun svn ( url : https://fgrun.svn.sourceforge.net/svnroot/fgrun/branches/osg_migration ) I am using OSG 2.3.1 . The same thing happens under Windows and under Linux Thanks for your help -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] simgear 1.0.0 crash
I had some spare time today and did some testing to reproduce the crash with a CVS buid a few days old. 1. removed .fgfsrc file and .fgfs directory to get a clean start 2. ran fgfs --native=file,out,20,fgfs.out 3. flew a (ugly) traffic pattern on ksfo 28R with full stop landing 4. ran fgfs --native=file,in,20,fgfs.out --fdm=externalfgfs --native=file,in,20,fgfs.out --fdm=external 5. got core dump this is the backtrace from gdb: #0 0x2b43c7043372 in memcpy () from /lib64/libc.so.6 #1 0x007ecf22 in std::vectorFGGroundCache::Triangle, std::allocatorFGGroundCache::Triangle ::operator= (this=0x575b288, __x=value optimized out) at /usr/include/c++/4.2.1/bits/stl_algobase.h:283 #2 0x007eb702 in FGNative::process (this=0xd362b40) at ../../src/FDM/groundcache.hxx:33 #3 0x0044527c in FGIO::update (this=value optimized out, delta_time_sec=0.0083332) at fg_io.cxx:328 #4 0x0040e265 in fgMainLoop () at main.cxx:497 #5 0x00444ad2 in GLUTidle () at fg_os.cxx:135 #6 0x2b43c498ee13 in glutMainLoop () from /usr/lib64/libglut.so.3 #7 0x00410dda in fgMainInit (argc=3, argv=0x7fffe6785308) at main.cxx:1119 #8 0x0040d152 in main (argc=3, argv=0x7fffe6785308) at bootstrap.cxx:215 pretty much the same as the one posted by tpalinkas. The dump occours in FGNative::process line 74, at *cur_fdm_state = buf; buf and cur_fdm_state are FGInterface, that have a FGGroundCache member. The FGGroundCache object has a member std::vectorTriangle and a member found_ground. The crash occours, when the ground_cache.found_ground is true and the triangles vector has elements. It appears to me, that the vector contains memory pointers, that are saved to a file and they are invalid when being read lateron. I am not sure if I understand the code correct, but is it a good idea to save the groundcache as part of the fdm state? And if so, it is probably better to save the content of the triangle vector than just the pointer? Maybe somebody with a deeper insight in the GroundCache code can step in here... I put my fgfs.out file here: http://www.t3r.de/fg/fgfs.out.bz2 Greetings, Torsten - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] vsi-6 / Aerostar changes
* SydSandy -- Wednesday 16 January 2008:
I rarely get time to check other's work , so I never know who
else is using the gauges ...
Sorry, but that's absurd. It takes almost no time to check ...
$ find $FG_ROOT/Aircraft -name \*.xml|while read i; do grep -l vsi-3d.xml $i;
done
/usr/local/share/FlightGear/Aircraft/harrier/Panel/harrier-panel.xml
/usr/local/share/FlightGear/Aircraft/pittss1c/Models/pittss1c.xml
/usr/local/share/FlightGear/Aircraft/Aerostar-700/Models/aerostar.xml
/usr/local/share/FlightGear/Aircraft/B-1B/Models/B-1B.xml
... and given that the Aircraft/Instruments{-3d} dirs *are*
about sharing there's an obligation to check if one breaks
something after making incompatible changes.
Of course, you can always miss something even if you check,
and it's not a tragedy if it happens. I just don't accept
the cheap excuse. :-}
m.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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] clearer patch to renderer.*xx - accomodates non 4:3 aspect ratios with osg
Patch adds a member function to FGRenderer class that returns the
current aspect ratio. Uses this in place of 4.0/3.0 in setFOV and
setNearFar.
The diff follows:
? renderer.diff
Index: renderer.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/renderer.cxx,v
retrieving revision 1.100
diff -p -u -r1.100 renderer.cxx
--- renderer.cxx6 Jan 2008 23:03:20 -1.100
+++ renderer.cxx16 Jan 2008 22:41:59 -
@@ -864,6 +864,11 @@ static float fov_height = 42.0;
static float fov_near = 1.0;
static float fov_far = 1000.0;
+float FGRenderer::getAspectRatio() {
+float xsize = fgGetInt(/sim/startup/xsize);
+float ysize = fgGetInt(/sim/startup/ysize);
+return xsize/ysize;
+}
/** FlightGear code should use this routine to set the FOV rather than
* calling the ssg routine directly
@@ -872,7 +877,7 @@ void FGRenderer::setFOV( float w, float
fov_width = w;
fov_height = h;
osgViewer::Viewer* viewer = globals-get_renderer()-getViewer();
-viewer-getCamera()-setProjectionMatrixAsPerspective(fov_height,
4.0/3.0,
+viewer-getCamera()-setProjectionMatrixAsPerspective(fov_height,
FGRenderer::getAspectRatio(),
fov_near,
fov_far);
}
@@ -886,7 +891,7 @@ n = 0.1;
fov_near = n;
fov_far = f;
osgViewer::Viewer* viewer = globals-get_renderer()-getViewer();
-viewer-getCamera()-setProjectionMatrixAsPerspective(fov_height,
4.0/3.0,
+viewer-getCamera()-setProjectionMatrixAsPerspective(fov_height,
FGRenderer::getAspectRatio(),
fov_near,
fov_far);
}
Index: renderer.hxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/renderer.hxx,v
retrieving revision 1.17
diff -p -u -r1.17 renderer.hxx
--- renderer.hxx21 Nov 2007 20:51:50 -1.17
+++ renderer.hxx16 Jan 2008 22:41:59 -
@@ -32,6 +32,8 @@ public:
void splashinit();
void init();
+static float getAspectRatio();
+
static void resize(int width, int height );
// calling update( refresh_camera_settings = false ) will not
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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] vsi-6 / Aerostar changes
On Wed, 16 Jan 2008 21:19:32 +0100
Melchior FRANZ [EMAIL PROTECTED] wrote:
* SydSandy -- Wednesday 16 January 2008:
I rarely get time to check other's work , so I never know who
else is using the gauges ...
Sorry, but that's absurd. It takes almost no time to check ...
$ find $FG_ROOT/Aircraft -name \*.xml|while read i; do grep -l vsi-3d.xml
$i; done
/usr/local/share/FlightGear/Aircraft/harrier/Panel/harrier-panel.xml
/usr/local/share/FlightGear/Aircraft/pittss1c/Models/pittss1c.xml
/usr/local/share/FlightGear/Aircraft/Aerostar-700/Models/aerostar.xml
/usr/local/share/FlightGear/Aircraft/B-1B/Models/B-1B.xml
... and given that the Aircraft/Instruments{-3d} dirs *are*
about sharing there's an obligation to check if one breaks
something after making incompatible changes.
Of course, you can always miss something even if you check,
and it's not a tragedy if it happens. I just don't accept
the cheap excuse. :-}
m.
Charming , as always :)
Your right , I'll MAKE time to check , as soon as I decipher that line above :)
Cheers
--
SydSandy [EMAIL PROTECTED]
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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] memory leak head branch
Hi everyone, A memory leak ran over me with fg + sg cvs/OSG 2.3.1 using SDL/osgviewer. It accumulates about 200mb/ 10 min, until your memory and swap is full, despite the 15mb/10min of the unleaked version. I narrowed the search: with fg + sg cvs from 5th of jan. there is no leak, while it is present in the cvs of the 7th, so I suspect the faulty code could have been added on the 6th, possibly in simgear cvs. Any clues? markus - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. 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] vsi-6 / Aerostar changes
On Jan 16, 2008 7:23 PM, SydSandy wrote:
On Wed, 16 Jan 2008 21:19:32 +0100
Melchior FRANZ wrote:
* SydSandy -- Wednesday 16 January 2008:
I rarely get time to check other's work , so I never know who
else is using the gauges ...
Sorry, but that's absurd. It takes almost no time to check ...
$ find $FG_ROOT/Aircraft -name \*.xml|while read i; do grep -l
vsi-3d.xml $i; done
/usr/local/share/FlightGear/Aircraft/harrier/Panel/harrier-panel.xml
/usr/local/share/FlightGear/Aircraft/pittss1c/Models/pittss1c.xml
/usr/local/share/FlightGear/Aircraft/Aerostar-700/Models/aerostar.xml
/usr/local/share/FlightGear/Aircraft/B-1B/Models/B-1B.xml
... and given that the Aircraft/Instruments{-3d} dirs *are*
about sharing there's an obligation to check if one breaks
something after making incompatible changes.
Of course, you can always miss something even if you check,
and it's not a tragedy if it happens. I just don't accept
the cheap excuse. :-}
m.
Charming , as always :)
Your right , I'll MAKE time to check , as soon as I decipher that line
above :)
Cheers
Syd,
Don't bother listening to Melchior, he's busy coming up with absurdly long
strings of obscure unix commands that are just a huge waste of time to
type. You can do the same check with this much simpler command and save 26
key strokes (if you start in the aircraft directory):
find . -name \*.xml -exec grep -l vsi-3d {} \;
:-)
If you are running gnu-find you can skip the path portion . or
$FG_ROOT/Aircraft entirely and it will assume the current directory (i.e.
.)
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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] vsi-6 / Aerostar changes
On Wed, 16 Jan 2008 21:46:05 -0600
Curtis Olson [EMAIL PROTECTED] wrote:
On Jan 16, 2008 7:23 PM, SydSandy wrote:
On Wed, 16 Jan 2008 21:19:32 +0100
Melchior FRANZ wrote:
* SydSandy -- Wednesday 16 January 2008:
I rarely get time to check other's work , so I never know who
else is using the gauges ...
Sorry, but that's absurd. It takes almost no time to check ...
$ find $FG_ROOT/Aircraft -name \*.xml|while read i; do grep -l
vsi-3d.xml $i; done
/usr/local/share/FlightGear/Aircraft/harrier/Panel/harrier-panel.xml
/usr/local/share/FlightGear/Aircraft/pittss1c/Models/pittss1c.xml
/usr/local/share/FlightGear/Aircraft/Aerostar-700/Models/aerostar.xml
/usr/local/share/FlightGear/Aircraft/B-1B/Models/B-1B.xml
... and given that the Aircraft/Instruments{-3d} dirs *are*
about sharing there's an obligation to check if one breaks
something after making incompatible changes.
Of course, you can always miss something even if you check,
and it's not a tragedy if it happens. I just don't accept
the cheap excuse. :-}
m.
Charming , as always :)
Your right , I'll MAKE time to check , as soon as I decipher that line
above :)
Cheers
Syd,
Don't bother listening to Melchior, he's busy coming up with absurdly long
strings of obscure unix commands that are just a huge waste of time to
type. You can do the same check with this much simpler command and save 26
key strokes (if you start in the aircraft directory):
find . -name \*.xml -exec grep -l vsi-3d {} \;
:-)
If you are running gnu-find you can skip the path portion . or
$FG_ROOT/Aircraft entirely and it will assume the current directory (i.e.
.)
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
Ah that's easier to understand :)
I generally just do a ( grep -R some word * ) from the Aircraft directory...
I don't know all the Linux commands , but that works for me .
Cheers
--
SydSandy [EMAIL PROTECTED]
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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
