Re: [Flightgear-devel] Missing Model Problem
* [EMAIL PROTECTED] (Jon Berndt) [2002.05.30 20:45]: > > I have not been keeping track of changes on the JSBSim XML formats for > > several months, so I'll try to update the -180 definitions tonight and > > see what happens. I will let you know if I get anyway. I'm pretty busy > > these days, so I'd be happy to hand this off to a willing 3rd party to > > pick up the pieces. > > > > Anyway, I'll see what I can do tonight. Thanks > > You can probably just go ahead and write the model as you understand the > JSBSim config file format. It hasn't changed much at all recently. Any > recent changes should be easily and quickly fixable. I went through and updated the config that is currently in JSBSim CVS. There were only minor changes needed to get it looking like the c172 config. I did not make any changes to the aero coefs. I've uploaded all of my changes to here: http://unbeatenpath.net/software/fgfs/PA-28-180/latest/ There's a -set.xml file there too that I basically just copied from the c172. My tests show a strong tendency to roll left. I have to maintain about 60% right aileron to maintain level flight. Replacing the Clb coef with the c172 one seems to fix the problem, but I left the original coef in place for someone with more know-how than me to look at it. Also, the other most notible aero problem I can see is the data tied to flap deflection. Pitch and drag seem to be a little high relative to the flap positions, but I'm not sure. There are several places in the XML file that have "NEEDS WORK" or "FIXME" by them. The only major piece that we hadn't gotten to was the propulsion section. I believe the c172 defaults are still in place. Please feel free to do what you want with this aircraft. I've taken it about as far as I can (with Cameron Munro's help, of course). If you need any data, let me know, and I'll see if I can help. Thanks -- Cameron Moore / Every so often, I like to stick my head out the \ \ window, look up, and smile for a satellite photo. / ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Developer Locations update
David Megginson wrote: > Cameron Moore writes: > > So, if you contribute to FG and would like to be listed, just let me > > know. > > Just to repeat something I mentioned before, it's probably a good idea > not to give your location *too* precisely. Heh, good point. But I like to live dangerously (and I don't have any good stuff, anyway): 37°54.204' N, 122°18.621' W I think that's my driveway. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] LinuxWorld Expo Aug 12-15
I could likely attend and lend a hand. jj On Thu, 30 May 2002, Curtis L. Olson wrote: > Do we have any plans to host an opensource booth at the linux world > expo in SFO aug 12-15. I don't think we've discussed this one yet? > Alex? Jim? > > Curt. > -- > Curtis Olson IVLab / HumanFIRST Program FlightGear Project > Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] > Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Pressure errors in FGEnvironment
I wrote: > First, the air pressures returned from the environment system don't > agree with the standard atmosphere that YASim uses to do its > calibration Heh, funny that. The new environment manager *is* using YASim's numbers. :) Nonetheless, I think I found the problem. In converting the YASim table to the new format, its values were re-encoded as deltas from sea level conditions, with sea level pressure defined as 29.92 inches of mercury. But in the FGEnvironment constructor, I see the following initializer: pressure_sea_level_inhg(28), Now, 28 in. Hg is a reasonable sea level pressure. But it's not the same one that the table is assuming. At sea level, it's off by only about 2 inches. But at altitude, it's off by a whopping TWO inches! :) This value can be set from other places, so I'm not 100% sure this is the problem. I can't test fgfs right now because my fiancee is laying out wedding invitations on the good computer. But it looks pretty suspicious. I'd suggest: -pressure_sea_level_inhg(28), +pressure_sea_level_inhg(29.92), Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim 747-400 climb performance
Jim Wilson wrote: > Andy Ross said: > > The bad pilot technique theory is looking pretty good. If YASim can > > get to 1400fpm at 300 knots, then I move that it be declared > > officially innocent on all counts. :) > > Well maybe not yet...it is better with today's patch...but still run > out of steam in the 29000 range. It also may be time related. In > otherwords the situation gets worse over time. It's not time related. First off, ditch the autopilot. It gets stuck behind the power curve every time I use it. When it does this, it very rapidly (in the space of 30 seconds or so) gets you trimmed all the way down to 200 knots, at which point the engines can't keep you in the air anymore and you have to dive to regain airspeed. Just trim for speed; this is really easy to do in an aircraft this big. You can verify that the climb performance drops slowly off toward zero as the altitude increases, and recovers as you descend. I've done a zillion of these this afternoon. :) That said, here are two more layers to this giant onion of a bug that won't die: First, the air pressures returned from the environment system don't agree with the standard atmosphere that YASim uses to do its calibration. They match pretty well at sea level, but diverge as altitude increase. At 35000 feet, they're too low by 20%, which is substantial. Could someone check and see where the environment system is getting its numbers? The ones YASim uses are typed in from McCormick, who got them from "The ARDC Model Atmosphere". I verified this afternoon that they are correct, so I'm pretty sure the bug lies elsewhere; some difference is fine, of course, but 20% difference at FL350 is a lower low pressure system than any hurricane. Ever. Replacing the new environment system with the old one yields significantly improved performance at altitude. Second, I realize now that the cruise performance numbers in the 747.xml file are tickling a problem. They are specified as a maximum speed of 530 KTAS, which I got out of a book somewhere. Problem is, this corresponds to 0.92 mach. At that speed, the plane should be seeing more drag than YASim calculates because of (as yet unmodelled) transsonic effects. But since YASim doesn't model this extra drag at high speed, it solves for an airplane with extra drag at all speeds. I've replaced the cruise setting in my .xml file with the long-range cruise numbers I found in David's link (the 75% throttle is just a guess), and this makes things better still. ... ... But, after all that, things still aren't quite right. The plane should, by the definition given in the solver output, fly at 490KTAS, FL360 with an AoA of 2.5 degrees. But it doesn't. At that altitude (which is attainable with the above modifications), it wants to fly much faster to stay in the air. I'm still working on it. And did I mention not to use the autopilot? If you must, watch it carefully. If it tries to trim the plane below 300 knots, shut it off! Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] LinuxWorld Expo Aug 12-15
Curtis L. Olson wrote: > If we could get a couple people to commit to spend a chunk of time > in the booth, then I think it would *definitely* be worth getting > something organized. I have a floor pass already, and could easily commit to spending a day in the booth if needed. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim 747-400 climb performance
Andy Ross <[EMAIL PROTECTED]> said: > The bad pilot technique theory is looking pretty good. If YASim can > get to 1400fpm at 300 knots, then I move that it be declared > officially innocent on all counts. :) > Well maybe not yet...it is better with today's patch...but still run out of steam in the 29000 range. It also may be time related. In otherwords the situation gets worse over time. Haven't quite nailed it down, but when I ran a test with the autopilot set at just 300 rpm it went into a stall around 24,000ft. Certainly at 300fpm we should be able to maintain a climb to cruise altitude. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] LinuxWorld Expo Aug 12-15
Alex Perry writes: > > Do we have any plans to host an opensource booth at the linux world > > expo in SFO aug 12-15. I don't think we've discussed this one yet? > > I haven't heard of anybody making plans for a booth at LWCE-SF. > I will not be attending - I have other plans this summer. It is mid-august this year so I'm worried I may have a conflict, but I had such a good time last year, I'd like to see if I could figure out a way to work my schedule so I could get out there again. I got to talk about flightgear non-stop for 2 days straight, what could be more fun! :-) Plus there is a ton of other interesting geek stuff to see and do. I don't think you'd need to be a hard core linux freak to enjoy the show. I mean, hey, linux or windows or mac, you still get all the same free pens and enough fortune cookings and candy to make you gag. :-) It is a fair bit of effort though to organize a booth. A flightgear booth just cries for lots of high end hardware. That means you have issues getting the hardware brought in and taken out ... it's downtown SFO and you can't just pull up to the front door and make a couple trips to haul all your stuff. I remember last year they had a bunch of *expensive* union guys doing the loading/unloading which was a tough obstacle for an unfunded open source booth, even if we wanted to do the work ourselves. (Alex and Jim are probably snickering at my cavalier use fo the word "our") ;-) And if you do manage to get all your equipment in, then you have issues of needing to make sure someone is there all the time to keep an eye on things. I don't think we had any problems last year, but I don't think the booth was ever completely unattended either. If we could get a couple people to commit to spend a chunk of time in the booth, then I think it would *definitely* be worth getting something organized. We have a lot of new stuff we could show, and (I may be a tad biased) but I think we had to be one of the busiest open source booths at the show. There was hardly ever a time when there wasn't at least one person there looking at something ... and most of the time there was a crowd. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Dual monitors
> > The only dual-head card I'v ever dealt with is this ATI peice of crap > > in my workstation here at work. It *sucks* (for VERY large values of > > "suck"). ATI couldn't write a driver properly if you held a gun to > > their collective heads and their lives depended on it. > > ..which ATI dual head card? Product URL? What OS etc? > If memory serves, it's a Radeon VE. I'm using it with two 17" flat panels. The machine is a Dell dual P4 running Win2k. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] enormous exe
Until you can recompile with ./configure --without-logging (you need to run make clean; then make after the configure) you could try minimizing the console window to see if that improves performance. Regards, Curt. Boslough, Mark B writes: > I tried it both ways under windows and it seems not to make > any difference, at least on my machine. > > Mark > > > -Original Message- > > From: Curtis L. Olson [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, May 30, 2002 3:17 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [Flightgear-devel] enormous exe > > > > > > Alex Perry writes: > > > It has a symbol table so that the debugger would be useful. > > > You can "strip" it, but it should have no impact on execution speed. > > > > But perhaps could impact how fast the application is loaded. I > > apologize if I am wrong, but I believe Linux does demand paging so it > > really should impact start times on linux, but perhaps might have an > > impact for dos??? > > > > Curt. > > -- > > Curtis Olson IVLab / HumanFIRST Program FlightGear Project > > Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] > > Minnesota http://www.menet.umn.edu/~curt > > http://www.flightgear.org > > > > ___ > > Flightgear-devel mailing list > > [EMAIL PROTECTED] > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] LinuxWorld Expo Aug 12-15
> Do we have any plans to host an opensource booth at the linux world > expo in SFO aug 12-15. I don't think we've discussed this one yet? I haven't heard of anybody making plans for a booth at LWCE-SF. I will not be attending - I have other plans this summer. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Missing Model Problem
> > Which Roskam did you find the Cherokee numbers in? > > Oops. I was mistaken. It's not Roskam -- it's McCormick, > "Aerodynamics, Aeronautics and Flight Mechanics", Appendix C. Cameron > Munro sent me copies of it. It's a very complete example. > > You could rough-in a Cherokee in YASim first, just to have something > > to drive your model, then ... > > My model? I hope you mean that collectively since there's probably no > way I'll ever be a 3D modeller. :-) > > I have not been keeping track of changes on the JSBSim XML formats for > several months, so I'll try to update the -180 definitions tonight and > see what happens. I will let you know if I get anyway. I'm pretty busy > these days, so I'd be happy to hand this off to a willing 3rd party to > pick up the pieces. > > Anyway, I'll see what I can do tonight. Thanks You can probably just go ahead and write the model as you understand the JSBSim config file format. It hasn't changed much at all recently. Any recent changes should be easily and quickly fixable. Jon smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] Dual monitors
On Thu, 30 May 2002 14:13:31 -0700 (PDT), Gene Buckle <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > The only dual-head card I'v ever dealt with is this ATI peice of crap > in my workstation here at work. It *sucks* (for VERY large values of > "suck"). ATI couldn't write a driver properly if you held a gun to > their collective heads and their lives depended on it. ..which ATI dual head card? Product URL? What OS etc? -- ..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] enormous exe
I tried it both ways under windows and it seems not to make any difference, at least on my machine. Mark > -Original Message- > From: Curtis L. Olson [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 30, 2002 3:17 PM > To: [EMAIL PROTECTED] > Subject: Re: [Flightgear-devel] enormous exe > > > Alex Perry writes: > > It has a symbol table so that the debugger would be useful. > > You can "strip" it, but it should have no impact on execution speed. > > But perhaps could impact how fast the application is loaded. I > apologize if I am wrong, but I believe Linux does demand paging so it > really should impact start times on linux, but perhaps might have an > impact for dos??? > > Curt. > -- > Curtis Olson IVLab / HumanFIRST Program FlightGear Project > Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] > Minnesota http://www.menet.umn.edu/~curt > http://www.flightgear.org > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Missing Model Problem
Jim Wilson writes: > Is Innovation3D's texture mapping any better? It has a UV editor, but I haven't tried it. > If not I'm going to take a stab at making a command line texture > re-mapper for ac3d files. To start with it'll probably just be > some sort of script (awk?) that adjusts the x or y coordinates. It would take a lot less time to learn Blender. Besides, batch-mode UV mapping wouldn't be fun. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: YASim solution solution?
> not only they are not useful as speed brakes but instead they seem to > provide extra thrust and lift. i was playing with the 747-yasim model > yesterday, trying to come in for landing, no power (still going pretty > fast at about 300 knots), gear down and then i lowered the flaps. it > was fun. the plane started gaining speed and altitude. i was at 2000 > feet when i lowered the flaps but before i knew it i was past 7000' > and my speed was about 450 knots. boy that was fun. i tried to > reproduce this, but so far no luck. I just broke the record: too a 747-400 to 14ft on idle power, full flaps. See snapshot for proof. Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === fgfs-screen-002.png Description: PNG image
[Flightgear-devel] Re: YASim solution solution?
Andy Ross <[EMAIL PROTECTED]> writes: > reason to split them out. Although be aware that the flap drag bug > prevents them from being very useful for speedbrakes. > not only they are not useful as speed brakes but instead they seem to provide extra thrust and lift. i was playing with the 747-yasim model yesterday, trying to come in for landing, no power (still going pretty fast at about 300 knots), gear down and then i lowered the flaps. it was fun. the plane started gaining speed and altitude. i was at 2000 feet when i lowered the flaps but before i knew it i was past 7000' and my speed was about 450 knots. boy that was fun. i tried to reproduce this, but so far no luck. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] enormous exe
Keith Wiley wrote: > > Something I've been wondering about. The program that comes with the > downloadable binary is about 4 megs. The program that is built from cvs > is about 56 megs. I have been having major framerate issues with the cvs > version (2 or 3 fps) whereas the binary version runs at 7 or 8 fps. no wonder. At that file size you'll get problems. 56 MB looks like a faulty compiler to me. That's more than the source code! CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] LinuxWorld Expo Aug 12-15
Do we have any plans to host an opensource booth at the linux world expo in SFO aug 12-15. I don't think we've discussed this one yet? Alex? Jim? Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] enormous exe
Alex Perry writes: > It has a symbol table so that the debugger would be useful. > You can "strip" it, but it should have no impact on execution speed. But perhaps could impact how fast the application is loaded. I apologize if I am wrong, but I believe Linux does demand paging so it really should impact start times on linux, but perhaps might have an impact for dos??? Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
AW: [Flightgear-devel] enormous exe
Keith, > Something I've been wondering about. > The program that comes with the > downloadable binary is about 4 megs. > The program that is built from cvs The exe produced via CVS has numerous debugging information. Use strip fgfs.exe to cut it down to normal size. (BTW, this is in the manual.) Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Dual monitors
Jon S Berndt writes: >> >A dual head card - at least in my case - works very good. >The drawback is as I stated before, but that can be fixed >by not displaying the panel. The HUD, however, is split >between two monitors. Other than that, it's flawless and >fast. This is one of the arguments for using the ssgContext mechanism instead of one global GL context as we currently do in that then one could shift the individual contexts arround through < sh.. > the properties < /sh.. > This is assuming of course that the HUD and Panel were had their own ssgContext. Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] enormous exe
It has a symbol table so that the debugger would be useful. You can "strip" it, but it should have no impact on execution speed. > Something I've been wondering about. The program that comes with the > downloadable binary is about 4 megs. The program that is built from cvs > is about 56 megs. I have been having major framerate issues with the cvs > version (2 or 3 fps) whereas the binary version runs at 7 or 8 fps. I'm > trying to figure out how to turn off the text-dump to the cmd window > (loggin). So far the --disable-logging flag hasn't work. However, I also > suspect that it may have something to do with the gigantic program that > cvs produces. Why is the program so large? > > > Keith Wiley[EMAIL PROTECTED] > http://www.unm.edu/~keithw http://www.mp3.com/KeithWiley > > "Yet mark his perfect self-contentment, and hence learn his lesson, > that to be self-contented is to be vile and ignorant, and that to > aspire is better than to be blindly and impotently happy." >-- Edwin A. Abbott, Flatland > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Dual monitors
> I might modify your statement to read: two individual > video cards on the same computer is a bad idea. > > A dual head card - at least in my case - works very good. > The drawback is as I stated before, but that can be fixed > by not displaying the panel. The HUD, however, is split > between two monitors. Other than that, it's flawless and > fast. > The only dual-head card I'v ever dealt with is this ATI peice of crap in my workstation here at work. It *sucks* (for VERY large values of "suck"). ATI couldn't write a driver properly if you held a gun to their collective heads and their lives depended on it. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Dual monitors
On Thu, 30 May 2002 13:57:41 -0700 (PDT) Gene Buckle <[EMAIL PROTECTED]> wrote: >It's generally accepted in the flight simulator community >that trying to >get two out-the-cockpit views on the same computer is a >Bad Idea(tm). I might modify your statement to read: two individual video cards on the same computer is a bad idea. A dual head card - at least in my case - works very good. The drawback is as I stated before, but that can be fixed by not displaying the panel. The HUD, however, is split between two monitors. Other than that, it's flawless and fast. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Dual monitors
It's generally accepted in the flight simulator community that trying to get two out-the-cockpit views on the same computer is a Bad Idea(tm). It's recommended that if you _must_ run two displays on the same computer that you run something less intense on the secondary display. For instance, among MSFS users it's popular to run one of the Project Magenta (or even OpenGC), or FreeFD programs on the 2nd display. This gives you 1 full screen out the cockpit view and other screen that holds all your avionics. If you have two matched boards (typically nVidia chipset boards) even using one agp and one pci, you technically _can_ do this with many software packages. I've seen a game of Quake ][ going on a single machine with 5 displays running. It worked very well, but I would NOT call the results "typical". A much better choice would be to run multiple computer outside views. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Dual monitors
Boslough, Mark B writes: > Does that mean that my GeForce 3 is overkill for fgfs? As I understand it, the GeForce3 can run at higher resolutions than a GeForce2 for the same frame rate. The GeForce3 introduces workable antialiasing. The GeForce2 antialiasing is not generally useful ... i.e. it's not something you'd want to just turn on and forget about it. The GeForce3 probably supports additional opengl extension and I'm sure has higher throughput throughout ... Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] enormous exe
Something I've been wondering about. The program that comes with the downloadable binary is about 4 megs. The program that is built from cvs is about 56 megs. I have been having major framerate issues with the cvs version (2 or 3 fps) whereas the binary version runs at 7 or 8 fps. I'm trying to figure out how to turn off the text-dump to the cmd window (loggin). So far the --disable-logging flag hasn't work. However, I also suspect that it may have something to do with the gigantic program that cvs produces. Why is the program so large? Keith Wiley[EMAIL PROTECTED] http://www.unm.edu/~keithw http://www.mp3.com/KeithWiley "Yet mark his perfect self-contentment, and hence learn his lesson, that to be self-contented is to be vile and ignorant, and that to aspire is better than to be blindly and impotently happy." -- Edwin A. Abbott, Flatland ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Missing Model Problem
Don't forget about wings... http://www.wings3d.com It's BSD licensed ;) (for modelling, not texturing.) > > In any case it'd be awful nice to have a gpl'd modler. Right now > > we've got a choice between two closed source binaries. One from a > > guy that may or may not ever get around to fixing the bugs, let > > alone improve it. And another from a larger company that is now as > > good as gone. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Developer Locations update
Cameron, I have added a link to your page from the flightgear web site. Thanks, Curt. Cameron Moore writes: > Many of you may be aware that I have a "Developer Locations" page[1] for > FlightGear (similar to Debian's). It's completely unofficial, but I > received a good response from everyone when I started it. Since then > we've gained a few new contributers. > > So, if you contribute to FG and would like to be listed, just let me > know. Thanks > > [1] http://unbeatenpath.net/software/fgfs/Developers/Developers.html > > PS - Just did my first "-O1 -fno-inline" compile, and I love it. > Thanks, Andy > -- > Cameron Moore > [ Okay, who stopped the payment on my reality check? ] > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Dual monitors
Does that mean that my GeForce 3 is overkill for fgfs? > -Original Message- > From: Jon S Berndt [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 30, 2002 2:25 PM > To: [EMAIL PROTECTED] > Subject: Re: [Flightgear-devel] Dual monitors > > > On Thu, 30 May 2002 14:14:13 -0600 > "Boslough, Mark B" <[EMAIL PROTECTED]> wrote: > >Thanks Jon, > > > >Mine are both single head, the Geforce 3 is AGP and the other > >is PCI. Maybe that's the problem. I always run with the heads-up > >display anyway so the panel problem probably would not be an issue > >for me. I'll see if I can find a duel head PCI card. > > I'm not sure how things would work if you run with two > video cards. That might screw things up - especially if > one is dual head. I'd recommend going to the Amamax web > site (www.amamax.com) and buying their Inno3D Dual Head > AGP GeForce2 MX/400 card w/64 MB RAM and TV out. It should > run about $100. If you want to run a second card, I think > it ought to be the PCI card. That ought to get you three > heads. I think that can be made to work, from what I've > read on the Inno3D site, but don't quote me. > > Jon > > > Jon > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim solution solution?
David Megginson <[EMAIL PROTECTED]> said: > Andy Ross writes: > > > Does anyone have good, hard climb numbers for this plane? I mean > > stuff like: "At NNN pounds gross weight, XXX feet MSL and YYY knots > > TAS, the 747-400 can climb at ZZZ feet per minute." My suspicion is > > that we're being bitten by a combination of bad performance numbers > > being fed to YASim, and bad pilot climb technique. > > >From the BADA site I posted a couple of days ago: > > ftp://bada.eurocontrol.fr/bada/3.3/B744__.PTF > That's it...the one I saw the other day. And you can see why the numbers suprised me... e.g. with nominal weight ROCD is 1110fpm at FL 350, 1850fpm at 280. A lot higher than other sources suggest like the ones that Andy found. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Dual monitors
Jon S Berndt writes: > I'm not sure how things would work if you run with two > video cards. Think about some of the implications ... For instance, textures are stored on the card, so if you load a texture into one card, it would some how need to be loaded into the 2nd card if a portion of the window overlaps onto the second display ... not impossible, but perhaps beyond the scope of current drivers. If a window spans two cards, the drivers would some how have to draw to both cards at the same time ... again this get's really complicated really fast. You say you have two different cards with perhaps different amounts of texture ram, and each possibly supporting different extensions. What if you fill up the texture ram of the card with less onboard ram and not the other? What if you start an application on one card, the app queries to see what extension that card supports, and then you drag the window over to a less capable card? What if you have two card from different vendors with no cooperation between the respective driver writers? There are some really tough, complicated issues here so it doesn't suprise me if the driver writers dropped 10 yards and punted on this. Curt. > That might screw things up - especially if > one is dual head. I'd recommend going to the Amamax web > site (www.amamax.com) and buying their Inno3D Dual Head > AGP GeForce2 MX/400 card w/64 MB RAM and TV out. It should > run about $100. If you want to run a second card, I think > it ought to be the PCI card. That ought to get you three > heads. I think that can be made to work, from what I've > read on the Inno3D site, but don't quote me. > > Jon > > > Jon > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Dual monitors
On Thu, 30 May 2002 14:14:13 -0600 "Boslough, Mark B" <[EMAIL PROTECTED]> wrote: >Thanks Jon, > >Mine are both single head, the Geforce 3 is AGP and the other >is PCI. Maybe that's the problem. I always run with the heads-up >display anyway so the panel problem probably would not be an issue >for me. I'll see if I can find a duel head PCI card. I'm not sure how things would work if you run with two video cards. That might screw things up - especially if one is dual head. I'd recommend going to the Amamax web site (www.amamax.com) and buying their Inno3D Dual Head AGP GeForce2 MX/400 card w/64 MB RAM and TV out. It should run about $100. If you want to run a second card, I think it ought to be the PCI card. That ought to get you three heads. I think that can be made to work, from what I've read on the Inno3D site, but don't quote me. Jon Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Dual monitors
Thanks Jon, Mine are both single head, the Geforce 3 is AGP and the other is PCI. Maybe that's the problem. I always run with the heads-up display anyway so the panel problem probably would not be an issue for me. I'll see if I can find a duel head PCI card. Mark > -Original Message- > From: Jon S Berndt [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 30, 2002 2:05 PM > To: [EMAIL PROTECTED] > Subject: Re: [Flightgear-devel] Dual monitors > > > On Thu, 30 May 2002 13:57:09 -0600 > "Boslough, Mark B" <[EMAIL PROTECTED]> wrote: > > > >I am attempting to run flightgear under Windows 2000 on a > >machine with 2 > >monitors. My primary monitor is driven by a Geforce 3, > >and my second one is > > ... > >MX, so I don't think it is a video driver problem. Is > >there a way to run on > >either monitor on a dual system (or even better, is there > >a way to span 2 > >monitors with one fgfs window)? > > > I've got two monitors run off a single, dual-head GeForce > 2 MX/400. Twin view is enabled. I use the nVidia driver. > When I crank up FlightGear I can maximize it and it spans > both screens just fine. The only drawback is that the > panel fills up pretty much the whole window - I get no out > the window view above it. > > Jon > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim solution solution?
Andy Ross writes: > Does anyone have good, hard climb numbers for this plane? I mean > stuff like: "At NNN pounds gross weight, XXX feet MSL and YYY knots > TAS, the 747-400 can climb at ZZZ feet per minute." My suspicion is > that we're being bitten by a combination of bad performance numbers > being fed to YASim, and bad pilot climb technique. >From the BADA site I posted a couple of days ago: ftp://bada.eurocontrol.fr/bada/3.3/B744__.PTF All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Dual monitors
On Thu, 30 May 2002 13:57:09 -0600 "Boslough, Mark B" <[EMAIL PROTECTED]> wrote: > >I am attempting to run flightgear under Windows 2000 on a >machine with 2 >monitors. My primary monitor is driven by a Geforce 3, >and my second one is > ... >MX, so I don't think it is a video driver problem. Is >there a way to run on >either monitor on a dual system (or even better, is there >a way to span 2 >monitors with one fgfs window)? I've got two monitors run off a single, dual-head GeForce 2 MX/400. Twin view is enabled. I use the nVidia driver. When I crank up FlightGear I can maximize it and it spans both screens just fine. The only drawback is that the panel fills up pretty much the whole window - I get no out the window view above it. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Dual monitors
I am attempting to run flightgear under Windows 2000 on a machine with 2 monitors. My primary monitor is driven by a Geforce 3, and my second one is a Geforce 2 MX. When I run fgfs, it pops up on the primary monitor and runs fine, but when I move the window it to the sencondary monitor the image freezes. The same thing happens when I run the primary monitor off the 2 MX, so I don't think it is a video driver problem. Is there a way to run on either monitor on a dual system (or even better, is there a way to span 2 monitors with one fgfs window)? Thanks!!! Mark Boslough ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim solution solution?
Andy Ross <[EMAIL PROTECTED]> said: > Jim Wilson wrote: > > Yeah but look at the values again...we're getting close to tropopause > > value at 23000ft. Mach should be well over 600knots at 23000ft, > > unless it's _really_ warm. > > Mach 1 at the tropopause and above is just about exactly 295 m/s, > which is 573 knots *true* airspeed. The numbers you quote are > "indicated" airspeed (that's the "I" in KIAS). That means that they > are corrected for density (basically by the square root of the density > ratio at subsonic speeds) and are much lower than true speeds at low > densities. At 23000 feet MSL, the correction is about 1.5, which > agrees very closely with the numbers you cite. > Ah...oh. Sorry about that. :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] compile/make/build flags?
> Keith Wiley wrote: > > In particular, to ditch the data dump to the cmd window, but where can I > > find a comprehensive list. I don't see this stuff on the website > > anywhere. > > Just do ./configure > this will give a full list of the possibilities. > > Yours is: --disable-logging Okay. At first I thought you meant that --disable-logging was a flag to configure, as in: % ./configure --disable-logging so I spent half an hour rebuilding for nothing. Anyway, I think I understand now, that --disable-logging a flag to the executable, as in: C:\>runfgfs.bat --disable-logging however, the program doesn't run if I give it this flag. Instead if pukes up a long list of legal flags, none of which are disable-logging, and none of which seem to suggest a similar action by a slightly different flag name. What am I missing here? Keith Wiley[EMAIL PROTECTED] http://www.unm.edu/~keithw http://www.mp3.com/KeithWiley "Yet mark his perfect self-contentment, and hence learn his lesson, that to be self-contented is to be vile and ignorant, and that to aspire is better than to be blindly and impotently happy." -- Edwin A. Abbott, Flatland ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim solution solution?
Andy Ross <[EMAIL PROTECTED]> said: > Jim Wilson wrote: > > Think I saw something that was maybe at a fixed weight. Not the full > > Flight manual table. When I get home I'll look for it. But I was > > suprised at the data. At lower altitudes it was over 4000fpm and was > > at least 2000fpm up to and over 3ft. Finally dropped off to about > > 400fpm at 4ft, reaching 0 somewhere around 43000ft. > > I found this X-Plane site: > > http://webpages.charter.net/rtpete/html/747.html > > Which agrees with you for the most part: > > > ROC Rate Of Climb > > [...] > > Above 10,000 ft to Cruise Flight Level FL > > * 2200fpm from 10,000 - 20,000ft @ 280 - 340kts > > * 2000 - 1500fpm from 20,000 - 26,000ft > > * 1500 - 400fpm from 26,000 - 35,000 ft depending on weight Yes I've seen that, which is why the other table suprised me, it's numbers were generally higher. Showing the 747-400 capable of climbing up to 43000ft and cruising at 40,000ft. > But note the speed: 280-340 knots (it doesn't say indicated or true, > sadly). That's much higher than the 230 knots that I was flying last > night. I think what's happening is that for the initial climb out, > the aircraft wants to be in a high-AoA attitude; otherwise you'd have > a liftoff speed of 300+ knots and the wheels would incinerate. Once > off the ground, the 250 knot speed limit is still on the back side of > the power curve. If the autopilot is engaged there, the aircraft will > get stuck on the back side, and never find the high-efficiency climb > regime at lower AoA. > > Try this (since I'm at work and can't): trim for 250 knots only up to > 1 feet, and then push the nose down and accelerate to something > like 300 before engaging the autopilot again (or better yet, trim for > 300 knots and don't engage the autopilot at all). See if the climb > performance in the flight levels improves. I've run many tests on that theory, and trying to find the right way. Even stepping up a couple thousand feet at a time keeping the pitch very gradual and the airspeed up it still dies out in the mid 20kft range. Can you commit that air temperature fix? That sounds like it might be important. If the air is too thin for the altitude, that AoA margin could be very small indeed. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] YASim 747-400 climb performance
More evidence. The following quote is from an HTMLized google cache of a file named "747operations.pdf". The file itself is gone from the web, unfortunately. It appears to be a "POH" compiled for an MSFS virtual airline: > After climbing as described above to 10,000 feet, reduce climb to > 500fpm. Accelerate to 280-300kts. If using autothrottle, increase by > 10-20kts, wait until aircraft attains that speed, and increase another > 10-20kts. Once accelerated, increase climb back to 1,400 to 1,800 > fpm. Once you are stable and climbing, you may turn off the fasten > seatbelt sign. At about 12,000 feet, switch to mach hold and set to > .55-.60. Increase up to .70 if needed. Do not drop below 240kts. The bad pilot technique theory is looking pretty good. If YASim can get to 1400fpm at 300 knots, then I move that it be declared officially innocent on all counts. :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim solution solution?
--- Jim Wilson <[EMAIL PROTECTED]> wrote: > Andy Ross <[EMAIL PROTECTED]> said: > > > Jim Wilson wrote: > > > On the other hand it could be lift. A possible > clue: when I'm having > > > trouble the "mach" reading seems to be way too > high as compared to the > > > KAIS reading just above. Examples: > > > > > > @ 19000ft 419KIAS MACH=0.91 > > > @ 23000ft 344KIAS MACH=0.83 > > > > Those numbers look correct to me. As altitude > increases, the speed of > > sound is decreasing due to the drop in temperature > and the absolute > > speed corresponding to "indicated" airspeed is > increasing due to the > > drop in density. At sea level, mach one is about > 700 KIAS. At the > > tropopause, it's only something like 370. > > Yeah but look at the values again...we're getting > close to tropopause value at > 23000ft. Mach should be well over 600knots at > 23000ft, unless it's _really_ warm. Be careful here. Andy is, I believe, putting out calibrated airspeed as IAS. Soundspeed is usually calculated in terms of true airspeed, which will be considerably higher CAS at high altitudes and/or mach numbers. > > Best, > > Jim > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Missing Model Problem
David Megginson <[EMAIL PROTECTED]> said: > In addition to PPE (ppe.sourceforge.net), there's K3D > (k3d.sourceforge.net) and Innovation3D (innovation3d.sourceforge.net). > I played with innovation 3D a bit, and while it's OK, it's no > Blender. For now, I'm willing to take my chances with a non-free, > unsupported app, as long as I can export into formats that other tools > support. Innovation3D is in Debian, so just type > Is Innovation3D's texture mapping any better? If not I'm going to take a stab at making a command line texture re-mapper for ac3d files. To start with it'll probably just be some sort of script (awk?) that adjusts the x or y coordinates. Probably that statement in my last message should have been more specific: we need a _usable_ 3d gpl'd modling package that is suitable for flightgear. AC3D is actually ideal for what we are doing with a very small number of bugs and weaknesses. For setting up the geometry of an aircraft model, I can't imagine something easier and more effective. The texturing is not good and could be greatly improved with very little effort. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim solution solution?
Jim Wilson wrote: > Yeah but look at the values again...we're getting close to tropopause > value at 23000ft. Mach should be well over 600knots at 23000ft, > unless it's _really_ warm. Mach 1 at the tropopause and above is just about exactly 295 m/s, which is 573 knots *true* airspeed. The numbers you quote are "indicated" airspeed (that's the "I" in KIAS). That means that they are corrected for density (basically by the square root of the density ratio at subsonic speeds) and are much lower than true speeds at low densities. At 23000 feet MSL, the correction is about 1.5, which agrees very closely with the numbers you cite. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim solution solution?
Jim Wilson wrote: > Think I saw something that was maybe at a fixed weight. Not the full > Flight manual table. When I get home I'll look for it. But I was > suprised at the data. At lower altitudes it was over 4000fpm and was > at least 2000fpm up to and over 3ft. Finally dropped off to about > 400fpm at 4ft, reaching 0 somewhere around 43000ft. I found this X-Plane site: http://webpages.charter.net/rtpete/html/747.html Which agrees with you for the most part: > ROC Rate Of Climb > [...] > Above 10,000 ft to Cruise Flight Level FL > * 2200fpm from 10,000 - 20,000ft @ 280 - 340kts > * 2000 - 1500fpm from 20,000 - 26,000ft > * 1500 - 400fpm from 26,000 - 35,000 ft depending on weight But note the speed: 280-340 knots (it doesn't say indicated or true, sadly). That's much higher than the 230 knots that I was flying last night. I think what's happening is that for the initial climb out, the aircraft wants to be in a high-AoA attitude; otherwise you'd have a liftoff speed of 300+ knots and the wheels would incinerate. Once off the ground, the 250 knot speed limit is still on the back side of the power curve. If the autopilot is engaged there, the aircraft will get stuck on the back side, and never find the high-efficiency climb regime at lower AoA. Try this (since I'm at work and can't): trim for 250 knots only up to 1 feet, and then push the nose down and accelerate to something like 300 before engaging the autopilot again (or better yet, trim for 300 knots and don't engage the autopilot at all). See if the climb performance in the flight levels improves. I'll see if I can throw together a "climb rate finder" program, along the same lines as the jet thrust analyzer I did yesterday. This would be generically useful -- being able to hand it a YASim description and get back a chart of best climb speed/AoA at each altitude. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim solution solution?
Andy Ross <[EMAIL PROTECTED]> said: > Jim Wilson wrote: > > On the other hand it could be lift. A possible clue: when I'm having > > trouble the "mach" reading seems to be way too high as compared to the > > KAIS reading just above. Examples: > > > > @ 19000ft 419KIAS MACH=0.91 > > @ 23000ft 344KIAS MACH=0.83 > > Those numbers look correct to me. As altitude increases, the speed of > sound is decreasing due to the drop in temperature and the absolute > speed corresponding to "indicated" airspeed is increasing due to the > drop in density. At sea level, mach one is about 700 KIAS. At the > tropopause, it's only something like 370. Yeah but look at the values again...we're getting close to tropopause value at 23000ft. Mach should be well over 600knots at 23000ft, unless it's _really_ warm. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim solution solution?
Andy Ross <[EMAIL PROTECTED]> said: > Does anyone have good, hard climb numbers for this plane? I mean > stuff like: "At NNN pounds gross weight, XXX feet MSL and YYY knots > TAS, the 747-400 can climb at ZZZ feet per minute." My suspicion is > that we're being bitten by a combination of bad performance numbers > being fed to YASim, and bad pilot climb technique. Think I saw something that was maybe at a fixed weight. Not the full Flight manual table. When I get home I'll look for it. But I was suprised at the data. At lower altitudes it was over 4000fpm and was at least 2000fpm up to and over 3ft. Finally dropped off to about 400fpm at 4ft, reaching 0 somewhere around 43000ft. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Strange property thing?
Andy Ross <[EMAIL PROTECTED]> said: > The simulator "freezing" is almost certainly due to a crash (the > airplane kind, not a segfault) on startup. Why? Dunno. As to the > rest of the symptoms, I'm as clueless as you are. Can you post the > "broken" XML file so I can try to reproduce it? YASim is involved > somehow, so I'd be willing to hack at it. > Straight out of CVS. And so far haven't heard anyone else complain so who knows. More than likely it is a weakness lurking in the property code. At some point I'll take a closer look. It might very well depend on what you have for other xml files and settings in .fgfsrc. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] compile/make/build flags?
Keith Wiley wrote: > In particular, to ditch the data dump to the cmd window, but where can I > find a comprehensive list. I don't see this stuff on the website > anywhere. Just do ./configure this will give a full list of the possibilities. Yours is: --disable-logging Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] compile/make/build flags?
In particular, to ditch the data dump to the cmd window, but where can I find a comprehensive list. I don't see this stuff on the website anywhere. Keith Wiley[EMAIL PROTECTED] http://www.unm.edu/~keithw http://www.mp3.com/KeithWiley "Yet mark his perfect self-contentment, and hence learn his lesson, that to be self-contented is to be vile and ignorant, and that to aspire is better than to be blindly and impotently happy." -- Edwin A. Abbott, Flatland ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim solution solution?
Jim Wilson wrote: > There should be speed brakes which would have helped a lot, but they > might not be implemented yet. Sure are: /controls/spoilers > There are also a bunch of flaps on a real 747 and I'm not sure which > ones are actually modeled. All of them; YASim models flaps symbolically as a property of the wing object; there's no need to put each surface in the configuration file They're not individually controllable anyway, so there'd be little reason to split them out. Although be aware that the flap drag bug prevents them from being very useful for speedbrakes. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim solution solution?
Major A wrote: > This may or may not have anything to do with the jet code, but with > the 747-yasim, I cannot slow the plane below about 280kt in level > flight at 3000ft ASL with throttles at minimum and full flaps, which > makes the plane rather hard to land... By way of disclosure: there is a known bug in the YASim computation of drag from flaps, which results in far too little drag being applied at full flaps. But that's not your problem. :) You seem to be expecting the aircraft to slow instantly when you pull back on the throttles. It won't. It's a *big* jet, and it takes a *long* time to resond to speed changes. I can verify that it trims nicely for approach at 136 knots when fuel is at 20% (you have to do this manually; the default is 50%, which is much heavier). This behavior is guaranteed by the YASim solver, in fact. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim solution solution?
Jim Wilson wrote: > On the other hand it could be lift. A possible clue: when I'm having > trouble the "mach" reading seems to be way too high as compared to the > KAIS reading just above. Examples: > > @ 19000ft 419KIAS MACH=0.91 > @ 23000ft 344KIAS MACH=0.83 Those numbers look correct to me. As altitude increases, the speed of sound is decreasing due to the drop in temperature and the absolute speed corresponding to "indicated" airspeed is increasing due to the drop in density. At sea level, mach one is about 700 KIAS. At the tropopause, it's only something like 370. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim solution solution?
Jim Wilson wrote: > Actually I tried all the way up to 80,000lbs and still ran into > problems in the 25000ft range. There is a little uncertaintly in just > what I'm observing. Basically there is a steady decrease in > attainable airspeed. I found one bug. There was a property name typo* in David's changes that hooked the global environment into YASim. This resulted in all temeratures at runtime (but not at solution time) being exactly 0 degrees C. This is far too warm for the flight levels, which resulted in an air density that was significantly lower than it should have been. Effectively, the airplane was performing as it it were at a higher altitude than it was. This improves things a bit, as does the increase of thrust to 63737 pounds (we should probably check that number in, btw). I did discover, however, that the airplane has a very sensitive "back of the power curve" behavior. I had it trimmed for climb at about 230 kias (about 7 degrees of AoA), and topped out at a service ceiling of FL220. Gently easing down on the trim, I had it climbing at 500fpm again at 260 kias and 4 degrees. Then I had to go to bed, so I didn't get a complete set of numbers. But certainly "climbing too slow" is part of the problem here. You need to keep the AoA down to avoid burning all your thrust working against induced drag. Does anyone have good, hard climb numbers for this plane? I mean stuff like: "At NNN pounds gross weight, XXX feet MSL and YYY knots TAS, the 747-400 can climb at ZZZ feet per minute." My suspicion is that we're being bitten by a combination of bad performance numbers being fed to YASim, and bad pilot climb technique. Andy * "degC" instead of "degc". Norman, you can fire away at the lack of symbol safety in the property system. This is one circumstance where it's deserved. :) -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Strange property thing?
Jim Wilson wrote: > With everything synced to the current CVS the YASim fdm fails to start > with 747-yasim on my system. It just spews a bunch of "Fail to unbind > property" messages and gives up. Flightgear keeps on going however. > The scene comes up...everything works, but the fdm is dead. I doubt these are related. The property unbind stuff is legacy code in YASim, from the days when some properties were bound to FGInterface/FGEngInterface (specifically the first two engines -- but the 747 has four), but others had to be set manually. Things have changed, and those properties are no longer bound the way they used to be, so the unbind calls result in warnings. But they're benign. The simulator "freezing" is almost certainly due to a crash (the airplane kind, not a segfault) on startup. Why? Dunno. As to the rest of the symptoms, I'm as clueless as you are. Can you post the "broken" XML file so I can try to reproduce it? YASim is involved somehow, so I'd be willing to hack at it. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Developer Locations update
Cameron Moore <[EMAIL PROTECTED]> said: Hi Cameron, You can flag me at 44-48N /068-49W. It's actually the location of KBGR, which is less than a mile away. Best, Jim -- Jim Wilson - IT Manager Kelco Industries PO Box 160 58 Main Street Milbridge, ME 04658 207-546-7989 - FAX 207-546-2791 http://www.kelcomaine.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Cessna POH's
Christian Mayer writes: > > If you mean large transport planes, then it's a whole different story. > > Big birds like the 747 (or even a 50-seater regional jet) have a large > > set of very long, very expensive manuals governed by the ATA 2100 > > standard, with names like AMM, FIM/FRM, CMM, SRM, and so on. The AMM > > (Aircraft Maintenance Manual) alone for a big jet can be over 200,000 > > pages, and it has to be updated every couple of months -- you can be > > that the cost of that gets passed on to the customer somehow. > > Well, there should be outdated version of it. As they are "useless" we > should be able to get them very cheap. But who sells them? The airlines get them directly from the aircraft manufacturers. I'd be surprised if they were allowed to resell outdated ones. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Cessna POH's
David Megginson wrote: > > Christopher S Horler writes: > > > I don't suppose such things exist for larger planes (or at least > > they wouldn't be so readily available)? > > Larger is relative. If you mean larger Cessnas (like the 310 or > Caravan), it probably wouldn't hurt to call -- they might cost a bit > more, with extra engines (and associated emergency procedures) etc., > but I'd guess that they'd still be under USD 100 if they're in stock. > > If you mean large transport planes, then it's a whole different story. > Big birds like the 747 (or even a 50-seater regional jet) have a large > set of very long, very expensive manuals governed by the ATA 2100 > standard, with names like AMM, FIM/FRM, CMM, SRM, and so on. The AMM > (Aircraft Maintenance Manual) alone for a big jet can be over 200,000 > pages, and it has to be updated every couple of months -- you can be > that the cost of that gets passed on to the customer somehow. Well, there should be outdated version of it. As they are "useless" we should be able to get them very cheap. But who sells them? CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Cessna POH's
Christopher S Horler writes: > I don't suppose such things exist for larger planes (or at least > they wouldn't be so readily available)? Larger is relative. If you mean larger Cessnas (like the 310 or Caravan), it probably wouldn't hurt to call -- they might cost a bit more, with extra engines (and associated emergency procedures) etc., but I'd guess that they'd still be under USD 100 if they're in stock. If you mean large transport planes, then it's a whole different story. Big birds like the 747 (or even a 50-seater regional jet) have a large set of very long, very expensive manuals governed by the ATA 2100 standard, with names like AMM, FIM/FRM, CMM, SRM, and so on. The AMM (Aircraft Maintenance Manual) alone for a big jet can be over 200,000 pages, and it has to be updated every couple of months -- you can be that the cost of that gets passed on to the customer somehow. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] fgfs-base "bugs"
Cameron Moore writes: > FYI, the ChangeLog file in the base package needs to be updated to point > to our "new" -cvslogs list page: > > http://mail.flightgear.org/mailman/listinfo/flightgear-cvslogs > > Also, do we use the version file anymore? I'm guessing not since mine > says 0.7.9. :-) Ooops, fixed ... Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Developer Locations update
Cameron Moore writes: > Many of you may be aware that I have a "Developer Locations" page[1] for > FlightGear (similar to Debian's). It's completely unofficial, but I > received a good response from everyone when I started it. Since then > we've gained a few new contributers. > > So, if you contribute to FG and would like to be listed, just let me > know. Thanks Just to repeat something I mentioned before, it's probably a good idea not to give your location *too* precisely. After all, we often post about what hardware we own, when we're going away on vacation, etc. -- perhaps just degrees and minutes will be good enough (it will tell someone your neighbourhood but not your house); even just degrees would be OK. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Missing Model Problem
Jim Wilson writes: > Thanks. I'm doing some major re-work with it now...basicly after > figuring out how to get around some of ac3d limitations. AC3D > works well for this stuff, but it's texturing options are limited > (but in the end sufficient). Blender is looking more attractive > but every time I open it up I just get overwhelmed. It's got a lot > more in it than we need for modeling aircraft. AC3D is easy to > learn and it isn't bad once you figure out how to get around it's > limitations and bugs. Yes, AC3D's lack of useful texturing support pushed me to Blender. Blender is a scary brute, but it took me only a couple of hours playing with online tutorials (start with the castle) before I could make my first DC-3 model. Now the program seems natural and intuitive to me, though I limit myself to mesh work. You can import your current 747 into Blender with only a little loss, then start fine-tuning the textures with the UV editor. You'll need Willian Germano's AC3D import/export scripts. > In any case it'd be awful nice to have a gpl'd modler. Right now > we've got a choice between two closed source binaries. One from a > guy that may or may not ever get around to fixing the bugs, let > alone improve it. And another from a larger company that is now as > good as gone. In addition to PPE (ppe.sourceforge.net), there's K3D (k3d.sourceforge.net) and Innovation3D (innovation3d.sourceforge.net). I played with innovation 3D a bit, and while it's OK, it's no Blender. For now, I'm willing to take my chances with a non-free, unsupported app, as long as I can export into formats that other tools support. Innovation3D is in Debian, so just type apt-get install innovation3d to try it out (assuming you use Debian). Here's a page with a list of 3D modellers and thumbnail reviews: http://www.worldforge.org/dev/eng/3d_compare_html All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Cessna POH's
I don't suppose such things exist for larger planes (or at least they wouldn't be so readily available)? On Friday 24 May 2002 4:09 pm, David Megginson wrote: > After waiting a month and a half for a C172P (1981) POH to get to my > flight club through the distribution chain, I just gave up and called > Cessna directly at > > (316) 517-5800 > > After they explained the difference between a POH (customized for a > specific serial number) and an Information Manual (same information, > but generalized for a complete model/year), I went ahead and ordered a > copy of the Information Manual for only US$21 + shipping. > > If anyone else is interested in doing serious simulated flying, > testing, or FDM development for a Cessna plane, you might consider > ordering an Information Manual for the plane you're interested in -- I > had no idea it would be so cheap. > > > All the best, > > > David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Missing Model Problem
On Wed 29. May 2002 22:21, you wrote: > I've fixed the missing model problem -- specifying a non-existant > aircraft model (not any other kind) will default to the glider again > rather than throwing an exception. > > By the way, the 747 model is looking good. I'm happy that we're > building up a nice stable (er, hangar) of unencumbered, open-source > aircraft models. What next? We're low on Pipers right now (both aero > data and 3D models). Any favourites? > Piper J3-Cub please, please. I have 3-view for my RC model. And there is a lot of MDL models for MSFS. I know that it has Clark Y profile at wings. And met on inet some performance data. Madr -- Martin Dressler e-mail: [EMAIL PROTECTED] http://www.musicabona.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Report on my Scenery Investigation
David Megginson wrote: > I'd be happy to supply my own, but I make different tradeoffs than > Curt -- I add roads, rivers, railroads, and small towns, villages, and > lakes, but I build with with a minimum angle of 0 so there are > occasional artifacts in hilly terrain; I also use vmap0 for almost > everything, including coastlines and land-use. Hmm, It would be nice if you could put your generated scenery somewhere so people could spot thr difference (and maybe make a vote afterwards). It sounds kind of cool ... :-) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
