Re: [Flightgear-devel] nonzero turbulence set by Preferences.xml?
Melchior FRANZ wrote: * dave perry -- Friday 07 December 2007: What is proposed is to make the default turbulence = 0.0 at start-up, not turning off turbulence modeling. You can still use the weather menu to set the desired turbulence or you can [...] OK, before even more people answer who didn't get what I was writing: - low/no default turbulence doesn't make fgfs a toy - high default turbulence doesn't make it professional just as - avoiding really difficult to fly aircraft in the default aircraft collection doesn't make fgfs a toy, and - including them doesn't make it professional I was just making a comparison! :-) In the end I don't care much, as I (like everyone else here) will not use the default package. The question is only, which defaults are least frustrating for someone who just downloaded 200 MB of data via dial up, and what makes the most sense. That we want maximum realism *and* a way to configure as much as possible and reasonable, was never disputed. m. A final comment in ending this discussion (I hope). I agree, as a user, that we do not want the default setting to be zero. I am an advocate of realism. The FG windows gui, in weather -- weather conditions allows one to set the turb to zero with sliders. Setting them to zero does not in fact set turb to zero, at least with my recent build of FG OSG. That would be a bug (in OSG version) should be fixed. A user can, as indicated earlier in this thread, set turb to zero on the command line. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nonzero turbulence set by Preferences.xml?
Curtis Olson wrote: On Dec 6, 2007 9:07 PM, dave perry wrote: Would anyone object to setting all the turbulence values in Preferences.xml to 0.0 for this release? Even the small values set by Preferences.xml cause increasing oscillations for most JSBSim autopilots in APR mode because the 500 ft. agl boundary turbulence is 0.1 . This is true for the c172p with the kap140 autopilot and the SenecaI with the AltimaticIIIc autopilot. Setting turbulence = 0.0 from fgrun will not zero these values. Using --turbulence=0.0 on the command line will result in all the turbulence values being zero. I'll put in my vote for zeroing these out in the preferences.xml file. If someone wants interesting weather they can just enable the real time metar. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ http://baron.flightgear.org/%7Ecurt/ Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d This change doesnt exactly affect the weather but is a temp hack until JSBsim developers adjust the modeling of turbulence. I donot see this issue with the other FDM. Calling for METAR or not is irrelevant I believe. I was calling for METAR on my test flights this evening, got real weather but no turb. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nonzero turbulence set by Preferences.xml?
dave perry wrote: Hi All, Would anyone object to setting all the turbulence values in Preferences.xml to 0.0 for this release? Even the small values set by Preferences.xml cause increasing oscillations for most JSBSim autopilots in APR mode because the 500 ft. agl boundary turbulence is 0.1. This is true for the c172p with the kap140 autopilot and the SenecaI with the AltimaticIIIc autopilot. Setting turbulence = 0.0 from fgrun will not zero these values. Using --turbulence=0.0 on the command line will result in all the turbulence values being zero. -Dave Perry Dave - Input from a humble user. I can confirm this on the cvs OSG version. Interestingly, the turbulence sliders in the weather conditions window of the gui all show no turb but only the command line invocation --turbulence=0.0 seems to actually set it to zero (--turbulence=0.0 set in the ~/.fgfsrc file does not do it). Although I like realistic flight my ILS approaches we very unstable with the turb values given in the Preferences.xml file when near the approach end of the runway. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
Melchior FRANZ wrote: * Melchior FRANZ -- Thursday 18 October 2007: The good news: I have a Nasal binding/script cache almost finished. I don't know yet if it makes a huge difference, [...] ..and the nvidia driver since then. Same old crappy hardware.) Just curious, what does old crappy hardware consist of? I ask because this seems more prevalent with people running high end systems (i.e. fancy graphics cards, dual core cpu's etc). - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FG OSG build error
After successful update of OSG SimGear my attempt to build FG (OSG) gave this: === . . . make[2]: Entering directory `/home/lvanek/FlightGear-0.9/source/src/Aircraft' g++ -DHAVE_CONFIG_H -I. -I../../src/Include -I../.. -I../../src -I/usr/local/include -g -O2 -D_REENTRANT -MT aircraft.o -MD -MP -MF .deps/aircraft.Tpo -c -o aircraft.o aircraft.cxx In file included from ../../src/Instrumentation/dclgps.hxx:35, from ../../src/Cockpit/panel.hxx:55, from aircraft.cxx:41: ../../src/Navaids/navrecord.hxx:35:46: error: simgear/structure/ssgSharedPtr.hxx: No such file or directory make[2]: *** [aircraft.o] Error 1 make[2]: Leaving directory `/home/lvanek/FlightGear-0.9/source/src/Aircraft' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/lvanek/FlightGear-0.9/source/src' make: *** [all-recursive] Error 1 = thoughts? - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG OSG build error
Csaba Hala'sz wrote: On 10/20/07, Laurence Vanek [EMAIL PROTECTED] wrote: simgear/structure/ssgSharedPtr.hxx: No such file or directory ... thoughts? You are probably trying to build plib branch of flightgear with osg branch of simgear. Those two have to match, ie. both plib or both osg. thanks for the reply, but no I have not. Been buiding OSG SimGear with OSG branch of FG for some time now. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG OSG build error
Durk Talsma wrote: On Saturday 20 October 2007 19:46, Csaba Halász wrote: On 10/20/07, Laurence Vanek [EMAIL PROTECTED] wrote: thanks for the reply, but no I have not. Been buiding OSG SimGear with OSG branch of FG for some time now. Ah, ok. Looks like Durk has slipped a dependency on plib-sg into osg-fg. Try changing the src/Navaids/navrecord.hxx:35 line to #include simgear/structure/SGSharedPtr.hxx or roll back that change from cvs. Yikes! That's what you get when installing the two versions on top of each other I guess... Should be fixed in CVS now. Cheers, Durk Its fixed for me. Thank you gentlemen. Durk, as a side note, I commend your efforts to track down the legendary stick-slip or stutter problem. A number of us have been suffering with this issue for some time now. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Bug-Report] Stutterer and pauses withdynamic-view
Melchior FRANZ wrote: Bug #3: Lee threw in an old bug and repeated the long disproved myth that listeners are the cause. They are not! This bug causes fgfs to freeze for a tenth of a second in 8 seconds intervals beginning a few minutes after startup (but not always). The intervals stay the same, but the freezing time becomes longer and longer over time. This happens now since years and on my machine it can reliably be fixed by turning off AI traffic (the c172/pa28 aircraft). I tried to track it down but didn't invest enough time. The fact that this AI part was full of bugs just didn't make it worthwhile. (I just say tower.cxx. :-) sorry to break your state of bliss on bug #3 but I have , had for some time, this bug without AI enabled. as far as I am concerned this is a long standing, semi-serious bug that remains unresolved. No, its not my hardware (popular explanation in months past). - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Bug-Report] Stutterer and pauses with dynamic-view
SydSandy wrote: On Tue, 28 Aug 2007 10:37:42 +0200 (CEST) Heiko Schulz [EMAIL PROTECTED] wrote: Hello, With the build from 08/15/2007 and some former ones until april I noticed stutters and pauses with 1-2 sec lenght. I write this, because it wasn't note here yet. With help from the IRC chat I did some testing. When I have enabled the dynamic view, everytime the view is changing, the fps decrease to 1-6 fps, very often it's pauses. The longer I fly, this behaviour seems to disappear. If the dynamic view is disabled, there are no stutters- even I disable the dynamic view at runtime. Sweeping the view 180 degrees around change anything. If I have disabled dynamic view, and I change the view manually with the mouse I can't reproduce the stutters. AMD Athlon XP 2400+ Windows XP NVidea GF 5200 with 128 RAM traffic manager and AI traffic disabled Build from Reagon Thomas from 08/15/2007 Thanks HHS I have the same problem , has nothing to do with dynamic view here , but with changing view... I generally have to pan 360 degrees a few times before takeoff to smooth things out used to be worse with PLIB , now about the same with both versions AMD Athalon 1100 Linux Geforce 6200 Cheers SydSandy [EMAIL PROTECTED] also had this problem in general (not with dynamic view). only thing that helped was adding the following to my .fgfsrc file: --prop:/sim/frame-rate-throttle-hz=75 as far I know no one has solved this problem. apparently only a few of us seem to have the issue. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Bug-Report] Stutterer and pauses with dynamic-view
Robert Black wrote: On Tuesday 28 August 2007 18:44, Laurence Vanek wrote: also had this problem in general (not with dynamic view). only thing that helped was adding the following to my .fgfsrc file: --prop:/sim/frame-rate-throttle-hz=75 as far I know no one has solved this problem. apparently only a few of us seem to have the issue. I thought everyone had this behavior. Most videos I have seen of FG have the stutter and pause. Robert I have learned to live with it. A point of interest is that x-plane does not exhibit this behavior using the same hardware and operating system. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Century IIB autopilot modeled
dave perry wrote: The real N7764P (pa24-250) has a Century IIB autopilot, not the KAP140 that is in the fgfs Comanche in cvs. I found a pdf of the pilot's operating handbook for this autopilot on the internet and have modeled this autopilot and replaced the kap140 in my local version of fgfs. This autopilot does not have a pitch axis control. It is a precursor to the Altimatic IIIc that is in the SenicaII. The model is complete in that it behaves as the documentation describes and as the real Century IIB behaves in the real AC. I actually find the approaches I do with this autopilot more precise than with the kap140. Question to anyone that uses the fgfs pa24; does the increased realism of the Century IIBoffset the loss of the pitch and altitude capture of the kap140 for this model? I would like to update the pa24 in cvs with this autopilot in place of the kap140. In working on this AP model, I noted that the model in the SenicaII for the Altimatic IIIc is not finished. The approach I used to implement the roll knob function when in ROL mode would work very well for the Altimatic IIIc. Torsten, if I can find a pilot's handbook for the Altimatic IIIc, I would like to complete that model for the SenicaII. Between the approach to handling the coupler mode selector and the roll knob and the kap140.nas from Vegard Ovesen, this should not be more than a few evenings work. Any problem with contributing to you fine model? Regards, Dave Perry Dave - I have flown the pa24 quite a bit in the recent past. I assume the lack of pitch control would mean no glide slope capture? I rarely used the altitude capture, so no loss for me. Even without pitch control, I vote for realism. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 'setUpdateVisitor' doesn't exist anymore in OSG?
Laurence Vanek wrote: Sébastien MARQUE wrote: Hi all, just willing to say you that OSG/SVN doesn't seem to have anymore the member 'setUpdateVisitor' in class osgViewer::Scene, which is needed at least the first time during compilation in renderer.cxx at line 396. After grepping in my local include directory, I found another 'setUpdateVisitor' member in osgUtil::SceneView, I tried to use it in renderer.cxx, line 391: osgUtil::SceneView* scene = viewer-getScene(); but then I get the following: renderer.cxx:392: erreur: cannot convert ‘osgViewer::Scene*’ to ‘osgUtil::SceneView*’ in initialization I know this is not a very orthodox method, but I wanted to give it a try ;) The last fine working OSG revison was the rev7802 here. System: Debian Sid, gcc4.2.1 Regards Seb Me also. After svn update of OSG, cvs updates of simgear FG today, I get this when attempting to build FG: . . . renderer.cxx: In member function ‘void FGRenderer::splashinit()’: renderer.cxx:396: error: ‘class osgViewer::Scene’ has no member named ‘setUpdateVisitor’ renderer.cxx: In static member function ‘static bool FGRenderer::pick(unsigned int, unsigned int, std::vectorSGSceneryPick, std::allocatorSGSceneryPick , const osgGA::GUIEventAdapter*)’: renderer.cxx:971: warning: converting to ‘unsigned int’ from ‘double’ make[2]: *** [renderer.o] Error 1 make[2]: Leaving directory `/home/lvanek/FlightGear-0.9/source/src/Main' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/lvanek/FlightGear-0.9/source/src' make: *** [all-recursive] Error 1 == Last rebuilds were ~one week ago with no issues. reply to myself. This problem still exists as of 30 minutes ago when I did fresh svn update of OSG rebuilds of simgear + FG. At presnt FG does not build from cvs head for me. Anyone else see this? - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 'setUpdateVisitor' doesn't exist anymore in OSG?
gh.robin wrote: On Sun 12 August 2007 19:10, Laurence Vanek wrote: Laurence Vanek wrote: reply to myself. This problem still exists as of 30 minutes ago when I did fresh svn update of OSG rebuilds of simgear + FG. At presnt FG does not build from cvs head for me. Anyone else see this? According to that, was previously said, there is a closed minded way the stable OSG version 2.0 Regards Gérard ok.not sure I understand what you are saying. I have been building OSG with the non-closed mind version for some time now without much trouble. I dont normally inhabit the devel list since I am a user not a developer. It would appear to me that the developers would be more than a little concerned with this issue. I will be patient. thanks for the reply. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 'setUpdateVisitor' doesn't exist anymore in OSG?
Tim Moore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Laurence Vanek wrote: gh.robin wrote: On Sun 12 August 2007 19:10, Laurence Vanek wrote: Laurence Vanek wrote: reply to myself. This problem still exists as of 30 minutes ago when I did fresh svn update of OSG rebuilds of simgear + FG. At presnt FG does not build from cvs head for me. Anyone else see this? According to that, was previously said, there is a closed minded way the stable OSG version 2.0 Regards Gérard I've committed a fix so that FlightGear will again compile with OSG 2.1.4, as well as older versions. ok.not sure I understand what you are saying. I have been building OSG with the non-closed mind version for some time now without much trouble. I dont normally inhabit the devel list since I am a user not a developer. It would appear to me that the developers would be more than a little concerned with this issue. Well, no. OSG SVN moves very rapidly and making sure that FlightGear always compiles against the latest and greatest OSG is not a priority. Tim Thanks for the fix. There have been times in the past when the reverse was true, i.e. needing to build the latest OSG to compile the latest FG. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 'setUpdateVisitor' doesn't exist anymore in OSG?
Sébastien MARQUE wrote: Hi all, just willing to say you that OSG/SVN doesn't seem to have anymore the member 'setUpdateVisitor' in class osgViewer::Scene, which is needed at least the first time during compilation in renderer.cxx at line 396. After grepping in my local include directory, I found another 'setUpdateVisitor' member in osgUtil::SceneView, I tried to use it in renderer.cxx, line 391: osgUtil::SceneView* scene = viewer-getScene(); but then I get the following: renderer.cxx:392: erreur: cannot convert ‘osgViewer::Scene*’ to ‘osgUtil::SceneView*’ in initialization I know this is not a very orthodox method, but I wanted to give it a try ;) The last fine working OSG revison was the rev7802 here. System: Debian Sid, gcc4.2.1 Regards Seb Me also. After svn update of OSG, cvs updates of simgear FG today, I get this when attempting to build FG: . . . renderer.cxx: In member function ‘void FGRenderer::splashinit()’: renderer.cxx:396: error: ‘class osgViewer::Scene’ has no member named ‘setUpdateVisitor’ renderer.cxx: In static member function ‘static bool FGRenderer::pick(unsigned int, unsigned int, std::vectorSGSceneryPick, std::allocatorSGSceneryPick , const osgGA::GUIEventAdapter*)’: renderer.cxx:971: warning: converting to ‘unsigned int’ from ‘double’ make[2]: *** [renderer.o] Error 1 make[2]: Leaving directory `/home/lvanek/FlightGear-0.9/source/src/Main' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/lvanek/FlightGear-0.9/source/src' make: *** [all-recursive] Error 1 == Last rebuilds were ~one week ago with no issues. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Severe Turbulence (Weather Interpolation Problem?)
Hans Fugal wrote: Flying in the vicinity of KCSQ just now (KCSQ 062055Z AUTO 16006KT 10SM CLR 26/23 A2979 RMK AO2) in both the pa28-161 and j3cub, I noticed some kind of weather-related problems. I'm afraid it was probably weather interpolation-related. My plane was being tossed around like a salad, but as you can see from that METAR there's no mention of severe turbulence. It went away when I chose fair weather scenario. Turning the turbulence down to 0 on the layer I was flying in changed nothing. It wasn't an FPS or machine load problem, which was my first suspect. It didn't feel like real turbulence, but it did feel like fighting walls of weather, as if they were alternating from one to another. FG/OSG (osgviewer) built from CVS from last night (roughly 0800 UTC), which I believe to be current. Happy to compile and try any variant (plib, osg/glut) on request. I can confirm this also. However, I took it as a taste of realism (feature not a bug?). I also had the turb set to zero. As Hans states it seems to conflict with what the METAR is saying. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] significant updates to pa28-161 and a few updates to the pa24-250
Dave Perry wrote: I submitted 3 patches via Melchior today. pa28-161 update Last year after I completed the pa24, David Megginson sent me all the detail pictures he had taken of his Piper Warrior II and indicated that I should finish up the details on the pa28-161 in FlightGear. I spent the last three weeks, evenings and weekends (other than 4 days at Oshkosh) finally doing just that. Since the next release will still be in plib, I did hot spots with panels (arg!). Many hot spots also have picks in osg. This update took the pa28 past the level of detail in the pa24, so I made several updates to the pa24 so they are at the same level now. You will notice that the aircraft now starts with all switches off and the fuel selector on off. As in the pa24, the clicking on help and then aircraft help will give you the keyboard keys for all the switches as well as a start sequence. There are now hot spots for all the switches, etc., including the flap lever, the rudder trim, and the elevator trim. The panel lights now are on a dimmer switch. Did the same for the pa24 via rotation of the nav light switch (as in the real pa24). Added nasal electrical system, the kt70 transponder, an AMP meter, magneto switch and key, flight com (texture only), vacuum gage, hobbs meter (texture only), carb heat, primer, and nasal simulated egt and stall warning that recognizes accelerated stall conditions, throttle and mixture on the power quadrant, rudder pedals with brakes, hand brake, yokes,and fuel valve and appropriate animations. Used several parts from Torsten Dreyer's fine SenecaII. 2. pa24-250 updates - added the kt70 transponder and dimming instrument lights as well as elevator trim hot spots on the overhead console. Changes to 3D instruments There are several changes to 3D instruments that might be noticed by other AC. 1. Rescaled the radio_stack slightly to match the real dimensions of the radios. Adding the kt70 made this dimension error obvious. 2. Shortened the RadioStack.ac rectangle so the extra space below the kap140 is gone. Without this change, it would have over lapped the pa28 switch panel. 3. Added a select animation to the kt70.xml file to only display the id_code (digit1 thru digit4) when the transponder has power. This should not negatively impact any other users as all the other features don't work without transponder power. 4. Changes to other 3D instruments: a. shortened the asi.ac needle so it stays within the instrument. b. added material animation to the pa28-fuel-oil.xml controlled by the panel light dimmer. c. added click groups and resized the pick rectangles to just slightly larger than the knobs they control in osg for alt.ac, hi.ac, and vor.ac. This was an attempt to make the pick rectangles less intrusive in plib. Let me know if any of these changes have a negative impact on any other AC. Enjoy a night approach in the Warrior II! Dave Dave - I have been having a great time flying this machine (pa28-161) today. I appreciate all the hard work. Big difference relative to how it used to be. Thanks. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] /sim/model-hz problems
Martin Spott wrote: wim van hoydonck wrote: Whenever I look outside in fg, the framerate skyrockets to values around 300 which induce stutter in the simulation. A (partial) solution would be to increase /sim/model-hz in the internal properties browser, so that less time is available to render the outside visuals. Once there was a --prop:/sim/frame-rate-throttle-hz=Number flag, see if it still works for example by setting it to 30 or 60 Hz, Martin. At last!! Martin you have cured my issue with this. I set mine at 85 Hz the behavior is almost entirely gone. Smooth simulation. I had been getting insanely high frame rates ( 200) rendering stutter. Now the frame rates are in the vicinity of 90-100. I posted this over on the user list but was told to go fix my X config. Tried everything I Nvidia support people could think of with no luck. I did not GL sync to blank (doesnt seem to work with these drivers anyway). Im running Intel core 2 duo (E6600) with Nvidia GeForce 7600 GS based graphics card. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar
syd sandy wrote: Hi again, I checked the source code , recent update , and delete rt is already commented out , so I recompiled and tried my Aerostar 700, which I recently added a weather radar to , and no more error message when I exit FG , so that must have done the trick ... Cheers Hi Syd - when can I try it out :-) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] patch for osgViewer and statistics
Nick Warne wrote: Hi Georg, On Wednesday 23 May 2007 19:05:43 Georg Vollnhals wrote: But where do you apply this -O3 parameter? Configure or Make when compiling the FlightGear sources? Thank you very much in advance for your help. Regards Georg EDDW Sorry, I read this too quick. You can build SG/FG with optimisations like this: ./configure CXXFLAGS=-O3 ... If you wish to include further flags, they need to enclosed in double quotes: ./configure CXXFLAGS=-march=athlon-tbird -O3 This is my full FG configure option: ./configure CXXFLAGS=-march=athlon-tbird -O3 --prefix=/usr --enable-sdl Nick wow! I can confirm the frame rate increase on this system as well using the above suggestions. It approx. doubled my frame rates. thank you gentlemen. Fedora Core 6, Intel core 2 duo, nVidia GeForce 7600 GS w/256 meg. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] framerate hesitations...
Syd Sandy wrote: gh.robin wrote: On Tue 10 April 2007 19:21, Jeff McBride wrote: On 4/10/07, Syd Sandy [EMAIL PROTECTED] wrote: Hi all , Not sure how to describe this , I get a barely visible hesitation in framerates while flying, about once a second . Noticed it in the Aerostar , so I suspected my Nasal electrical routine was causing it but after changing the loop timing it didnt seem to match Running with log-level = info , it appears to closely match the refreshing timestamp message , but not entirely positive yet... Just wondering if anyone else has noticed this ? I tried a few other aircraft , and didnt notice it as much , so I'll keep hunting . Cheers, Syd Probably not the culprit, but I have found on my computer at times that when I have the fgmap (from pigeond) open in mozilla while flying, it can cause brief stutters when it refreshes at a regular interval. -Jeff Jeff is right, i noticed that problem a loong time ago, And never got any answer. I have solved it with running fgmap on a separate computer Regards. I get this with varying degrees from different aircraft , with nothing else running , AI / Traffic and MP disabled , but its not consistant enough to find the problem easily... I also noticed long ago , but spend more time fixing than flying and forgot about it I also noticed it affects both PLIB and OSG versions... Cheers, Syd I also see this with most aircraft, some more than others. The aerostar is by no means the worst. Ive taken to ignoring it. Im reluctant to believe its hardware in origin, since too many different O/S's and hardware combinations report it. For info Im running 2gig of RAM, Intel core 2 duo (E6600), nVidia based graphics card with 256 meg of VRAM. O/S is Fedora Core 6. When the stutter occurs frame rate doesnt seem to be affected. Changing monitor parameters has no impact. I notice it seems worse passing thru cloud layers so perhaps its something to do with eye candy a person is using. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] problem updating base package
Dave Perry wrote: I get the following trying to update data. [EMAIL PROTECTED] ~]$ cd $FG_ROOT [EMAIL PROTECTED] data]$ su -c 'cvs update -dP' Password: cvs [update aborted]: error writing to server: Connection reset by peer [EMAIL PROTECTED] data]$ Tried last evening and again this morning with the same result. Dave - Have you gotten cvs update to complete yet? I just finished with both data source. No problems. Maybe a temp server issue thats fixed now. Running Fedora Core 6. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] error compiling osg with fresh fc6 install
Dave Perry wrote: On Sat, 2007-03-17 at 01:19 -0500, Laurence Vanek wrote: Dave Perry wrote: I get the following compile error well into the OSG compile on my just installed FC6. Entering directory freetype make[3]: Entering directory `/usr/local/source-osg/OpenSceneGraph/src/osgPlugins/freetype' make[4]: Entering directory `/usr/local/source-osg/OpenSceneGraph/src/osgPlugins/freetype/Linux32.Opt' make[4]: *** No rule to make target `/usr/include/freetype2/freetype/internal/internal.h', needed by `FreeTypeLibrary.o'. Stop. There is no '/usr/include/freetype2/freetype/internal' folder. I updated, compiled, and installed the osg branch in FC5 successfully this morning and then made a copy of all the directories before doing the FC6 install. After using the 'software updater' on FC6, I moved all the source back in place and compiled plib, OpenThreads, Producer successfully, but get the above error compiling OpenScenGraph. Do any of the FC6 users recognize this error? Thanks for any ideas in advance, Dave Dave - I have FC6 I am running FG svn OSG. I have these freetype rpms installed on my system: freetype-2.2.1-16.fc6 freetype-devel-2.2.1-16.fc6 Do you have the devel package installed? Dont think you get that with a new install. Yes, both are installed. And this is the svn OSG. Do you have the '/usr/include/freetype2/freetype/internal' folder? Thanks for the reply, Dave Dave - I have this directory: /usr/include/freetype2/freetype there is no internal directory under the above directory. I will attempt to build svn OSG again today sometime. Its been a couple of days since I last built OSG. Maybe there's glitch in OSG that has recently appeared. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] error compiling osg with fresh fc6 install
Laurence Vanek wrote: Dave Perry wrote: On Sat, 2007-03-17 at 01:19 -0500, Laurence Vanek wrote: Dave Perry wrote: I get the following compile error well into the OSG compile on my just installed FC6. Entering directory freetype make[3]: Entering directory `/usr/local/source-osg/OpenSceneGraph/src/osgPlugins/freetype' make[4]: Entering directory `/usr/local/source-osg/OpenSceneGraph/src/osgPlugins/freetype/Linux32.Opt' make[4]: *** No rule to make target `/usr/include/freetype2/freetype/internal/internal.h', needed by `FreeTypeLibrary.o'. Stop. There is no '/usr/include/freetype2/freetype/internal' folder. I updated, compiled, and installed the osg branch in FC5 successfully this morning and then made a copy of all the directories before doing the FC6 install. After using the 'software updater' on FC6, I moved all the source back in place and compiled plib, OpenThreads, Producer successfully, but get the above error compiling OpenScenGraph. Do any of the FC6 users recognize this error? Thanks for any ideas in advance, Dave Dave - I have FC6 I am running FG svn OSG. I have these freetype rpms installed on my system: freetype-2.2.1-16.fc6 freetype-devel-2.2.1-16.fc6 Do you have the devel package installed? Dont think you get that with a new install. Yes, both are installed. And this is the svn OSG. Do you have the '/usr/include/freetype2/freetype/internal' folder? Thanks for the reply, Dave Dave - I have this directory: /usr/include/freetype2/freetype there is no internal directory under the above directory. I will attempt to build svn OSG again today sometime. Its been a couple of days since I last built OSG. Maybe there's glitch in OSG that has recently appeared. Dave - As promised I rebuilt all libraries + FG on this Fedora Core 6 system. I did the following: From svn: updates of OpenThreads, osgProducer, OpenSceneGraph all make make install (as root) ok without error. One note, I seem to need to make OSG as root for some reason on this system. Appraently OSG make needs access to things it cant get at unless user is root. From cvs: updates of SimGear-0.3, FlightGear-0.9/source, FlightGear-0.9/data all make make install ok without error. More notes things you already know perhaps: Whats in your /etc/ld.so.conf file? Mine has: include ld.so.conf.d/*.conf /usr/local /usr/local/lib /usr/local/include /usr/local/include/simgear /usr/local/include/OpenThreads /usr/local/include/Producer /usr/local/lib/osgPlugins My freetype2 stuff (header files) is located in /usr/include/freetype2 directory. Hope this helps a little. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] error compiling osg with fresh fc6 install
Dave Perry wrote: I get the following compile error well into the OSG compile on my just installed FC6. Entering directory freetype make[3]: Entering directory `/usr/local/source-osg/OpenSceneGraph/src/osgPlugins/freetype' make[4]: Entering directory `/usr/local/source-osg/OpenSceneGraph/src/osgPlugins/freetype/Linux32.Opt' make[4]: *** No rule to make target `/usr/include/freetype2/freetype/internal/internal.h', needed by `FreeTypeLibrary.o'. Stop. There is no '/usr/include/freetype2/freetype/internal' folder. I updated, compiled, and installed the osg branch in FC5 successfully this morning and then made a copy of all the directories before doing the FC6 install. After using the 'software updater' on FC6, I moved all the source back in place and compiled plib, OpenThreads, Producer successfully, but get the above error compiling OpenScenGraph. Do any of the FC6 users recognize this error? Thanks for any ideas in advance, Dave Dave - I have FC6 I am running FG svn OSG. I have these freetype rpms installed on my system: freetype-2.2.1-16.fc6 freetype-devel-2.2.1-16.fc6 Do you have the devel package installed? Dont think you get that with a new install. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Compile failure
Craig Benbow wrote: Didier Fabert wrote: Le Wednesday 14 March 2007 04:36:25 Craig Benbow, vous avez écrit : Trying to build a CVS version of FG. Can anyone point me to whats wrong here? Its a bit beyond my C++ skills sorry. Actually I guess this is a linkage problem...still haven't a clue what to look for... Craig Do you compile AND install simgear CVS before ? you need OSG too. More informations at http://wiki.flightgear.org/flightgear_wiki/index.php?title=OpenSceneGraph and http://wiki.flightgear.org/flightgear_wiki/index.php?title=Building_Flightgear Yes. Both are latest versions and newly built. Looks like a compile option is not set right for the linker but I'm no expert on this. After viewing the Wiki I wonder if I have to backdate to the 20061113 version. The Wiki is unclear on which build one should use. Craig Is the version of OSG you are using from cvs (I guess its svn these days)? I know the version available as an rpm for Fedora Core 6 wont work. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Compile failure
Didier Fabert wrote: Le Thursday 15 March 2007 00:57:07 Laurence Vanek, vous avez écrit : Is the version of OSG you are using from cvs (I guess its svn these days)? I know the version available as an rpm for Fedora Core 6 wont work. I use the SVN version of OSG. i have made an update of OSG, simgear and flightgear today, and all are compiling and running correctly. Didier. thanks so do I. I was trying to help the original poster. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG cvs (OSG) seg fault
Ron Jensen wrote: On Tue, 2007-02-20 at 22:45 -0600, Laurence Vanek wrote: After fresh cvs updates of OpenSceneGraph FlightGear I got a seg fault during inital startup. backtrack below: snip Laurence, You did rebuild simgear, too, right? Build order should be OSG-simgear-flightgear Ron - That is my usual build order. Since I did not note any updates to Simgear (cvs update -dP) I had skipped the build of Simgear after building OSG. Apparently, I should not have done that. Doing cvs updates builds of OSG, SimGear, FG worked this time around. Thanks for advice. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FG cvs (OSG) seg fault
After fresh cvs updates of OpenSceneGraph FlightGear I got a seg fault during inital startup. backtrack below: == (gdb) run Starting program: /home/lvanek/FlightGear-0.9/source/src/Main/fgfs [Thread debugging using libthread_db enabled] [New Thread -1208404240 (LWP 21753)] [New Thread 27581328 (LWP 21756)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208404240 (LWP 21753)] 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x008fdb32 in osg::Transform::computeBound () at /usr/local/include/osg/Referenced:130 #2 0x085231b4 in SGReadFileCallback::readNode (this=0x9a01bc8, [EMAIL PROTECTED], opt=0x9a018a0) at model.cxx:237 #3 0x009e8d48 in osgDB::readNodeFile () at /usr/local/include/osg/Referenced:130 #4 0x0851cc6d in sgLoad3DModel ([EMAIL PROTECTED], [EMAIL PROTECTED], prop_root=0x9a0efc0, sim_time_sec=0, load_panel=0x83eadc0 load_panel, data=0x0, [EMAIL PROTECTED]) at /usr/local/include/osgDB/ReadFile:107 #5 0x083eadad in fgLoad3DModelPanel ([EMAIL PROTECTED], [EMAIL PROTECTED], prop_root=0x9a0efc0, sim_time_sec=0, [EMAIL PROTECTED]) at model_panel.cxx:43 #6 0x083ea6fa in FGAircraftModel::init (this=0xbbcf480) at acmodel.cxx:76 #7 0x0805e0e6 in fgIdleFunction () at main.cxx:750 #8 0x0809e051 in GLUTidle () at fg_os.cxx:122 #9 0x00632d6f in glutMainLoop () at /usr/local/include/osg/Referenced:130 #10 0x0805d8a2 in fgMainInit (argc=1, argv=0xbfd56464) at main.cxx:1029 #11 0x0805c745 in main (argc=0, argv=0x0) at bootstrap.cxx:209 (gdb) c Continuing. Program terminated with signal SIGSEGV, Segmentation fault. The program no longer exists. (gdb) quit = I noted quite a few updates to OSG so perhaps therein we have the problem(s). Im running linux Fedora Core 6. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] 787
I love this model. My company is designing hardware for this aircraft. Very nice work. Now starts up ok using FG cvs OSG (used to crash on initialization). I get these messages at in terminal window: === . . . Nasal runtime error: function/method call invoked on uncallable object at /home/lvanek/FlightGear-0.9/data/Nasal/controls.nas, line 351 Nasal runtime error: function/method call invoked on uncallable object at /home/lvanek/FlightGear-0.9/data/Nasal/controls.nas, line 351 Nasal runtime error: function/method call invoked on uncallable object at /home/lvanek/FlightGear-0.9/data/Nasal/controls.nas, line 351 Nasal runtime error: function/method call invoked on uncallable object at /home/lvanek/FlightGear-0.9/data/Nasal/controls.nas, line 351 Nasal runtime error: function/method call invoked on uncallable object at /home/lvanek/FlightGear-0.9/data/Nasal/controls.nas, line 351 . . . . === I am not able to zoom in or out in the cockpit but can pan around. Running Fedora Core 6. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] 787 startup issue - FG CVS OSG
While attempting to tryout latest 787 updates, I get this sample of output errors during program initialization: === . . . called from: tth_filter, line 90 called from: tth_filter, line 90 called from: tth_filter, line 90 called from: tth_filter, line 90 called from: tth_filter, line 90 called from: tth_filter, line 90 called from: /home/lvanek/FlightGear-0.9/data/Nasal/view.nas, line 94 called from: /home/lvanek/FlightGear-0.9/data/Nasal/dynamic_view.nas, line 431 called from: /home/lvanek/FlightGear-0.9/data/Nasal/dynamic_view.nas, line 441 Nasal runtime error: call stack overflow at tth_filter, line 90 called from: tth_filter, line 90 called from: tth_filter, line 90 called from: tth_filter, line 90 called from: tth_filter, line 90 . . . . After program startup, cockpit view is seriously corrupted panel unresponsive (at least part I can recognize). I had been able to run the 787 back in my PLIB days. Running Fedora Core 6, Nvidia GeForce 7600 GS graphics card. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] glibc invalid pointer error - fgfs cvs osg (UPDATE)
Laurence Vanek wrote: After fresh updates builds of osg, simgear fg I get this when executing flightgear from command line (sorry for the long post). This is new behavior for me. Im running Fedora Core 6 with nvidia geforce 7600 GS graphics card (256 megs VRAM). No problems prior to latest cvs update. There have been no recent updates to nvidia drivers or glibc on this machine. FG seems to startup as always - odd. == [EMAIL PROTECTED] ~]$ fgfs --aircraft=c172p Model Author: Unknown Creation Date: 2002-01-01 Version: $Id: c172p.xml,v 1.18 2007-01-15 12:50:45 ehofman Exp $ Description: Cessna C-172 Initializing Nasal Electrical System power up *** glibc detected *** fgfs: free(): invalid pointer: 0x08f2b880 *** === Backtrace: = /lib/libc.so.6[0xe2b09d] /lib/libc.so.6(cfree+0x90)[0xe2e6f0] /usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xb89ef1] /usr/local/lib/libOpenThreads.so(_ZN11OpenThreads5MutexD0Ev+0x4a)[0x96383a] /usr/local/lib/libosg.so(_ZN3osg10ReferencedD2Ev+0x160)[0x4bac30] /usr/local/lib/libosg.so(_ZN3osg4NodeD2Ev+0x211)[0x499fb1] /usr/local/lib/libosg.so(_ZN3osg5GroupD2Ev+0x10e)[0x47f53e] /usr/local/lib/libosg.so(_ZN3osg9TransformD2Ev+0x28)[0x50dee8] /usr/local/lib/libosg.so(_ZN3osg6CameraD0Ev+0x2c7)[0x40ced7] /usr/local/lib/libosg.so(_ZN3osg5GroupD2Ev+0xea)[0x47f51a] /usr/local/lib/libosg.so(_ZN3osg11LightSourceD0Ev+0x7e)[0x487b7e] /usr/local/lib/libosg.so(_ZN3osg5GroupD0Ev+0xea)[0x47f13a] /usr/local/lib/libosg.so(_ZN3osg5GroupD2Ev+0xea)[0x47f51a] /usr/local/lib/libosg.so(_ZN3osg9TransformD2Ev+0x28)[0x50dee8] /usr/local/lib/libosg.so(_ZN3osg10CameraViewD0Ev+0x2d)[0x411ccd] /usr/local/lib/libosg.so(_ZN3osg5GroupD2Ev+0xea)[0x47f51a] /usr/local/lib/libosg.so(_ZN3osg9TransformD2Ev+0x28)[0x50dee8] /usr/local/lib/libosg.so(_ZN3osg6CameraD0Ev+0x2c7)[0x40ced7] /usr/local/lib/libosgUtil.so(_ZN7osgUtil9SceneViewD0Ev+0xe1)[0x310101] fgfs[0x806390d] /lib/libc.so.6(exit+0xe9)[0xdf0939] fgfs[0x809474e] fgfs[0x8070890] fgfs[0x8598abd] fgfs[0x82f91e7] /usr/lib/libplibpu.so.1.8.4(_ZN8puButton5doHitE+0x126)[0x7b9496] /usr/lib/libplibpu.so.1.8.4(_ZN9puOneShot5doHitE+0x3e)[0x7c070e] /usr/lib/libplibpu.so.1.8.4(_ZN8puObject8checkHitE+0x78)[0x7bf1f8] /usr/lib/libplibpu.so.1.8.4(_ZN7puGroup8checkHitE+0x154)[0x7bc434] /usr/lib/libplibpu.so.1.8.4(_ZN7puGroup8checkHitE+0x154)[0x7bc434] /usr/lib/libplibpu.so.1.8.4(_Z7puMouse+0x85)[0x7b86a5] fgfs[0x83202ac] fgfs[0x831c8f4] /usr/local/lib/libglut.so.3(glutMainLoopEvent+0x274)[0x9d7594] /usr/local/lib/libglut.so.3(glutMainLoop+0x51)[0x9d7d21] fgfs[0x805d7c2] fgfs[0x805c665] /lib/libc.so.6(__libc_start_main+0xdc)[0xddaf2c] fgfs(_ZN7puGroup4drawEii+0x115)[0x805c471] === Memory map: 0011-00123000 r-xp 09:02 7799016/lib/libpthread-2.5.so 00123000-00124000 r-xp 00012000 09:02 7799016/lib/libpthread-2.5.so 00124000-00125000 rwxp 00013000 09:02 7799016/lib/libpthread-2.5.so 00125000-00127000 rwxp 00125000 00:00 0 00127000-00129000 r-xp 09:02 7799040/lib/libdl-2.5.so 00129000-0012a000 r-xp 1000 09:02 7799040/lib/libdl-2.5.so 0012a000-0012b000 rwxp 2000 09:02 7799040/lib/libdl-2.5.so 0012b000-00144000 r-xp 09:02 7799006/lib/ld-2.5.so 00144000-00145000 r-xp 00018000 09:02 7799006/lib/ld-2.5.so 00145000-00146000 rwxp 00019000 09:02 7799006/lib/ld-2.5.so 00146000-001d9000 r-xp 09:02 25986442 /usr/local/lib/libosgSim.so 001d9000-001dc000 rwxp 00093000 09:02 25986442 /usr/local/lib/libosgSim.so 001dc000-001ee000 r-xp 09:02 17826407 /usr/lib/libz.so.1.2.3 001ee000-001ef000 rwxp 00011000 09:02 17826407 /usr/lib/libz.so.1.2.3 001ef000-00205000 r-xp 09:02 25993589 /usr/lib/libXmu.so.6.2.0 00205000-00206000 rwxp 00016000 09:02 25993589 /usr/lib/libXmu.so.6.2.0 00206000-0020b000 r-xp 09:02 17826337 /usr/lib/libalut.so.0.1.0 0020b000-0020e000 rwxp 4000 09:02 17826337 /usr/lib/libalut.so.0.1.0 0020e000-00219000 r-xp 09:02 7799649 /lib/libgcc_s-4.1.1-20070105.so.1 00219000-0021a000 rwxp a000 09:02 7799649 /lib/libgcc_s-4.1.1-20070105.so.1 0021a000-0021c000 r-xp 09:02 17826411 /usr/lib/libXau.so.6.0.0 0021c000-0021d000 rwxp 1000 09:02 17826411 /usr/lib/libXau.so.6.0.0 0021d000-00239000 r-xp 09:02 26004620 /usr/lib/libplibpuaux.so.1.8.4 00239000-0023a000 rwxp 0001b000 09:02 26004620 /usr/lib/libplibpuaux.so.1.8.4 0023a000-00376000 r-xp 09:02 25986465 /usr/local/lib/libosgUtil.so 00376000-0037d000 rwxp 0013b000 09:02 25986465 /usr/local/lib/libosgUtil.so 0037d000-0056b000 r-xp 09:02 25986446 /usr/local/lib/libosg.so 0056b000-00573000 rwxp 001ee000 09:02 25986446 /usr/local/lib/libosg.so 00573000-00574000 rwxp 00573000 00:00 0 00574000-00672000 r-xp 09:02 26009959 /usr/lib/libX11.so.6.2.0 00672000-00676000 rwxp
[Flightgear-devel] glibc invalid pointer error - fgfs cvs osg
After fresh updates builds of osg, simgear fg I get this when executing flightgear from command line (sorry for the long post). This is new behavior for me. Im running Fedora Core 6 with nvidia geforce 7600 GS graphics card (256 megs VRAM). No problems prior to latest cvs update. There have been no recent updates to nvidia drivers or glibc on this machine. FG seems to startup as always - odd. == [EMAIL PROTECTED] ~]$ fgfs --aircraft=c172p Model Author: Unknown Creation Date: 2002-01-01 Version: $Id: c172p.xml,v 1.18 2007-01-15 12:50:45 ehofman Exp $ Description: Cessna C-172 Initializing Nasal Electrical System power up *** glibc detected *** fgfs: free(): invalid pointer: 0x08f2b880 *** === Backtrace: = /lib/libc.so.6[0xe2b09d] /lib/libc.so.6(cfree+0x90)[0xe2e6f0] /usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xb89ef1] /usr/local/lib/libOpenThreads.so(_ZN11OpenThreads5MutexD0Ev+0x4a)[0x96383a] /usr/local/lib/libosg.so(_ZN3osg10ReferencedD2Ev+0x160)[0x4bac30] /usr/local/lib/libosg.so(_ZN3osg4NodeD2Ev+0x211)[0x499fb1] /usr/local/lib/libosg.so(_ZN3osg5GroupD2Ev+0x10e)[0x47f53e] /usr/local/lib/libosg.so(_ZN3osg9TransformD2Ev+0x28)[0x50dee8] /usr/local/lib/libosg.so(_ZN3osg6CameraD0Ev+0x2c7)[0x40ced7] /usr/local/lib/libosg.so(_ZN3osg5GroupD2Ev+0xea)[0x47f51a] /usr/local/lib/libosg.so(_ZN3osg11LightSourceD0Ev+0x7e)[0x487b7e] /usr/local/lib/libosg.so(_ZN3osg5GroupD0Ev+0xea)[0x47f13a] /usr/local/lib/libosg.so(_ZN3osg5GroupD2Ev+0xea)[0x47f51a] /usr/local/lib/libosg.so(_ZN3osg9TransformD2Ev+0x28)[0x50dee8] /usr/local/lib/libosg.so(_ZN3osg10CameraViewD0Ev+0x2d)[0x411ccd] /usr/local/lib/libosg.so(_ZN3osg5GroupD2Ev+0xea)[0x47f51a] /usr/local/lib/libosg.so(_ZN3osg9TransformD2Ev+0x28)[0x50dee8] /usr/local/lib/libosg.so(_ZN3osg6CameraD0Ev+0x2c7)[0x40ced7] /usr/local/lib/libosgUtil.so(_ZN7osgUtil9SceneViewD0Ev+0xe1)[0x310101] fgfs[0x806390d] /lib/libc.so.6(exit+0xe9)[0xdf0939] fgfs[0x809474e] fgfs[0x8070890] fgfs[0x8598abd] fgfs[0x82f91e7] /usr/lib/libplibpu.so.1.8.4(_ZN8puButton5doHitE+0x126)[0x7b9496] /usr/lib/libplibpu.so.1.8.4(_ZN9puOneShot5doHitE+0x3e)[0x7c070e] /usr/lib/libplibpu.so.1.8.4(_ZN8puObject8checkHitE+0x78)[0x7bf1f8] /usr/lib/libplibpu.so.1.8.4(_ZN7puGroup8checkHitE+0x154)[0x7bc434] /usr/lib/libplibpu.so.1.8.4(_ZN7puGroup8checkHitE+0x154)[0x7bc434] /usr/lib/libplibpu.so.1.8.4(_Z7puMouse+0x85)[0x7b86a5] fgfs[0x83202ac] fgfs[0x831c8f4] /usr/local/lib/libglut.so.3(glutMainLoopEvent+0x274)[0x9d7594] /usr/local/lib/libglut.so.3(glutMainLoop+0x51)[0x9d7d21] fgfs[0x805d7c2] fgfs[0x805c665] /lib/libc.so.6(__libc_start_main+0xdc)[0xddaf2c] fgfs(_ZN7puGroup4drawEii+0x115)[0x805c471] === Memory map: 0011-00123000 r-xp 09:02 7799016/lib/libpthread-2.5.so 00123000-00124000 r-xp 00012000 09:02 7799016/lib/libpthread-2.5.so 00124000-00125000 rwxp 00013000 09:02 7799016/lib/libpthread-2.5.so 00125000-00127000 rwxp 00125000 00:00 0 00127000-00129000 r-xp 09:02 7799040/lib/libdl-2.5.so 00129000-0012a000 r-xp 1000 09:02 7799040/lib/libdl-2.5.so 0012a000-0012b000 rwxp 2000 09:02 7799040/lib/libdl-2.5.so 0012b000-00144000 r-xp 09:02 7799006/lib/ld-2.5.so 00144000-00145000 r-xp 00018000 09:02 7799006/lib/ld-2.5.so 00145000-00146000 rwxp 00019000 09:02 7799006/lib/ld-2.5.so 00146000-001d9000 r-xp 09:02 25986442 /usr/local/lib/libosgSim.so 001d9000-001dc000 rwxp 00093000 09:02 25986442 /usr/local/lib/libosgSim.so 001dc000-001ee000 r-xp 09:02 17826407 /usr/lib/libz.so.1.2.3 001ee000-001ef000 rwxp 00011000 09:02 17826407 /usr/lib/libz.so.1.2.3 001ef000-00205000 r-xp 09:02 25993589 /usr/lib/libXmu.so.6.2.0 00205000-00206000 rwxp 00016000 09:02 25993589 /usr/lib/libXmu.so.6.2.0 00206000-0020b000 r-xp 09:02 17826337 /usr/lib/libalut.so.0.1.0 0020b000-0020e000 rwxp 4000 09:02 17826337 /usr/lib/libalut.so.0.1.0 0020e000-00219000 r-xp 09:02 7799649 /lib/libgcc_s-4.1.1-20070105.so.1 00219000-0021a000 rwxp a000 09:02 7799649 /lib/libgcc_s-4.1.1-20070105.so.1 0021a000-0021c000 r-xp 09:02 17826411 /usr/lib/libXau.so.6.0.0 0021c000-0021d000 rwxp 1000 09:02 17826411 /usr/lib/libXau.so.6.0.0 0021d000-00239000 r-xp 09:02 26004620 /usr/lib/libplibpuaux.so.1.8.4 00239000-0023a000 rwxp 0001b000 09:02 26004620 /usr/lib/libplibpuaux.so.1.8.4 0023a000-00376000 r-xp 09:02 25986465 /usr/local/lib/libosgUtil.so 00376000-0037d000 rwxp 0013b000 09:02 25986465 /usr/local/lib/libosgUtil.so 0037d000-0056b000 r-xp 09:02 25986446 /usr/local/lib/libosg.so 0056b000-00573000 rwxp 001ee000 09:02 25986446 /usr/local/lib/libosg.so 00573000-00574000 rwxp 00573000 00:00 0 00574000-00672000 r-xp 09:02 26009959 /usr/lib/libX11.so.6.2.0 00672000-00676000 rwxp 000fd000 09:02 26009959 /usr/lib/libX11.so.6.2.0 00676000-006b1000 r-xp 09:02 17826373
Re: [Flightgear-devel] Rendered geometry/scenery graphics messed up on my Fedora 6 system with NVidia GeForce 600 graphics card
Rob Ratcliff wrote: Hi, I just started working with FlightGear. I checked out the latest (head of trunk) distribution of FlightGear, data and SimGear from CVS. After finding that fgfs and js_demo core dumped with the existing rpm versions of the dependent libraries, I grabbed the latest CVS/SVN sources for OpenThreads, OpenProducer, OpenSceneGraph, plib, freeglut and recompiled. (The .9.10 release also core dumped with the released rpms of these libraries as well on my box.) So now the programs run without core dumping, but I'm having trouble with the rendering as shown in this picture: http://www.futuretek.com/flight/flight1.jpg I can hear the sound and see the heads up display, the cockpit instruments, the runway lights and the sun, but the airplane and scenery geometry isn't being rendered correctly. Any ideas why this would be occurring and how to fix it? Thanks, Rob p.s. Here's some information about my system in case that helps: [EMAIL PROTECTED] bin]$ gl-info GL_VENDOR = NVIDIA Corporation GL_RENDERER = GeForce Go 6800 Ultra/PCI/SSE2 GL_VERSION = 2.1.0 NVIDIA 97.46 GL_EXTENSIONS = GL_ARB_color_buffer_float GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_half_float_pixel GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_ATI_draw_buffers GL_ATI_texture_float GL_ATI_texture_mirror_once GL_S3_s3tc GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_Cg_shader GL_EXT_depth_bounds_test GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXT_gpu_program_parameters GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_pixels GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_sRGB GL_EXT_timer_query GL_EXT_vertex_array GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_blend_square GL_NV_copy_depth_to_color GL_NV_depth_clamp GL_NV_fence GL_NV_float_buffer GL_NV_fog_distance GL_NV_fragment_program GL_NV_fragment_program_option GL_NV_fragment_program2 GL_NV_framebuffer_multisample_coverage GL_NV_half_float GL_NV_light_max_exponent GL_NV_multisample_filter_hint GL_NV_occlusion_query GL_NV_packed_depth_stencil GL_NV_pixel_data_range GL_NV_point_sprite GL_NV_primitive_restart GL_NV_register_combiners GL_NV_register_combiners2 GL_NV_texgen_reflection GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 GL_NV_texture_expand_normal GL_NV_texture_rectangle GL_NV_texture_shader GL_NV_texture_shader2 GL_NV_texture_shader3 GL_NV_vertex_array_range GL_NV_vertex_array_range2 GL_NV_vertex_program GL_NV_vertex_program1_1 GL_NV_vertex_program2 GL_NV_vertex_program2_option GL_NV_vertex_program3 GL_NVX_conditional_render GL_SGIS_generate_mipmap GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow GL_SUN_slice_accum GL_RED_BITS = 8 GL_GREEN_BITS = 8 GL_BLUE_BITS = 8 GL_ALPHA_BITS = 0 GL_DEPTH_BITS = 24 GL_INDEX_BITS = 0 GL_STENCIL_BITS = 0 GL_ACCUM_RED_BITS = 16 GL_ACCUM_GREEN_BITS = 16 GL_ACCUM_BLUE_BITS = 16 GL_ACCUM_ALPHA_BITS = 16 GL_AUX_BUFFERS = 4 GL_MAX_ATTRIB_STACK_DEPTH = 16 GL_MAX_NAME_STACK_DEPTH = 128 GL_MAX_TEXTURE_STACK_DEPTH = 10 GL_MAX_PROJECTION_STACK_DEPTH = 4 GL_MAX_MODELVIEW_STACK_DEPTH = 32 GL_MAX_CLIP_PLANES = 6 GL_MAX_EVAL_ORDER = 8 GL_MAX_LIGHTS = 8 GL_MAX_LIST_NESTING = 64 GL_MAX_TEXTURE_SIZE = 4096 GL_MAX_VIEWPORT_DIMS = 4096,4096 GL_POINT_SIZE_GRANULARITY = 0.125 GL_POINT_SIZE_RANGE = 1,63.375 Default values: GL_UNPACK_ALIGNMENT = 4 GL_UNPACK_ROW_LENGTH = 0 GL_UNPACK_SKIP_PIXELS = 0 GL_UNPACK_SKIP_ROWS = 0 GL_BLEND_SRC = 1 GL_BLEND_DST = 0 xwininfo: Window id: 0x123 Desktop Absolute upper-left X: 0 Absolute upper-left Y: 0
