Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
On Wednesday 24 October 2007 00:15, Vivian Meazza wrote: Not here, I'm afraid. Very good frame rates using the Buccaneer (70+) but there are still noticeable pauses over land. None over the ocean tiles. The pauses, or hesitations do not seem to be associated with any Subsystem Timing Alert, of which there are almost none. Hmmm, I didn't say that FlightGear is completely pause free now. I did say that the mysterious interval pauses are gone. These are the pauses that become increasingly longer and longer over time (up to the point of several seconds, or even minutes). The interval pauses are not affected by terrain type or whatever, and originate because the nasal memory footprint keeps growing and growing. From the sound of it, you're experiencing model loading pauses (either caused by Multiplayer / AI, of the tile loader). Most likely, the pauses you see correspond to pauses coming from the terrain loader (since they don't correspond to Subsystem activity). To verify, place a debug statement in simgear/scene/model/model.cxx, line 462, or thereabouts. Something like: SG_LOG(SG_GENERAL, SG_INFO, Requesting model path); and see if that message corresponds to the pauses you see. Its obvious that eventually we need to address these pauses too. This may take a bit longer, because it requires redesigning. In plib we're actually hitting a design limitation, but in OSG it should be possible. Having said that, addressing the model loading pauses isn't nearly as daunting, because the problem is well understood. This is stark contrast with the interval pausing, where none of us really had a good idea what was going on, until about a week ago or so. Cheers, Durk - 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] FlightGear/Plib periodic stutter notes
Georg Vollnhals Sent: 23 October 2007 23:34 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes Vivian Meazza schrieb: Not here, I'm afraid. Very good frame rates using the Buccaneer (70+) but there are still noticeable pauses over land. None over the ocean tiles. The pauses, or hesitations do not seem to be associated with any Subsystem Timing Alert, of which there are almost none. Regards, Vivian Hi Vivian, mmmh, as it really works for me as I already posted I want to add that my test still was made with Sync to VBlank on AND all AI stuff swiched off in the preferences.xml. AI stuff might now work without resulting in stuttering, I have to test it, but I doubt that I can omit the Sync switch, this seems to be another special problem. Did you think of that? I have tested with vsync on and off. On balance vsync on seems to make the situation worse. I have also tried throttling the frame rate: this definitely is counterproductive, noticeably increasing the frequency and magnitude of the hesitations. One significant difference is that the Buccaneer has no malformed listeners in its Nasal so the gain in correcting this bug would, I think, be marginal. Vivian - 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] FlightGear/Plib periodic stutter notes
Durk Sent: 24 October 2007 07:22 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes On Wednesday 24 October 2007 00:15, Vivian Meazza wrote: Not here, I'm afraid. Very good frame rates using the Buccaneer (70+) but there are still noticeable pauses over land. None over the ocean tiles. The pauses, or hesitations do not seem to be associated with any Subsystem Timing Alert, of which there are almost none. Hmmm, I didn't say that FlightGear is completely pause free now. I did say that the mysterious interval pauses are gone. These are the pauses that become increasingly longer and longer over time (up to the point of several seconds, or even minutes). The interval pauses are not affected by terrain type or whatever, and originate because the nasal memory footprint keeps growing and growing. From the sound of it, you're experiencing model loading pauses (either caused by Multiplayer / AI, of the tile loader). Most likely, the pauses you see correspond to pauses coming from the terrain loader (since they don't correspond to Subsystem activity). To verify, place a debug statement in simgear/scene/model/model.cxx, line 462, or thereabouts. Something like: SG_LOG(SG_GENERAL, SG_INFO, Requesting model path); and see if that message corresponds to the pauses you see. Its obvious that eventually we need to address these pauses too. This may take a bit longer, because it requires redesigning. In plib we're actually hitting a design limitation, but in OSG it should be possible. Having said that, addressing the model loading pauses isn't nearly as daunting, because the problem is well understood. This is stark contrast with the interval pausing, where none of us really had a good idea what was going on, until about a week ago or so. Thanks for clearing that up: yes, we do seem to have cleared a significant bug. Your analysis of the problem seems plausible. I'll try the debug statement later today. Vivian - 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] FlightGear/Plib periodic stutter notes
Heiko Schulz Sent: 23 October 2007 23:55 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes Hi, Couldn't test it, waiting that someones will do a precompiled binary for windows. But it sounds good, very good though at least there are still some perfomance issues. I think of AI and the loading of the scenery tiles. What Vivian is writing sounds for me like the stutters of loading of objects. If I use Random Objects FGFS is hardly to use, even I decrease the count of objects. It would be good if Vivian could send his choosen settings for comparing. HHS --- Georg Vollnhals [EMAIL PROTECTED] schrieb: Vivian Meazza schrieb: Not here, I'm afraid. Very good frame rates using the Buccaneer (70+) but there are still noticeable pauses over land. None over the ocean tiles. The pauses, or hesitations do not seem to be associated with any Subsystem Timing Alert, of which there are almost none. Regards, Vivian Hi Vivian, mmmh, as it really works for me as I already posted I want to add that my test still was made with Sync to VBlank on AND all AI stuff swiched off in the preferences.xml. AI stuff might now work without resulting in stuttering, I have to test it, but I doubt that I can omit the Sync switch, this seems to be another special problem. Did you think of that? This test was run with every option de-selected, including --prop:/sim/replay/disable=1 Vivian - 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] Positioning Point of View and controlling direction I look
Mike Yukish wrote: More questions! So how do I change the direction in which I am viewing and the position that I am viewing from? I did not see them in the list of properties, which seemed like a good guess on where they'd be. The camera balls on aircraft typically are hanging below the fuselage. You can set the position, field of view, and initial view direction (along with all sort of other stuff not covered by adding a new view to the aircraft config - the following just needs adding to the -set.xml file somewhere between the sim/sim tags: view n=100 internal archive=ytrue/internal config nameYour view name here/name typelookfrom/type x-offset-m archive=y -0.237 /x-offset-m !-- Right -- y-offset-m archive=y 0.291 /y-offset-m !-- Up-- z-offset-m archive=y -1.172 /z-offset-m !-- Back -- pitch-offset-deg0/pitch-offset-deg roll-offset-deg0/roll-offset-deg yaw-offset-deg0/yaw-offset-deg /config /view It's possible to define a whole load of views in this way - user defined views should start from n=100. Jon - 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] FlightGear/Plib periodic stutter notes
The Seneca is special in that it attaches listeners to YASim internal properties, which are updated multiple times per frame, unlike most other listeners, which run *at most* once per frame, but actually very rarely. Oh - wasn't it using JSBSim as fdm!? I hope that the stuttering is fixed for all. And in any case should the Seneca fix its listener use. For example, by using on-change-only listeners, or using a simple loop which checks the interesting values once per frame. I'm available for consulting if necessary. :-) I am working on this and have removed most of the frequent-update listeners in my local copy. I will have it ready for cvs soon after some more testing here. At least my listener-loaded-code was not *that* bad: It helped Durk to track the stutter-bug. Now that I know it is found, I can safely remove this bug-showing-feature in the Seneca-code ;-) Thanks all for the great work! Torsten - 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] backtrace dump
I was just a bit worried since it seems that there was always a problem when it tried to download that specific file.. - But as i think about it- you may actually be right... i dont know enough about how its being loaded so who knows :-) Okay, i have to give it a try as soon as i get home to my test platform. Ill write as soon as i know anything. 2007/10/23, Csaba Halász [EMAIL PROTECTED]: On 10/23/07, Tobias Nielsen [EMAIL PROTECTED] wrote: Im not convinced that this is an issue of the ATI problem Maybe, but any backtrace involving DrawArrayLengths rings the alarm bell for me :) -- Csaba - 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 -- Yours kindly Tobias Nielsen - 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] FlightGear/Plib periodic stutter notes
* Torsten Dreyer -- Wednesday 24 October 2007: The Seneca is special in that it attaches listeners to YASim internal properties, which are updated multiple times per frame, unlike most other listeners, [...] Oh - wasn't it using JSBSim as fdm!? Indeed. I remembered that wrongly because the Seneca doesn't have a SenecaII-set.xml file, but only a SenecaII-jsbsim-set.xml, which is usually only done when there are more choices. (I have that shorter name as a line to the long one.) I [...] have removed most of the frequent-update listeners in my local copy. [...] At least my listener-loaded-code was not *that* bad: True, kind-of. But the reason why I found evidence for a bug in Nasal's garbage collector had nothing to do with the Seneca, or claims that listeners are slow. This was just because I worked on making FGBinding::fire() faster, as this was another point on Durk's blacklist. I use the node refcounter for the script cache's own garbage collector, so I printed it to the console, and the steadily increasing counter for the throttle binding property rang the alarm bell. :-) Although some of the listeners in the Seneca are used inefficiently, they were mostly bad because of that GC bug. Now that this is fixed, they are only unfortunate, but no longer evil. Listeners should be used on properties to get notice about occasional changes. In cases where we *know* when the property changes -- once per loop or more often -- we can have the same result cheaper with a loop. (Listeners on YASim properties are special in that those can change several times per frame, and one may indeed want the listener triggered every time. But this should be a deliberate decision, not an accident.) For some of your listeners it may be enough to set the second optional argument to 0, so that the listener code is only triggered when the node value changes. Just turn on listener logging or put a print() message into it to see the costs. $ fgfs --log-level=debug 21|grep listener m. - 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] Compiling FlightGear-0.9.11-pre1
Hi guys, Thanks to the person who gave me pointers on how to correct the plib compile problem. I still have another problem though. I get the following error when I try to compile FlightGear-0.9.11-pre1 est-epsilon.c:13:19: error: GL/glut.h: No such file or directory est-epsilon.c: In function 'main': est-epsilon.c:17: error: 'GLfloat' undeclared (first use in this function) est-epsilon.c:17: error: (Each undeclared identifier is reported only once est-epsilon.c:17: error: for each function it appears in.) est-epsilon.c:17: error: expected ';' before 'a' est-epsilon.c:19: error: 'a' undeclared (first use in this function) est-epsilon.c:24: error: 't' undeclared (first use in this function) make[1]: *** [est-epsilon.o] Error 1 make[1]: Leaving directory `/root/FlightGear-0.9.11-pre1/tests' make: *** [all-recursive] Error 1 I checked for the file glut.h in the FlightGear-0.9.11-pre1 directoty structure but it isn't there. Does anyone have ideas? I thought of excluding the whole test directory from the compile but I'm not sure of the effect. - 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] Compiling FlightGear-0.9.11-pre1
On 10/24/07, Nick Othieno [EMAIL PROTECTED] wrote: I checked for the file glut.h in the FlightGear-0.9.11-pre1 directoty structure but it isn't there. Does anyone have ideas? I thought of excluding the whole test directory from the compile but I'm not sure of the effect. Install glut development package for your distribution. In debian, that could be freeglut3-dev or glutg3-dev. FYI, on the irc channel you can get quicker answers to such questions. -- Csaba - 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] Compiling FlightGear-0.9.11-pre1
glut.h comes with your glut installation. If you don't have glut installed, try freeglut at http://freeglut.sourceforge.net/ If you're in Linux the header files will probably be stored in /usr/share/include or similar depending on distro. Jonathan Wagner Nick Othieno wrote: Hi guys, Thanks to the person who gave me pointers on how to correct the plib compile problem. I still have another problem though. I get the following error when I try to compile FlightGear-0.9.11-pre1 est-epsilon.c :13:19: error: GL/glut.h: No such file or directory est-epsilon.c: In function 'main': est-epsilon.c:17: error: 'GLfloat' undeclared (first use in this function) est-epsilon.c:17: error: (Each undeclared identifier is reported only once est-epsilon.c:17: error: for each function it appears in.) est-epsilon.c:17: error: expected ';' before 'a' est-epsilon.c:19: error: 'a' undeclared (first use in this function) est-epsilon.c:24: error: 't' undeclared (first use in this function) make[1]: *** [est-epsilon.o] Error 1 make[1]: Leaving directory `/root/FlightGear-0.9.11-pre1/tests' make: *** [all-recursive] Error 1 I checked for the file glut.h in the FlightGear-0.9.11-pre1 directoty structure but it isn't there. Does anyone have ideas? I thought of excluding the whole test directory from the compile but I'm not sure of the effect. - 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 - 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] FlightGear/Plib periodic stutter notes
Heiko, I applied the patches to plib branch (I get runtime errors with FG link against OSG 2.2 that I haven't figured out): http://www.rato.us/flightgear/builds/plib/20071024plibexe.zip -Reagan On 10/23/07, Heiko Schulz [EMAIL PROTECTED] wrote: Hi, Couldn't test it, waiting that someones will do a precompiled binary for windows. But it sounds good, very good though at least there are still some perfomance issues. I think of AI and the loading of the scenery tiles. What Vivian is writing sounds for me like the stutters of loading of objects. If I use Random Objects FGFS is hardly to use, even I decrease the count of objects. It would be good if Vivian could send his choosen settings for comparing. HHS --- Georg Vollnhals [EMAIL PROTECTED] schrieb: Vivian Meazza schrieb: Not here, I'm afraid. Very good frame rates using the Buccaneer (70+) but there are still noticeable pauses over land. None over the ocean tiles. The pauses, or hesitations do not seem to be associated with any Subsystem Timing Alert, of which there are almost none. Regards, Vivian Hi Vivian, mmmh, as it really works for me as I already posted I want to add that my test still was made with Sync to VBlank on AND all AI stuff swiched off in the preferences.xml. AI stuff might now work without resulting in stuttering, I have to test it, but I doubt that I can omit the Sync switch, this seems to be another special problem. Did you think of that? Regards Georg - 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 Heute schon einen Blick in die Zukunft von E-Mails wagen? www.yahoo.de/mail - 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 - 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] backtrace dump
Ill write as soon as i know anything. Nope the problem still exists - still breaks down the same place.. :-( - 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] Compiling FlightGear-0.9.11-pre1
Hello Nick, seems you are about to go a long way. For windows ( and free Microsoft compiler ) you might find useful the following page http://www.sim-ai.org/FlightGearlesson.htm ( one of the draft of set of lessons ) where all code is already compiled and tested ( for where to get compiler take a look here http://www.sim-ai.org/simplestgame.htm ) Regards Sergey On 10/24/07, Nick Othieno - 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] FlightGear/Plib periodic stutter notes
On Wednesday 24 October 2007 11:21, Melchior FRANZ wrote: [snip...] Listeners should be used on properties to get notice about occasional changes. In cases where we *know* when the property changes -- once per loop or more often -- we can have the same result cheaper with a loop. (Listeners on YASim properties are special in that those can change several times per frame, and one may indeed want the listener triggered every time. But this should be a deliberate decision, not an accident.) This touches on the area that became a show-stopper for me and while it's good news to see some of the problems being chased down and cleared imho there are still some vital things that need to be addressed. The problem, as I see it, is that there are two different timing regimes in FG: the fixed rate FDM timing and the variable frame-rate timing. That is, the FDM operates at a fixed rate (I believe the default is 120 Hz) but nearly everything else, afaikt, operates at the frame rate, which varies. This means that if I'm trying to use Nasal (and the A/P PID controllers and filters) in a FBW framework not only do I need them to run at a specified fixed and non-varying rate but ideally I'd want them to run at the FDM fixed rate and in lock-step with it because if I just run these subsystems at the FDM fixed rate, but not locked to the FDM clock, they are likely to drift and I'd end up getting an effective rate that varied between the FDM rate and the FDM rate/2 as they drift into and out of synchronisation. Because 120 Hz isn't really that high, in the context of GHz processing speeds, I would have thought Nasal would be ok for this purpose but am I expecting too much of it? Perhaps the real problem is that nearly every other subsystem, apart from the FDM, get their turn on the CPU within the frame-rate loop and although this would seem to make obvious sense, because the graphics sub-system is by far the greatest user of resources, I'd suggest that if the other subsystems use so little of the available resources, giving them priority over the graphics would have a negligible impact on the frame rate, which is variable according to graphics load anyway. For example, if the graphics subsystem uses 95% of resources to produce 40 fps it's still likely to return 35 fps if it's only given 90% of resources (and anything much over 25-30 fps is wasted on human eyes anyway). Perhaps I'm just using the wrong approach but like I said, expecting 100-200 Hz rates doesn't seem too ambitious in the context of GHz processors. If, however, there are good reasons why Nasal can't run at these rates (and the A/P PID controllers and filters, being time based _need_ to run at fixed rates in any case), what would be the best solution? LeeE - 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] Compiling FlightGear-0.9.11-pre1
Hi Sergey, Thanks. I have just sorted out that problem. I run FC5 and it seems the freeglut rpm did not install the glut sources so I just compiled and installed it. However, after doing that, I run into this error: gl-info.o: In function `main': /root/FlightGear-0.9.11-pre1/tests/gl-info.c:61: undefined reference to `glutInit' /root/FlightGear-0.9.11-pre1/tests/gl-info.c:62: undefined reference to `glutInitDisplayMode' /root/FlightGear-0.9.11-pre1/tests/gl-info.c:63: undefined reference to `glutCreateWindow' collect2: ld returned 1 exit status make[1]: *** [gl-info] Error 1 make[1]: Leaving directory `/root/FlightGear-0.9.11-pre1/tests' make: *** [all-recursive] Error 1 It is still a GLUT error but I don't know how to sort it out. What is the irc channel url? I want to set it up on gaim. On 10/24/07, Sergey [EMAIL PROTECTED] wrote: Hello Nick, seems you are about to go a long way. For windows ( and free Microsoft compiler ) you might find useful the following page http://www.sim-ai.org/FlightGearlesson.htm ( one of the draft of set of lessons ) where all code is already compiled and tested ( for where to get compiler take a look here http://www.sim-ai.org/simplestgame.htm ) Regards Sergey On 10/24/07, Nick Othieno - 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 - 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] Compiling FlightGear-0.9.11-pre1
Hi Nick I used freeglut http://freeglut.sourceforge.net/ with FlightGear Regards Sergey On 10/24/07, Nick Othieno [EMAIL PROTECTED] wrote: Hi Sergey, Thanks. I have just sorted out that problem. I run FC5 and it seems the freeglut rpm did not install the glut sources so I just compiled and installed it. However, after doing that, I run into this error: gl-info.o: In function `main': /root/FlightGear-0.9.11-pre1/tests/gl-info.c:61: undefined reference to `glutInit' /root/FlightGear-0.9.11-pre1/tests/gl-info.c:62: undefined reference to `glutInitDisplayMode' /root/FlightGear-0.9.11-pre1/tests/gl-info.c:63: undefined reference to `glutCreateWindow' collect2: ld returned 1 exit status m - 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] Compiling FlightGear-0.9.11-pre1
On 10/24/07, Nick Othieno [EMAIL PROTECTED] wrote: It is still a GLUT error but I don't know how to sort it out. What is the irc channel url? I want to set it up on gaim. Did you re-run configure (with the correct options, if you didn't install glut in a standard location)? Looks like it is not adding the appropriate libraries/paths to the linker command (which you didn't show). IRC is at: irc.flightgear.org, #flightgear -- Csaba - 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] FlightGear/Plib periodic stutter notes
This is starting to enter the realm of my own opinions so please keep that in mind. Nasal was never intended to do work at this low level. However, the fact that it can be used to successfully model an advanced flight control system [mostly successfully] says a lot about the capabilities of nasal and how tightly it's been integrated into FlightGear. Typically in a real time system you'd want to seriously consider coding stuff that runs often and at high rates of speed in native C/C++. If you did that, you would be able to tie your code into run at FDM rates. In my opinion, if someone can write advanced nasal code, it's only a small step beyond that to be able to write full fledged C code. Nasal is very C-like in many ways. Probably the biggest barrier for most people is going to be getting their development system setup properly so they can compile their new code additions or changes. Regards, Curt. On 10/24/07, leee wrote: On Wednesday 24 October 2007 11:21, Melchior FRANZ wrote: [snip...] Listeners should be used on properties to get notice about occasional changes. In cases where we *know* when the property changes -- once per loop or more often -- we can have the same result cheaper with a loop. (Listeners on YASim properties are special in that those can change several times per frame, and one may indeed want the listener triggered every time. But this should be a deliberate decision, not an accident.) This touches on the area that became a show-stopper for me and while it's good news to see some of the problems being chased down and cleared imho there are still some vital things that need to be addressed. The problem, as I see it, is that there are two different timing regimes in FG: the fixed rate FDM timing and the variable frame-rate timing. That is, the FDM operates at a fixed rate (I believe the default is 120 Hz) but nearly everything else, afaikt, operates at the frame rate, which varies. This means that if I'm trying to use Nasal (and the A/P PID controllers and filters) in a FBW framework not only do I need them to run at a specified fixed and non-varying rate but ideally I'd want them to run at the FDM fixed rate and in lock-step with it because if I just run these subsystems at the FDM fixed rate, but not locked to the FDM clock, they are likely to drift and I'd end up getting an effective rate that varied between the FDM rate and the FDM rate/2 as they drift into and out of synchronisation. Because 120 Hz isn't really that high, in the context of GHz processing speeds, I would have thought Nasal would be ok for this purpose but am I expecting too much of it? Perhaps the real problem is that nearly every other subsystem, apart from the FDM, get their turn on the CPU within the frame-rate loop and although this would seem to make obvious sense, because the graphics sub-system is by far the greatest user of resources, I'd suggest that if the other subsystems use so little of the available resources, giving them priority over the graphics would have a negligible impact on the frame rate, which is variable according to graphics load anyway. For example, if the graphics subsystem uses 95% of resources to produce 40 fps it's still likely to return 35 fps if it's only given 90% of resources (and anything much over 25-30 fps is wasted on human eyes anyway). Perhaps I'm just using the wrong approach but like I said, expecting 100-200 Hz rates doesn't seem too ambitious in the context of GHz processors. If, however, there are good reasons why Nasal can't run at these rates (and the A/P PID controllers and filters, being time based _need_ to run at fixed rates in any case), what would be the best solution? LeeE - 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 -- Curtis Olson: http://baron.flightgear.org/~curt/ Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - 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] FlightGear/Plib periodic stutter notes
* leee -- Wednesday 24 October 2007:
the FDM operates at a fixed rate (I believe the default is 120 Hz)
but nearly everything else, afaikt, operates at the frame rate,
which varies.
Yes, but most Nasal code does things that influence visuals/sound
(like instrument stuff, view handling, etc.), so there's a natural
relationship with the frame rate. Tying Nasal to the frame rate
therefor makes sense. Otherwise we would probably see interference
artifacts ... good old jitter. :-)
Only FDM stuff would like to be tied to the FDM update rate, and
I think that's a desirable goal. What about a callback function
then? The FDM subsystem would set /sim/signals/fdm-update, and you
could attach a listener to that which does all the things that
should interact with the FDM, such as AP, FCS, etc. The rest of
Nasal would keep running with the frame rate.
There's just one (minor) problem at the moment. There's no generic
FDM update() function where one could put a sig.setDoubleValue(dt).
This would have to be done in all FDMs.
Interested aircraft would then do something like ...
setlistener(/sim/signals/fdm-update, func(n) {
var dt = n.getValue();
# ... and whatever needs to be done at fdm rate
});
m.
-
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 subsystem timing/scheduling [was FlightGear/Plib periodic stutter notes]
Hi Curt, thought I'd better switch the subject line:) Using C/C++ for this sort of subsystem is probably the best choice and would certainly be the best way to go once an effective framework had been developed but at the stage I was working at, I was just trying to find out if the ideas and approaches I'd thought of would actually work in practice and so Nasal seemed ideal for this sort of rapid development/testing/prototyping. While I think I was able to make some progress and learn a lot about organising the different components, and mostly get things working, I was a long way from establishing a comprehensive framework that could be coded in C++ and then configured via xml. The big problem for me, personally, is that while I can understand C/C++ logic and basic syntax, and have been able to track down a couple of logic bugs in the FG code over the years, I wouldn't know where to start when it came to designing C++ code and integrating it into FG:( I guess it's because of that same gap in my understanding of C++ design that I just don't know how difficult it would be to change the scheduling policy of FG so that most of the subsystems ran at a fixed rate with just the graphics subsystem having a variable rate and using the resources that were left over after the other subsystems had their bite. LeeE This is starting to enter the realm of my own opinions so please keep that in mind. Nasal was never intended to do work at this low level. However, the fact that it can be used to successfully model an advanced flight control system [mostly successfully] says a lot about the capabilities of nasal and how tightly it's been integrated into FlightGear. Typically in a real time system you'd want to seriously consider coding stuff that runs often and at high rates of speed in native C/C++. If you did that, you would be able to tie your code into run at FDM rates. In my opinion, if someone can write advanced nasal code, it's only a small step beyond that to be able to write full fledged C code. Nasal is very C-like in many ways. Probably the biggest barrier for most people is going to be getting their development system setup properly so they can compile their new code additions or changes. Regards, Curt. Preamble below On 10/24/07, leee wrote: On Wednesday 24 October 2007 11:21, Melchior FRANZ wrote: [snip...] Listeners should be used on properties to get notice about occasional changes. In cases where we *know* when the property changes -- once per loop or more often -- we can have the same result cheaper with a loop. (Listeners on YASim properties are special in that those can change several times per frame, and one may indeed want the listener triggered every time. But this should be a deliberate decision, not an accident.) This touches on the area that became a show-stopper for me and while it's good news to see some of the problems being chased down and cleared imho there are still some vital things that need to be addressed. The problem, as I see it, is that there are two different timing regimes in FG: the fixed rate FDM timing and the variable frame-rate timing. That is, the FDM operates at a fixed rate (I believe the default is 120 Hz) but nearly everything else, afaikt, operates at the frame rate, which varies. This means that if I'm trying to use Nasal (and the A/P PID controllers and filters) in a FBW framework not only do I need them to run at a specified fixed and non-varying rate but ideally I'd want them to run at the FDM fixed rate and in lock-step with it because if I just run these subsystems at the FDM fixed rate, but not locked to the FDM clock, they are likely to drift and I'd end up getting an effective rate that varied between the FDM rate and the FDM rate/2 as they drift into and out of synchronisation. Because 120 Hz isn't really that high, in the context of GHz processing speeds, I would have thought Nasal would be ok for this purpose but am I expecting too much of it? Perhaps the real problem is that nearly every other subsystem, apart from the FDM, get their turn on the CPU within the frame-rate loop and although this would seem to make obvious sense, because the graphics sub-system is by far the greatest user of resources, I'd suggest that if the other subsystems use so little of the available resources, giving them priority over the graphics would have a negligible impact on the frame rate, which is variable according to graphics load anyway. For example, if the graphics subsystem uses 95% of resources to produce 40 fps it's still likely to return 35 fps if it's only given 90% of resources (and anything much over 25-30 fps is wasted on human eyes anyway). Perhaps I'm just using the wrong approach but like I said, expecting 100-200 Hz rates doesn't seem too ambitious in the context of GHz processors. If, however, there are good
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
On Wednesday 24 October 2007 18:30, Melchior FRANZ wrote:
* leee -- Wednesday 24 October 2007:
the FDM operates at a fixed rate (I believe the default is 120 Hz)
but nearly everything else, afaikt, operates at the frame rate,
which varies.
Yes, but most Nasal code does things that influence visuals/sound
(like instrument stuff, view handling, etc.), so there's a natural
relationship with the frame rate. Tying Nasal to the frame rate
therefor makes sense. Otherwise we would probably see interference
artifacts ... good old jitter. :-)
Only FDM stuff would like to be tied to the FDM update rate, and
I think that's a desirable goal. What about a callback function
then? The FDM subsystem would set /sim/signals/fdm-update, and you
could attach a listener to that which does all the things that
should interact with the FDM, such as AP, FCS, etc. The rest of
Nasal would keep running with the frame rate.
There's just one (minor) problem at the moment. There's no generic
FDM update() function where one could put a sig.setDoubleValue(dt).
This would have to be done in all FDMs.
Interested aircraft would then do something like ...
setlistener(/sim/signals/fdm-update, func(n) {
var dt = n.getValue();
# ... and whatever needs to be done at fdm rate
});
m.
The idea of an FDM callback function sounds as though it would work but
the A/P controllers and filters, which were the real problem, are
independent of Nasal and would remain a problem until they could
guarantee a fixed rate regardless of the frame rate. This is essential
for reliable operation because they are time based.
I think I really have to agree with Curt - a FBW subsystem would be
better written in C/C++ and perhaps Nasal isn't really suited to it,
although as I said in my reply to him, Nasal seemed ideal for trying
out untested ideas and developing a framework that could then be coded
in C/C++ and configured in xml.
LeeE
-
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] FlightGear/Plib periodic stutter notes
* leee -- Wednesday 24 October 2007: the A/P controllers and filters, which were the real problem, are independent of Nasal and would remain a problem until they could guarantee a fixed rate regardless of the frame rate. The FDM doesn't run at a fixed rate, either, AFAIK. Yes, it runs 120 times per second (if so configured), but it runs all iterations for a frame one after the other, then waits until the next frame. m. - 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] FlightGear/Plib periodic stutter notes
FYI: this bug is now fixed in CVS, albeit in a different way, so it's a good idea to revert that last patch in your local copies. m. - 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] FlightGear/Plib periodic stutter notes
On Wednesday 24 October 2007 19:15, Melchior FRANZ wrote: * leee -- Wednesday 24 October 2007: the A/P controllers and filters, which were the real problem, are independent of Nasal and would remain a problem until they could guarantee a fixed rate regardless of the frame rate. The FDM doesn't run at a fixed rate, either, AFAIK. Yes, it runs 120 times per second (if so configured), but it runs all iterations for a frame one after the other, then waits until the next frame. m. Hmm... I always thought that it ran asynchronously from the rest of FG, at a steady rate. Surely this can't be a good thing? It really seems to me that the only subsystem in FG where variable timing won't cause a problem is the display, where it doesn't matter if you're seeing 25 fps or 60 fps, or anything in between. Heh - I am not a flight simulator scientist though ;) LeeE - 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] Stutter/Nasal issue resolved (was: FlightGear/Plib periodic stutter notes)
Csaba Halász wrote: Don't know if Melchior and Andy have arrived at anything while I was away, but here is what I found. Yup, that's exactly it. New nasal objects are added to a temporary bin when they are created, because further allocation might cause a garbage collection to happen before the code that created the object can store a reference to it where the garbage collector can find it. For performance and simplicity, this list is stored per-context. When the context next executes code, it clears this list. Here's the problem: we do a lot of our naNewXX() calls in FlightGear using the old global context object that is created at startup. But this context is no longer used to execute scripts* at runtime, so as Csaba discovered, it's temporaries are never flushed. That essentially causes a resource leak: those allocations (mostly listener nodes) will never be freed. And all the extra reachable Nasal data floating around causes the garbage collector to take longer and longer to do a full collection as time goes on, causing stutter. And scripts that use listeners extensively (the cmdarg() they use was one of the affected allocations) will see the problem more seriously. * That's a feature, not a bug. Once listeners were added, scripts could be recursive: (script A sets property X which causes listener L to fire and cause script B to run) We need two or more contexts on the stack to handle that; a single global one won't work. I didn't like the fix though. Exposing the temporary bin as part of the Nasal public API is ugly; it's an internal design feature, not something users should tune. Instead, I just hacked at the FlightGear code to reinitialize this context every frame, thus cleaning it up. A proper fix would be to remove the global context entirely, but that would touch a bunch of code. Andy - 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] FlightGear/Plib periodic stutter notes
On 10/24/07, leee wrote: Hmm... I always thought that it ran asynchronously from the rest of FG, at a steady rate. Surely this can't be a good thing? It really seems to me that the only subsystem in FG where variable timing won't cause a problem is the display, where it doesn't matter if you're seeing 25 fps or 60 fps, or anything in between. Here's a quick explanation. The FDM runs at 120 hertz and with a fixed time step. However, we play one small trick to make that happen. We take the time that has elapsed since the last frame, compute how many whole iterations of the FDM will fit in that time slice (at 1/120th of a second per iteration.) Then we invoke the FDM that many times with a time step of 1/120th of a second. Finally we save out the remainder and add that into the next time slice. This can produce a small amount of temporal jitter between the graphics and the fdm if the graphics frame rates are not a diviser of 120. In the best case scenario, you've locked your graphics frame rate to 60 hz so the FDM runs exactly 2 iterations every time it is invoked and there is no temporal jitter at all, ever. One thing to keep in mind is that handing a different size time slice to the FDM every frame (and sometimes that time slice could be 1 second or more?) can lead to instabilities in the math. So our approach is intended to avoid that potential problem. As far as the FDM is concerned, it *is* running asyncronously, at a fixed time step. But, we are playing a little trick on the FDM (it doesn't care) in order to handle the unfortunate possibility of non-fixed and highly variable frame rates on PC hardware running consumer grade operating systems. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - 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] Compiling FlightGear-0.9.11-pre1
Thanks for the info. I successfully compiled. Now when I run fgfs, I get the following error: 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 Audio initialization failed! Could not change the current ALC context Failed to load wav file: at The operation was invalid in the current ALUT state Failed to load wav file: at The operation was invalid in the current ALUT state Failed to load wav file: at The operation was invalid in the current ALUT state Failed to load wav file: at The operation was invalid in the current ALUT state Failed to load wav file: at The operation was invalid in the current ALUT state Failed to load wav file: at The operation was invalid in the current ALUT state Failed to load wav file: at The operation was invalid in the current ALUT state Failed to load wav file: at The operation was invalid in the current ALUT state Failed to load wav file: at The operation was invalid in the current ALUT state Failed to load wav file: at The operation was invalid in the current ALUT state Failed to load wav file: at The operation was invalid in the current ALUT state freeglut (fgfs): Failed to create cursor freeglut ERROR: Function glutSetCursor called without first calling 'glutInit'. The platform is still FC5 On 10/24/07, Csaba Halász [EMAIL PROTECTED] wrote: On 10/24/07, Nick Othieno [EMAIL PROTECTED] wrote: It is still a GLUT error but I don't know how to sort it out. What is the irc channel url? I want to set it up on gaim. Did you re-run configure (with the correct options, if you didn't install glut in a standard location)? Looks like it is not adding the appropriate libraries/paths to the linker command (which you didn't show). IRC is at: irc.flightgear.org, #flightgear -- Csaba - 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 - 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] FlightGear/Plib periodic stutter notes
On Wednesday 24 October 2007 19:41, Curtis Olson wrote: On 10/24/07, leee wrote: Hmm... I always thought that it ran asynchronously from the rest of FG, at a steady rate. Surely this can't be a good thing? It really seems to me that the only subsystem in FG where variable timing won't cause a problem is the display, where it doesn't matter if you're seeing 25 fps or 60 fps, or anything in between. Here's a quick explanation. The FDM runs at 120 hertz and with a fixed time step. However, we play one small trick to make that happen. We take the time that has elapsed since the last frame, compute how many whole iterations of the FDM will fit in that time slice (at 1/120th of a second per iteration.) Then we invoke the FDM that many times with a time step of 1/120th of a second. Finally we save out the remainder and add that into the next time slice. This can produce a small amount of temporal jitter between the graphics and the fdm if the graphics frame rates are not a diviser of 120. In the best case scenario, you've locked your graphics frame rate to 60 hz so the FDM runs exactly 2 iterations every time it is invoked and there is no temporal jitter at all, ever. One thing to keep in mind is that handing a different size time slice to the FDM every frame (and sometimes that time slice could be 1 second or more?) can lead to instabilities in the math. So our approach is intended to avoid that potential problem. As far as the FDM is concerned, it *is* running asyncronously, at a fixed time step. But, we are playing a little trick on the FDM (it doesn't care) in order to handle the unfortunate possibility of non-fixed and highly variable frame rates on PC hardware running consumer grade operating systems. Regards, Curt. Thanks for the explanation - I think I'll need a little while to get my head around the paradigm shift though:) I was under the impression that the FDMs got a constant/continuous 120Hz. Seems to work for the FDMs ok though:) On my 1.7 GHz Athlon XP+Nv6600 256MB based system I was getting anything between 45-20 fps, depending on the view I was using and what was in the background (I increased the visibility ranges over the default settings, so there was an additional performance hit there). Synching to vblank never made any difference here but with those frame rates I wasn't too surprised. LeeE - 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
