Re: [Flightgear-devel] FGCOM bug: Call rejected by remote
[...] > > The problem is: that has not much to do with VoIP - so you havn't any > > features of VoIP and no implementations for server and client. Feel free > > to do so :-) > > > > Perhaps someone can extend the IAX2 protocol and write a new > > app_meetme.so for Asterisk which ca realise this. But I think it is not > > really neccessary at this time. > I could not do it in C or C++ but I might be able in, lets say, C#. though > currently I working on too many other open source things, both related to > flightgear and other things, to have time. The implementation with Asterisk can be done with nearly every language. The magic application in the dialplan is EAGI(). With this function you get full AGI access and on the file descriptor 3 the audio of the stream. You have "only" to connect to a multiplayer server and if the callsign on the mp server, the user on asterisk and the frq are matching you can calculate the distance and mix up the audio streams and so on. Theoretically no problem :-) See: http://www.voip-info.org/wiki/view/Asterisk+EAGI Regard, Holger -- # ## ## Holger Wirtz Phone : (+49 30) 884299-40 ## ## ## ### ## DFN-Verein Fax : (+49 30) 884299-70 ## ## ## Stresemannstr. 78E-Mail: [EMAIL PROTECTED] ## ## ## ## ### 10963 Berlin # ## ## ## GERMANY WWW : http://www.dfn.de GPG-Fingerprint: ABFA 1F51 DD8D 503C 85DC 0C51 E961 79E2 6685 9BCF - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGCOM bug: Call rejected by remote
Hi, On Wed, Dec 19, 2007 at 11:55:31AM +0100, AnMaster wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Holger Wirtz wrote: > > Hi Arvid, > > No, yes, no... yes it's a kind of bug. I had such things not in mind as > > I wrote fgcom. There should be a feature that allows to use the echo box > > even if you are authenticated to the server but this works only as > > guest. I will fix this soon. Than I have to setup asterisk to create > > conferences for _every_ frequency. That maybe working but I have to > > think about problems with this... > > > > Regards, Holger > > > Nice. But do fgcom make a difference between the same frequency used for, lets > say, an airport in Sweden and one in US? Or if you use it in any place just > outside the range of that airport? fgcom makes differences - but only for airport becuase than you can calculate the distance. For every other frequency I can install a workaround which causes this frq to be unlimeted range - not very realistic. Regards, Holger > > Regards, > > Arvid Norlander > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.7 (GNU/Linux) > > iD8DBQFHaPijWmK6ng/aMNkRCobNAKCFAper1HujYKcWbcS5ONjJP+VCJwCfcQnu > zGjdYAPTGdWCQn54BqX9mXM= > =2bnH > -END PGP SIGNATURE- > > - > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services > for just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- # ## ## Holger Wirtz Phone : (+49 30) 884299-40 ## ## ## ### ## DFN-Verein Fax : (+49 30) 884299-70 ## ## ## Stresemannstr. 78E-Mail: [EMAIL PROTECTED] ## ## ## ## ### 10963 Berlin # ## ## ## GERMANY WWW : http://www.dfn.de GPG-Fingerprint: ABFA 1F51 DD8D 503C 85DC 0C51 E961 79E2 6685 9BCF - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgfs crashes; glibc detected free(): invalid pointer
On Dec 21, 2007 3:08 AM, Zach Welch <[EMAIL PROTECTED]> wrote: > Hi all, > > I have been trying to establish a current FG development environment on > a Gentoo Linux system (GCC 4.1.2, glibc 2.6.1, ATI/flgrx). I have > current CVS working copies of plib, OSG, SimGear, and FG. While > everything builds and installs, I get the attached crash when trying to > run fgfs, even after a clean re-build of those libraries. Looks like the good old ATI driver bug, search the archives for a possible workaround. -- Csaba/Jester - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] fgfs crashes; glibc detected free(): invalid pointer
Hi all, I have been trying to establish a current FG development environment on a Gentoo Linux system (GCC 4.1.2, glibc 2.6.1, ATI/flgrx). I have current CVS working copies of plib, OSG, SimGear, and FG. While everything builds and installs, I get the attached crash when trying to run fgfs, even after a clean re-build of those libraries. The first trace (trace.txt) was produced by directly running the fgfs app, apparently after loading the aircraft data. The second trace (grind.txt) was produced by valgrind. It successfully works around the bug and allows fgfs to continue, until valgrind itself segfaults. Any ideas? Cheers, Zach *** glibc detected *** fgfs: free(): invalid pointer: 0x0885b3e8 *** === Backtrace: = /lib/libc.so.6[0xb6e989e0] /lib/libc.so.6(cfree+0x89)[0xb6e9a6d9] /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6(operator delete(void*)+0x21)[0xb70159a9] fgfs(__gnu_cxx::new_allocator::deallocate(int*, unsigned int)+0x11)[0x823789b] fgfs(std::_Vector_base >::_M_deallocate(int*, unsigned int)+0x27)[0x82378c5] fgfs(std::_Vector_base >::~_Vector_base()+0x36)[0x82378fe] /data/fgfs/local/lib/libosgd.so.26(std::vector >::~vector()+0x60)[0xb7655f06] /data/fgfs/local/lib/libosgd.so.26(osg::VectorGLsizei::~VectorGLsizei()+0x1d)[0xb76c21b5] /data/fgfs/local/lib/libosgd.so.26(osg::DrawArrayLengths::~DrawArrayLengths()+0x30)[0xb76c23b6] fgfs(osg::Referenced::unref() const+0xa9)[0x80a17ff] /data/fgfs/local/lib/libosgTextd.so.26(osg::ref_ptr::~ref_ptr()+0x28)[0xb7e168f2] /data/fgfs/local/lib/libosgTextd.so.26(void std::_Destroy >(osg::ref_ptr*)+0x1d)[0xb7e1691f] /data/fgfs/local/lib/libosgTextd.so.26(void std::__destroy_aux*>(osg::ref_ptr*, osg::ref_ptr*, __false_type)+0x1f)[0xb7e16945] /data/fgfs/local/lib/libosgTextd.so.26(void std::_Destroy*>(osg::ref_ptr*, osg::ref_ptr*)+0x2c)[0xb7e16984] /data/fgfs/local/lib/libosgTextd.so.26(void std::_Destroy*, osg::ref_ptr >(osg::ref_ptr*, osg::ref_ptr*, std::allocator >)+0x24)[0xb7e169ae] /data/fgfs/local/lib/libosgTextd.so.26(std::vector, std::allocator > >::~vector()+0x4b)[0xb7e169ff] /data/fgfs/local/lib/libosgUtild.so.26(osgUtil::Tessellator::~Tessellator()+0x40)[0xb7cd44be] /data/fgfs/local/lib/osgPlugins-2.3.0/osgdb_ac.so(ac3d::SurfaceBin::finalize(ac3d::MaterialData const&, ac3d::TextureData const&)+0xaa7)[0x9728fce7] /data/fgfs/local/lib/osgPlugins-2.3.0/osgdb_ac.so(ac3d::readObject(std::basic_istream >&, ac3d::FileData&, osg::Matrixd const&, ac3d::TextureData)+0x19ae)[0x9728891e] /data/fgfs/local/lib/osgPlugins-2.3.0/osgdb_ac.so(ac3d::readObject(std::basic_istream >&, ac3d::FileData&, osg::Matrixd const&, ac3d::TextureData)+0x29e5)[0x97289955] /data/fgfs/local/lib/osgPlugins-2.3.0/osgdb_ac.so(ac3d::readFile(std::basic_istream >&, osgDB::ReaderWriter::Options const*)+0xb6)[0x97289d86] /data/fgfs/local/lib/osgPlugins-2.3.0/osgdb_ac.so(ReaderWriterAC::readNode(std::basic_istream >&, osgDB::ReaderWriter::Options const*) const+0xd2)[0x97299562] /data/fgfs/local/lib/osgPlugins-2.3.0/osgdb_ac.so(ReaderWriterAC::readNode(std::basic_string, std::allocator > const&, osgDB::ReaderWriter::Options const*) const+0x36a)[0x97296cda] fgfs[0x85962a2] fgfs[0x85994af] fgfs[0x8590020] /data/fgfs/local/lib/libosgDBd.so.26(osgDB::Registry::readNode(std::basic_string, std::allocator > const&, osgDB::ReaderWriter::Options const*)+0x56)[0xb79cad8a] /data/fgfs/local/lib/libosgDBd.so.26(osgDB::readNodeFile(std::basic_string, std::allocator > const&, osgDB::ReaderWriter::Options const*)+0x3e)[0xb79c8cc2] fgfs[0x858db41] fgfs[0x84387c3] fgfs[0x8437e12] fgfs[0x8094c6a] fgfs[0x80dc82b] /data/fgfs/local/lib/libosgViewerd.so.26(osgGA::GUIEventHandler::handleWithCheckAgainstIgnoreHandledEventsMask(osgGA::GUIEventAdapter const&, osgGA::GUIActionAdapter&)+0x75)[0xb7f2e36f] /data/fgfs/local/lib/libosgViewerd.so.26(osgViewer::Viewer::eventTraversal()+0x1269)[0xb7f738e5] /data/fgfs/local/lib/libosgViewerd.so.26(osgViewer::ViewerBase::frame(double)+0x9a)[0xb7f7b660] /data/fgfs/local/lib/libosgViewerd.so.26(osgViewer::ViewerBase::run()+0xe5)[0xb7f7ca71] /data/fgfs/local/lib/libosgViewerd.so.26(osgViewer::Viewer::run()+0xae)[0xb7f74b76] fgfs[0x80e153c] fgfs[0x80945db] fgfs[0x8093766] /lib/libc.so.6(__libc_start_main+0xdc)[0xb6e48fbc] fgfs[0x8093581] === Memory map: 08048000-08782000 r-xp 08:04 9503686/data/fgfs/local/bin/fgfs 08782000-08793000 rw-p 0073a000 08:04 9503686/data/fgfs/local/bin/fgfs 08793000-0d8c rw-p 08793000 00:00 0 [heap] 9640-96421000 rw-p 9640 00:00 0 96421000-9650 ---p 96421000 00:00 0 96584000-96b05000 rw-p 96584000 00:00 0 96c24000-96f27000 rw-p 96c24000 00:00 0 96f27000-96f39000 rw-p a5971000 00:00 0 96f39000-9708f000 rw-s 16957000 00:0e 15430 /dev/dri/card0 9708f000-9719 rw-p 9708f000 00:00 0 97277000-9729e000 r-xp 08:04 9505759 /data/fgfs/local/lib/osgPlugins-2.3.0/osgdb_ac.so 9729e000-9729f000 rw-p 00026000 08:04 9505759 /data/fgfs/local/lib/osgPlug
[Flightgear-devel] OSG and Makefile.am
In src/Main/Makefile.am, OSG_LIBS is set explicitly to -losg, etc. This is not portable with OS X, which uses "-framework osg" (it can also use the -losg style depending on how osg was installed. End users will use the -framework style installation). The following patch demonstrates the problem, but it's not meant for general consumption. It seems that what should be happening instead is an autoconf check for the appropriate libraries. Autoconf is able to find the right flags, whether they be -l or -framework. I'm not an autoconf guru, but I think the magic command is AC_CHECK_LIB(osg, ) and so forth. I'd be willing to write a patch adding AC_CHECK_LIB statements to configure.ac, if someone more familiar with osg will point out a symbol from each library (osgViewer osgGA osgText osgFX osgUtil osgDB osgSim osg OpenThread), so I don't have to ingest the whole OSG API in the process. Index: fgs/src/Main/Makefile.am === --- fgs.orig/src/Main/Makefile.am 2007-12-20 17:39:36.0 -0700 +++ fgs/src/Main/Makefile.am2007-12-20 17:40:09.0 -0700 @@ -29,7 +29,7 @@ if USE_OSGDEBUG OSG_LIBS = -losgViewerd -losgGAd -losgTextd -losgFXd -losgUtild -losgDBd -losgSimd -losgd -lOpenThreadsd else -OSG_LIBS = -losgViewer -losgGA -losgText -losgFX -losgUtil -losgDB -losgSim -losg -lOpenThreads +OSG_LIBS = -framework osgViewer -framework osgGA -framework osgText -framework osgFX -framework osgUtil -framework osgDB -framework osgSim -framework osg -framework OpenThreads endif JSBSIM_LIBS = \ @@ -111,13 +111,14 @@ -lsgstructure -lsgenvironment \ -lplibpuaux -lplibpu -lplibfnt -lplibjs -lplibnet \ -lplibsg -lplibul \ - $(OSG_LIBS) \ $(THREAD_LIBS) \ $(network_LIBS) \ -lz \ $(opengl_LIBS) \ $(openal_LIBS) +fgfs_LDFLAGS = $(OSG_LIBS) + metar_SOURCES = metar_main.cxx metar_LDADD = \ -- Hans Fugal Fugal Computing - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FYI: new Linux nvidia driver 169.07
On Thursday 20 December 2007 22:25, Melchior FRANZ wrote: > * Melchior FRANZ -- Thursday 20 December 2007: > > psychedelic sky, bo105 all black. > > And it looks like this: > > http://members.aon.at/mfranz/lsd.jpg [20.4 kB] > > m. :-) > Cool! ;) LeeE - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FYI: new Linux nvidia driver 169.07
Melchior > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of FRANZ > Sent: 20 December 2007 22:34 > To: flightgear-devel@lists.sourceforge.net > Subject: Re: [Flightgear-devel] FYI: new Linux nvidia driver 169.07 > > > The problem was acknowleged by nVidia for the beta 169.04! > WTF didn't they fix it for the release?! (Ok, ok, some say > that about our bugs ... :-) > > http://www.nvnews.net/vbulletin/showthread.php?t=104363 > > (And no, removing ~/.nvidia-settings-rc doesn't help.) Windows driver is similarly afflicted. Vivian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FYI: new Linux nvidia driver 169.07
Cool. I saw that once on LSD. Melchior FRANZ wrote: * Melchior FRANZ -- Thursday 20 December 2007: psychedelic sky, bo105 all black. And it looks like this: http://members.aon.at/mfranz/lsd.jpg [20.4 kB] m. :-) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bugs with recent CVS HEAD (osg)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 AnMaster wrote: > > Also about 10% of the times I start flightgear I end up starting below terrain > and falling. This should be fixed in CVS. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHavmZeDhWHdXrDRURAijQAJ4ujVYjFweN9Srza6WGfmnnHLuIPgCeKp26 OdhfAg0lnqg3savlrLBK5ug= =HPvU -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] External Cargo, was: Re: screenshots (and "snapshots")
I wrote: > Sent: 19 December 2007 09:17 > To: 'FlightGear developers discussions' > Subject: RE: [Flightgear-devel] External Cargo, was: Re: > screenshots (and "snapshots") > > > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On > > Behalf Of Maik Justus > > Sent: 18 December 2007 23:12 > > To: FlightGear developers discussions > > Subject: Re: [Flightgear-devel] External Cargo, was: Re: > > screenshots (and "snapshots") > > > > > > Hi Viviam, > > Vivian Meazza schrieb am 18.12.2007 23:41: > > > I've just a few moments ago added a few lines of code to > > AIBallistic > > > which apply an external force (using the same math as > > above). The rest > > > works as before. I just need few properties to set the > > magnitude and > > > vector of the external force and it will be done, at least for > > > testing. > > Thank you, very good. Is it possible to pass the forces in the earth > > fixed coordinates axes base? (in Newton or pof)? > > I'm planning, and have tested the passing of the force in > terms of magnitude (pound force), azimuth (degrees, north = > 0) and elevation (degrees, horizontal = 0, up = 90). I hope > this is what you need, and can work with. > > > > It's trivial > > > really, but I'm assuming that the external force applies no > > rotational > > > force to the object. > > I think this could be easily faked. e.g. new_roll = old_roll + > > cos(old_roll) * force_in_y_direction * a_magic_constant * dt > > but i f I read the code correctly, yaw and hdg are pointing > > at the speed > > direction (slightly filtered)? Therefore we need something > > like _elevation = atan2(force_in_z_direction,force_in_x_direction) > > and then your filter to add some inertia? > > Right now there are 2 options - 1, the ballistic object > aligns with the velocity vector (damped), or 2, it remains > static. These options both work with the new code. I think > option 1 will do for an under slung load? > > > > I haven't a great deal of time available in the run up to > > Christmas so > > > no promises on completion. > > > > > Same here. I will have very limited access to my computer (family > > visiting tour). Fortunately my computer is a notebook, but I > > am not sure > > if there is any space in the car for my joystick. > > We have a horde of family visitors over the coming days - all > competing for my time and the computer. We'll see how much > can be done (not a lot I expect). > Christmas has arrived slightly early! I've got something which: A. runs B. looks OK with limited testing The ballistic object aligns with the direction of flight in pitch and heading with an external force applied. It would be possible to align it with the direction of the external force, but I think that would need roll as well. I'm not sure which one would look best. The external force is defined in terms of: Magnitude (lbf) Azimuth (deg, North = O) Elevation (deg, up = 90) In a user-defined property. Of course, some external program needs to set the external force data. This all now needs testing in a more realistic environment. I'm not totally convinced that the ballistic object won't disappear into space/to the centre of the earth, or oscillate like a deranged spring. Vivian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FYI: new Linux nvidia driver 169.07
> - > This SF.net email is sponsored by: Microsoft And can we, please, change our mail provider? :-} m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FYI: new Linux nvidia driver 169.07
Melchior FRANZ schrieb: > * Melchior FRANZ -- Thursday 20 December 2007: > >> psychedelic sky, bo105 all black. >> > > And it looks like this: > > http://members.aon.at/mfranz/lsd.jpg [20.4 kB] > > m. :-) > > - > Maybe a slight lead to some drug abuse at NVIDIA? ;-) Georg - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FYI: new Linux nvidia driver 169.07
The problem was acknowleged by nVidia for the beta 169.04! WTF didn't they fix it for the release?! (Ok, ok, some say that about our bugs ... :-) http://www.nvnews.net/vbulletin/showthread.php?t=104363 (And no, removing ~/.nvidia-settings-rc doesn't help.) m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FYI: new Linux nvidia driver 169.07
* Melchior FRANZ -- Thursday 20 December 2007: > psychedelic sky, bo105 all black. And it looks like this: http://members.aon.at/mfranz/lsd.jpg [20.4 kB] m. :-) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FYI: new Linux nvidia driver 169.07
* Melchior FRANZ -- Thursday 20 December 2007: > But the FlightGear splash screens are now broken! All of them! > Only colorful pattern. And the HUD font. And the "classic" GUI style font (which is a texture font). And the vasi/papi lights! Looks like this is something that needs to be fixed in plib. And OSG. In OSG the drama is even bigger: psychedelic sky, bo105 all black. So it's an nvidia screwup? Need to check their forum ... m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FYI: new Linux nvidia driver 169.07
* Melchior FRANZ -- Thursday 20 December 2007: > Often this isn't something that's worth announcing, but this time > the list of changes sounds interesting: > > http://www.nvidia.com/object/linux_display_ia32_169.07.html [...] > Not that I've tried yet ... And now I have. *The* *horror*! Well, the desktop works nice and all. But the FlightGear splash screens are now broken! All of them! Only colorful pattern. And the HUD font. Not good for a version 1.0! I see a FlightGear v1.1 release on the horizon. But first we need a fix for the disaster. m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] two minor patches
Hi all,
I have attached two minor patches that I have in my CVS tree, which can
be applied against the HEAD of the FlightGear-0.9/source directory.
The patch to the Main/Makefile.am fixes the dependencies to allow
parallel builds ('make -j'). The patch to cvsignore adds photomodel and
removes 3dcovert (which appears to be unreferenced and obsolete).
Cheers,
Zach Welch
Index: src/Main/Makefile.am
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/Makefile.am,v
retrieving revision 1.78
diff -u -p -r1.78 Makefile.am
--- src/Main/Makefile.am7 Dec 2007 09:11:46 - 1.78
+++ src/Main/Makefile.am20 Dec 2007 18:47:16 -
@@ -72,7 +72,7 @@ libMain_a_SOURCES = \
fgfs_SOURCES = bootstrap.cxx
fgfs_LDADD = \
- $(top_builddir)/src/Main/libMain.a \
+ libMain.a \
$(top_builddir)/src/Aircraft/libAircraft.a \
$(top_builddir)/src/ATC/libATC.a \
$(top_builddir)/src/Cockpit/libCockpit.a \
Index: utils/Modeller/.cvsignore
===
RCS file: /var/cvs/FlightGear-0.9/source/utils/Modeller/.cvsignore,v
retrieving revision 1.4
diff -u -p -r1.4 .cvsignore
--- utils/Modeller/.cvsignore 5 Oct 2005 11:53:34 - 1.4
+++ utils/Modeller/.cvsignore 20 Dec 2007 18:47:49 -
@@ -1,7 +1,7 @@
.deps
-3dconvert
Makefile
Makefile.in
animassist
threedconvert
normalmap
+photomodel
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] an important growing trend now in softwareapplications to make them" portable" in the sense that thecomplete installation resides in it's one directory.
On Dec 20, 2007 9:47 AM, Bill Galbraith <> wrote: > > > -- > *From:* [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] *On Behalf Of *Curtis > Olson > *Sent:* Thursday, December 20, 2007 10:43 AM > *To:* FlightGear developers discussions > *Subject:* Re: [Flightgear-devel] an important growing trend now in > softwareapplications to make them" portable" in the sense that thecomplete > installation resides in it's one directory. > > On Dec 20, 2007 1:20 AM, GWMobile <> wrote: > > > There is an important growing trend now in software applications to make > > > > them" portable" in the sense that the complete installation resides in > > it's one directory. > > > > > I was able to burn this onto a CD, and run it from that, so I don't know > what the problem is. > Hehe, it's just MicroSoft discovering yet again (after 30, err 40 years) that the way Unix has always done things has always been best. :-) Memory management, Process scheduling, Security, Networking, now Software Installation ... :-) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] an important growing trend now in softwareapplications to make them" portable" in the sense that thecomplete installation resides in it's one directory.
_ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curtis Olson Sent: Thursday, December 20, 2007 10:43 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] an important growing trend now in softwareapplications to make them" portable" in the sense that thecomplete installation resides in it's one directory. On Dec 20, 2007 1:20 AM, GWMobile <> wrote: There is an important growing trend now in software applications to make them" portable" in the sense that the complete installation resides in it's one directory. I was able to burn this onto a CD, and run it from that, so I don't know what the problem is. Bill - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] an important growing trend now in software applications to make them" portable" in the sense that the complete installation resides in it's one directory.
On Dec 20, 2007 1:20 AM, GWMobile <> wrote: > There is an important growing trend now in software applications to make > them" portable" in the sense that the complete installation resides in > it's one directory. The "core" FlightGear code has always been setup to be relocatable and containable within a single directory tree. We do support a ~/.fgfsrc file for unix folks, but that isn't required. I don't know all the specifics of "fgrun", I believe that it writes some persistent state info to your home directory, but I don't know if that can be relocated or avoided? We have always tried to maintain a flexible balance with our installation and location capabilities so an end user could compile/install FlightGear in their own area, or a system adminstrator could install flightgear system or network wide so it is available for all users on a computer or within an organization. I do think we still need to keep moving towards user friendliness. FlightGear started out as a command line app, not as a gui app, so the result has been a bit clunky for people that are used to slick platform specific user interfaces. But at the same time, we have tried to create a widely portable system which means we need to seek a least common denominator in gui capabilities ... a trade off between portability and a pretty gui ... Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] repeatable keys
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Indeed AltGr is broken with SDL last I tried (Swedish keyboard here) so I recommend glut in that case until the osgviewer input works nicely. Regards, Arvid Norlander Cédric Lucantis wrote: > Hi, > I'd like to know if the 'repeatable' flag in the key bindings is supposed to work ? >>> Yes, but only with SDL. It does (AFAIK) not yet work with >>> osgViewer, and it will probably never work with glut. >> ok it works, thanks for the tip, but now I have a bigger problem ;) >> It concerns keys using the alt-gr modifier (and sometimes some other >> modifiers) : when not repeatable, those only work the first time you >> press them and then get 'stuck' and never work again. > > hum, sorry to insist, but am I the only one to have this problem ? > Doesn't sound like a trivial bug... I'm using SDL now and with all > default settings (and a french keyboard) many of my flight commands are > just unusable (maybe this does not happen with us/uk keyboard as these > don't have so many non-ascii keys? Do they have an alt-gr modifier?) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHanzkWmK6ng/aMNkRConUAJ4yNeBmw/+8LVQA6xuGN4gxoh9xeQCbBlme vQwejcnYYEPsLGxgmQ2rEsE= =H+PO -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot filters upset after reloading autopilot
On Thursday 20 December 2007 11:21, LeeE wrote: > On Thursday 20 December 2007 10:53, Roy Vegard Ovesen wrote: > > On Tuesday 18 December 2007, LeeE wrote: > > > Hi all, > > > > > > I've noticed recently that after re-loading an autopilot the > > > filters that are being used seem to be getting a bit > > > 'confused'. I spotted it when I was comparing the unfiltered > > > input with the filtered output and saw that the input was > > > stable to 2 decimal places but the filtered output seemed to > > > be oscillating very quickly up to the first decimal place. > > > > > > I don't know if this happens with all filter types - all the > > > ones I've been using are noise-spike types. > > > > I've seen something similar after I added an option > > to the filters on my local branch. Whenever I enable a filter > > by setting some property to true (just like enabling PID > > controllers), I see the output from the filter, wich is > > connected to the control surface, makes the plane do some wild > > flying. > > > > I believe that I need to add some initialization code to the > > filters so that they behave nicely when they are enabled. I'm > > working on this. > > > > Also I'll remove the build() call in reinit() inless there is a > > good reason for calling build() twice. > > Doh! - It's only just occurred to me that we could use the > logging facility to log the output from controllers and filters > and analyse the results 'off-line' so to speak. Should be > trivial to import the results into a spreadsheet and plot graphs > - it'll only take a little bit of effort to set up the logging > details - I'll try this when I get a chance. > > LeeE got some data in a .csv - attached. TGT-PITCH-DEG is the input and TGT-PITCH-DEGF is the output from the filter. The sampling interval was set to 50 ms - in practice it's not as regular as that though. I imported it in to OO Calc to plot it and it seems to show that the filtered output isn't crossing the input but is sort of 'bouncing' off of it. The input _is_ varying in synch with the filtered output but I suspect that this is because the controller, which generates the target-pitch, is responding to the consequences of the 'bounces' in the filtered output, which was driving the elevator. In any case, it seems to show that the filtered output is varying much more than the input, which shouldn't be the case - the noise-spike filter should only limit the rate between the input variation levels, not exceed them. Interestingly, this is only happens when there is some variation in the input - if you switch off the controller that generates the input, or cause it to max out, the filter settles down and stabilises - the input needs to be varying a little bit for the problem to appear. LeeE Time,TGT-PITCH-DEG,TGT-PITCH-DEGF 915.942,1.33209,1.431093073 915.992,1.33209,1.332092643 916.033,1.33387,1.333867431 916.1,1.33419,1.500534097 916.133,1.33419,1.367200764 916.183,1.33655,1.433867431 916.408,1.3329,1.989651442 916.408,1.3329,1.989651442 916.408,1.3329,1.989651442 916.408,1.3329,1.989651442 916.442,1.3329,1.856318108 916.483,1.34099,1.889651442 916.542,1.33116,1.789651442 916.583,1.33116,1.622984775 916.65,1.31422,1.556318108 916.692,1.29495,1.589651442 916.733,1.28033,1.556318108 916.8,1.26023,1.489651442 916.842,1.26023,1.322984775 916.883,1.24673,1.356318108 916.95,1.24201,1.242008686 916.983,1.23672,1.308675353 917.033,1.23672,1.236724138 917.092,1.23537,1.235374451 917.133,1.24104,1.268707784 917.2,1.24955,1.249554515 917.233,1.25641,1.316221182 917.3,1.26561,1.356407261 917.342,1.26561,1.265610218 917.383,1.27426,1.298943551 917.45,1.27787,1.277867556 917.483,1.28017,1.344534222 917.55,1.28304,1.380168176 917.592,1.28304,1.283035755 917.633,1.2831,1.283098459 917.7,1.28233,1.283098459 917.742,1.28149,1.38274 917.783,1.28149,1.281490803 917.842,1.27937,1.279367566 917.883,1.27661,1.276611328 917.942,1.27424,1.509944661 917.983,1.27424,1.343277995 918.05,1.27818,1.278181434 918.092,1.27493,1.311514767 918.133,1.2723,1.341598574 918.183,1.2723,1.272304296 918.25,1.26944,1.269443274 918.292,1.27064,1.270636916 918.333,1.27033,1.337303583 918.383,1.27033,1.270326734 918.442,1.27173,1.271729112 918.483,1.27347,1.273471713 918.683,1.28299,1.939923286 918.683,1.28299,1.939923286 918.683,1.28299,1.939923286 918.683,1.28299,1.939923286 918.733,1.28299,1.739923286 918.783,1.29474,1.739923286 918.85,1.28841,1.606589953 918.892,1.27263,1.639923286 918.933,1.27263,1.47325662 918.992,1.25483,1.439923286 919.042,1.24046,1.439923286 919.083,1.22354,1.47325662 919.142,1.21445,1.439923286 919.183,1.21445,1.27325662 919.242,1.20351,1.239923286 919.292,1.20087,1.239923286 919.35,1.19963,1.199625731 919.392,1.19926,1.299625731 919.433,1.19926,1.199256182 919.483,1.20634,1.265922848 919.55,1.21445,1.214454889 919.592,1.22125,1.314454889 919.8,1.24697,1.904868126 919.8,1.24697,1.904868126 919.8,1.24697,1.904868126 919.8,1.24697,1.904868126 919.833,1.24697,1.771534793
Re: [Flightgear-devel] repeatable keys
Hi, > > > I'd like to know if the 'repeatable' flag in the key bindings is > > > supposed to work ? > > > > Yes, but only with SDL. It does (AFAIK) not yet work with > > osgViewer, and it will probably never work with glut. > > ok it works, thanks for the tip, but now I have a bigger problem ;) > It concerns keys using the alt-gr modifier (and sometimes some other > modifiers) : when not repeatable, those only work the first time you > press them and then get 'stuck' and never work again. hum, sorry to insist, but am I the only one to have this problem ? Doesn't sound like a trivial bug... I'm using SDL now and with all default settings (and a french keyboard) many of my flight commands are just unusable (maybe this does not happen with us/uk keyboard as these don't have so many non-ascii keys? Do they have an alt-gr modifier?) thanks, -- Cédric Lucantis - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance issues in Win32
LeeE wrote: > On Thursday 20 December 2007 01:07, Shad Young wrote: > >> Hi all, >> >> Again not sure if I should post this to the users list. >> >> I have been experimenting with the latest FG 1.0.0 on Win32 (XP >> SP2) and am having some rather significant frame dropping. >> >> FPS on or near the ground at San Fran in all AC often results in >> long pauses and jumps, with regular stutters. FPS are all over >> the map, from 60fps to 1 frame every couple of seconds. >> >> I am using a Dual Core FX60, 2 Gig DDR, with an NV8800GTX. >> >> Are there specific tweaks that can be made, or are there some >> settings that should be turned off? I have tried to reset to >> default but then FG launcher seems to crash. >> >> I tried to remove FG using the uninstall program and then >> cleaning out the registry, deleting the folder etc, but it seems >> to be keeping the settings that I had with FG 0.9.10 (is there an >> INI somewhere other than in the FG folder in Program Files?) >> >> TIA >> Shad >> > > Are you getting this at KSFO? It takes nearly a minute after > starting FG at KSFO for my system to settle down into a stable > frame-rate due to all the models being loaded. During this time I > see the same wide variations in frame-rate as you - 60~1 fps. > > Do you get the same results if you start at a much simpler airport > some distance away from KSFO? > > LeeE > > I have not yet installed any additional scenery, so I can not get very far from KSFO but I did try at a smaller airport. I did not seem to make a difference at a smaller airport within the base package. I turned off all optional features such as AI and random objects, but this seemed to have no effect. So far the only thing that has a small effect is running it in a window at 1280x1024 @16bit. But there is still the occasional pause and stutter. Reading the threads in the User List, there was a suggestion by Stuart that I may need to be 500nm away, so I will add some scenery far away and see how that goes. Thanks Shad - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance issues in Win32
Frederic Bouvier wrote: > Selon Shad Young : > > I tried to remove FG using the uninstall program and then cleaning out the registry, deleting the folder etc, but it seems to be keeping the settings that I had with FG 0.9.10 (is there an INI somewhere other than in the FG folder in Program Files?) >> Ok, I found the solution to one problem. The uninstall leaves the >> flightgear.org folder in Application Data within Documents and Settings. >> Manually deleting this is necessary for a clean re-install. >> > > There is also de "Default" button to come back to default settings > > -Fred > > Hi Fred, thanks for the reply. Sadly, clicking on the Default button causes the launcher to crash. But I found the hidden folder in "Application Data". Deleting it brought me back to defaults. Cheers Shad - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGCOM bug: Call rejected by remote
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Holger Wirtz wrote: > Hi, > > after thinking about this feature I recognized that there are some > problems: > > Real radio has a limited range. So you can use the same frequency at > every point on the world. If you can hear someone on the same frequency > depends on how much power his transmitter has (and some other physical > rules) and/or how far away he is and so on. But with the normal radio > in a plane (or on ground) you cannot reach the whole world. And radio > communication is a broadcast media. > > Now try to solve this with unicast media (such as VoIP). Without > information about the coords of each member you cannot decide "how far > away" you can be heared by other users. > > I have tried to fix this problem by using one well known coordinate (the > one of the tower) and the next one of the plane - and a limited range. > fgcom calculates which airport is most nearby your selected frequency. > With the coords of this airport it can calculate how far away fgcom is > and it can drop the line if it is out of range. > > The ideal algorithm would be some kind of conference server which gets > the frequency it is responsible for, the voice streams _and_ the coords > of all members on this frequency. With this data the stream for _each_ > member can be mixed up (far away = quite) and send it towards each > client. > > The problem is: that has not much to do with VoIP - so you havn't any > features of VoIP and no implementations for server and client. Feel free > to do so :-) > > Perhaps someone can extend the IAX2 protocol and write a new > app_meetme.so for Asterisk which ca realise this. But I think it is not > really neccessary at this time. I could not do it in C or C++ but I might be able in, lets say, C#. though currently I working on too many other open source things, both related to flightgear and other things, to have time. Regards, Arvid Norlander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHam5UWmK6ng/aMNkRCveyAJ9bVJkhOgJKBmUCVnOrr2C2CPWicACfQljg P757L0tDt+Wi3JUgtkx5kYE= =vp1/ -END PGP SIGNATURE- - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGCOM bug: Call rejected by remote
Hi, after thinking about this feature I recognized that there are some problems: Real radio has a limited range. So you can use the same frequency at every point on the world. If you can hear someone on the same frequency depends on how much power his transmitter has (and some other physical rules) and/or how far away he is and so on. But with the normal radio in a plane (or on ground) you cannot reach the whole world. And radio communication is a broadcast media. Now try to solve this with unicast media (such as VoIP). Without information about the coords of each member you cannot decide "how far away" you can be heared by other users. I have tried to fix this problem by using one well known coordinate (the one of the tower) and the next one of the plane - and a limited range. fgcom calculates which airport is most nearby your selected frequency. With the coords of this airport it can calculate how far away fgcom is and it can drop the line if it is out of range. The ideal algorithm would be some kind of conference server which gets the frequency it is responsible for, the voice streams _and_ the coords of all members on this frequency. With this data the stream for _each_ member can be mixed up (far away = quite) and send it towards each client. The problem is: that has not much to do with VoIP - so you havn't any features of VoIP and no implementations for server and client. Feel free to do so :-) Perhaps someone can extend the IAX2 protocol and write a new app_meetme.so for Asterisk which ca realise this. But I think it is not really neccessary at this time. Regards, Holger On Tue, Dec 18, 2007 at 07:47:59PM +0100, AnMaster wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > So when will this be fixed. Considering the type of flights I normally make I > really need this feature. For example I was planning cross atlantic flight > with > in air refueling over mp using fgcom but until this BUG is fixed that is not > possible. Because I consider it a bug. > > Regards, > > Arvid Norlander > > Csaba Halász wrote: > > On Dec 18, 2007 5:36 PM, AnMaster <[EMAIL PROTECTED]> wrote: > >> When I select a frequency that is not a tower freq for any nearby airport I > >> always get "Call rejected by remote". That is wrong, I should be able to > >> use any > >> frequency anywhere and talk to any aircraft within range. There is no > >> airport > >> out over the Atlantic for example. There are a lot of places with no > >> airport in > >> range, yet I should be able to talk to other aircrafts within range of my > >> radio, > >> and only those. > > > > Yes, the design of fgcom doesn't support that at the moment. That is > > not a bug, but a limitation. > > Currently fgcom is mostly usable for fixed position ATC. > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.7 (GNU/Linux) > > iD8DBQFHaBXeWmK6ng/aMNkRClI+AJ0eun88BJ0d9zibWuq5ufPgJzAhigCghW0/ > XaoTLP9Ihy9rV62mF/EWLoY= > =4Y/J > -END PGP SIGNATURE- > > - > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services > for just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- # ## ## Holger Wirtz Phone : (+49 30) 884299-40 ## ## ## ### ## DFN-Verein Fax : (+49 30) 884299-70 ## ## ## Stresemannstr. 78E-Mail: [EMAIL PROTECTED] ## ## ## ## ### 10963 Berlin # ## ## ## GERMANY WWW : http://www.dfn.de GPG-Fingerprint: ABFA 1F51 DD8D 503C 85DC 0C51 E961 79E2 6685 9BCF - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3-Dimensional forests.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I tried doing this but I couldn't get it to work. How do you "set a trace with it"? Regards, Arvid Norlander Melchior FRANZ wrote: > * Georg Vollnhals -- Wednesday 19 December 2007: >> You asked on the FG forum for driving cars. I made an example a long >> time ago with a driving truck on the EDDW airport. > > BTW: the ufo does since a while export flightplans. You just > select an arbitrary object, set a trace with it, and press > the 'n'-key. Final adjustments have to be done manually, of > course. Setting a snowplow route with that should be a matter > of minutes. :-) > > m. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHalx+WmK6ng/aMNkRCqi/AJ9XNeyjc9JLfRbxEP9TnrKEbV+H/QCfRD+X sKtJzX0xvGHeNFCgf1tzs9w= =/fsE -END PGP SIGNATURE- - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot filters upset after reloading autopilot
On Thursday 20 December 2007 10:53, Roy Vegard Ovesen wrote: > On Tuesday 18 December 2007, LeeE wrote: > > Hi all, > > > > I've noticed recently that after re-loading an autopilot the > > filters that are being used seem to be getting a bit > > 'confused'. I spotted it when I was comparing the unfiltered > > input with the filtered output and saw that the input was > > stable to 2 decimal places but the filtered output seemed to be > > oscillating very quickly up to the first decimal place. > > > > I don't know if this happens with all filter types - all the > > ones I've been using are noise-spike types. > > I've seen something similar after I added an option to > the filters on my local branch. Whenever I enable a filter by > setting some property to true (just like enabling PID > controllers), I see the output from the filter, wich is connected > to the control surface, makes the plane do some wild flying. > > I believe that I need to add some initialization code to the > filters so that they behave nicely when they are enabled. I'm > working on this. > > Also I'll remove the build() call in reinit() inless there is a > good reason for calling build() twice. Doh! - It's only just occurred to me that we could use the logging facility to log the output from controllers and filters and analyse the results 'off-line' so to speak. Should be trivial to import the results into a spreadsheet and plot graphs - it'll only take a little bit of effort to set up the logging details - I'll try this when I get a chance. LeeE - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot filters upset after reloading autopilot
On Tuesday 18 December 2007, LeeE wrote: > Hi all, > > I've noticed recently that after re-loading an autopilot the filters > that are being used seem to be getting a bit 'confused'. I spotted > it when I was comparing the unfiltered input with the filtered > output and saw that the input was stable to 2 decimal places but > the filtered output seemed to be oscillating very quickly up to the > first decimal place. > > I don't know if this happens with all filter types - all the ones > I've been using are noise-spike types. I've seen something similar after I added an option to the filters on my local branch. Whenever I enable a filter by setting some property to true (just like enabling PID controllers), I see the output from the filter, wich is connected to the control surface, makes the plane do some wild flying. I believe that I need to add some initialization code to the filters so that they behave nicely when they are enabled. I'm working on this. Also I'll remove the build() call in reinit() inless there is a good reason for calling build() twice. -- Roy Vegard Ovesen - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance issues in Win32
On Thursday 20 December 2007 01:07, Shad Young wrote: > Hi all, > > Again not sure if I should post this to the users list. > > I have been experimenting with the latest FG 1.0.0 on Win32 (XP > SP2) and am having some rather significant frame dropping. > > FPS on or near the ground at San Fran in all AC often results in > long pauses and jumps, with regular stutters. FPS are all over > the map, from 60fps to 1 frame every couple of seconds. > > I am using a Dual Core FX60, 2 Gig DDR, with an NV8800GTX. > > Are there specific tweaks that can be made, or are there some > settings that should be turned off? I have tried to reset to > default but then FG launcher seems to crash. > > I tried to remove FG using the uninstall program and then > cleaning out the registry, deleting the folder etc, but it seems > to be keeping the settings that I had with FG 0.9.10 (is there an > INI somewhere other than in the FG folder in Program Files?) > > TIA > Shad Are you getting this at KSFO? It takes nearly a minute after starting FG at KSFO for my system to settle down into a stable frame-rate due to all the models being loaded. During this time I see the same wide variations in frame-rate as you - 60~1 fps. Do you get the same results if you start at a much simpler airport some distance away from KSFO? LeeE - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot filters upset after reloading autopilot
On Wednesday 19 December 2007 16:38, Tiago Gusmão wrote: > LeeE wrote: > > On Wednesday 19 December 2007 12:56, Tiago Gusmão wrote: > >> LeeE wrote: > >>> On Tuesday 18 December 2007 22:52, Tiago Gusmão wrote: > LeeE wrote: > > Hi all, > > > > I've noticed recently that after re-loading an autopilot > > the filters that are being used seem to be getting a bit > > 'confused'. I spotted it when I was comparing the > > unfiltered input with the filtered output and saw that the > > input was stable to 2 decimal places but the filtered > > output seemed to be oscillating very quickly up to the > > first decimal place. > > > > I don't know if this happens with all filter types - all > > the ones I've been using are noise-spike types. > > > > LeeE > > Are you sure it's oscillating instead of just catching up > with the current input? anyway, you can try to enable debug > on that filter and show us some values. > > In the meantime i've had my own problem with the AP (now > solved, don't use alpha=0 or you will get a NaN that will > bring FG to a halt if tied to the controls) > but i found some things that don't make much sense to me > > xmlauto.cxx, line 798, FGXMLAutopilot::reinit: > > -why is build() called there? it's already called inside > init() > > -maybe my C++ is a little forgotten, but don't we need to > delete the objects contained in components() ? > > Cheers, > Tiago > >>> > >>> Hi Tiago, > >>> > >>> I'm not absolutely sure it's oscillating - it's changing too > >>> fast to actually see the numbers to be sure - but the visual > >>> pattern - that is, the apparent 'shape' that you can see > >>> suggests it is rapidly switching between two values, which > >>> change more slowly, over time, as the input changes. > >>> > >>> Like I said, I compared the un-filtered input with the > >>> filtered output and while the input could be stable to 2 > >>> decimal places the filtered output could be changing at the > >>> first decimal place i.e. the output was varying more than the > >>> input by a factor of up to 100, so it's not a case of the > >>> filter trying to catch up. > >>> > >>> The effect is that it is oscillating because it's vastly > >>> overshooting it's target in both directions. > >>> > >>> LeeE > >> > >> I wasn't able to reproduce, i tried with > >> > >> > >> test filter > >> true > >> noise-spike > >> /controls/flight/elevator > >> /controls/flight/filtered-elevator > >> 0.1 > >> > >> > >> > >> Also my "paper simulations" seemed ok. > >> > >> Could you post your filter? > >> > >> Anyway, the current behavior of resetting the filtered output > >> to zero doesn't seem very good, i think starting at the > >> current input would be best. > >> > >> > >> > >> Cheers, > >> Tiago > > > > Hi Tiago, > > > > have a look at the 'Target Pitch Filter' in the BAC-TSR2 > > autopilot - I saw the problem with that filter. The filename > > is: > > Aircraft/BAC-TSR2/Systems/BAC-TSR2-autopilot.xml > > > > LeeE > > I've tested it and it seems the input oscillates and can even > change sign very briefly, you need to pause right after reloading > the AP to be able to spot it. Because the filtered output will > restart at zero, it will be able to quickly go negative and then > will take quite some time to return to normal values. So while > this is AP's fault, it's not because of the filter. > > Anyway, AP reloading isn't something we expect users to mess > with, so i wouldn't bother much with it. > > And from what i've seen in the code, reloading is reliable in the > sense that it really creates new instances of the objects, so > there are no stale values. > > BTW, it was really nice to see the TSR2 fly KSFO -> KSCK over > those hills, good work :) > > Cheers, > Tiago Hi Tiago, thanks for looking into it. On the TSR2 some of the controllers are very 'tightly' tuned and close to oscillating, and can become unstable at very high speeds. This is largely a nature-of-the-beast type problem - it's a relatively high mass aircraft with small wings and with the elevators(elevons) set close to the wing, giving a small moment arm. At the same time though, they need a lot of authority. The way to get around that would be to run the controllers at a higher rate, which would give them a higher resolution, but I decided to peg them all at 20Hz so that they would work on relatively modest h/w. The controllers are therefore very sensitive and can 'kick', hence the use of filters. Now that I know about the problem, and it really is only a problem while you're tuning the controllers, I know what to look out for. Heh - I first spotted it while I was tuning controllers, which means that you end up re-loading the autopilot a lot, and I spent a long time trying to tune the oscillations out before I noticed that the
