Re: [Flightgear-devel] Comments on FGFS review summary
On Thu, 6 Jun 2002 13:35:47 -0400, David Megginson <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > Arnt Karlsen writes: > > > ..IMHO, we should have more "oddball EAA" planes than spam cans and > > > > airliners. Blom&Voss 141, Me 323, Me 163, and the Horten Vings, > > Howard Hughes Spruce Goose, Van's RV3-4-5-6-7-8-9, Rutans > > Vari-Viggen, VariEze, Defiant, Lancair IV, Colomban Cri-Cri, Zenair > > CH-801, Ryan "Spirit of St Louis", Leza AirCam, the Hummelbird, the > > Volksplane etc. > > Sure, but I'm also interested in getting FlightGear set up as a decent > general-aviation FTD -- some of the stuff in the flight schools is > ancient, and FTD's are way overpriced. ..a "market" and a tool. I agree. GA is mainly built on volonteered efforts, like in aero clubs. Also add to the geek factor as in 'done the right way', as GA is not mainstream, either. ;-) -- ..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] FlightXpress article - SuSE 8.0 is an old version
> I just went round to the SuSE booth and looked on a 8.0 demo computer. > The packaged version is 0.7.8 which we released last summer, a year ago. Ooops, I was quite shure they packaged a 0.7.9 for SuSE-8.0. > I still think it would be worth submitting a formal request that > the future SuSE 8.1 please package 0.7.10 or later for their customers. I already submitted a request for information what to take into account for building a package that conforms to SuSE's conventions. I never got an anyswer :-( After failing to update to SuSE-8.0 because of a stupid update installer I doubt that I want to support SuSE in the future Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments on FGFS review summary
> For what it's worth, I'm involved in a side project that is using > FlightGear + a commercial C172 flight dynamics model + cockpit > hardware to hopefully achieve an FAA (and JAR) certified sim by late > summer / early fall. The commercial fdm will run as a seperate > program [...] Hmm, _this_ is what I'm waiting for. Will there be any documentation on how the network protocol will look like ? I'm recognizing that you have checked in several patches to the ExternalNet interface over the time. I would love to profit from this. > Imagine being able to run with the default "stable" JSBSim, or the > previous "stable" version, or the one you are currently hacking on, > just by restarting the desired fdm process. maybe with FlightGear getting run from 'inetd', if the FDM sits on a remote machine !? O.k., this might be difficult because of X server write permissions, but I'd like to take care of that if times come, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments on FGFS review summary
Jon S Berndt writes: > Should we make it "nastier"? Is there a human factors > scale anywhere that has "Nasty" on it? :-) One American "Nasty" unit =~ 0.789 Metric "Paris Cabbies". 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] Comments on FGFS review summary
> > Tony: > > > > Should we make it "nastier"? Is there a human factors scale anywhere > > that has "Nasty" on it? :-) > > > Hmm, nasty enough? > > Eff = (16*h / b)*(16*h / b) > Oe = Eff*Eff/(1 + Eff*Eff)(where 0 <= Oe <= 1) > D = q_infinite * S * (CDo + 0e * ( (CL*CL)/(pi * e * A * r) ) ) > > D: decrease in drag > h: height of the wing above the ground > b: wingspan > > :-0 > ...and thus begat the FlightGear "Smackdown" flap system... g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments on FGFS review summary
Jon S Berndt wrote: > On Thu, 6 Jun 2002 14:48:49 -0400 > David Megginson <[EMAIL PROTECTED]> wrote: > >> Lowering flaps does cause a very nasty pitching moment during >> low-speed maneuvers on a C172 (i.e. approach, when you're too close to >> stall-speed and too close to the ground already) -- not as nasty as >> what you describe, but perhaps a little nastier than what JSBSim >> currently models. > > > Tony: > > Should we make it "nastier"? Is there a human factors scale anywhere > that has "Nasty" on it? :-) Hmm, nasty enough? Eff = (16*h / b)*(16*h / b) Oe = Eff*Eff/(1 + Eff*Eff)(where 0 <= Oe <= 1) D = q_infinite * S * (CDo + 0e * ( (CL*CL)/(pi * e * A * r) ) ) D: decrease in drag h: height of the wing above the ground b: wingspan :-0 Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Solaris Compile of FG 0.7.10
Salman Sheikh wrote: > ../../src/FDM/libFlight.a(LaRCsimIC.o): In function `LaRCsimIC::solve(double *, >double)': > /folks/salman/FlightGear-0.7.10/src/FDM/LaRCsimIC.cxx:382: undefined reference to >`LLC150' > collect2: ld returned 1 exit status > gmake[1]: *** [fgfs] Error 1 > gmake[1]: Leaving directory `/folks/salman/FlightGear-0.7.10/src/Main' > gmake: *** [all-recursive] Error 1 > > Also, I had other errors but I eliminated them by adding -lplibsl and -lplibsm to >the Makefile in the src/Main directory. > I would have thought those would automatically be included. I am using simgear0.18 >and plib-1.4.2. > > Any ideas? Another one to try would be defining LD=ld before running configure. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Solaris Compile of FG 0.7.10
Salman Sheikh wrote: > Hello, > > I almost have Flight-Gear compiled for solaris. > I am down to the following error: > ../../src/FDM/libFlight.a(LaRCsimIC.o): In function `LaRCsimIC::solve(double *, >double)': > /folks/salman/FlightGear-0.7.10/src/FDM/LaRCsimIC.cxx:382: undefined reference to >`LLC150' > collect2: ld returned 1 exit status > gmake[1]: *** [fgfs] Error 1 > gmake[1]: Leaving directory `/folks/salman/FlightGear-0.7.10/src/Main' > gmake: *** [all-recursive] Error 1 > > Also, I had other errors but I eliminated them by adding -lplibsl and -lplibsm to >the Makefile in the src/Main directory. > I would have thought those would automatically be included. I am using simgear0.18 >and plib-1.4.2. > > Any ideas? > > I don't see any functions LLC177 and LLC150 in the files hud_card.cxx an >LaRCsimIC.cxx in the lines referenced in the errors above. After searching the internet a bit I started wondering, does Solaris have a libllc which should be included by FlightGear? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments on FGFS review summary
On Thu, 6 Jun 2002 14:48:49 -0400 David Megginson <[EMAIL PROTECTED]> wrote: >Lowering flaps does cause a very nasty pitching moment during >low-speed maneuvers on a C172 (i.e. approach, when you're too close to >stall-speed and too close to the ground already) -- not as nasty as >what you describe, but perhaps a little nastier than what JSBSim >currently models. Tony: Should we make it "nastier"? Is there a human factors scale anywhere that has "Nasty" on it? :-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments on FGFS review summary
Curtis L. Olson writes: > - There is a severe proplem going to first notch of flaps. Extreme > pitch up. You need *full* down trip to fly level with any flaps at > all. Lowering flaps does cause a very nasty pitching moment during low-speed maneuvers on a C172 (i.e. approach, when you're too close to stall-speed and too close to the ground already) -- not as nasty as what you describe, but perhaps a little nastier than what JSBSim currently models. Even with my limited experience, I already reflexively (i.e. involuntarily) push forward on the yoke whenever I lower any flaps, without waiting for the pitching to start -- perhaps Alex Perry can let us know whether this is common for C172 pilots or I'm just developing a bad habit. Last week, my first time in a C172M (which has an annoying rocker switch instead of a sliding flap-position switch), I accidentally lowered 40 degrees of flaps on the base leg -- I descended a little too far, and ended up needing full throttle just to level my descent briefly at 70 KIAS. It's like dragging a parachute. 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
[Flightgear-devel] Solaris Compile of FG 0.7.10
Hello, I almost have Flight-Gear compiled for solaris. I am down to the following error: gmake[1]: Entering directory `/folks/salman/FlightGear-0.7.10/src/Main' c++ -DPKGLIBDIR=\"/opt/sis/lib/FlightGear\" -g -O2 -L/opt/sis/lib -L/usr/local/lib -o fgfs main.o fg_commands.o fg_init.o fg_io.o fg_props.o fgfs.o globals.o logger.o options.o splash.o viewer.o viewmgr.o location.o ../../src/Aircraft/libAircraft.a ../../src/ATC/libATC.a ../../src/Autopilot/libAutopilot.a ../../src/Cockpit/libCockpit.a ../../src/Cockpit/built_in/libBuilt_in.a ../../src/Controls/libControls.a ../../src/FDM/libFlight.a ../../src/FDM/Balloon/libBalloon.a ../../src/FDM/JSBSim/libJSBSim.a ../../src/FDM/YASim/libYASim.a ../../src/FDM/JSBSim/filtersjb/libfiltersjb.a ../../src/FDM/LaRCsim/libLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a ../../src/GUI/libGUI.a ../../src/Model/libModel.a ../../src/Navaids/libNavaids.a ../../src/Scenery/libScenery.a ../../src/Sound/libSound.a ../../src/Airports/libAirports.a ../../src/Network/libNetwork.a ../../src/Objects/libObjects.a ../../src/Time/libTime.a ../../src/WeatherCM/libWeatherCM.a ../../src/Input/libInput.a -lsgroute -lsgsky -lsgephem -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgdebug -lsgmagvar -lsgmisc -lsgxml -lsgserial -lplibpu -lplibfnt -lplibnet -lplibssg -lplibsg -lplibsl -lplibsm -lmk4 -lz -lnsl -lsocket -L/usr/openwin/lib -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lsocket -lpthread -lm -lplibul -lm ../../src/Cockpit/libCockpit.a(hud_card.o): In function `hud_card::zoomed_scale(int, int)': /folks/salman/FlightGear-0.7.10/src/Cockpit/hud_card.cxx:1263: undefined reference to `LLC177' ../../src/FDM/libFlight.a(LaRCsimIC.o): In function `LaRCsimIC::solve(double *, double)': /folks/salman/FlightGear-0.7.10/src/FDM/LaRCsimIC.cxx:382: undefined reference to `LLC150' collect2: ld returned 1 exit status gmake[1]: *** [fgfs] Error 1 gmake[1]: Leaving directory `/folks/salman/FlightGear-0.7.10/src/Main' gmake: *** [all-recursive] Error 1 Also, I had other errors but I eliminated them by adding -lplibsl and -lplibsm to the Makefile in the src/Main directory. I would have thought those would automatically be included. I am using simgear0.18 and plib-1.4.2. Any ideas? I don't see any functions LLC177 and LLC150 in the files hud_card.cxx an LaRCsimIC.cxx in the lines referenced in the errors above. Line 1263 in the hud_card.cxx file is drawOneLine(xpoint,ypoint+10.0,xpoint-5.0,ypoint+5.0); and Line 382 in the LaRCsimIC.cxx file is: return success; -- Salman Sheikh 301-286-3763 301-286-0220 (fax) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Crash on "Reset" function.
David Megginson <[EMAIL PROTECTED]> said: > Curt has mentioned that there are ordering dependencies, especially > around rendering, that we have to be careful not to break. We should > be able to get those automatically, as long as we add the subsystems > to the vector in the right order. The rendering related order dependencies (sequence of rendering) could be managed by a rendering subsystem. We could add the subsystem vectors as we go along during the fg_init process. It'd be good to have those kinds of dependencies documented, with embedded comments, so we know why one subsystem comes before another when trying to make a decision about reordering something. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments on FGFS review summary
David Megginson writes: > Sure, but I'm also interested in getting FlightGear set up as a decent > general-aviation FTD -- some of the stuff in the flight schools is > ancient, and FTD's are way overpriced. For what it's worth, I'm involved in a side project that is using FlightGear + a commercial C172 flight dynamics model + cockpit hardware to hopefully achieve an FAA (and JAR) certified sim by late summer / early fall. The commercial fdm will run as a seperate program in order to avoid GPL issues, but building full featured support for remote FDM's is a really good thing for us I think. Imagine being able to run with the default "stable" JSBSim, or the previous "stable" version, or the one you are currently hacking on, just by restarting the desired fdm process. The current state of this whole project is that we have *many* things done, but we also have a pretty good sized todo list, some items minor, some items fairly major. The commercial C172 does a few things better than us (off the top of my head): - Engine/prop modeling is much closer I think. - Startup sequence and rpm's during the crank are more realistic. - Prop windmills properly in the air if engine off. - It properly models left/right only magnetos. - If you lean out engine in the air it sputters and coughs along which is pretty cool. - Generally the flight modeling seems very plausible (and from my perspective perhaps just a bit better tweaked ... i.e. same effects, but the gains or magnitudes are tweaked a little better.) And a few things that are worse: - Ground handling is nothing to write home about. - There is a severe proplem going to first notch of flaps. Extreme pitch up. You need *full* down trip to fly level with any flaps at all. - Perhaps it is over agressive on climbs, but then again there could be weight and temperature issues which we haven't dug into yet. These negative things will get addressed, but overall, I think the JSBSim and YASim C172's are pretty comperable in quality with this commercial code (which is already part of one FAA certified flight sim.) Regards, 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] Re: pthread error (valgrind)
* Andy Ross -- Thursday 06 June 2002 00:08:
> Melchior FRANZ wrote:
> > valgrind reports this bug:
> >
> >pthread_mutex_destroy: mutex is still in use
> > at 0x40523AB4: pthread_error (vg_libpthread.c:229)
> > by 0x405249B5: __pthread_mutex_destroy (vg_libpthread.c:825)
> > by 0x40625220: _IO_default_finish (in /lib/libc.so.6)
> This error is happening deep inside [...] There's no way FlightGear
> could possibly touch that lock directly.
OK, so the adequate remedy for now is a valgrind suppression rule. :-]
{
zlib/pthread-bug ... don't bother
PThread
fun:pthread_error
fun:__pthread_mutex_destroy
fun:_IO_default_finish
}
Thanks for your expertise.
m.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Comments on FGFS review summary
Arnt Karlsen writes: > ..IMHO, we should have more "oddball EAA" planes than spam cans and > airliners. Blom&Voss 141, Me 323, Me 163, and the Horten Vings, > Howard Hughes Spruce Goose, Van's RV3-4-5-6-7-8-9, Rutans Vari-Viggen, > VariEze, Defiant, Lancair IV, Colomban Cri-Cri, Zenair CH-801, Ryan > "Spirit of St Louis", Leza AirCam, the Hummelbird, the Volksplane etc. Sure, but I'm also interested in getting FlightGear set up as a decent general-aviation FTD -- some of the stuff in the flight schools is ancient, and FTD's are way overpriced. 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] Comments on FGFS review summary
..my impression is this is a "glossy mainstream wintendo sim magazine, for mainstream people who sim-fly mainstream big airlines and other spamcans". Nothing wrong with that. ;-) ..neither FG nor EAA (http://eaa.org/) nor Gnu/Linux is mainstream. You see the similarity? We all _build_ stuff to use. And, we know we are _not_ mainstream. Yet. We're different. Outsiders. Geeks. And _we_ have failed to communicate _that_. ;-) ..IMHO, we should have more "oddball EAA" planes than spam cans and airliners. Blom&Voss 141, Me 323, Me 163, and the Horten Vings, Howard Hughes Spruce Goose, Van's RV3-4-5-6-7-8-9, Rutans Vari-Viggen, VariEze, Defiant, Lancair IV, Colomban Cri-Cri, Zenair CH-801, Ryan "Spirit of St Louis", Leza AirCam, the Hummelbird, the Volksplane etc. ..paragliders, zeppeliners, choppers, blimps, hang gliders, and R/C models: Check out 'http://www.davincitechnologies.com/' for AirplanePDQ, "Simulation requires X-Plane". Wintendo only. ;-) ..we can do better. I'm thinking of talking VariCad (http://varicad.com/) into something similar. They do both OpenGL 3d and develop cross-platform, and, they do it _now_. ;-) ..and we have people like Olivier makeing more cool stuff. -- ..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] Crash on "Reset" function.
Norman Vine writes:
> I don't want to start another flame fest and I agree that FGFS
> is MUCH more sophisticated now then when 'reset' was originally
> written but this should mean a 'reset' is easier todo :-)
Norm is absolutely right.
The problem is that right now we have two different approaches -- a
lot of stuff is handled cleanly in individual modules' update()
methods, but a lot of stuff is still handled by hundreds of lines of
BASIC-like, hard-to-read spaghetti code in main.cxx and fg_init.cxx
(forget OO, it's not even functional programming).
That was the right idea to get started -- I'm not a fan of wasting
time on an initial OO design that you won't end up using -- but now we
need to finish cleaning it up, until the main loop is something like
this:
double dt_sec = calculateDeltaTime_sec();
for (int i = 0; i < globals.nSubsystems(); i++)
globals.get_subsystem(i)->update(dt_sec);
Then, the reset can be as easy as
restoreSavedProperties();
for (int i = 0; i < globals.nSubsystems(); i++)
globals.get_subsystems(i)->reset();
The init routine should look like this:
globals.add_subsystem("controls", new FGControls);
globals.add_subsystem("environment", new FGEnvironment);
and so on.
Curt has mentioned that there are ordering dependencies, especially
around rendering, that we have to be careful not to break. We should
be able to get those automatically, as long as we add the subsystems
to the vector in the right order.
> IMHO being able to pause, restart with initial conditions, restart
> with arbritray conditions is a good < should I say basic > test of
> a well designed simulation. ie one that is controlable
Agreed -- we need to make this a high priority.
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] Comments on FGFS review summary
Alex Perry writes: > - not to be compared with state-of-the art simulators > > This can be a good thing, for all their associated features that we > hate. When I started my flying lessons, and the JSBSim and YASim 172's were both having problems, I decided not to be prejudiced and to go back and practice some maneuvers in the FLY! 172, which has been praised extensively for its panel and aero. Well, the panel had all the right gauges and switches (except a working thermometer on the air vent), but it updated at such a low rate that it was basically worthless -- cross-checking with the panel actually made me fly worse. Likewise for the aero modelling -- it just didn't feel like a 172 (and I have flown a 172R a couple of times). I have found both the JSBSim and the YASim 172s much, much more useful for practice than FLY!'s; in fact, I plan simply to delete FLY! the next time I boot into Windows (which happens every 2-4 months). > This can either mean that most of our cockpits are steam-gauge based, > which is true for the reviewed version that doesn't have OpenGC integration, > or that it looks flat like the 1999 era simulation programs, which is true > for the reviewed version and may be true by default for current release too. > I think the 3D cockpit wasn't default due to lacking mouse interaction ? Yes, that's a big TODO item -- we cannot use the 3D cockpit for IFR until it is interactive. > - Bad flight characteristics (sometimes planes react too sensitive, > sometimes too sluggish), much worse than X-Plane > > This puzzles me; real planes have huge changes in control sensitivity > over the operational speed range, which we (and to a lesser extent) > X-Plane try to model. Perhaps the chap is used to playing video games > where effectiveness is not context sensitive ? Maybe not a GA pilot ? > We certainly have limitations on control realism, but not to the extent > that I'd critique us in the same breath as our other limitations. I'm amazed at how close it is now, given the limitations of the environment. I still find FlightGear harder to hold in the flare than the real thing, but that's probably because of the lack of peripheral vision and motion cues. I also find that the viewpoint in the 3D cockpit is still slightly too low for me. 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] FlightXpress article - SuSE 8.0 is an old version
* [EMAIL PROTECTED] (Alex Perry) [2002.06.06 09:54]: > I still think it would be worth submitting a formal request that > the future SuSE 8.1 please package 0.7.10 or later for their customers. Hopefully later than 0.7.10 simply because of the "failed to load model" problem that has been fixed in CVS. Wish we could get a "stable" 0.8.0 released and then contact SuSE. -- Cameron Moore [ Why are they called apartments, when they're all stuck together? ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FlightXpress article - SuSE 8.0 is an old version
Alex, > I just went round to the SuSE booth and looked on a 8.0 demo computer. > The packaged version is 0.7.8 which we released last summer, a year ago. > Although they were mildly embarrassed when I pointed this out to them, Even if the article still contains some truth, I might write a "letter from a reader" like note to make this point clear. 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] Comments on FGFS review summary
On Sat, 01 Jun 2002 14:24:45 -0700 Alex Perry <[EMAIL PROTECTED]> wrote: > Meanwhile, it would be a nice upgrade to have a menu item that brings > up a dialog which contains _every_ command line parameter that is not > otherwise represented in the existing set of run-time accessible menu items. > The exit buttons are "accept and restart" or "cancel"; if the former is > selected, the existing command line is extended with the chosen options > and then the application "exec()"s itself so that they take effect. > > Over time, as those features become run-time configurable, the dialog will > shrink. I seriously doubt whether it will ever become empty, so I think > the dialog will be a long term capability (especially on the CVS tree). > Actually, I'm working on such a GUI. (I need it for my personnal use of FlightGear). It's a python set of scripts which use wxPython (wxWindows wrap) and pyxml to "SAX-interact" with the preferences.xml file. It should help to choose your aircraft (with a nice photo), your airport (by re processing the default.apt) and with a screenshot too (if available), your environment conditions : time, weather, ..., the ability to launch Atlas at the same time on the right port, and some additional stuff. At the moment it is only experimentation, but as soon as I have a working script, I put it under GPL, put it online and give a link to try it. All the best, Olivier ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FlightXpress article - SuSE 8.0 is an old version
I just went round to the SuSE booth and looked on a 8.0 demo computer. The packaged version is 0.7.8 which we released last summer, a year ago. Although they were mildly embarrassed when I pointed this out to them, I still think it would be worth submitting a formal request that the future SuSE 8.1 please package 0.7.10 or later for their customers. In consequence, the opinions stated in the review are applicable to the FGFS version that we demonstrated in summer 2001 at LinuxTag in Stuttgart and at LinuxWorld in San Francisco, except that CVS patches and improved scenery (San Jose and San Francisco) were not available to the reviewer. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Crash on "Reset" function.
David Megginson writes: >Norman Vine writes: > > > Hopefully once we get 'reset' working again developers will test 'reset' > > before submitting their changes in the future so we don't repeat this > > quagmire > >It's a little more complicated than that. The original reset was a >simple kludge that worked fine for a simple program; now that >FlightGear is a lot more sophisticated, . David I don't want to start another flame fest and I agree that FGFS is MUCH more sophisticated now then when 'reset' was originally written but this should mean a 'reset' is easier todo :-) IMHO it became a kludge because and ONLY because it was 'ignored' by some in their development efforts and I kept trying to retrofit it back in on top of a program that was being changed rapidly by some who apparently didn't care about the requirements of the 'reset' functionality. IMHO being able to pause, restart with initial conditions, restart with arbritray conditions is a good < should I say basic > test of a well designed simulation. ie one that is controlable As such IMHO and I realize that this may not be your opinion, getting 'restart' working again AND KEEPING it working is a necessary thing todo. It shouldn't be that difficult in that it only requires that you return the individual parts of the simulation to their initial conditions. It is a GOOD exercise in that it illustrates the interdependencies of the program by rewarding you with a 'hard crash' if you do not understand them. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Comments on FGFS review summary
From: Melchior FRANZ <[EMAIL PROTECTED]> > OK, let's sort the items and add a few: - Old-fashioned overall appearance Yep. Our photographic fidelity is deprecated wrt functional representation. 2001-era flight simulators have inherited a lot of the visual artistry of the 3D combat video games, thereby providing a much more intensive impression of being present inside the simulation. The difference is similar to comparing a photograph of a landscape and an oil painting. The latter, if well done, appears to be a more realistic and faithful of the scene even though the color palette is narrower and the pixel pixel count is generally an order of magnitude lower than the former. The work, changing from a purely technically accurate rendering of the visual scene to an engaging and realistic image, requires good art skills to modify the textures we use and optionally add a few vertices in models. Although this is ongoing, it isn't complete and certainly not released. - (4 screenshots delivered, including KSFO + C172 panel) The CVS detail visual content is greatly improved compared to the Gallery, but the limitations implied by the previous point are still present. It is interesting to compare our primary screenshots with the equivalent ones for other simulators, note the inferior elements and figure out how to generate a better screenshot (and any simulator hooks that are needed). The San Jose scenery method is a good example of such an underlying hook. - not to be compared with state-of-the art simulators This can be a good thing, for all their associated features that we hate. However, this is intended to be a negative comment. Obvious differences are (a) we don't have an integrated capability for an intro video sequence. (b) We don't have a pulldown menu for selecting scenarios and similar. We can make (a) a hook that is attached to (b), with a fallback to showing a static image (like our existing splash) when unable to play the video. Then we provide a default scenario that calls up the video and has a voiceover that provides context for the initial simulation state. - Very few functions compared to other simulators[1] Many of our function set are selected only at startup on the command line and the reviewer was probably not aware of some of our power and flexibility. This is bad and we _intend_ the problem go away at some point in the future. Meanwhile, it would be a nice upgrade to have a menu item that brings up a dialog which contains _every_ command line parameter that is not otherwise represented in the existing set of run-time accessible menu items. The exit buttons are "accept and restart" or "cancel"; if the former is selected, the existing command line is extended with the chosen options and then the application "exec()"s itself so that they take effect. Over time, as those features become run-time configurable, the dialog will shrink. I seriously doubt whether it will ever become empty, so I think the dialog will be a long term capability (especially on the CVS tree). - Cockpits "from yesterday" This can either mean that most of our cockpits are steam-gauge based, which is true for the reviewed version that doesn't have OpenGC integration, or that it looks flat like the 1999 era simulation programs, which is true for the reviewed version and may be true by default for current release too. I think the 3D cockpit wasn't default due to lacking mouse interaction ? I doubt this is the point of the critique, but we also have a lack of secondary indicators and controls that are irrelevant to a working simulation. The stuff that would be used for a procedures trainer. When the C172 panel has every control, light and fuse mounted into it, it will be worth writing the python scripting to tie things together (such as turning off radios when the avionics circuit breaker is tripped). On another side note; it would be handy to have tooltips on the 3D panel, so that mouseover can tell the user what real-life action will occur when a mouseclick is generated. That helps with the learning curve. For example, the door latch would have "open door" while the door handle would have "close door" ... ideally with 3D model door motion tie-in. - Bad flight characteristics (sometimes planes react too sensitive, sometimes too sluggish), much worse than X-Plane This puzzles me; real planes have huge changes in control sensitivity over the operational speed range, which we (and to a lesser extent) X-Plane try to model. Perhaps the chap is used to playing video games where effectiveness is not context sensitive ? Maybe not a GA pilot ? We certainly have limitations on control realism, but not to the extent that I'd critique us in the same breath as our other limitations. - Weather + Scenery disappointing The former is an active area of development (again, and again, and again). The latter is limited by our data sources and by our huge file sizes. My long term goal of doing strea
Re: [Flightgear-devel] YASim and the atmosphere
Andy Ross <[EMAIL PROTECTED]> writes: > David Megginson wrote: >> 1. Sea level 35degC, 28.5inHG >> 2. Sea level -25degC, 32inHG > The "density altitude difference" (a butchered term -- the density > altitude that corresponds to the same ratio vs. standard sea level > conditions) that this corresponds to is about 11000 feet MSL. That's > a pretty hefty difference in density! :) > >> The C172 barely climbs out of ground effect, and eventually manages an >> anemic 200-300fpm climb at 70 KIAS >> [vs.] >> The C172 finishes the takeoff roll in seconds and shoots up like a >> rocket at over 1500fpm at 70 KIAS. >> >> These are the right types of effects, but I think that the magnitudes >> are a little excessive, at least for a sea-level airfield. I have done a substantial amount of flying at high altitudes, including training for and actual missions doing search and rescue at high altitudes (up to 13000+ feet). From my experience, I would say that the effects you are seeing with a density altitude difference of 11000 feet are pretty much in line with reality, for a 172. When flying at those altitudes, climb rate is minimal, and rate of turn is huge -- i.e. if you try to reverse your direction by 180 degrees, it takes you *much* longer to make that turn at 11000 feet than it does at 2000 feet. (Do the various FDMs model that characteristic of density altitude well or at all?) Cheers, Derrell ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Crash on "Reset" function.
Jim Wilson writes: > Actually my most recent observations show some issues with multiple > teleports, or combination of teleports and resets. But I can reset > many times without trouble (I just did 20 resets in a row using > today's CVS with clouds disabled). So, I would suggest that the > recent fix that allows one reset has left a bug in there that > wasn't there a couple weeks ago. You should be able to do the same with clouds enabled. 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] Crash on "Reset" function.
Norman Vine writes: > Hopefully once we get 'reset' working again developers will test 'reset' > before submitting their changes in the future so we don't repeat this > quagmire It's a little more complicated than that. The original reset was a simple kludge that worked fine for a simple program; now that FlightGear is a lot more sophisticated, we need to refactor a bit rather than just holding things together with scotch tape and bubble gum. 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] YASim flaps flap
On Wed, 2002-06-05 at 20:54, Andy Ross wrote: > Tony Peden wrote: > > Induced drag is a function of the vortices surrounding the wing. > > Those vortices vary in strength with lift, not angle of attack. > > Not so. The induced drag of an aircraft in high-speed cruise is much > lower than an aircraft in level flight at stall speed. I probably used lift where I should have used CL. So, at cruise, the dynamic pressure is high and the CL required much lower than at approach speeds where the dynamic pressure is relatively low. Induced drag goes with CL^2 and CL doesn't change much across a flap transition. The lift in > these situations is the same (and equal to weight, of course). Think > about it: if induced drag depended solely on lift, there would be no > such thing as the "back side" of the power curve. Drag would go > asymptotically to some constant as airspeed dropped to zero -- that > clearly isn't right. For real aircraft, drag always increases with > AoA. > > In reality, induced drag looks much more like a function of AoA than > it does a function of lift. Well, in "real" reality induced drag is > just a metaphor; so it isn't "really" a function of anything. > > Maybe you mean to say that induced drag is a function of lift > *coefficient* -- as on a drag polar plot? This is true, but unhelpful > to me. I don't know what the lift coefficient is until I calculate > the AoA. And we're back to where we started. Hmmm... > > 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 -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
