Re: [Flightgear-devel] msvc6-win32-0.7.9 Ok
JSBSim (def), YASim and 'magic' - zlib > Note: JSBSim config files allow the user to specify a log file to be generated Wow! Yes, when I looked around after the 'flight' I saw this abt 6 MB csv file, and wondered - 'where did that come from?'. I had a quick peek inside and deleted that first one ... But I have now done another partial flight using the 'default' c172.xml and there is some interesting information in (this time 4 MB) csv file ... You can 'see' that it took some 2 minutes - 130.792 secs to be exact - before i got the engine rolling ... so that's some 1310 lines (@ 10 HZ) of csv that yield little ... One can be puzzled why the last column, very largely labeled engine[?].RPM starts at 1071.807 RPM, but over the next 10-15 secs falls to a low of 759.0082 - yes, engines seldom hold a 'constant' rpm, but ... abt row 1730 (173 secs) i apply throttle, and the RPM quite quickly climbs to 2100 at row 1800 (abt 180s)... It is not until row 1781 that i can see the 'Altitude' move above abt 4.66 (column 'AU' - 177.892 seconds) of the SF runway ... Lift (column 'AA') has risen to -25 somethings ... so i got LIFT ... By row 2350 - 235 secs - i am passing thru 500 feets - rising gently ... RPM holding around 2100+ ... At row 2486 (248 secs) i hit 'p' to pause, and could never get things going again ... Even had to use Ctrl+C on the CONSOLE screen to exit the sim ... Yes, yes, yes - very facinating stuff. Full of useful information on the 'plight' of the FDM - keeping prefect double precision track of so many variables - engine and airframe ... this is good. But IMHO i hope this can soon become OFF, or should i say "NONE", in the 'default' release 0.7.9 c172.xml? A newbe trier of fgfs should 'see' the thing operate at its best ... Have so 'adjusted' my c172.xml, and that last JSBSim try left no 'trace' ... And to again say g'by to QNAN forever ... --fdm=yasim Meantime have also flown again with YASim, and c172-yasim ... This time as the first thing after machine boot, and it flew as-well-as-can-be-expected. --fdm=magic To be able to 'see' how the sim handles travel across the earth, there is nothing to beat 'magic' ... Those of you 'lumbered' with WIN32 *must* try this ... Watch those tiles tumble forward ... And as I have often repeated, it seems to me the main fgfs problem in WIN32 - using my msvc6 compiled debug exe - is all to do with memory of course, and disk io ... And i am sure some of that is due to using the windows memory mapping of files (in metakit at least). A simple check to see if the sim is humming yet, or i should wait some more, is to click the Brake ON, and if the panel lights up almost immediately ... And sound(s) becomes continuous ... But with JSB and YA sims, they 'see' a wheel brake, and even if there is an imperceptable forward aircraft motion, the FDM compresses the front wheel springs, and pitches the ac forward ... This means the outside scene must be completely redone for each small change in the ac pitch ... and it becomes a racey disk io bottle neck. DirectX wants to repaint full scene, and during that delay the FDM had actually rocked another degree or 2 forward, which changed the scene again ... But as stated, at certain times, sometimes for many seconds - maybe you've sat cluching the js for dear life trying not to move it for 1/2 minute before, but - :-)) the simulator FLIES :-)) It flies. Ordinary co-ordinated eye-hand movement can control / postion the ac exactly where you would like it to be ... fdm 'magic' is far less 'jittery', thus the system's memory managment, including cached io, mapped io, ..., etc catch up more frequently, and then i can see 30 fps plus. Assuming i have taken on 15000 feet in altitude, and swung around to 090 I can give it FULL throttle ... Unfortunately magic's max. speed is clamped to only 3600 kts. i love FS2000's 32767 kts in slew mode and must find a way to speed-up magic ... *** zlib *** One day it's there - the next day it's not. Sad that we lost poor little zlib ... :-(( rgds, Geoff. ps: Tks., Curt for the system.fgfsrc --fg-scenery=D:\FG... tip. It works fine, naturally :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 Ok
I would also vote to have the logging turned off by default, but this needs to happen in the JSBSim cvs (and thus John/Tony must agree / be convinced to do it this way.) In my opinion, logging options are probably not the best fit to go into the aircraft definition file. It would seem to me that these would be better handled as a run time option, or maybe the JSBSim script file or reset file could turn logging on if desired? The problem with the current approach of putting everything into one file is that even if we turn it off by default in JSBSim, and that propogates through to flightgear, then at some future point, someone's going to be debugging an aircraft in JSBSim, they'll turn on logging, this will inadvertantly be commited to CVS, and it will propogate right back to FlightGear again. I agree it should definitely be off in the 0.7.9 release. Hopefully if no action happens on this front on the JSBSim side before then, someone will remind me to at least turn it off on the FlightGear side. Regards, Curt. Geoff McLane writes: > JSBSim (def), YASim and 'magic' - zlib > > > Note: JSBSim config files allow the user to specify a log file to be > generated > > Wow! Yes, when I looked around after the > 'flight' I saw this abt 6 MB csv file, > and wondered - 'where did that come > from?'. I had a quick peek inside and > deleted that first one ... > > But I have now done another partial > flight using the 'default' c172.xml > and there is some interesting information > in (this time 4 MB) csv file ... > > You can 'see' that it took some 2 minutes - > 130.792 secs to be exact - before i got the > engine rolling ... so that's some 1310 > lines (@ 10 HZ) of csv that yield little ... > > One can be puzzled why the last column, > very largely labeled engine[?].RPM starts > at 1071.807 RPM, but over the next 10-15 secs > falls to a low of 759.0082 - yes, engines > seldom hold a 'constant' rpm, but ... abt row > 1730 (173 secs) i apply throttle, and the RPM > quite quickly climbs to 2100 at row 1800 > (abt 180s)... > > It is not until row 1781 that i can see > the 'Altitude' move above abt 4.66 (column > 'AU' - 177.892 seconds) of the SF runway ... > Lift (column 'AA') has risen to -25 > somethings ... so i got LIFT ... > > By row 2350 - 235 secs - i am passing > thru 500 feets - rising gently ... > RPM holding around 2100+ ... > At row 2486 (248 secs) i hit 'p' to > pause, and could never get things > going again ... Even had to use > Ctrl+C on the CONSOLE screen to > exit the sim ... > > Yes, yes, yes - very facinating stuff. > Full of useful information on the > 'plight' of the FDM - keeping prefect > double precision track of so many > variables - engine and airframe ... > this is good. > > But IMHO i hope this can soon become > OFF, or should i say "NONE", in the > 'default' release 0.7.9 c172.xml? > > A newbe trier of fgfs should 'see' the > thing operate at its best ... > > Have so 'adjusted' my c172.xml, and that > last JSBSim try left no 'trace' ... > > And to again say g'by to QNAN forever ... > > > --fdm=yasim > > Meantime have also flown again with > YASim, and c172-yasim ... This time > as the first thing after machine boot, > and it flew as-well-as-can-be-expected. > > > --fdm=magic > > To be able to 'see' how the sim handles > travel across the earth, there is nothing > to beat 'magic' ... > > Those of you 'lumbered' with WIN32 *must* > try this ... Watch those tiles tumble > forward ... > > And as I have often repeated, it seems > to me the main fgfs problem in WIN32 - > using my msvc6 compiled debug exe - is > all to do with memory of course, and > disk io ... And i am sure some of that > is due to using the windows memory > mapping of files (in metakit at least). > > A simple check to see if the sim is > humming yet, or i should wait some more, > is to click the Brake ON, and if the > panel lights up almost immediately ... > And sound(s) becomes continuous ... > > But with JSB and YA sims, they 'see' a > wheel brake, and even if there is an > imperceptable forward aircraft motion, > the FDM compresses the front wheel springs, > and pitches the ac forward ... > > This means the outside scene must be completely > redone for each small change in the ac > pitch ... and it becomes a racey disk io > bottle neck. DirectX wants to repaint full > scene, and during that delay the FDM had actually > rocked another degree or 2 forward, which > changed the scene again ... > > But as stated, at certain times, sometimes for > many seconds - maybe you've sat cluching the > js for dear life trying not to move it for > 1/2 minute before, but - > > :-)) the simulator FLIES :-)) > > It flies. Ordinary co-ordinated eye-hand movement > can control / postion the ac exactly where you > would like it to be ... > > fdm 'magic' is far less 'jittery', thus the system's > memory managment, including cached io, mapped io, > ..., etc catch up more frequently, and then i can > see 30 fps plus.
Re: [Flightgear-devel] msvc6-win32-0.7.9 Ok
On Sat, 2002-01-26 at 05:28, Curtis L. Olson wrote: > I would also vote to have the logging turned off by default, but this > needs to happen in the JSBSim cvs (and thus John/Tony must agree / be > convinced to do it this way.) > > In my opinion, logging options are probably not the best fit to go > into the aircraft definition file. It would seem to me that these > would be better handled as a run time option, or maybe the JSBSim > script file or reset file could turn logging on if desired? IMO, the logging options should be moved off to a separate file and no version of that file should be committed to base CVS. That way, no user will ever get logging when they don't want it and developers can set things up the way they like for *all* JSBSim aircraft. > > The problem with the current approach of putting everything into one > file is that even if we turn it off by default in JSBSim, and that > propogates through to flightgear, then at some future point, someone's > going to be debugging an aircraft in JSBSim, they'll turn on logging, > this will inadvertantly be commited to CVS, and it will propogate > right back to FlightGear again. > > I agree it should definitely be off in the 0.7.9 release. Hopefully > if no action happens on this front on the JSBSim side before then, > someone will remind me to at least turn it off on the FlightGear side. > > Regards, > > Curt. > > Geoff McLane writes: > > JSBSim (def), YASim and 'magic' - zlib > > > > > Note: JSBSim config files allow the user to specify a log file to be > > generated > > > > Wow! Yes, when I looked around after the > > 'flight' I saw this abt 6 MB csv file, > > and wondered - 'where did that come > > from?'. I had a quick peek inside and > > deleted that first one ... > > > > But I have now done another partial > > flight using the 'default' c172.xml > > and there is some interesting information > > in (this time 4 MB) csv file ... > > > > You can 'see' that it took some 2 minutes - > > 130.792 secs to be exact - before i got the > > engine rolling ... so that's some 1310 > > lines (@ 10 HZ) of csv that yield little ... > > > > One can be puzzled why the last column, > > very largely labeled engine[?].RPM starts > > at 1071.807 RPM, but over the next 10-15 secs > > falls to a low of 759.0082 - yes, engines > > seldom hold a 'constant' rpm, but ... abt row > > 1730 (173 secs) i apply throttle, and the RPM > > quite quickly climbs to 2100 at row 1800 > > (abt 180s)... > > > > It is not until row 1781 that i can see > > the 'Altitude' move above abt 4.66 (column > > 'AU' - 177.892 seconds) of the SF runway ... > > Lift (column 'AA') has risen to -25 > > somethings ... so i got LIFT ... > > > > By row 2350 - 235 secs - i am passing > > thru 500 feets - rising gently ... > > RPM holding around 2100+ ... > > At row 2486 (248 secs) i hit 'p' to > > pause, and could never get things > > going again ... Even had to use > > Ctrl+C on the CONSOLE screen to > > exit the sim ... > > > > Yes, yes, yes - very facinating stuff. > > Full of useful information on the > > 'plight' of the FDM - keeping prefect > > double precision track of so many > > variables - engine and airframe ... > > this is good. > > > > But IMHO i hope this can soon become > > OFF, or should i say "NONE", in the > > 'default' release 0.7.9 c172.xml? > > > > A newbe trier of fgfs should 'see' the > > thing operate at its best ... > > > > Have so 'adjusted' my c172.xml, and that > > last JSBSim try left no 'trace' ... > > > > And to again say g'by to QNAN forever ... > > > > > > --fdm=yasim > > > > Meantime have also flown again with > > YASim, and c172-yasim ... This time > > as the first thing after machine boot, > > and it flew as-well-as-can-be-expected. > > > > > > --fdm=magic > > > > To be able to 'see' how the sim handles > > travel across the earth, there is nothing > > to beat 'magic' ... > > > > Those of you 'lumbered' with WIN32 *must* > > try this ... Watch those tiles tumble > > forward ... > > > > And as I have often repeated, it seems > > to me the main fgfs problem in WIN32 - > > using my msvc6 compiled debug exe - is > > all to do with memory of course, and > > disk io ... And i am sure some of that > > is due to using the windows memory > > mapping of files (in metakit at least). > > > > A simple check to see if the sim is > > humming yet, or i should wait some more, > > is to click the Brake ON, and if the > > panel lights up almost immediately ... > > And sound(s) becomes continuous ... > > > > But with JSB and YA sims, they 'see' a > > wheel brake, and even if there is an > > imperceptable forward aircraft motion, > > the FDM compresses the front wheel springs, > > and pitches the ac forward ... > > > > This means the outside scene must be completely > > redone for each small change in the ac > > pitch ... and it becomes a racey disk io > > bottle neck. DirectX wants to repaint full > > scene, and during that delay the FDM had actually > >
Re: [Flightgear-devel] msvc6-win32-0.7.9 Ok
Tony Peden writes: > IMO, the logging options should be moved off to a separate file and > no version of that file should be committed to base CVS. > That way, no user will ever get logging when they don't want it and > developers can set things up the way they like for *all* JSBSim > aircraft. Moving the logging request to a separate file seems reasonable to me. Maybe you could even have several logging.xml files to specify different subsets of data which you might be interested in looking at depending on what you were working on at the time ... log-gear.xml, log-engine.xml, etc. I don't see any problem commiting these to the base cvs, as long as they aren't activated by default. Having them could be useful if an end user is trying to understand more about what is going on, or wants to send back an accurate/informative bug report or question. This probably involves Jon doing the actual coding work, right? (that is if he agrees with us.) Curt. -- Curtis Olson Intelligent Vehicles Lab 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] Creating a sub window
Has anyone ever tried incorporating a sub window into flightgear? If so, is there some sort of trick? I have a sub window running with flightgear, but it appears that something in FG is overriding what happens inside the sub window. Please excuse my posting to the wrong list. Thanks, Dawn Ellis ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 Ok
>You can 'see' that it took some 2 minutes - >130.792 secs to be exact - before i got the >engine rolling ... so that's some 1310 >lines (@ 10 HZ) of csv that yield little ... > >One can be puzzled why the last column, >very largely labeled engine[?].RPM starts >at 1071.807 RPM, but over the next 10-15 secs >falls to a low of 759.0082 - yes, engines >seldom hold a 'constant' rpm, but ... abt row >1730 (173 secs) i apply throttle, and the RPM >quite quickly climbs to 2100 at row 1800 >(abt 180s)... Geoff: It appears that your machine may not be capable of running FlightGear properly. This stuff should not be happening. What kind of machine do you have? There is something else going on with your setup that isn't right. I don't believe Christian sees these problems. Certainly, I don't see it under Cygwin. I ran into similar things to what you are seeing a year ago when I had a seriously underpowered machine/display card. Note that JSBSim, at least, has been compiled under Borland C++, CygWin g++, and Linux g++ and runs fine under those OSes in standalone mode. It has also been compiled under Linux, CygWin, IRIX, Macintish, and MSVC (Christian) as the default FDM within FlightGear and I haven't seen reports (with the new CVS stuff, anyhow) that comes close to the chaotic mess you are reporting. That doesn't mean there isn't a problem to be reported, here, nor does it mean I can't help you. But I think your problems are beyond my control. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 Ok
>IMO, the logging options should be moved off to a separate file and >no version of that file should be committed to base CVS. >That way, no user will ever get logging when they don't want it and >developers can set things up the way they like for *all* JSBSim >aircraft. This is probably true, but the last line is a very good point. Let me think about this today; I'll likely move it, but I want to consider some things, first. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] YASIM Options
Hi, Believe there was a discussion while back regards YASIM options, but can't find it. Could someone tell me command line options for running YASIM with the various models? Thanks John W.
Re: [Flightgear-devel] YASIM Options
John Wojnaroski writes: > Hi, > > Believe there was a discussion while back regards YASIM options, but can't find it. > > Could someone tell me command line options for running YASIM with the various models? With the cvs version you should just have to look in $(FG_ROOT)/Aircraft and find all the *-set.xml files. There should be several yasim entries so if you want to try the YASim DC-3, you just need to run fgfs --aircraft=dc3-yasim Curt. -- Curtis Olson Intelligent Vehicles Lab 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] YASIM Options
John Wojnaroski wrote: > Believe there was a discussion while back regards YASIM options, but > can't find it. > > Could someone tell me command line options for running YASIM with the > various models? If you're just running it, then the aircraft files already take care of everything for you. Just use --aircraft=xxx-yasim (where xxx can currently be c172, c310, dc3, a4, harrier, or 747). The only command line argument that will affect the FDM as such is overriding the /sim/fuel-fraction property. The jets, especially, have different performance with different fuel loads. Just use: --prop:/sim/fuel-fraction=0.2 (for example) to get a reasonable "approach" configuration. With the jets, you'll also want the HUD turned on as there aren't any panels yet. I use: --enable-hud and --disable-panel for these guys. There's also a complication with the Harrier. You'll need to map a joystick axis to the /controls/thrust-vector[0] property in order to work the thrust vectoring. A keyboard interface would be possible too, but due to the lack of a panel there's no feedback to the user about what the setting is currently. I use one of the rotary dials on my Saitek X45 (OT note: a *GREAT* joystick, if anyone is interested in recommendations) and it works great. I've been playing/practicing with the Harrier a lot recently. I really should write up a "training guide" or somesuch, for folks just getting into it. The learning curve on the VTOL stuff is nasty and steep, kind of like being a real life test pilot on the things. Loads of fun. I can *almost* reliably land vertically now -- but hovering still eludes me. Once I move away from the location I picked to land on, I have to fly off and re-do the whole approach. Oh, and Gene: I've got an F-15C for you (attached) but I'm not entirely satified with it. What's happened is that the "parasite" drag has to be pushed so low by the solver in order to match the mach 2.5 cruise number that the induced drag (that is, the backwards component of the lift at non-zero AoA) ends up dominating. The aircraft bleeds speed *fast* in a turn, much faster than the A-4, which has a broadly similar wing configuration and loading. I'll need to put in supersonic drag handling before this works really well. But it takes off, lands, and accelerates more or less like the real thing. 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] Creating a sub window
Dawn Ellis wrote: > Has anyone ever tried incorporating a sub window into flightgear? If > so, is there some sort of trick? > > I have a sub window running with flightgear, but it appears that > something in FG is overriding what happens inside the sub window. Platform? FlightGear's main window is an OpenGL rendering context. I'd be surprised if there was any portable way of getting an OS subwindow. You'd be better off working with the PUI library inside the context instead. At least in X11, though, this "should" work, barring driver bugs. With the current NVidia drivers, I can verify that a foreground window (an xterm, whatever) properly obscures and clips the fgfs window. 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 Options
Andy Ross wrote: > Oh, and Gene: I've got an F-15C for you (attached) but I'm not > entirely satified with it. What's happened is that the "parasite" > drag has to be pushed so low by the solver in order to match the mach > 2.5 cruise number that the induced drag (that is, the backwards > component of the lift at non-zero AoA) ends up dominating. The > aircraft bleeds speed *fast* in a turn, much faster than the A-4, > which has a broadly similar wing configuration and loading. I'll need > to put in supersonic drag handling before this works really well. But > it takes off, lands, and accelerates more or less like the real thing. Oops, I lied. Now it's attached. Apologies. 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) yasim f15 1.0 true Aircraft/c172/Panels/c172-vfr-panel.xml Aircraft/c172/Panels/c172-trans-mini-panel.xml
Re: [Flightgear-devel] YASIM Options
Knew it was something like that, just couldn't remember the exact syntax ... > With the jets, you'll also want the HUD turned on as there aren't any > panels yet. I use: --enable-hud and --disable-panel for these guys. > Actually using a set of glass displays I've developed that match the 747 flight deck. Runs on a seperate machine with a LAN interface and has a full set of EICAS (Engine Instruments Crew Alerting System) and Navigtion displays. Just need to get the "turbine data" across the link (Assuming that YASIM is generating N1, N2, EGT, EPR, oil pressure, fuel flow, etc) Thanks John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM Options
John Wojnaroski wrote: > Actually using a set of glass displays I've developed that match the > 747 flight deck. Runs on a seperate machine with a LAN interface and > has a full set of EICAS (Engine Instruments Crew Alerting System) and > Navigtion displays. Oh yeah. Duh. I knew that. :) I *will* try that someday, but I'm lacking the required second machine at the moment. > Just need to get the "turbine data" across the > link (Assuming that YASIM is generating N1, N2, EGT, EPR, oil > pressure, fuel flow, etc) Sure thing: /engines/engine[n]/n1 /engines/engine[n]/n2 /engines/engine[n]/epr /engines/engine[n]/egt-degf /engines/engine[n]/fuel-flow-gph No oil pressure though, because I haven't seen any data on what it should look like. I suspect it'll just scale linearly (with a zero-offset) with N1 (presuming that's the turbine stage that runs the oil pump) for a given engine. If you have cruise data for oil pressure, I'd love to see it. Also, recognize that these numbers have had only the most cursory testing; I make no promises. The actual numbers that the current jet model is turning out are those for a 707 turbojet at the same fractional power. The numbers themselves can be tuned to match any given engine, but no such work has been done yet. Specifically, you'll see EPR numbers that are too high for the turbofans the 747 is using. The fuel flow is based on a TSFC specified in the tag in the aircraft XML. I don't know if I got that right, either. Although this one is kind of academic as YASim doesn't actually consume fuel yet. :) It also gets a little goofy at supersonic speeds. Due to ram air compression, the power goes up with speed faster than a real engine should -- the F15 at mach 2.5 is showing something like 128% N1. Real engines have complicated inlet losses at high mach that aren't modelled. Not a problem with the 747, but just something you might notice. 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 Options
John Wojnaroski writes: > Could someone tell me command line options for running YASIM with > the various models? fgfs --aircraft=c172-yasim fgfs --aircraft=c310-yasim fgfs --aircraft=dc3-yasim etc. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] DC-3 3-D model (partial)
In an effort to learn 3-D modeling, I've been tinkering with a DC-3 model in Blender -- so far, it's been much easier than I expected. The model is just roughed in -- it's untextured and far from complete (no propeller, hub, exhaust, ailerons, flaps, or struts, some funky normals, etc.), but you can already play with it in FlightGear with the YASim DC-3 FDM. Here are a couple of screenshots: http://www.megginson.com/flightsim/dc3-01.png http://www.megginson.com/flightsim/dc3-02.png Here's the VRML1 model (only 44K), which PLIB (and FlightGear) can use: http://www.megginson.com/flightsim/dc3.wrl Here's the Blender binary source (60K) if anyone else wants to work with the model (I'm putting it in the Public Domain): http://www.megginson.com/flightsim/dc3.blend Blender's default orientation is a little different from FlightGear's. I'll fix things up later, but for now, it's necessary to set a few properties to align the model correctly. I copied dc3.wrl into $FG_ROOT/Models, then invoked FlightGear like this: fgfs --aircraft=dc3-yasim \ --prop:/sim/model/path=Models/dc3.wrl \ --prop:/sim/model/pitch-offset-deg=90 \ --prop:/sim/model/roll-offset-deg=270 \ --prop:/sim/model/z-offset-m=-1.5 Comments and contributions welcome. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3-D model (partial)
On Saturday 26 January 2002 04:09 pm, you wrote: > In an effort to learn 3-D modeling, I've been tinkering with a DC-3 > model in Blender -- so far, it's been much easier than I expected. > > The model is just roughed in -- it's untextured and far from complete > (no propeller, hub, exhaust, ailerons, flaps, or struts, some funky > normals, etc.), but you can already play with it in FlightGear with > the YASim DC-3 FDM. Here are a couple of screenshots: > > http://www.megginson.com/flightsim/dc3-01.png > http://www.megginson.com/flightsim/dc3-02.png > > Here's the VRML1 model (only 44K), which PLIB (and FlightGear) can > use: > > http://www.megginson.com/flightsim/dc3.wrl > > Here's the Blender binary source (60K) if anyone else wants to work > with the model (I'm putting it in the Public Domain): > > http://www.megginson.com/flightsim/dc3.blend > > Blender's default orientation is a little different from > FlightGear's. I'll fix things up later, but for now, it's necessary > to set a few properties to align the model correctly. I copied > dc3.wrl into $FG_ROOT/Models, then invoked FlightGear like this: > > fgfs --aircraft=dc3-yasim \ >--prop:/sim/model/path=Models/dc3.wrl \ >--prop:/sim/model/pitch-offset-deg=90 \ >--prop:/sim/model/roll-offset-deg=270 \ >--prop:/sim/model/z-offset-m=-1.5 > > Comments and contributions welcome. > > > All the best, > > > David Not bad! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Creating a sub window
> Andy wrote: > Platform? FlightGear's main window is an OpenGL rendering context. > I'd be surprised if there was any portable way of getting an OS > subwindow. You'd be better off working with the PUI library inside > the context instead. > We are running on a Windows 2000 machine, using the cygwin environment. I've used the glutCreateSubWindow function, and I do get two windows, but FG seems to be overriding the display callback for the subwindow. We are using Jon's shuttle model for a landing simulation that we are developing for the Challenger Center at the school. We are using a modified HUD display with special audio to simulate mission control, and the sub window will be used to display text. Dawn ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM Options
Andrew wrote: > Oh yeah. Duh. I knew that. :) I *will* try that someday, but I'm > lacking the required second machine at the moment. > > > Just need to get the "turbine data" across the > > link (Assuming that YASIM is generating N1, N2, EGT, EPR, oil > > pressure, fuel flow, etc) > > Sure thing: > > /engines/engine[n]/n1 > /engines/engine[n]/n2 > /engines/engine[n]/epr > /engines/engine[n]/egt-degf > /engines/engine[n]/fuel-flow-gph > Double Duh!! After downloading and compiling the latest CVS, (my last update was mid -dec) I added my latest changes to the interface and it naturally bombed, big time. When I realized that the FGEngInterface class was gone my first reaction was OH NO!!! I should have looked at the opengc.cxx source first before replacing it. :-O Whoever made the changes in opengc.cxx to properties, thank you. I've duplicated a lot of the navigation code on the opengc side which reduces the interface immensely and makes building the FMC a lot easier. for example, the FMC does such things as auto-tuning to select VOR stations in range to update current position against the flight plan, displays routes, waypoints, airports, and such. There are 12 to 13 different Nav displays including weather radar, lots of eye-candy to build! >zero-offset) with N1 (presuming that's the turbine stage that runs the >oil pump) for a given engine. If you have cruise data for oil >pressure, I'd love to see it. If you want a good source for engine data from taxi to cruise, touch base with [EMAIL PROTECTED] Thanks again John w. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] internet socket server (aka telnet)
When started with --props=socket,bi,5,localhost,5501,tcp fgfs does only allow one session e.g. via telnet. After closing this session, it isn't possible to connect again. I had a look at that problem and seem to have found the reason. Yet I cannot provide a patch. On the one hand I'm not really familiar with socket programming. On the other hand I didn't completely understand how fgfs is supposed to deal with this socket stuff and I would probably break more than I would fix. Anyway, here is my diagnosis::-) simgear/sg_socket.cxx doesn't accept(2) a pending connection and hence get a session handle. Instead, it works with the server socket handle that it got from socket(2). While this works for the first connection, it makes "quit" cancel the server(!) instead of the session. (Of course, one should be able to install a new server, but this wouldn't be a clean solution.) Unfortunately, there doesn't seem to be a place where an accept(2) call would fit in. Ideally, there would be a forked off process that cares for socket connections and would simply wait until accept(2) returns, or at least something like SGSocket::process that would regularly be called by FGProps::process and would start the session. Now the first function that is polled is SGSocket::readline, in which an accept(2) call would IMHO be already too late. Hmm ... (?) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [OT] Developer configuration under Linux
Hi Guys! Yerstaday i had to reinstall my linux and my second CD from mandrake linux distribution was scratched so i download missing developers (zlib,jpeg,png) packets from internet in rpm format and install them using rpmdrake utility but when i run ./configure script i see this results . checking for jpeg_destroy_decompress in -ljpeg... no configure: warning: *** JPEG library not found *** checking for zlibVersion in -lz... no configure: warning: *** zlib library not found *** checking for png_init_io in -lpng... no configure: warning: *** PNG library not found *** checking for ANSI C header files... no checking for GL/gl.h... yes checking for GL/glut.h... yes checking for png.h... yes checking for jpeglib.h... yes ... as I understand ldconfig works only with .so modules and doesn't maintain .a libs gcc knows about header files but not about libraries. What should I do? Thanx in advance Roman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
