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. > > 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 -- 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
