[Flightgear-devel] Old complaints about instability?
I was just rebuilding FGFS's binary when I noticed these warnings. Depending on what your compiler does, the runtime effect could be bad. Someone was mentioning having occasional crashes. source='tower.cxx' object='tower.o' libtool=no \ depfile='.deps/tower.Po' tmpdepfile='.deps/tower.TPo' \ depmode=gcc /bin/sh ../../depcomp \ g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/X11R6/include -g -O2 -D_REENTRANT -c -o tower.o `test -f tower.cxx || echo './'`tower.cxx tower.cxx: In method `void FGTower::CheckCircuitList(double)': tower.cxx:901: warning: `double' used for argument 1 of `abs(int)' tower.cxx:934: warning: `double' used for argument 1 of `abs(int)' tower.cxx:944: warning: `double' used for argument 1 of `abs(int)' tower.cxx:954: warning: `double' used for argument 1 of `abs(int)' ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Old complaints about instability?
Alex Perry wrote: I was just rebuilding FGFS's binary when I noticed these warnings. Depending on what your compiler does, the runtime effect could be bad. Someone was mentioning having occasional crashes. source='tower.cxx' object='tower.o' libtool=no \ depfile='.deps/tower.Po' tmpdepfile='.deps/tower.TPo' \ depmode=gcc /bin/sh ../../depcomp \ g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/X11R6/include -g -O2 -D_REENTRANT -c -o tower.o `test -f tower.cxx || echo './'`tower.cxx tower.cxx: In method `void FGTower::CheckCircuitList(double)': tower.cxx:901: warning: `double' used for argument 1 of `abs(int)' I've checked these once and the only thing missing here is a typecast. I don't think these can cause segmentation faults. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New YASim fuel code
Andy Ross wrote Now that the new release is out (yeah, that's my exuse...), I've finally checked in the new Nasal fuel code I've been working on, along with YASim changes to enable it. This hasn't been tested terribly well, so please let me know if I broke something. You should be able to set the /consumables/fuel/tank[n]/level-gal_us properties and watch the FDM do the right thing. As we come up with new fuel flow behavior (in flight refuelling, etc...) we can hook the Nasal script to do what we want. Andy How do we handle fuel in lbs and account for Avgas/JP4? Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Old complaints about instability?
Alex Perry [EMAIL PROTECTED] writes:
I was just rebuilding FGFS's binary when I noticed these warnings.
Depending on what your compiler does, the runtime effect could be bad.
Someone was mentioning having occasional crashes.
source='tower.cxx' object='tower.o' libtool=no \
depfile='.deps/tower.Po' tmpdepfile='.deps/tower.TPo' \
depmode=gcc /bin/sh ../../depcomp \
g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src
-I/usr/X11R6/include -g -O2 -D_REENTRANT -c -o tower.o `test -f tower.cxx || echo
'./'`tower.cxx
tower.cxx: In method `void FGTower::CheckCircuitList(double)':
tower.cxx:901: warning: `double' used for argument 1 of `abs(int)'
tower.cxx:934: warning: `double' used for argument 1 of `abs(int)'
tower.cxx:944: warning: `double' used for argument 1 of `abs(int)'
tower.cxx:954: warning: `double' used for argument 1 of `abs(int)'
Hmm, I always compile with -Wall but it doesn't flag these :-( I'll fix them...
Re. the occasional crashes, the ATC init ones I posted about a while ago Melchior
helped me with off list, it came down to something stupid I'd done years ago:
*.hxx...
class A {
private:
const char* c
*.cxx...
void A::init() {
string s;
c = s;
Something like that anyway!
The crashes in ssgCullAndDraw went away when Erik reverted some transparency rendering
patches a week or two ago.
I'm now clear of inexplicable crashes on both Cygwin and Linux :-)
Famous last words - it's bound to bomb out now!!
I will fix those warnings though.
Cheers - Dave
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FlightGear 0.9.4 Slackware Package
The package for the new release is now available at: http://flightgear.stockill.org.uk Just download and do upgradepkg FlightGear-0.9.4-i486-1.tgz if you have a previous version or installpkg FlightGear-0.9.4-i486-1.tgz if you've not used it before. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: releases FlightGear-0.9.4.tar.gz, NONE,
Curtis L. Olson wrote: The other thing to consider is everyone seems to have one more fix they'd like to get in. If we waited for everyone to be happy, we literally would never be able to have a release. At some point we have to draw the line and ship. The 0.9.4 release is simply the current state of cvs as of today, so if more people tried the cvs version and made patches along the way, we'd have less surprises on release day. I agree with Curt. There are two basic strategies for releasing: 1. Release rarely, testing every release exhaustively first. 2. Release often, testing every release only lightly. I think that #2 works better for most cases -- many bugs won't show up during testing by the members of the developers' list anyway, so it's best to get the release out into the wild and find the real problems earlier rather than later. I know that some people like the idea of separate development and stable branches, but unless we're dealing with critical core infrastructure like a kernel or Web server, it's hard to motivate people to spend all the extra time to backport bug fixes and OS compability changes to the stable branch: it often ends up that the development branch is more stable than the so-called stable branch anyway, while making twice as much work for the maintainers. I would support a 4-week code freeze before 1.0, however, and I do think it's just about time for a 1.0. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] YASim starter motor
Andy Ross wrote: Tune up the starter torque to match the recent changes to engine friction. We should get these better calibrated at some point... When you engage a starter on a piston engine (I have no turbine experience), it spins the propeller at an extremely slow, constant speed -- maybe 30 rpm -- until the engine fires; at that point, the engine spins the propeller up to speed (say, 1000 rpm with the throttle slightly open) almost instantly. With YASim (and possibly JSBSim -- I don't remember), the starter seems to gradually spin the propeller up to the engine's idle speed (600-800 rpm), at which point the engine takes over. That has no relation to what really happens. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: releases FlightGear-0.9.4.tar.gz, NONE,
David Megginson said: Curtis L. Olson wrote: The other thing to consider is everyone seems to have one more fix they'd like to get in. If we waited for everyone to be happy, we literally would never be able to have a release. At some point we have to draw the line and ship. The 0.9.4 release is simply the current state of cvs as of today, so if more people tried the cvs version and made patches along the way, we'd have less surprises on release day. I agree with Curt. There are two basic strategies for releasing: 1. Release rarely, testing every release exhaustively first. 2. Release often, testing every release only lightly. I think that #2 works better for most cases -- many bugs won't show up during testing by the members of the developers' list anyway, so it's best to get the release out into the wild and find the real problems earlier rather than later. At one time I think I would have leaned toward #1 but have since become a #2 fan. I was going to say this yesterday, but I also realize that doing #2 often involves quite a time commitment. Would it make sense to run a nightly script for folks that don't run cvs? Or is that just a waste of bandwidth? Maybe binaries are the ticket. How about various team members running nightly build scripts and then uploading the results somewhere? I know that some people like the idea of separate development and stable branches, but unless we're dealing with critical core infrastructure like a kernel or Web server, it's hard to motivate people to spend all the extra time to backport bug fixes and OS compability changes to the stable branch: it often ends up that the development branch is more stable than the so-called stable branch anyway, while making twice as much work for the maintainers. That's right. Maybe some day simgear, but I would think that backporting efforts would be driven by the requirements of the backporters rather than anticipated as a requirement. I would support a 4-week code freeze before 1.0, however, and I do think it's just about time for a 1.0. We're close, maybe next release, but I think we need to get the subsystem/initialization thing straightened out first. Fred's fix for the tilemanager last week raised an issue about something that might be missing in the subsystem design. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim starter motor
David Megginson said: Andy Ross wrote: Tune up the starter torque to match the recent changes to engine friction. We should get these better calibrated at some point... When you engage a starter on a piston engine (I have no turbine experience), it spins the propeller at an extremely slow, constant speed -- maybe 30 rpm -- until the engine fires; at that point, the engine spins the propeller up to speed (say, 1000 rpm with the throttle slightly open) almost instantly. With YASim (and possibly JSBSim -- I don't remember), the starter seems to gradually spin the propeller up to the engine's idle speed (600-800 rpm), at which point the engine takes over. That has no relation to what really happens. As far as YASim is concerned I don't think it would take much to fix this. Right now the start spins up to the idle rpm value (iirc) and then switches the engine to run mode. You could probably do something like not let the rpm increase beyond 30 (or whatever) unless the magnetos are on and fuel mixture is available. If the starter function is torque based (probably it is) you could just make starter torque a low value until you reach firing rpm and the right values for running are there. The first couple of pops are what get the engine up to idling speed by adding to the starter torque. A third approach might be just decrease the starter torque and have the yasim engine switch to run mode at some other value below idle, but I'm not sure all that would be involved (maybe just a separate config value). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New YASim fuel code
On Sat, 27 Mar 2004 10:17:00 -, Vivian Meazza [EMAIL PROTECTED] wrote: How do we handle fuel in lbs and account for Avgas/JP4? Avgas and Jet A1 have different specific gravities. I can't remember what the Sp.G of Jet A1 is but Avgas here is quoted as 0.7 - i.e. (0.7 x The equivalent volume of water). You'll basically get differing quantities of each for the same weight. Sorry if this isn't what you were asking :-) All the best, Matt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: releases FlightGear-0.9.4.tar.gz, NONE,
Jim Wilson wrote: David Megginson said: I would support a 4-week code freeze before 1.0, however, and I do think it's just about time for a 1.0. We're close, maybe next release, but I think we need to get the subsystem/initialization thing straightened out first. Fred's fix for the tilemanager last week raised an issue about something that might be missing in the subsystem design. Maybe it's time to start some sort of to-do list with issues that _have_ to be addressed for a 1.0 release. I agree we're close to be able to earn the 1.0 version number. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: releasesFlightGear-0.9.4.tar.gz, NONE,
Jim Wilson wrote: I would support a 4-week code freeze before 1.0, however, and I do think it's just about time for a 1.0. We're close, maybe next release, but I think we need to get the subsystem/initialization thing straightened out first. Fred's fix for the tilemanager last week raised an issue about something that might be missing in the subsystem design. I also think we should begin to move to 1.0. About initialization, there is still an issue where --wp and --flight-plan are not working ( read segfaulting ) because they rely on the presence of the Airport/Fixes databases that can only be initilized after the --fg-root option is known. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] YASim starter motor
With YASim (and possibly JSBSim -- I don't remember), the starter seems to gradually spin the propeller up to the engine's idle speed (600-800 rpm), at which point the engine takes over. That has no relation to what really happens. Thanks for the report, and I agree with Jim that this ought not to be very hard to fix for any of the FDMs, where the problem is present. One thing I'd like to emphasize is that (for JSBSim) this is exactly the kind of thing that ought to go in as a bug report at the JSBSim web site. Go to www.jsbsim.org, click on the Bug Report link at left, and add the bug. It might seem like nothing ever gets done with these bug reports, but that's not exactly true. At the present time, and for the recent past, there has been a lot of major stuff going on behind the scenes with JSBSim that has taken precedence, so nothing has been done with the bug reports recently EXCEPT that they are NOT getting lost or forgotten. They are in the queue. PLEASE FILE BUG REPORTS. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New YASim fuel code
Vivian Meazza wrote: How do we handle fuel in lbs and account for Avgas/JP4? For read access, you will find a level-lbs property also. But the only one you are allowed to change is the gallons one. There is a density-ppg property there too, for doing conversions. It gets set from the FDM with a density appropriate to the fuel in the tank. Here's the complete documentation as it appears at the top of fuel.nas: # Properties under /consumables/fuel/tank[n]: # + level-gal_us- Current fuel load. Can be set by user code. # + level-lbs - OUTPUT ONLY property, do not try to set # + selected- boolean indicating tank selection. # + density-ppg - Fuel density, in lbs/gallon. # + capacity-gal_us - Tank capacity # # Properties under /engines/engine[n]: # + fuel-consumed-lbs - Output from the FDM, zeroed by this script # + out-of-fuel - boolean, set by this code. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim starter motor
David Megginson wrote: When you engage a starter on a piston engine (I have no turbine experience), it spins the propeller at an extremely slow, constant speed -- maybe 30 rpm -- until the engine fires; at that point, the engine spins the propeller up to speed (say, 1000 rpm with the throttle slightly open) almost instantly. Yeah, although that's not too terribly different than what happens now. The issues are all with tuning and threshold changes. The problems with the current approach that I can see: + The start threshold is probably too high (it's currently set to 200 RPM, which doesn't match your value of 30 very well.) + The torque behavior of the engine and propeller at low speeds is kinda broken. The propeller isn't draggy enough, so you had to tune up the engine friction to get the idle speed right, which led to complaints on IRC that the Mustang wouldn't start, which led me to hack in the starter motor changes for a near-term fix. Turning down the start RPM would probably be the fix required here. I'll check that in instead (I think I might use 60 instead of 30, which really does seem awfully slow) and see if folks like it. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Pre-Releases and Releases
David Megginson wrote: I agree with Curt. There are two basic strategies for releasing: 2. Release often, testing every release only lightly. I think that #2 works better for most cases What he said. One way of looking at it is this: The goal isn't to produce individual releases with the greatest quality, it's to produce the best software we can with the resources available. Waiting on releases for testing means that developers have to put off contributions, bug reports on those contributions then come in later than they would otherwise, the bug fixes go in later and the next release gets pushed back. We end up doing less development and making fewer releases, which is *bad* for software quality in the long run. Andy My current task (daytime) involves leading the development of prototype space shuttle flight software, which includes testing the releases and writing the release reports. If I took the above approach I'd be out of a job in two minutes. Obviously, it's different for volunteer efforts. I would strongly disagree with the sentiment that seems to be reflected in the statement: The goal isn't to produce individual releases with the greatest quality, it's to produce the best software we can with the resources available. This seems to say, release often, and we really don't care if it works that well or not because we're in a hurry and don't have much help. IMHO, that's what we do in CVS as we develop. Releases are a different matter altogether. How many releases have been put together in the past year? Since January 2003 there have been three releases (IMHO this is NOT often). The release before that had to be redone within days because a file was missing, I think. My hope is that the pre-releases could sit as is a bit longer - I'd say at least over a weekend - so more people can have a chance to try it out. What's a few days more in comparison to the several-month release cycles? My experience tells me this would result in less re-work in the long run, and it would also result in a better release. It would also use a lot more of the resources we have available by allowing more people to use their available resources on weekends or as time permits to help out and _share_the_burden_. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-Releases and Releases
Jon Berndt said: David Megginson wrote: I agree with Curt. There are two basic strategies for releasing: 2. Release often, testing every release only lightly. I think that #2 works better for most cases What he said. One way of looking at it is this: The goal isn't to produce individual releases with the greatest quality, it's to produce the best software we can with the resources available. Waiting on releases for testing means that developers have to put off contributions, bug reports on those contributions then come in later than they would otherwise, the bug fixes go in later and the next release gets pushed back. We end up doing less development and making fewer releases, which is *bad* for software quality in the long run. Andy My current task (daytime) involves leading the development of prototype space shuttle flight software, which includes testing the releases and writing the release reports. If I took the above approach I'd be out of a job in two minutes. Obviously, it's different for volunteer efforts. I would That's right, it is different, and I think that should be enough to skip the rest of your argument. Given everyone's commitments, especially Curt's (with the new baby), I am no less than amazed that we have any sort of release now. strongly disagree with the sentiment that seems to be reflected in the statement: The goal isn't to produce individual releases with the greatest quality, it's to produce the best software we can with the resources available. This seems to say, release often, and we really don't care if it works that well or not because we're in a hurry and don't have much help. IMHO, that's what we do in CVS as we develop. So what's the diff? I see releases from an alpha/beta level development project as just a way for non programmers/non-cvs users to participate in the process. Releases are a different matter altogether. How many releases have been put together in the past year? Since January 2003 there have been three releases (IMHO this is NOT often). The release before that had to be redone within days because a file was missing, I think. My hope is that the pre-releases could sit as is a bit longer - I'd say at least over a weekend - so more people can have a chance to try it out. What's a few days more in comparison to the several-month release cycles? I think you've ignored Curt's response to this the first time, why are you repeating the same point? The first was good enough for me. My experience tells me this would result in less re-work in the long run, and it would also result in a better release. It would also use a lot more of the resources we have available by allowing more people to use their available resources on weekends or as time permits to help out and _share_the_burden_. Let's see what happens then. Can you still do some testing now anyway? It is never too late to contribute a bug fix. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Pre-Releases and Releases
Jim Wilson writes: Jon Berndt said: David Megginson wrote: I agree with Curt. There are two basic strategies for releasing: 2. Release often, testing every release only lightly. I think that #2 works better for most cases One way of looking at it is this: The goal isn't to produce individual releases with the greatest quality, it's to produce the best software we can with the resources available. My current task (daytime) involves leading the development of prototype space shuttle flight software, which includes testing the releases and writing the release reports. If I took the above approach I'd be out of a job in two minutes. Obviously, it's different for volunteer efforts. I would That's right, it is different, and I think that should be enough to skip the rest of your argument. There is no reason we can't have our cake and eat it too. The way to be able todo this is to use more of CVS features. i.e. USE BRANCHES for all commits. Believe it or not this, lberally using branches within the CVS, leads to less rather then more work as is often percieved. http://dev.zope.org/CVS/ZopeCVSFAQ I am no less than amazed that we have any sort of release now. Indeed I am always amazed at how any OpenSource project with *multiple* developers manages to get a release out at all :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] mouse.cxx: CURSOR_TWEAKS??
I'm picking up work on the de-glutification stuff right now, and have
a question:
Does anyone understand what is going on in src/Input/mouse.cxx with
the {X|WIN32}_CURSOR_TWEAKS preprocessor defines? I'm having a hard
time figuring this out. Right now, it looks like the windows and X11
builds actually have different/incompatible behavior for the mouse
cursor.
Nothing in the underlying (portable) glut API should require this, so
far as I can see, nor should there be a need for platform dependency
in this code. Does anyone know the history here?
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Pre-Releases and Releases
That's right, it is different, and I think that should be enough to skip the rest of your argument. Given everyone's commitments, especially Curt's (with the new baby), I am no less than amazed that we have any sort of release now. Like I said - I'm in that boat, too (X2!) and very sensitive to that concern, with the past two months filled with sickness rotating amongst the six of us and an additional and separate open source project under heavy development. My suggestions and comments are made with all due respect to our various participants' pressing needs and responsibilities, and with special consideration of Curt, who has to put the release together. Perhaps we ought to come to an agreement on what releases are for. My feeling is that when we release something it ought to be held to a higher standard than what is generally in CVS, it ought to go through testing from as many people as possible, and that once a pre-release is let out, no NEW features should be allowed in - only bug fixes. The second pre-release should be effectively what is released, unless something glaring is found. Both pre-releases ideally ought to encompass a full weekend, and last at least four or five days, with the first one perhaps longer. These are just suggestions off the top of my head. I think you've ignored Curt's response to this the first time, why are you repeating the same point? I'm not sure what you are talking about. I don't think I am ignoring Curt's comments - I read them all. The idea is that we ought to come to an agreement on what is expected when a release is impending: 1) Changes are halted at a specified time. 2) Pre-release 3) Bug fixes only 4) Final Pre-release 5) Release 6) back to normal ... My biggest gripe (and I am not angry about this, or perturbed) is that the second pre-release came about pretty quickly (and I wasn't the only one who was a little surprised). It would have been nice to allow some others to test on the weekend. If that means an opportunity for Curt passes by for another week, then we have to accept that a few times a year we are going to have to hold off on CVS commits for a few days - no big sacrifice, I think. IMHO, this doesn't add to Curt's workload - only stretches out the schedule. The big caveats here are that I have never had to do a FlightGear release, and I don't live in Curt's shoes. Let's see what happens then. Can you still do some testing now anyway? It is never too late to contribute a bug fix. I will begin the update and build process immediately. I'm simply trying to make some suggestions for process improvement. :-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] mouse.cxx: CURSOR_TWEAKS??
Andy Ross writes: Does anyone understand what is going on in src/Input/mouse.cxx AFAIK mouse.cxx is not in the current CVS Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] mouse.cxx: CURSOR_TWEAKS??
Norman Vine wrote: Andy Ross writes: Does anyone understand what is going on in src/Input/mouse.cxx AFAIK mouse.cxx is not in the current CVS I typoed the path. It's in src/GUI Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim starter motor
Andy Ross wrote: Turning down the start RPM would probably be the fix required here. I'll check that in instead (I think I might use 60 instead of 30, which really does seem awfully slow) and see if folks like it. I'm trying to remember how fast the blades go by while cranking. They are slow enough that you can very easily count them -- by closing my eyes and trying to remember, I get about a blade per second, or 30 rpm for a two-bladed prop. It might be a bit faster than that, but I don't think it's 60 rpm -- the spinning really is very leisurely. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim starter motor
Jim Wilson wrote: Ah ok. From memory (not so good) I thought this was configurable. 60 sounds like a good value anyway. Would this make engines appear to start too quickly? There should be a time delay. Pilots talk about starting on the second blade or on the third blade for an engine that starts well. A cold engine, an engine with a weak battery, an engine with aluminum wiring, an inexperienced pilot, etc. can make the starting last much longer, possibly five to ten seconds. During that entire time, the prop is spinning at a constant, slow speed until the engine fires. Spinning up to, say, 45 RPM and then starting the engine instantly would not be very realistic, either. Depending on the engine, some of the cylinders might not fire at first -- that can make the engine run rough for a few seconds before they all catch. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-Releases and Releases
Jon Berndt wrote: My current task (daytime) involves leading the development of prototype space shuttle flight software, which includes testing the releases and writing the release reports. If I took the above approach I'd be out of a job in two minutes. Over time, the release-early-release-often approach leads to strong, robust software because we go through many more release cycles; in fact, I'd like to see a minor release at least four times a year, if not bimonthly. It's an evolution thing: we get better software five years from now in exchange for the occasional bug now (think of how bacteria evolve resistence to antibiotics). We can afford to go long-term, while you necessarily have to think short-term since you have lives on the line. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 'fgfs --show-aircraft' gives a Segmentation fault
See subject. This is with the current CVS FlightGear and base package. The problem is that there are two aircraft configuration files that try to include PropertyLists from files that no longer exist. The files in question are: - Aircraft/c310u3a/c310-3d-set.xml -- tries to include c310u3a-3d-jsbsim-set.xml, which is no longer in the base package. - Aircraft/c172/c172-larcsim-set.xml -- tries to include ../c172p/c172p-base.xml, which is no longer in the base package. In the case of c310-3d-set.xml, I just removed it since it was really only an alias pointing to a deleted file. For c172-larcsim-set.xml, I changed the file to include c172-base.xml instead. This isn't a perfect fix, though. The resulting LaRCSim c172 is missing a 3D model, for instance. I guess this is all just lingering clean-up work left over from all the Aircraft reorganization that's been going on of late. In tracking down this problem, however, two thoughts came to mind. First, it is very suprising to me that an error in a configuration file would result in FlightGear segfaulting. I encountered this problem before while editing a joystick configuration. I was adding a little Nasal script to the config and forgot to include the /script tag at the end of the script. The result when I tried to run FlightGear was also a Segmentation fault. If I had not just finished editing that joystick config, I would have had no clue where to start looking for the problem. An error message saying, Error parsing 'my_joystick_config.xml': missing /script tag would be a much more user-friendly way to handle this error. In the case of the missing Aircraft configuration files, I traced the segfault back till I got to plib's 'readProperties' function, so I guess I should be talking to the plib people instead of venting my spleen here. I guess my point is that the configuration files, being read in at run-time and out there for users to edit (or screw up) as they see fit, should not be trusted implicitly, and maybe some more robust error handling would be appropriate. When I have the time, I may take a crack at this problem. I hesitate to mention my second thought, since I am not a FlightGear developer and my opinion on this matter shouldn't count for much. I looked back in the base package CVS logs, and I see that the missing aircraft config files which caused the segfault were removed from the base package nine days ago. I can only assume this means that the '--show-aircraft' option will also cause a segfault for the recent 0.9.4 release (can anyone confirm or deny?). I've read the recent threads on flightgear-devel concerning the release process, and I can see where the champions of the quick release strategy are coming from. But IMHO, this error is a good example of why there should be at least a minimal set of formal checks for proper function before the code is released. I'm not talking about some major regression testing or anything. It should be possible however to come up with a small list of important items to check before release. Think 'pre-flight checklist', and not 'annual inspection' :). As an example, it might be appropriate to check that all the options listed by 'fgfs --help' actually work as described. On the other hand, it might not be a big deal if one of the more obscure options listed by 'fgfs --help --verbose' was not quite working as advertised. As I said, I hesitate to bring up this issue, since I certainly didn't do any user testing of the 0.9.4 pre-release, and I really do appreciate all the work that the developers put into FlightGear. In the future, I will try to find the time to do some testing before a release. When I get a chance, I'll do some brainstorming and come up with a list of key tests that I as a user can do before the next release. Anybody have suggestions? Regards, -Eric Hathaway P.S. -- I'm surprised nobody encountered this error for nine whole days. I don't get a chance to use FlightGear as often as I'd like, but when I do I routinely use the --show-aircraft option to see which aircraft I feel like flying. What does everybody else do? Has everyone else started using a graphical front end to fgfs? -ELH ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 'fgfs --show-aircraft' gives a Segmentation fault
As I said, I hesitate to bring up this issue, since I certainly didn't do any user testing of the 0.9.4 pre-release, and I really do appreciate all the work that the developers put into FlightGear. In the future, I will try to find the time to do some testing before a release. When I get a chance, I'll do some brainstorming and come up with a list of key tests that I as a user can do before the next release. Anybody have suggestions? This is a good point. What I do with JSBSim is to automatically run a series of tests -- or flight profiles -- with our own scripting capability. Then, a set of plots is automatically generated, along with an HTML page that interfaces with those plots. Within one minute I then have a representative set of plots that serves as a regression test compared to prior results plotted. If the plots make me happy, I commit the changes. FlightGear is a much larger program, but I wonder if nasal might provide the means to automatically run a set of tests. A scripted plotting capability ought to be able to co-plot test results, for those things that can be plotted. Jon -- Project Coordinator JSBSim Flight Dynamics Model http://www.jsbsim.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New YASim fuel code
Andy Ross replied Vivian Meazza wrote: How do we handle fuel in lbs and account for Avgas/JP4? For read access, you will find a level-lbs property also. But the only one you are allowed to change is the gallons one. There is a density-ppg property there too, for doing conversions. It gets set from the FDM with a density appropriate to the fuel in the tank. Here's the complete documentation as it appears at the top of fuel.nas: # Properties under /consumables/fuel/tank[n]: # + level-gal_us- Current fuel load. Can be set by user code. # + level-lbs - OUTPUT ONLY property, do not try to set # + selected- boolean indicating tank selection. # + density-ppg - Fuel density, in lbs/gallon. # + capacity-gal_us - Tank capacity # # Properties under /engines/engine[n]: # + fuel-consumed-lbs - Output from the FDM, zeroed by this script # + out-of-fuel - boolean, set by this code. In the YASim file we quote tank capacities as lbs (and that is normal AFAIK in UK) and can specify Avgas or JetA. I think but (I'm not sure) that the new fuel code appears to only allow Avgas 80/100/100LL? (Avgas 100 Density @ 15°C 695 (kg/m3)), and not JetA (820 (kg/m3)). JetA is only available in US and Canada, so perhaps JetA-1 (available worldwide) would be more appropriate (804 (kg/m3)). JetA-1 is equivalent (approx - don't ask) to Avtur in UK military use. I can fix up the density for Avtur, when I've worked up the ppg equivalent (phew!!), for my own use if that's required. Or have I got this all wrong? Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 'fgfs --show-aircraft' gives a Segmentation fault
Eric L Hathaway wrote: See subject. This is with the current CVS FlightGear and base package. The problem is that there are two aircraft configuration files that try to include PropertyLists from files that no longer exist. The files in question are: - Aircraft/c310u3a/c310-3d-set.xml -- tries to include c310u3a-3d-jsbsim-set.xml, which is no longer in the base package. - Aircraft/c172/c172-larcsim-set.xml -- tries to include ../c172p/c172p-base.xml, which is no longer in the base package. In the case of c310-3d-set.xml, I just removed it since it was really only an alias pointing to a deleted file. For c172-larcsim-set.xml, I changed the file to include c172-base.xml instead. This isn't a perfect fix, though. The resulting LaRCSim c172 is missing a 3D model, for instance. I guess this is all just lingering clean-up work left over from all the Aircraft reorganization that's been going on of late. In tracking down this problem, however, two thoughts came to mind. First, it is very suprising to me that an error in a configuration file would result in FlightGear segfaulting. Humm.. just tried in debug mode. The windows version is just throwing sg_exceptions as expected and they are caught by the code and the program nicely slip on the problem without segfaulting. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: 'fgfs --show-aircraft' gives a Segmentation fault
* Frederic Bouvier -- Saturday 27 March 2004 23:13: Humm.. just tried in debug mode. The windows version is just throwing sg_exceptions as expected and they are caught by the code and the program nicely slip on the problem without segfaulting. ... but if you have compiled fgfs with a libglut that had not been compiled with exception support, then nobody catches, which results in an abort(). This looks like a segfault and creates a core file, but it doesn't really pretend to be a segfault. With my crappy nVidia driver, though, the Xserver freezes and I have to reboot. (The kernel is fine, but the keyboard/mouse/ screen is locked. :-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New YASim fuel code
Vivian Meazza wrote: In the YASim file we quote tank capacities as lbs (and that is normal AFAIK in UK) and can specify Avgas or JetA. [...] I can fix up the density for Avtur, when I've worked up the ppg equivalent (phew!!), for my own use if that's required. Or have I got this all wrong? You don't need to do anything short term. YASim will fill out the tank record for you at initialization (it has hard-coded values for gasoline and jet fuel). But ultimately, this stuff should move out of the FDM proper and into the aircraft configuration, since it needs to interact with the rest of the system through the property tree. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Aircraft description missing
Looking closely at the output of --show-aircraft, it appears that some aircraft are not having a description, and as such, do not appear in the fgrun aircraft viewer, making them unavailable for fgrun users. These aircraft are : * a10-yasim * a10cl-yasim * a10fl-yasim * a10wl-yasim * an225-yasim * b52-yasim * fkdr1-v1-nl-uiuc * seahawk * sopwithCamel-v1-nl-uiuc Curt, it could be wise to add something before releasing fgsetup-0.9.4, because some are major contributions to the FlightGear hangar. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [OT] X-43A flight apparently successful
Today's hypersonic X-43A flight was apparently successful, though I have not seen much news on it, yet. It should appear here: http://www.nasa.gov/missions/research/x43-main.html -and- http://www.dfrc.nasa.gov/ Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] X-43A flight apparently successful
On Saturday 27 March 2004 22:55, Jon Berndt wrote: Today's hypersonic X-43A flight was apparently successful, though I have not seen much news on it, yet. It should appear here: http://www.nasa.gov/missions/research/x43-main.html -and- http://www.dfrc.nasa.gov/ Jon Ta for the heads-up on that. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: 'fgfs --show-aircraft' gives a Segmentationfault
Melchior FRANZ wrote: * Frederic Bouvier -- Saturday 27 March 2004 23:13: Humm.. just tried in debug mode. The windows version is just throwing sg_exceptions as expected and they are caught by the code and the program nicely slip on the problem without segfaulting. ... but if you have compiled fgfs with a libglut that had not been compiled with exception support, then nobody catches, which results in an abort(). This looks like a segfault and creates a core file, but it doesn't really pretend to be a segfault. With my crappy nVidia driver, though, the Xserver freezes and I have to reboot. (The kernel is fine, but the keyboard/mouse/ screen is locked. :-) Is it only a problem with glut ? This is a major problem that we use exceptions on a system that can't safely handle them. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [OT] X-43A flight apparently successful
On Saturday 27 March 2004 22:55, Jon Berndt wrote: Today's hypersonic X-43A flight was apparently successful, though I have not seen much news on it, yet. It should appear here: http://www.nasa.gov/missions/research/x43-main.html -and- http://www.dfrc.nasa.gov/ Jon Ta for the heads-up on that. LeeE THere's a press conference in about an hour (4 pm PST) for those who can get NASA Select. That oughta be good. For general interest: LaRCSim author Bruce Jackson was involved in that reflight effort, IIRC. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] X-43A flight apparently successful
On Saturday 27 March 2004 22:55, Jon Berndt wrote: Today's hypersonic X-43A flight was apparently successful, though I have not seen much news on it, yet. It should appear here: http://www.nasa.gov/missions/research/x43-main.html -and- http://www.dfrc.nasa.gov/ Jon Heh! - less than a minute after I posted the thanks there was a mention of it on BBC Radio 4 news - no details but it went on to point out how it much it could reduce travelling times...:) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-Releases and Releases
On Sat, 27 Mar 2004 13:02:20 -0500, Norman wrote in message [EMAIL PROTECTED]: Jim Wilson writes: Jon Berndt said: David Megginson wrote: I agree with Curt. There are two basic strategies for releasing: 2. Release often, testing every release only lightly. I think that #2 works better for most cases One way of looking at it is this: The goal isn't to produce individual releases with the greatest quality, it's to produce the best software we can with the resources available. My current task (daytime) involves leading the development of prototype space shuttle flight software, which includes testing the releases and writing the release reports. If I took the above approach I'd be out of a job in two minutes. Obviously, it's different for volunteer efforts. I would That's right, it is different, and I think that should be enough to skip the rest of your argument. There is no reason we can't have our cake and eat it too. The way to be able todo this is to use more of CVS features. i.e. USE BRANCHES for all commits. ..my understanding of cvs the FlightGear way is our early work in cvs was mistakenly put into the cvs tree the oposite way of what cvs guys meant cvs to be, am I way off, or was this mistake corrected? Believe it or not this, lberally using branches within the CVS, leads to less rather then more work as is often percieved. http://dev.zope.org/CVS/ZopeCVSFAQ I am no less than amazed that we have any sort of release now. Indeed I am always amazed at how any OpenSource project with *multiple* developers manages to get a release out at all :-) Norman ..amen, and thank you. :-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
..BO105 and BK117 pix, was: [Flightgear-devel] Outsider Opinion
On Sat, 27 Mar 2004 01:14:23 +0100, Georg wrote in message [EMAIL PROTECTED]: 4. BO105 helo livery As far as the livery for the BO105 is concerned (I would like to have a medevac livery) I could ask the ADAC for written permission as I am flying with their helos (NOT as a pilot) since nearly two decades and I know that many R/C pilots and even a MSFS helo designer came to us and made(officially granted) photos of our BK117. For ADAC or DRF (rescue organisations in Germany) this all is some sort of cheap PR and welcome as long as there are not conflicts in interest (may be a war game ..). We are flying a BK117 but had a BO105 in exchange for some days the last year at our base. So if anyone is interested in some exteriour photos I made at that time, I can eMail them to him. ..the second you put these online and post the link here, you IMHO qualify as an insider. Welcome onboard! :-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
..Iljas Tu154 as FG bait for your FLY!II guys?, was: [Flightgear-devel] Outsider Opinion
On Sat, 27 Mar 2004 01:14:23 +0100, Georg wrote in message [EMAIL PROTECTED]: Hi, I am observing this mailing list since some time because I am curious what is going on with Flight Gear. Since the very first versions available for Windows (1999?) I tested FG and have to tell you that you are doing a very good job, FG has improved very much in that time and much interesting development is going on. I am a FLY!II simmer due to many aspects (heli flight modell, very open system) but looking for an alternative in the future, that means in 2 or 3 years when FLY will be outdated due to the stopped developement. ..on getting you guys across here, ;-) can the development of a fdm for Iljas new Tu154, serve as a way to show you FLY!II guys how we make new planes in FG? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
..grok law, was: [Flightgear-devel] Outsider Opinion
On Sat, 27 Mar 2004 01:14:23 +0100, Georg wrote in message [EMAIL PROTECTED]: 3. The Trademark violations could be a problem quest Peter Tishma has a name like poison in all the flightsim-community. ...as has Darl McBride and other Microsoft shills at the SCO Group of Lindon, Utah. Do you and your FLY!II guys know of http://Groklaw.net/ ? Even an Austrian/German Flightmagazin for MSFS wrote some articles about him in the past, they had a very bad opinion about what he is doing. Even TRI gave the Cessna and other aircraft some general names (Cessna - Flyhawk ...) in FLY!II, the reason might be these trademark protection. But all the freeware-designers for FLY!, X-Plane and MSFS are undisturbed by this theoretical question and I have not heard about any problem until now. ...over at Groklaw, we're really more amused than worried about such Nigerian 419 style piracy in American courts. The best part is we're gonna get the GPL set firmly as case law first on IBM and then on Microsoft funding. Do I hear tremble damages? ;-) ..I would worry a fair bit more about other free licensed projects, as they may be targetted by scamsters buying up and enforcing IP rights like SCO and Peter Tishma purports and purported to. ..so, we do need to keep our eyes open to avoid running into the next Microsoft funded ambushes in courts. Is as simple as reading license etc terms _first_, and then _carefully_ consider your theoretical options, they _are_ pretty real to Lindows in the Benelux area. ;-) http://www.groklaw.net/article.php?story=200403251307269 -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] mouse.cxx: CURSOR_TWEAKS??
Andy Ross writes:
Does anyone understand what is going on in src/Input/mouse.cxx with
the {X|WIN32}_CURSOR_TWEAKS preprocessor defines? I'm having a hard
time figuring this out. Right now, it looks like the windows and X11
builds actually have different/incompatible behavior for the mouse
cursor.
IMHO we want the WIN32_CURSOR_TWEAKS for all platforms
I didn't know how to do this for X at the time I wrote this
Note there use to be a time delay that would turn the cursor off
after 'x' seconds of no mouse activity and code that turned it
back on detecting any movement under WIN32 also that would
be a nice feature to reintroduce
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim starter motor
On Sat, 27 Mar 2004 15:34:03 -0500, David wrote in message [EMAIL PROTECTED]: Jim Wilson wrote: Ah ok. From memory (not so good) I thought this was configurable. 60 sounds like a good value anyway. Would this make engines appear to start too quickly? There should be a time delay. Pilots talk about starting on the second blade or on the third blade for an engine that starts well. A cold engine, an engine with a weak battery, an engine with aluminum wiring, an inexperienced pilot, etc. can make the starting last much longer, possibly five to ten seconds. During that entire time, the prop is spinning at a constant, slow speed until the engine fires. Spinning up to, say, 45 RPM and then starting the engine instantly would not be very realistic, either. Depending on the engine, some of the cylinders might not fire at first -- that can make the engine run rough for a few seconds before they all catch. ..these parameters can be set in a config file? Slowest cranking I saw start LN-AEB (a 60'ies PA28-140 with the standard 4-banger and quite likely a ditto vintage battery) was a blade every 5 seconds. It was usually a blade every 2 to 3 seconds. Facinating. ;-) ..do we model the compression's effect on crank speed fluctuation? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim starter motor
Arnt Karlsen wrote: ..these parameters can be set in a config file? Slowest cranking I saw start LN-AEB (a 60'ies PA28-140 with the standard 4-banger and quite likely a ditto vintage battery) was a blade every 5 seconds. It was usually a blade every 2 to 3 seconds. Facinating. ;-) So Arnt is suggesting a typical cranking speed of 10-15 rpm, vs. my wild guess of 30 rpm. Neither one is blindingly fast. His worst case example was 6 rpm. I'll mention again that once the engine fires, the jump to normal RPM is pretty-much instantaneous -- there's no gradual spin-up over a few of seconds. ..do we model the compression's effect on crank speed fluctuation? We're a long way from anything like that. Right now, it's basically just a fancy animation. If we wanted to model engine starts properly, we'd have to model each cylinder individually. That would also allow the engine to (possibly) run rough when leaned, based on different air/fuel distribution to different cylinders, etc. (at least until we installed virtual GAMIjectors on the fuel-injected engines). We could also model fouled plugs -- that would encourage fgfs users to do a proper runup before every flight. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Pre-Releases and Releases
Jon Berndt said: I'm not sure what you are talking about. That I can see. I know your concerns are valid. No doubt there is a better way. There always is. But Curt knows what he is doing and this is the schedule that worked this time. We all know what it is like to suddenly have a block of time available to do something and not be sure when we'll see another. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] X-43A flight apparently successful
Jon Berndt said: Today's hypersonic X-43A flight was apparently successful, though I have not seen much news on it, yet. It should appear here: http://www.nasa.gov/missions/research/x43-main.html -and- http://www.dfrc.nasa.gov/ That's really cool. Sure would speed up the trip to LA from here. :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
