Re: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
* Jon Berndt -- Monday 30 May 2005 00:26: Melchior FRANZ wrote: When you fly over a beacon, the ground cache has to eat all these triangles, which makes the FDM stutter or even hang. Is the ground cache for the benefit of the FDM? The FDMs are currently the only users of the groundcache, and yes, they benefit from it. A lot. Per-wheel/contact-point ground awareness hadn't been done before Mathias implemented the ground cache. And probably it would have been a big performance problem to constantly do intersection test with the whole tile. Still, I didn't mean to blame the problems on the FDMs. I just called it FDM stuttering because this is what the user sees (and because the ground-cache code is in the FDM/ directory :-) But the FDM only stuttered, because it wasn't called in time, because of unfortunate groundcache/beacon interaction. And that wasn't really a bug, either. Neither in the beacon, nor in the ground cache. Just a detail that had to be tuned for better performance. :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
Still, I didn't mean to blame the problems on the FDMs. I just called it FDM stuttering because this is what the user sees (and because the ground-cache code is in the FDM/ directory :-) But the FDM only stuttered, because it wasn't called in time, because of unfortunate groundcache/beacon interaction. The groundcache/beacon interaction was only effecting the Yasim FDM, correct? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
* Dave Culp -- Monday 30 May 2005 09:27: The groundcache/beacon interaction was only effecting the Yasim FDM, correct? I've only tested it with YASim (bo105, b1900d) where I saw it before, but not after fixing it. I can't say if it happened with JSBSim, although I use both regularly. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FGFS final link fails: _imp__pthread symbols not found
I've tried compiling fgfs from cvs on mingw again. There are various little changes which I'll roll up at some point (as in, when it's working ;). However, there's an odd problem I'm getting at final link: g++ -DPKGLIBDIR=\/point/share/FlightGear\ -g -O2 -D_REENTRANT -L/point/lib -o fgfs.exe bootstrap.o ../../src/Main/libMain.a ../../src/Aircraft/libAircraft.a ../../src/ATC/libATC.a ../../src/Cockpit/libCockpit.a ../../src/Cockpit/built_i n/libBuilt_in.a ../../src/Controls/libControls.a ../../src/FDM/libFlight.a ../.. /src/FDM/Balloon/libBalloon.a ../../src/FDM/ExternalNet/libExternalNet.a ../../s rc/FDM/ExternalPipe/libExternalPipe.a ../../src/FDM/JSBSim/libJSBSim.a ../../src /FDM/YASim/libYASim.a ../../src/FDM/JSBSim/filtersjb/libfiltersjb.a ../../src/FD M/LaRCsim/libLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a ../../src/FDM/SP/l ibSPFDM.a ../../src/GUI/libGUI.a ../../src/Autopilot/libAutopilot.a ../../src/In put/libInput.a ../../src/Instrumentation/libInstrumentation.a ../../src/Model/li bModel.a ../../src/AIModel/libAIModel.a ../../src/Network/libNetwork.a ../../src /Navaids/libNavaids.a ../../src/Scenery/libScenery.a ../../src/Scripting/libScri pting.a ../../src/Sound/libSound.a ../../src/Airports/libAirports.a ../../src/R eplay/libReplay.a ../../src/Systems/libSystems.a ../../src/Time/libTime.a ../../ src/Traffic/libTraffic.a ../../src/Environment/libEnvironment.a -lsgclouds3d -lsgroute -lsgsky -lsgsound -lsgephem -lsgmaterial -lsgtgdb -lsgmodel -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgprops -lsgdebug -lsgmagvar -lsgmisc -lsgnasal -lsgxml -lsgsound -lsgserial -lsgstructure -lsgenvironment -lsgthreads -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul -lz -lglut32 -lglu32 -lopengl32 -luser32 -lgdi32 -lALut -lopenal32 -lws2_32 -lwinmm -ldsound -ldxguid -lole32 Warning: .drectve `-defaultlib:uuid.lib ' unrecognized Warning: .drectve `-defaultlib:uuid.lib ' unrecognized ../../src/Scenery/libScenery.a(tilemgr.o)(.text+0xb7a): In function `ZN9FGTileMgr16all_queues_emptyEv': C:/msys/1.0/point/include/simgear/threads/SGThread.hxx:232: undefined reference to `_imp__pthread_mutex_lock' ../../src/Scenery/libScenery.a(tilemgr.o)(.text+0xb9e):C:/msys/1.0/point/include/simgear/threads/SGThread.hxx:238: undefined reference to `_imp__pthread_mutex_unlock' This continues for many screens (and for many other calls - it's not just mutex related). The error is the same whether or not I add -lpthread to the command. Investigating the pthread library, all the calls are present in the form _pthread (_pthread_mutex_lock, _pthread_mutex_unlock, _pthread_cond_destroy etc), but none with the _imp_ prefix. gcc 3.4.2 (mingw-special) with win32 thread model. Does anybody have any ideas about what is going wrong? Giles Robertson PS: Apologies for the html email. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RC aircraft + ground view
Lee Elliott wrote: On Monday 30 May 2005 01:02, Sam Heyman wrote: I have finished implementing an RC UAV (2.2m span) and am now trying to create a new view, that corresponds to the guy standing next to the runway, near the plane. Is there an existing view I can use and edit, or do I have to start from scratch? I have read through quite a lot of the past threads and didn't get much information. Thanks for your help, Sam Curious - I replied to this on the FDM list - just checked the msg in my 'Sent' box but it's not come back to me yet. Oh well, computers eh? Anyway... The A-10s have what I've called a 'Drop' view. It's an additional lookat view where the view location can be 'dropped' behind the aircraft. Look in the A-10cl-set.xml or A-10fl-set.xml files for the setup. I also played with a similar Ground Observer view by using the altitude and altitude-agl values in the property tree, together with some basic Nasal, to position the view position 2m above the ground immediately below the aircraft. However, I had some problems with the near-plane clipping and didn't progress with it. Hi Lee, Yes I remember, you aswered my question on the FDM list. I was told however that the FDM list was not the right list for this question and so I asked it again on the devel list. I am in the middle of exams just now so I am not working on the simulator much Just one question though, what is Nasal? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel]Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
Is the ground cache for the benefit of the FDM? The FDMs are currently the only users of the groundcache, and yes, they benefit from it. A lot. Per-wheel/contact-point ground awareness hadn't been done before Mathias implemented the ground cache. And probably it would have been a big performance problem to constantly do intersection test with the whole tile. Still, I didn't mean to blame the problems on the FDMs. I just What I was curious about was if per-wheel contact point checking was being done when it doesn't need to be done - that is, when the aircraft isn't even close to the ground? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RC aircraft + ground view
Citeren Sam Heyman [EMAIL PROTECTED]: Lee Elliott wrote: On Monday 30 May 2005 01:02, Sam Heyman wrote: I have finished implementing an RC UAV (2.2m span) and am now trying to create a new view, that corresponds to the guy standing next to the runway, near the plane. snip Hi Lee, Yes I remember, you aswered my question on the FDM list. I was told however that the FDM list was not the right list for this question and so I asked it again on the devel list. I am in the middle of exams just now so I am not working on the simulator much Just one question though, what is Nasal? Nasal is Flightgear's scripting language. It's like Python for the Fly!-simulator. Greets, Steven PS: good luck with the exams. Mine start within 2 weeks so I'm pretty busy preparing for them :-). ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel]Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
Jon Berndt wrote: Is the ground cache for the benefit of the FDM? The FDMs are currently the only users of the groundcache, and yes, they benefit from it. A lot. Per-wheel/contact-point ground awareness hadn't been done before Mathias implemented the ground cache. And probably it would have been a big performance problem to constantly do intersection test with the whole tile. Still, I didn't mean to blame the problems on the FDMs. I just What I was curious about was if per-wheel contact point checking was being done when it doesn't need to be done - that is, when the aircraft isn't even close to the ground? I'm not certain the area that the ground cache covers, but I suspect it has applications beyond just contact points. ISTR Lee was wanting to know ground elevation a distance ahead of the aircraft for the terrain following mode of the TSR2s autopilot - could this be used? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Problems with todays CVS
I've just updated and built todays CVS code, discovered a problem. Starting on runway 09 at EGNM with the default cessna the sim freezes a couple of seconds after the aircraft starts rolling. I don't think it's even travelled its own length. Menus are all still fully operational, and shift-esc puts the aircraft back on the end of the runway where the whole thing can be repeated - same freeze every time. Repeating this on runway 24 at EGXG exhibits exactly the same problem. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] OpenAL for CygWin
I'm finally getting around to reinstalling FlightGear after a hard drive crash a couple months ago. I have this as a place to get OpenAL for Cygwin: http://www.vso.cape.com/~nhv/files/fgfs/openal.tgz Is this still the latest/best dist? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] OpenAL for CygWin
Jon Berndt wrote: I'm finally getting around to reinstalling FlightGear after a hard drive crash a couple months ago. I have this as a place to get OpenAL for Cygwin: http://www.vso.cape.com/~nhv/files/fgfs/openal.tgz Is this still the latest/best dist? Try this version: ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/openal_cyg.tgz Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] OpenAL for CygWin
Vivian Meazza writes: Jon Berndt wrote: I'm finally getting around to reinstalling FlightGear after a hard drive crash a couple months ago. I have this as a place to get OpenAL for Cygwin: http://www.vso.cape.com/~nhv/files/fgfs/openal.tgz Is this still the latest/best dist? I no longer have that file on my site Please delete any links to it and use this one instead Try this version: ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/openal_cyg.tgz Thanks Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems with todays CVS
Giles Robertson wrote: See the same thing with CVS at KSFO this morning (but thought it was a local problem). Higher logging levels produce our well-known and well-loved no scenery below the aircraft ground cache message. I've just updated and built todays CVS code, discovered a problem. Starting on runway 09 at EGNM with the default cessna the sim freezes a couple of seconds after the aircraft starts rolling. I don't think it's I don't get it, I didn't see this behavior until after I committed the patches, when I noticed it once. Melchior has these patches also applied and didn't complain. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Problems with todays CVS
* Erik Hofman -- Monday 30 May 2005 18:22: I don't get it, I didn't see this behavior until after I committed the patches, when I noticed it once. Melchior has these patches also applied and didn't complain. And I first saw it when I tried to reproduce Jon's problem. Which worked. Seems like I do really somehow prefer YASim, at least always if I try to test stuff. (The bo105 may have to do with it.) YASim works. Only JSBSim doesn't. :-( m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems with todays CVS
well-loved no scenery below the aircraft ground cache message. I don't get it, I didn't see this behavior until after I committed the patches, when I noticed it once. Melchior has these patches also applied and didn't complain. Maybe this is something to do with OS, compiler, or video card? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems with todays CVS
Dave Culp wrote: well-loved no scenery below the aircraft ground cache message. I don't get it, I didn't see this behavior until after I committed the patches, when I noticed it once. Melchior has these patches also applied and didn't complain. Maybe this is something to do with OS, compiler, or video card? Slackware 10.0 gcc-3.3.4 nvidia fx5200 What's everyone else using? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FGFS final link fails: _imp__pthread symbols not found
Giles Robertson wrote: I've tried compiling fgfs from cvs on mingw again. There are various little changes which I'll roll up at some point (as in, when it's working ;). However, there's an odd problem I'm getting at final link: g++ -DPKGLIBDIR=\/point/share/FlightGear\ -g -O2 -D_REENTRANT -L/point/lib -o C:/msys/1.0/point/include/simgear/threads/SGThread.hxx:232: undefined reference to `_imp__pthread_mutex_lock' ../../src/Scenery/libScenery.a(tilemgr.o)(.text+0xb9e):C:/msys/1.0/point/include/simgear/threads/SGThread.hxx:238: undefined reference to `_imp__pthread_mutex_unlock' This continues for many screens (and for many other calls - it's not just mutex related). The error is the same whether or not I add -lpthread to the command. Investigating the pthread library, all the calls are present in the form _pthread (_pthread_mutex_lock, _pthread_mutex_unlock, _pthread_cond_destroy etc), but none with the _imp_ prefix. gcc 3.4.2 (mingw-special) with win32 thread model. Does anybody have any ideas about what is going wrong? Giles Robertson PS: Apologies for the html email. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I know nothing about mingw but perhaps you are using the wrong pthread.lib(.a) The msvc pthreadVC2.lib that I use have symbols begining with _imp, perhaps you should pick this one. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: Problems with todays CVS
* Erik Hofman -- Monday 30 May 2005 18:22: I don't get it, I didn't see this behavior until after I committed the patches, when I noticed it once. Melchior has these patches also applied and didn't complain. And I first saw it when I tried to reproduce Jon's problem. Which worked. Seems like I do really somehow prefer YASim, at least always if I try to test stuff. (The bo105 may have to do with it.) YASim works. Only JSBSim doesn't. :-( Only the **C-172** doesn't? Or, any JSBSim aircraft? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems with todays CVS
Le lundi 30 mai 2005 11:36 -0500, Dave Culp a crit : well-loved no scenery below the aircraft ground cache message. I don't get it, I didn't see this behavior until after I committed the patches, when I noticed it once. Melchior has these patches also applied and didn't complain. Maybe this is something to do with OS, compiler, or video card? Dave I don't know if it is FDM dependant == None of my JSBSim prototype Aircraft running with the last CVS. The aircraft Freeze . animations elevators, propellers,... continu running :- -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Problems with todays CVS
* Jon Berndt -- Monday 30 May 2005 18:53: * * Melchior FRANZ: And I first saw it when I tried to reproduce Jon's problem. Which worked. Seems like I do really somehow prefer YASim, at least always if I try to test stuff. (The bo105 may have to do with it.) YASim works. Only JSBSim doesn't. :-( Only the **C-172** doesn't? Or, any JSBSim aircraft? I tried several aircraft: all YASim worked. None of the JSBSim aircraft did. But I wouldn't worry about it. Give Mathias a few hours time. That's probably not hard to fix. (And enjoy the bo105 in the meantime! :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: Problems with todays CVS
Only the **C-172** doesn't? Or, any JSBSim aircraft? I tried several aircraft: all YASim worked. None of the JSBSim aircraft did. But I wouldn't worry about it. Give Mathias a few hours time. That's probably not hard to fix. (And enjoy the bo105 in the meantime! :-) m. You suspect the new ground callback code? Well, I'm in no hurry. It's a holiday. I'm taking the family to see Madagascar. With four small kids. At their normal nap time. Ought to be interesting. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Problems with todays CVS
Jon Berndt wrote: * Erik Hofman -- Monday 30 May 2005 18:22: I don't get it, I didn't see this behavior until after I committed the patches, when I noticed it once. Melchior has these patches also applied and didn't complain. And I first saw it when I tried to reproduce Jon's problem. Which worked. Seems like I do really somehow prefer YASim, at least always if I try to test stuff. (The bo105 may have to do with it.) YASim works. Only JSBSim doesn't. :-( Only the **C-172** doesn't? Or, any JSBSim aircraft? Same problem with the F-18 Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Problems with todays CVS
* Jon Berndt -- Monday 30 May 2005 19:12: You suspect the new ground callback code? Yes, that's a safe bet. The clouds can hardly do that, neither can my modified beacon. There were no other commits. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Problems with todays CVS
Jon Berndt wrote: * Erik Hofman -- Monday 30 May 2005 18:22: I don't get it, I didn't see this behavior until after I committed the patches, when I noticed it once. Melchior has these patches also applied and didn't complain. And I first saw it when I tried to reproduce Jon's problem. Which worked. Seems like I do really somehow prefer YASim, at least always if I try to test stuff. (The bo105 may have to do with it.) YASim works. Only JSBSim doesn't. :-( Only the **C-172** doesn't? Or, any JSBSim aircraft? I've seen it with the F-16. But not directly, it took some time. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Problems with todays CVS
Only JSBSim doesn't. :-(
While we're finding out the cause and fixing the ground cache thing, how about
making a small modification to JSBSim.cxx that will spit out useful data and
*not* freeze the FDM? (about line 409)
// Compute the potential movement of this aircraft and query for the
// ground in this area.
double groundCacheRadius = acrad + 2*dt*Propagate-GetUVW().Magnitude();
double alt, slr, lat, lon;
FGColumnVector3 cart = Auxiliary-GetLocationVRP();
if ( needTrim startup_trim-getBoolValue() ) {
alt = fgic-GetAltitudeFtIC();
slr = fgic-GetSeaLevelRadiusFtIC();
lat = fgic-GetLatitudeDegIC() * SGD_DEGREES_TO_RADIANS;
lon = fgic-GetLongitudeDegIC() * SGD_DEGREES_TO_RADIANS;
cart = FGLocation(lon, lat, alt+slr);
}
double cart_pos[3] = { cart(1), cart(2), cart(3) };
bool cache_ok = prepare_ground_cache_ft( State-Getsim_time(), cart_pos,
groundCacheRadius );
if (!cache_ok) {
SG_LOG(SG_FLIGHT, SG_WARN,
FGInterface is being called without scenery below the aircraft!
\n);
cout altitude = alt endl;
cout sea level radius = slr endl;
cout latitude = lat endl;
cout longitude= lon endl;
//return;
}
I know it works fine in the air (I've been using it for a couple days while
trying to recreate the error conditions), but what happens if you get a bad
cache on the ground? Don't know.
Dave
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Problems with todays CVS
Le lundi 30 mai 2005 12:34 -0500, Dave Culp a crit : Only JSBSim doesn't. :-( cout altitude = alt endl; cout sea level radius = slr endl; cout latitude = lat endl; cout longitude= lon endl; //return; } I know it works fine in the air (I've been using it for a couple days while trying to recreate the error conditions), but what happens if you get a bad cache on the ground? Don't know. Dave may be an other way for research: I have build CVS with the JSBSim 9.8 source , FGFS gives the same Freeze with the well known message: FGInterface is beeing called without scenery below the aircraft. So , Is it really a JSBSim bug??? -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FGFS final link fails: _imp__pthread symbols not
Giles Robertson wrote: g++ -DPKGLIBDIR=\/point/share/FlightGear\ -g -O2 -D_REENTRANT [...] -lpthread is missing - same effect as with GCC-3.4.2 on Solaris. Add it manually and feel happy ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
On Mon, 30 May 2005 08:50:43 +0200, Melchior wrote in message [EMAIL PROTECTED]: * Jon Berndt -- Monday 30 May 2005 00:26: Melchior FRANZ wrote: When you fly over a beacon, the ground cache has to eat all these triangles, which makes the FDM stutter or even hang. Is the ground cache for the benefit of the FDM? The FDMs are currently the only users of the groundcache, and yes, they benefit from it. A lot. Per-wheel/contact-point ground awareness hadn't been done before Mathias implemented the ground cache. And probably it would have been a big performance problem to constantly do intersection test with the whole tile. Still, I didn't mean to blame the problems on the FDMs. I just called it FDM stuttering because this is what the user sees (and because the ground-cache code is in the FDM/ directory :-) But the FDM only stuttered, because it wasn't called in time, because of unfortunate groundcache/beacon interaction. And that wasn't really a bug, either. Neither in the beacon, nor in the ground cache. Just a detail that had to be tuned for better performance. :-) ..so we need it on the ground, and immediately before impact. ;o) ..if we disable it at altitude, how much time do we need to load it immediately before impact ? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel]Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
On Monday 30 May 2005 13:21, Jon Stockill wrote: Jon Berndt wrote: Is the ground cache for the benefit of the FDM? The FDMs are currently the only users of the groundcache, and yes, they benefit from it. A lot. Per-wheel/contact-point ground awareness hadn't been done before Mathias implemented the ground cache. And probably it would have been a big performance problem to constantly do intersection test with the whole tile. Still, I didn't mean to blame the problems on the FDMs. I just What I was curious about was if per-wheel contact point checking was being done when it doesn't need to be done - that is, when the aircraft isn't even close to the ground? I'm not certain the area that the ground cache covers, but I suspect it has applications beyond just contact points. ISTR Lee was wanting to know ground elevation a distance ahead of the aircraft for the terrain following mode of the TSR2s autopilot - could this be used? Jon Hello Jon, well remembered:) I did give some thought to look-ahead algorithms and I think it would be possible to come up with a rolling max/min type algorithm that would only need one look-ahead sample per frame to get a good straight-line TF target agl. Gets much more complicated if turning, of course:) LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems with Terrasynch
On Monday 30 May 2005 00:03, Lee Elliott wrote: On Sunday 29 May 2005 17:27, Lee Elliott wrote: Hello all, I've just tried to use terrasynch for the first time but I'm getting connection time-outs. I _think_ I've got it set up and running correctly at this end but I don't know how to test that the repository I'm trying to connect to is ok. (I'm using --nmea entries here - one for Atlas and the other for terrasynch, using different ports of course, and I can see the rsynch commands being issued for the correct locations) Can anyone confirm that scenery.flightgear.org is working ok? TIA LeeE Still no-go using the default rsynch source compiled into terrasynch. I've been looking for alternate sources but haven't found any yet - are there any? and if so, how do I specify them? Thanks again. LeeE Can anyone confirm that terrasynch is currently working? LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems with Terrasynch
Lee Elliott wrote: Can anyone confirm that terrasynch is currently working? Hmmm, the master scenery server looks like it may have gone down ... I can't ping it or log into it right now. It's going to have to wait until tomorrow am before I'll be near the machine to look at it though. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Problems with todays CVS
Le lundi 30 mai 2005 21:45 +0200, Gerard ROBIN a crit : Le lundi 30 mai 2005 12:34 -0500, Dave Culp a crit : Only JSBSim doesn't. :-( cout altitude = alt endl; cout sea level radius = slr endl; cout latitude = lat endl; cout longitude= lon endl; //return; } I know it works fine in the air (I've been using it for a couple days while trying to recreate the error conditions), but what happens if you get a bad cache on the ground? Don't know. Dave may be an other way for research: I have build CVS with the JSBSim 9.8 source , FGFS gives the same Freeze with the well known message: FGInterface is beeing called without scenery below the aircraft. So , Is it really a JSBSim bug??? I would like to be more clear regarding my previous mail: I did build the existing CVS, after patching it with the ==JSBSim version which is in the stable flightgear-9.8 the resulting fgfs presents exactly --the same Freeze --the same message error FGInterface is beeing called without scenery below the aircraft. We could conclude: the error is not in JSBSim but in an other part of fg -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel]Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
On Monday 30 May 2005 13:21, Jon Stockill wrote: I'm not certain the area that the ground cache covers, but I suspect it has applications beyond just contact points. ISTR Lee was wanting to know ground elevation a distance ahead of the aircraft for the terrain following mode of the TSR2s autopilot - could this be used? Jon Hello Jon, well remembered:) I did give some thought to look-ahead algorithms and I think it would be possible to come up with a rolling max/min type algorithm that would only need one look-ahead sample per frame to get a good straight-line TF target agl. Gets much more complicated if turning, of course:) LeeE If you are using look-ahead algorithms for terrain following (i.e. modeling a LANTIRN pod or something) this should only be enabled when it is actually used - probably not many models need that. Certainly, the C-172 does not. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
