Re: [Flightgear-devel] Installing only changed header files
Curtis L. Olson wrote: This is off the top of my head with a healthy mix of speculation. But, I believe you can override the 'install' command in the Makefiles. Often it is just cp or the is often an actual install program or similar install.sh script. This means that in theory, you ought to be able to write a script that compares the md5sum of the installed file with the about to be installed file and only actually install it if the two files are different. Now that you mention it, I haven't seen this begaviour for quite some time. The only difference I can think of is that I don't build SimGear and FlightGear in the root directory but instead I create a directory called $(top_dir)/build and start from there (run ../configure whatever from within this directory). Maybe that solves this? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Fw: Airspeeds?
On Thu, 2002-04-18 at 17:57, John Wojnaroski wrote: - Original Message - From: John Wojnaroski To: [EMAIL PROTECTED] Sent: Thursday, April 18, 2002 3:02 PM Subject: Airspeeds? Hi, On the subject of airspeeds: Indicated Airspeed (IAS) is calculated based on the difference between stagnation pressure in the pitot tube and the static pressure. formula is square root of 2 x [ stag - static ] / air density, if I recall correctly. now to get to true airspeed (TAS) we pass through a couple of filters Calibrated Airspeed (CAS) is IAS corrected for installation and position of the sensors which can be somewhat complex and it also varies during high AOAs and beta's. Variation with alpha and beta is a product of the pitot-static system, so these errors will be apparent in IAS as well. Either you have an air data computer that handles the correction for you or a few numbers called out in the flight manual to apply depending on your flight regime. For light aircraft it is probably just a couple of knots to add or subtarct from the indicated. Next comes Equivalent Airspeed (EAS) which is CAS corrected for compressibily (F factor).Which can be ignored if you plan to stay below 200 kts and 10,000 feet. You can find a table on most flight computer wheels. the result is to reduce the TAS. If your trying to do precise navigation at higher altitudes and airspeeds you need to worry about this. Finally TAS is EAS corrected for temperature and pressure (density altitude). Now this is important even for those in a c172 since you use TAS to compute your flight plan and adjust ground speeds for the winds at your flight altitude. So for the more complex equipment : IAS=CAS=EAS=TAS =Mach number For the smaller and lighter: IAS=TAS will work the majority of the time For a simulator, IAS is impossible to compute in a generic way since the variation from CAS will be different from airplane to airplane. A general formula for the conversion is 1.7 * density-altitude /1000 gives percent of change. Say at 10,000 feet an IAS of 100knots yields a TAS = 100 * (1.0 + .17) = 117. The factor 1.7 increases to about 2.1 at 30,000 feet. Note it is density altitude ( temp and pressure ) used to make the conversion. Bottom line question for the FDM' rs: Would you take a few moments to commen t/explain how your models handle the various airspeeds. Is the calibrated for a c172? Is the EAS to TAS done outside the FDMs? Are there installation corrections for the other aircraft models (dc-3, 747, x-15, c310, etc)? We do not do installation corrections at all, just give CAS as IAS. (This is usually what the instrument is trying to show anyway) All the forces and moment calculations depend on TAS, so that is done inside the FDM's. We compute EAS as well. Ultimately, the FMC in the glass displays has to have the same set of environmental data as the flight models by way of a common database or pressure and temp parameters used in the calculations. Right now, it looks like the values identified are not all reported across the FDM interface. Regards John W. ___ 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
Re: [Flightgear-devel] Fw: Airspeeds?
On Thu, 2002-04-18 at 18:23, Andy Ross wrote: John Wojnaroski wrote: Indicated Airspeed (IAS) Calibrated Airspeed (CAS) Next comes Equivalent Airspeed (EAS) Finally TAS Bottom line question for the FDM' rs: Would you take a few moments to comment/explain how your models handle the various airspeeds. The FDM interface treats CAS and IAS identically -- the calibration error, as you point out, is poorly defined and will vary between installations. All FDMs simply report a single calibrated airspeed value; if other code wants to model the vagaries of a given ASI, then it's welcome to. :) It's also worth pointing out that the FDMs work, internally, with a real, 3D velocity. So TAS is what you get natively as the projection of velocity along the aircraft's X axis; everything else is computed from that. EAS is really simple -- it's just the true speed multiplied by the square root of the density ratio; it corresponds directly to a given dynamic pressure (which is the space in which force constants like drag coefficients are measured). CAS gets hairy. At low speeds, it's identical to EAS. At higher speeds, it needs to be corrected for compressibility; and at supersonic speeds it needs to be corrected for shock wave effects. I have a good handle on the first two, but the shock stuff is beyond me. JSBSim had code for doing this, so (after verifying that it agreed perfectly at sub-mach numbers) I just used that. :) That code assumes that the pitot probe is placed out in front of the aircraft, so that a cone shaped shock forms ahead of it. It is further assumed that the pitot probe opening is small enough that that portion of the shock in front of it can be assumed to be planar. After that, it's a straightforward application of 1D compressible flow theory. 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
[Flightgear-devel] View problem
Hello, Just got current CVS of all packages around 07:30 4/19 EDT and compiled without errors. Starting the default model, I am sitting at KSFO in the dark (as expected). Change environment airport to KALE and have a sunny day with proper hills in the distance. External chase view also correct. Then step view again, and both tower views are back at the KSFO tower in the pre-dawn. Interestingly, the look-at view is aimed at a point of not-too-distant ground. If my visualization off the globe is correct, it may well be looking at KABE directly, but the ground blocks the direct chord. The poor Cessna would be well under 1 pixel at that range. -- Bill Earnest wde3@ptd-dot-net Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] View problem
Hello, Just got current CVS of all packages around 07:30 4/19 EDT and compiled without errors. Starting the default model, I am sitting at KSFO in the dark (as expected). Change environment airport to KABE and have a sunny day with proper hills in the distance. External chase view also correct. Then step view again, and both tower views are back at the KSFO tower in the pre-dawn. Interestingly, the look-at view is aimed at a point of not-too-distant ground. If my visualization off the globe is correct, it may well be looking at KABE directly, but the ground blocks the direct chord. The poor Cessna would be well under 1 pixel at that range. -- Bill Earnest wde3@ptd-dot-net Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] View problem
Yes, thats right, its looking at KABE directly. You will also note that the tower view stays where it was even if you fly far away. Currently the tower location is just an arbitrary setting the is based on the starting location, until we have some real tower locations in there. Possibly we can move the tower during teleports though...hmmm. Best, Jim William Earnest [EMAIL PROTECTED] said: Hello, Just got current CVS of all packages around 07:30 4/19 EDT and compiled without errors. Starting the default model, I am sitting at KSFO in the dark (as expected). Change environment airport to KALE and have a sunny day with proper hills in the distance. External chase view also correct. Then step view again, and both tower views are back at the KSFO tower in the pre-dawn. Interestingly, the look-at view is aimed at a point of not-too-distant ground. If my visualization off the globe is correct, it may well be looking at KABE directly, but the ground blocks the direct chord. The poor Cessna would be well under 1 pixel at that range. -- Bill Earnest wde3@ptd-dot-net Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] View problem
Jim Wilson writes: Yes, thats right, its looking at KABE directly. You will also note that the tower view stays where it was even if you fly far away. Currently the tower location is just an arbitrary setting the is based on the starting location, until we have some real tower locations in there. Possibly we can move the tower during teleports though...hmmm. If we came up with some code to find the closest airport to a lat/lon, then we could write a function to move the tower view to the closest airport, and bind a key to it. Or perhaps allow the user to specify which airport to move the tower too ... if I am inbound to KLAX for instance, it might be interesting to move the tower view there well in advance of my arrival ... but this is something that would have to be done interactively. 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] View problem
Curtis L. Olson [EMAIL PROTECTED] said: If we came up with some code to find the closest airport to a lat/lon, then we could write a function to move the tower view to the closest airport, and bind a key to it. Or perhaps allow the user to specify which airport to move the tower too ... if I am inbound to KLAX for instance, it might be interesting to move the tower view there well in advance of my arrival ... but this is something that would have to be done interactively. What I was thinking is that it'd be cool to move the tower automatically when hitting the outer marker. Any idea if I can ID the airport when OM goes off? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Strange opengl compiler error ?
Dear developers, I am still in the process of becoming a developer. I installed cygwin, plib, simgear and flightgear. I used getstarted.pdf to learn to compile flightgear. Something missing in this pdf is that one has to install Xfree86 Metakit For simgear one has to install the latest version of metakit (2.4.4.34). Version 2.4.2 as delivered with simgear gives compiler errors. After this I was able to compile and install plib and simgear. Next I tried to make flightgear and got the following errors while compiling main.cxx in simgear source that I do not understand because simgear was already compiled and the functions (for instance glflush() are available through include gl.h in tr.cxx ? One thing I was also wondering about is whether one always has to call : aclocal ; automake -a ; autoconf as mentioned on the simgear website or is this only a prerequisite for simgear to build the configure script ? ++ -DPKGLIBDIR=\/usr/local/lib/FlightGear\ -g -O2 -L/usr/local/lib -o fgfs main.o fg_commands.o fg_init.o fg_io.o fg_prop s.o fgfs.o globals.o options.o splash.o viewer.o viewer_lookat.o viewer_rph.o viewmgr.o ../../src/Aircraft/libAircraft.a. ./../src/ATC/libATC.a ../../src/Autopilot/libAutopilot.a ../../src/Cockpit/libCockpit.a ../../src/Controls/libControl s.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/Navaids/libNavaids.a ../../src/Scenery/libScenery. a ../../src/Sound/libSound.a ../../src/Airports/libAirports.a ../../src/Network/libNetwork.a ../.. /src/NetworkOLK/libNetworkOLK.a ../../src/Objects/libObjects.a ../../src/Time/libTime.a../../src/WeatherCM/l ibWeatherCM.a ../../src/Input/libInput.a -lsgroute -lsgsky -lsgephem -lsgtiming -lsgio -lsgscreen-lsgmath -lsg bucket -lsgdebug -lsgmagvar -lsgmisc -lsgxml-lsgserial -lplibpu -lplibfnt -lplibnet -lplibssg -lplibsg - lmk4 -lz-lpthread -lm -lglut32 -lglu32 -lopengl32 -luser32 -lgdi32 -lplibsl -lplibsm -lwinmm -lplibul -lm Warning: resolving _glBlendFunc by linking to _glBlendFunc@8 Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable these fixups Warning: resolving _glPopAttrib by linking to _glPopAttrib@0 Warning: resolving _glPushAttrib by linking to _glPushAttrib@4 Warning: resolving _glDisable by linking to _glDisable@4 Warning: resolving _glPopMatrix by linking to _glPopMatrix@0 Warning: resolving _glOrtho by linking to _glOrtho@48 Warning: resolving _glPushMatrix by linking to _glPushMatrix@0 Warning: resolving _glPixelStorei by linking to _glPixelStorei@8 Warning: resolving _glMatrixMode by linking to _glMatrixMode@4 Warning: resolving _glViewport by linking to _glViewport@16 Warning: resolving _glGetIntegerv by linking to _glGetIntegerv@8 Warning: resolving _glLoadIdentity by linking to _glLoadIdentity@0 /usr/local/lib/libsgscreen.a(screen-dump.o): In function `sg_glDumpWindow(char const *, int, int)': /home/Administrator/source/simgear-0.0.17/simgear/screen/screen-dump.cxx :85: undefined reference to `glFinish' /home/Administrator/source/simgear-0.0.17/simgear/screen/screen-dump.cxx :87: undefined reference to `glReadPixels' /usr/local/lib/libsgscreen.a(tr.o): In function `trEndTile(_TRctx *)': /home/Administrator/source/simgear-0.0.17/simgear/screen/tr.cxx:404: undefined reference to `glFlush' /home/Administrator/source/simgear-0.0.17/simgear/screen/tr.cxx:418: undefined reference to `glReadPixels' /home/Administrator/source/simgear-0.0.17/simgear/screen/tr.cxx:437: undefined reference to `glReadPixels' /usr/local/lib/libsgscreen.a(tr.o): In function `trRasterPos3f(_TRctx *, float, float, float)': /home/Administrator/source/simgear-0.0.17/simgear/screen/tr.cxx:468: undefined reference to `glRasterPos3f' /home/Administrator/source/simgear-0.0.17/simgear/screen/tr.cxx:476: undefined reference to `glGetDoublev' /home/Administrator/source/simgear-0.0.17/simgear/screen/tr.cxx:477: undefined reference to `glGetDoublev' /home/Administrator/source/simgear-0.0.17/simgear/screen/tr.cxx:484: undefined reference to `gluProject' /home/Administrator/source/simgear-0.0.17/simgear/screen/tr.cxx:495: undefined reference to `glRasterPos3f' /home/Administrator/source/simgear-0.0.17/simgear/screen/tr.cxx:500: undefined reference to `glBitmap' collect2: ld returned 1 exit status make[2]: *** [fgfs] Error 1 make[2]: Leaving directory `/home/Administrator/source/flightgear-0.7.9/src/Main' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/Administrator/source/flightgear-0.7.9/src' make: *** [all-recursive] Error 1 I hope somebody can help me kind regards Marcel Wittebrood ADSE _ ADSE Consultancy and Engineering B.V. Tel. +31 (0)
RE: [Flightgear-devel] View problem
Curtis L. Olson writes: Jim Wilson writes: Possibly we can move the tower during teleports though...hmmm. +10 If we came up with some code to find the closest airport to a lat/lon, then we could write a function to move the tower view to the closest airport, and bind a key to it. Or perhaps allow the user to specify which airport to move the tower too ... if I am inbound to KLAX for instance, it might be interesting to move the tower view there well in advance of my arrival ... but this is something that would have to be done interactively. Yes setting the tower view to a specific airport would need some kind intervention. Perhaps tie'ing it to the current waypoint makes sense .. hmmm Also The tile_cache mechanism could be extended to keep a list of loaded airports and this list could be queried for the closest one or those within some range. Note that a fast 'chord distance' would work well for this as all we are interested in is the 'relative' distance and the since the spherical chord has a one to one maping to the geodetic distance at the kind of scale involved here, it would be sufficient. Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flap positions
That's normal from JSBSim. Is it causing you some difficulty? --- Erik Hofman [EMAIL PROTECTED] wrote: Hi, When checking the flap postions I notices they return to another postition then they came from: down: 0.0 -- 0.34 -- 0.68 -- 1.0 up: 1.0 -- 0.66 -- 0.32 -- 0.0 Is this the default for the c172? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] WARNING: ssgLoadMDL: Couldn't open MDL file
Hello alltogether, would you mind changing this back to the previous behaviour which means not to crash if there's no model description. Unfortunalety I've been off scene for a few days so it's not quite clear to me when the change happened. I was trying the Beech99 in the hope to see a working gear quickstep: 17:13:39 ~ fgfs NewAirportInit EDWS idx = 7631 Current greenwich mean time = Fri Apr 19 15:13:43 2002 Current local time = Fri Apr 19 17:13:43 2002 WARNING: ssgLoadMDL: Couldn't open MDL file '/home/mas/src/FlightGear/fgfsbase/Aircraft/Beech99/Models/beech_99.mdl'! Fatal error: Failed to load 3D model (received from ) quickstep: 17:13:43 ~ Is anybody able to reproduce this 'feature' ? FlightGear was built from today's CVS, 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] Realy strange
Thanks for the information Julian. Yes, I removed the old config.cache file. Did I get this right, the only way to make it work again is reverting to the old version? Cheers Alexander On Fri, 19 Apr 2002, Julian Foad wrote: configure.in includes a fix to make it work with both versions of the auto-tools: if OLD_AUTOMAKE INCLUDES += -I$(top_srcdir) else INCLUDES = -I$(top_srcdir) endif But (1) If = is good enough in the new version, isn't it good enough in both versions? (Not necessarily: maybe the meaning has changed.) (2) OLD_AUTOMAKE seems to be erroneously set on Alexander's system. Alexander, have you forced a re-configure in the SimGear directory by deleting config.cache? If you haven't, that is probably what you need to do. - Julian Alexander Kappes wrote: I recently upgraded from SuSE 7.2 to 8.0 and since then I get strange error messages when I try to run autogen for SimGear (and also FlightGear): --- Host info: Linux i686 automake: 1.5 (15) Running aclocal Running autoheader autoheader: simgear/simgear_config.h.in is unchanged Running automake --add-missing simgear/bucket/Makefile.am: INCLUDES must be set with `=' before using `+=' simgear/debug/Makefile.am: INCLUDES must be set with `=' before using `+=' simgear/ephemeris/Makefile.am: INCLUDES must be set with `=' before using `+=' ... ___ 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] View problem
Jim Wilson writes: Norman Vine [EMAIL PROTECTED] said: Perhaps tie'ing it to the current waypoint makes sense .. hmmm Yes, but I'd probably want to wait until I was within a few kilometers of the current waypoint before switching. or perhaps when the 'current waypoint' is closer then the the 'current tower location' That would do the trick. We'd need that anyway if we wanted to do an approximate model of a GPS some day. I don't understand what you mean by model a GPS Are you are using 'GPS' to mean a 'muti-function' GPS receiver ? If so most of the pieces are already in place. still need a 'cross-track error' though untested pseudo code, off the top of my head using normallized geocentic representation i.e. direction cosine form using geocentric latitude sgdSubVec3( dir, track_start, track_end ) // simgear function sgdClosestPointToLine( closest_pt, current_pt, track_start, dir ) // can probably skip this next step for 'short enough' tracks sgdNormalizeVec3(closest_pt) sgdScaleVec3(closest_pt,sea_level_radius) sgdScaleVec3(current_pt, sea_level_radius) sgdSubVec3(error_vec, closest_pt, current_pt) // this should be close enough for our purposes crosstrack_error_dist = sgdScalarProductVec3(error_vec) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Fw: Airspeeds?
Hi, Bottom line question for the FDM' rs: Would you take a few moments to comment/explain how your models handle the various airspeeds. Just a quick thank you for the info put. To make the FG/OpenGC interface effective will require a little handshaking on both ends to sync up. Back in a few weeks with some ideas and options. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] View problem
Norman Vine [EMAIL PROTECTED] said: That would do the trick. We'd need that anyway if we wanted to do an approximate model of a GPS some day. I don't understand what you mean by model a GPS Are you are using 'GPS' to mean a 'muti-function' GPS receiver ? Support for a NRST airport button? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] latest cvs changes
Anyone up for a 0.7.10 release sometime soon? I wouldn't object a 0.7.10 release as long as where were at least two or three weeks for fixing obvious known bugs that prevent users from using functionality that is _supposed_ to be usuable right now (see my posting on the Beech99). In the meantime I'd have a chance to experience the differences from the previous release to see what changes are _really_ necessary for the Getting Started manual :-) 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] Strange opengl compiler error ?
I used getstarted.pdf to learn to compile flightgear. This is very nice to hear, so we know there really _are_ people reding our manual ;-) Something missing in this pdf is that one has to install Xfree86 Metakit Hmmm, I believe it is _really_ obvious that yoy need X11 for FlightGear. MetaKit is another deal - I'll take care of this in the next release of Getting Started, 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
[Flightgear-devel] autoconf problem
Ok, I installed now the old version of automake (v 2.4) but I have still problems running autogen --- ltkappes/home/kappes/ltka/fgfs/SimGear autogen.sh Host info: Linux i686 automake: 1.4-p5 (14) Running aclocal Running autoheader autoheader: simgear/simgear_config.h.in is unchanged Running automake --add-missing Running autoconf configure.in:21: error: possibly undefined macro: AC_SG_SET_COMPILER --- Autoconf is version 2.52. Cheers Alexander ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] View problem
im Wilson writes: Norman Vine [EMAIL PROTECTED] said: That would do the trick. We'd need that anyway if we wanted to do an approximate model of a GPS some day. I don't understand what you mean by model a GPS Are you are using 'GPS' to mean a 'muti-function' GPS receiver ? Support for a NRST airport button? Gottcha -- I keep forgetting that 'GPS' is shorthand nowadays for a multifunction navigation computer that has a GPS reciever builtin FWIW The first GPS I worked with took up most of a 4x6 foot equipment rack and only measured time differences converting these into a latlon was done by entering these by hand into yet another computer system and / or doing a quick slide rule calculation Never mind having a general purpose navigation routines builtin :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flap positions
Erik Hofman wrote: Well It's making it slightly difficult for the sound code. But I saw YASim does the same. These numbers are actually generated by the panel code, not the FDM. Both FDMs just seek the position to the specified control input. In this case, the panel code adds or subtracts 0.33 to the current value. You're seeing the rounding error resulting from the not-quite-one-third stepping value. Add some threes. :) 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] Flap positions
Andy Ross wrote: Erik Hofman wrote: Well It's making it slightly difficult for the sound code. But I saw YASim does the same. These numbers are actually generated by the panel code, not the FDM. Both FDMs just seek the position to the specified control input. In this case, the panel code adds or subtracts 0.33 to the current value. You're seeing the rounding error resulting from the not-quite-one-third stepping value. Add some threes. :) We're starting to create a problem here. There are different values for keyboard, mouse (panel) and IO modules. I think we should define a fixed value for each flap position, otherwise every module looking at the value has to support (0 0.32 or 0.34 0.66 or 0.66 1.0)! Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Installing only changed header files
Thanks; I think I'll do that. - Julian David Megginson wrote: Julian Foad writes: Doesn't everyone have the same problem that I have: that after re-building plib and/or SimGear, even after a one-file change, the make install copies all of the header files to the install directory, putting the current date stamp on them, even though they have not changed. This causes almost every file in FlightGear to be re-compiled. I keep the SimGear source tree in /usr/local/src, then just do this: rm -rf /usr/local/include/simgear ln -s /usr/local/src/SimGear/simgear /usr/local/include ln -sf `find /usr/local/src/SimGear -name '*.a' -print` /usr/local/lib Then, I make sure I never do a 'make install' in /usr/local/src/SimGear, and everything works nicely. For plib, the procedure is slightly different, since all include files have to be in the same directory: rm -rf /usr/local/include/plib mkdir /usr/local/include/plib ln -sf `find /usr/local/src/plib/ -name '*.h' -print` /usr/local/include/plib ln -sf `find /usr/local/src/plib/ -name '*.a' -print` /usr/local/lib I'm doing this from memory, so please forgive any typos. There's one caveat -- if SimGear or plib changes only in the cxx files, you will have to remove the FlightGear binary to force a relink. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Fwd: LOCAL: FlightGear presentation in Davis, CA - May 7th
FYI. The Linux Users' Group of Davis (LUGOD), will be holding a meeting on: Tuesday May 7th, 2002 6:30pm - 9:30pm (Doors open at 6:00pm; please try to arrive on-time!) The meeting will be held at: Z-World, Inc. 2900 Spafford Street Davis, CA 95616 (Near Sacramento) The topic will be: FlightGear flight simulator software for Linux and Windows presented by: Andy Ross of the FlightGear project FlightGear is a completely Open Source multi-platform, cooperative flight simulation development project. The FlightGear project is working to create a sophisticated flight simulator framework for the development and pursuit of interesting flight simulator ideas. It is a solid, basic simulator that can be expanded and improved upon by anyone interested in contributing. (See: http://www.flightgear.org/ ) For details on this meeting, visit: http://www.lugod.org/meeting/ For maps, directions, public transportation schedules, etc., visit: http://www.lugod.org/meeting/zworld/ LUGOD is a non-profit organization dedicated to the Linux Operating System, and which holds meetings twice a month in Davis, CA. Meetings are always free, and open to the public. Please visit our website for details: http://www.lugod.org/ -bill! [EMAIL PROTECTED] http://www.lugod.org/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Realy strange
Alexander, It's ok to be seeing this error messages about = vs +=. They are annoying, but harmless. Curt. Alexander Kappes writes: Thanks for the information Julian. Yes, I removed the old config.cache file. Did I get this right, the only way to make it work again is reverting to the old version? Cheers Alexander On Fri, 19 Apr 2002, Julian Foad wrote: configure.in includes a fix to make it work with both versions of the auto-tools: if OLD_AUTOMAKE INCLUDES += -I$(top_srcdir) else INCLUDES = -I$(top_srcdir) endif But (1) If = is good enough in the new version, isn't it good enough in both versions? (Not necessarily: maybe the meaning has changed.) (2) OLD_AUTOMAKE seems to be erroneously set on Alexander's system. Alexander, have you forced a re-configure in the SimGear directory by deleting config.cache? If you haven't, that is probably what you need to do. - Julian Alexander Kappes wrote: I recently upgraded from SuSE 7.2 to 8.0 and since then I get strange error messages when I try to run autogen for SimGear (and also FlightGear): --- Host info: Linux i686 automake: 1.5 (15) Running aclocal Running autoheader autoheader: simgear/simgear_config.h.in is unchanged Running automake --add-missing simgear/bucket/Makefile.am: INCLUDES must be set with `=' before using `+=' simgear/debug/Makefile.am: INCLUDES must be set with `=' before using `+=' simgear/ephemeris/Makefile.am: INCLUDES must be set with `=' before using `+=' ... ___ 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] Realy strange
Alexander Kappes wrote: Thanks for the information Julian. Yes, I removed the old config.cache file. Did I get this right, the only way to make it work again is reverting to the old version? The old version of the auto-tools will probably work, but I don't know for sure. And I don't know whether that is the only way to make it work. Sorry. You should also check that SimGear/configure.in contains the line AC_PREREQ(2.13) near the beginning. If you are not using a recent version from CVS, you need to add it: AC_INIT(simgear/bucket/newbucket.cxx) + # Require at least automake 2.13 + AC_PREREQ(2.13) + dnl Initialize the automake stuff AM_INIT_AUTOMAKE(SimGear, 0.0.18pre1) That might solve the problem. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Realy strange
Julian Foad writes: Curtis L. Olson wrote: These are actually harmless error messages for lines that aren't even executed by your version of automake, but the error checker isn't as smart as it could be and doesn't know about automake conditionals. Are you referring to this message (running automake): simgear/xml/Makefile.am: INCLUDES must be set with `=' before using `+=' This ... I haven't run across other error messages. 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] Flap positions
--- Erik Hofman [EMAIL PROTECTED] wrote: Andy Ross wrote: Erik Hofman wrote: Well It's making it slightly difficult for the sound code. But I saw YASim does the same. These numbers are actually generated by the panel code, not the FDM. Both FDMs just seek the position to the specified control input. In this case, the panel code adds or subtracts 0.33 to the current value. You're seeing the rounding error resulting from the not-quite-one-third stepping value. Add some threes. :) We're starting to create a problem here. There are different values for keyboard, mouse (panel) and IO modules. I think we should define a fixed value for each flap position, otherwise every module looking at the value has to support (0 0.32 or 0.34 0.66 or 0.66 1.0)! Making the sound code dependent upon particular values of flap position might not be a good idea. Many aircraft have a different number of flap detents, some as many as nine. I would suggest that the controlling code generate an in-transit flag or, conversely, an in-detent flag. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Installing only changed header files
Alex Romosan wrote: Julian Foad [EMAIL PROTECTED] writes: Doesn't everyone have the same problem that I have: that after re-building plib and/or SimGear, even after a one-file change, the make install copies all of the header files to the install directory, putting the current date stamp on them, even though they have not changed. This causes almost every file in FlightGear to be re-compiled. how about: make INSTALL='install -pc' install from the install man page: -p, --preserve-timestamps apply access/modification times of SOURCE files to corresponding destination files this works for me. --alex-- Excellent! That's the sort of thing I was hoping for. I don't know how I missed that when I read the install manual. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flap positions
Erik Hofman writes: I think we should define a fixed value for each flap position, otherwise every module looking at the value has to support (0 0.32 or 0.34 0.66 or 0.66 1.0)! How are you trying to use the information? There might be an easier approach. 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] Fw: Airspeeds?
On 19 Apr 2002 05:25:24 -0700, Tony Peden [EMAIL PROTECTED] wrote in message 1019219125.18988.16.camel@raptor: On Thu, 2002-04-18 at 17:57, John Wojnaroski wrote: - Original Message - From: John Wojnaroski To: [EMAIL PROTECTED] Sent: Thursday, April 18, 2002 3:02 PM Subject: Airspeeds? Hi, On the subject of airspeeds: Indicated Airspeed (IAS) is calculated based on the difference between stagnation pressure in the pitot tube and the static pressure. formula is square root of 2 x [ stag - static ] / air density, if I recall correctly. now to get to true airspeed (TAS) we pass through a couple of filters Calibrated Airspeed (CAS) is IAS corrected for installation and position of the sensors which can be somewhat complex and it also varies during high AOAs and beta's. Variation with alpha and beta is a product of the pitot-static system, so these errors will be apparent in IAS as well. ... For a simulator, IAS is impossible to compute in a generic way since the variation from CAS will be different from airplane to airplane. ... We do not do installation corrections at all, just give CAS as IAS. (This is usually what the instrument is trying to show anyway) ..most planes have some info on IAS - CAS conversion, placarded or in manuals etc, these form workable starting points? ..for magnetic compass manouvering errors: compare it with a gyro in standard rate turns, double rate turns etc, both righthand and lefthand. Video tape the pair. And chances are we want this tape for all magnetic latitudes... ;-) -- ..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
..ot: aoulde gps, was: [Flightgear-devel] View problem
On Fri, 19 Apr 2002 12:44:14 -0400, Norman Vine [EMAIL PROTECTED] wrote in message 000701c1e7c1$712a8180$a300a8c0@nhv: im Wilson writes: Norman Vine [EMAIL PROTECTED] said: That would do the trick. We'd need that anyway if we wanted to do an approximate model of a GPS some day. I don't understand what you mean by model a GPS Are you are using 'GPS' to mean a 'muti-function' GPS receiver ? Support for a NRST airport button? Gottcha -- I keep forgetting that 'GPS' is shorthand nowadays for a multifunction navigation computer that has a GPS reciever builtin FWIW The first GPS I worked with took up most of a 4x6 foot equipment ..stone age. _Everything_ done in hardware? Navstar? Valves? ;-) rack and only measured time differences converting these into a latlon was done by entering these by hand into yet another computer system and / or doing a quick slide rule calculation Never mind having a general purpose navigation routines builtin :-) -- ..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] latest cvs changes
On Friday 19 April 2002 04:34 am, you wrote: Jim Wilson wrote: As for the numbering, how about jumping to 0.8 and then continuing on as we have? This will look like a pretty major update with the new models and 3d internal view. I would think 0.8.0 is reserved for a *stable* release. Although much has changed in the recent past, changes ar this release won't be a good and stable release as expected for a 0.8 release. Erik We need hotspots to work in the 3D cockpit to earn the .8.0 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: LOCAL: FlightGear presentation in Davis,CA - May 7th
On Friday 19 April 2002 01:56 pm, you wrote: Erik Hofman wrote: FlightGear flight simulator software for Linux and Windows presented by: Andy Ross of the FlightGear project I'd just like to point out that this is all Alex's fault. I didn't have anything to do with it (other than saying uh, ok, that is). I haven't done much planning yet. If folks have suggestions for really cool features to demo, fire away. They have an LCD projector, and I'm going to bring my machine down. I was also planning on burning a bunch of (well, maybe a dozen or so) CDs with current code and the full scenery downloads as party favors. Andy Definitely have an ISO on the drive. If they have a LAN going put it on ftp. Encourage people with laptops to download it during the presentation. Allow plenty of demo time, if anybody that downloaded it installed it, demo a master/slave setup. Also keep a copy of Atlas on hand. Have fun with it, it's a good topic. TTYL J ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Simgear timezone file parsing anomaly
What this code says is ignore anything after a hash ... unless we're compiling with
Microsoft C, in which case only ignore lines which start with a hash. Surely this
isn't intended. Curt checked in the change last May, but almost certainly didn't
invent it.
My tentative guess would be that MSVC users were bitten by the memory over-run bug in
the same file, which was fixed only last month (thanks to Melchior) and that this was
sort of a crude work-around for it. Not sure, though.
Unless someone has a valid reason for it, I suggest the #ifdef _MSC_VER ... #else
section be removed.
TimezoneContainer::TimezoneContainer(const char *filename)
{
...
fgets(buffer, 256, infile);
...
#ifdef _MSC_VER
if( buffer[0] == '#' )
continue;
#else
for (char *p = buffer; *p; p++) {
if (*p == '#') {
*p = 0;
break;
}
}
#endif
if (buffer[0]) {
...
}
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FGFS Link Error
Gents, When making the latest CVS FGFS on Cygwin/Win2k, the following link error occurs: rc/WeatherCM/libWeatherCM.a ../../src/Input/libInput.a -lsgroute -lsgsk y -lsgephem -lsgtiming -lsgio -lsgscreen-lsgmath -lsgbucket -lsgdebu g -l sgmagvar -lsgmisc -lsgxml -lsgserial -lplibpu -lplibfnt - lpli bnet -lplibssg -lplibsg -lmk4 -lz -lpthread -lm -lglut32 -lgl u32 -lopengl32 -luser32 -lgdi32 -lplibsl -lplibsm -lwinmm -lplibul -lm /usr/lib/libplibul.a(ulContext.o)(.text+0x47):ulContext.cxx: undefined reference to `wglGetCurrentContext@0' collect2: ld returned 1 exit status It looks like the link order is wrong - the PLIB libraries should be linked before the OpenGL libraries. But a check of src/Main/Makefile shows: fgfs: $(fgfs_OBJECTS) $(fgfs_DEPENDENCIES) @rm -f fgfs $(CXXLINK) $(fgfs_LDFLAGS) $(fgfs_OBJECTS) $(fgfs_LDADD) $(LIBS) and from src/Main/Makefile.am: fgfs_LDADD = \ $(top_builddir)/src/Aircraft/libAircraft.a \ ... lots more libraries... $(THREAD_LIBS) \ -lplibpu -lplibfnt -lplibnet -lplibssg -lplibsg \ -lmk4 -lz \ $(opengl_LIBS) \ $(audio_LIBS) ..which looks correct and hasn't changed in a few days. Yes, this was a clean rebuild from autogen.sh on up. The dates on the src/Main/Makefile* files are correct. automake: 1.4-p5 (14). This was working yesterday. Any ideas? Thanks, Paul Paul R. Deppe Veridian Engineering (formerly Calspan) Flight Aerospace Research Group 150 North Airport Drive Buffalo, NY 14225 (716) 631-6898 (716) 631-6990 FAX [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] latest cvs changes
* [EMAIL PROTECTED] (Curtis L. Olson) [2002.04.19 21:24]: Anyone up for a 0.7.10 release sometime soon? If anyone wants a real time wasting discussion, what do people think about switching from 0.7.10, 0.7.11, 0.7.12, etc. to going 0.8, 0.9, 1.0, 1.1, 1.2, 1.3, that way it looks like our development is moving at 10x the speed. Or perhaps I should say that our current number scheme makes the development look like it is proceeding at 0.1x the speed it actually is. :-) What exactly do we want 1.0 to be? Here are some things I'd like to see in 1.0: - Runway lighting - Sane gear model in JSBSim - Turbine engine model in JSBSim - Complete c172 (fully functional 2D/3D models) Wouldn't that create a usable flight simulator for many people? Thanks -- Cameron Moore / Why do people without a watch look at their \ \ wrist when you ask them what time it is? / ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] latest cvs changes
On Behalf Of Cameron Moore What exactly do we want 1.0 to be? Here are some things I'd like to see in 1.0: - Runway lighting - Sane gear model in JSBSim In work, as we speak. Of course, this has been in work for months, and is likely to continue to be for at least days if not weeks. - Turbine engine model in JSBSim I just had a discussion on this with Erik. There is likely to be an extremely simplistic turbine engine model sooner rather than later. Improvements can be made with time, but we need at-the-very-least this: thrust = throttle_pct * max_thrust; ;-) Jon smime.p7s Description: application/pkcs7-signature
[Flightgear-devel] PLIB
What version of Plib I have to use to compile FG and Simgear? Marcio Shimoda ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] U3-A 3D Cockpit
Well I've been working on an interior for the U3-A for a while and have gotten to the point where it isn't too embarassing to reveal what it looks like. http://www.spiderbark.com/fgfs/c310-cockpit-1.png http://www.spiderbark.com/fgfs/c310-cockpit-2.png The cockpit was made by cutting a section of the fuselage out and pasting the necessary parts on the inside, adjusting them so they fit well. Then I discarded the fuselage section and put the cockpit in the original model. The problem with this is the interior is slightly too close to the outer shell and shows through once in a while (not necessarily at far distance). Does anyone know how I might be able to scale the cockpit to about 99.9% of its current size and maintain the same origin, etc? Using ac3D. I know you can resize with a mouse but I'd rather have something more precise. Of course I'm also thinking that I could make sure there aren't any normals sticking out of the cockpit...but not sure if that method would have any potential repercussions. Advice and/or suggestions welcome. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
