Re: [Flightgear-devel] JSBSim engine config
On Saturday 15 April 2006 03:55, Dave Culp wrote: The 737-300 uses a CFM56-3 engine and the stabilized idle EGT should be approximately 475 degrees Celcius although it can be as high as 650 degrees Celcius on a hot day in bleed configuration and if it's in a bad condition. My manual says 360 to 510 degrees. I suppose it depends on the engine variant being used. I'm using the CFM56-3C-1 data from the Boeing 737-300,400,500 operations manual which was last revised in December 2002 and from CFM's web site. ( http://www.cfm56.com/engines/cfm56-3/tech.html ) Maybe that figure is for the 3-B1 or 3B-2 variant. The turbine model has no way of knowing what a particular engine will display for EGT. It depends not only on the engine's thermodynamics, but also the EGT probe placement. I intended for users to add offsets and scales in the instrumentation code to bring the EGT in line with expectations. In fact, I at first considered just reporting EGT as a normalized value, since any value it provides will be wrong anyway. Yes, I suppose it's not something that can be generically modeled easily. Maybe it really should be modeled in nasal and left out of the engine modeling all together since it'll be impossible to model correctly for all engine types. There was one other thing I saw - the EGT falls off too fast when shutting down the engine. It drops from 378 degrees C down to ambient temperature in less than 1 minute and cools down at a linear rate. I'm sure there would be lots of happy pilots if it did that in real life. Hot restarts would be a thing of the past. :) Also the N1 and N2 seem to hit a brick wall when they reach their maximum and minimum. Instead of slowing down as they reach their limits they suddenly stop at the limits. The brick wall is a feature. Looks right to me. Hmmm ... I always thought that the engine acclerations would slow down a bit as they reach their limits. This is at least what I've seen from cockpit videos. The last few percent near max RPM should take a few seconds to reach. If it doesn't battle to reach the upper limit doesn't it mean that there is no RPM limit and the engine should be able to rev to infinity? Maybe some RW airline pilots could give their input on this? (Do we have any such lurkers on the lists?) For some reason I always find myself a bit unenthusiastic about attending to your complaints. I wonder what the reason could be? I guess I forgot to coat it with honey and icing sugar. :) Sorry, l guess my linguistics and inter-personal relationship skills suck. I know I faired below average in that area the last time I took an aptitude test. I didn't mean it as a personal attack on your work. Paul --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MacOS build of FlightGear
On 15 Apr 2006, at 00:43, James Turner wrote:I'll do the 0.9.10 build tomorrow, first thing (promise!) As for it being official, well, now I have the X-Code projects sorted, actually doing the build is straight-forward, almost automatic. If I had an account on an 'always on' Mac, it would be easy to do a scripted nightly build, for example.Ok, the binary is here:teal.worldforge.org/~jmt/fgfs-0.9.10-macosx.dmgThis is sitting on my cable connection (in the UK), so transfer rate will not be awesome; I assume Curt will pull it and mirror as soon as he has time, but if you want to try in the meantime, and let me know if I've screwed anything up, feel free - I don't have a bandwidth cap, it'll just be slow!I have a script that pulls and builds a release bundle now, it needs some tweaking (property list isn't set, no icon), but it's pretty straightforward. James -- There is a very fine line between 'hobby' and 'mental illness'
[Flightgear-devel] Fresh build problem
Hi, I'm doing a fresh FG-0.9.10 build on a new machine with Linux Debian (sarge) and 2.6.15.. Building Simgear complains about the openal libraries: checking for library containing glutGetModifiers... -lglut checking for library containing alGenBuffers... no checking for library containing alutInit... no You *must* have the openal library installed on your system to build SimGear! Please see README.OpenAL for more details. configure aborted. Here's the output from the openal make install... make[1]: Leaving directory `/usr/local/src/openal/linux/doc' /usr/bin/install -c -d -m 755 /usr/local/lib /usr/bin/install -c -m 755 src/libopenal.so.0.0.8 /usr/local/lib ln -s -f libopenal.so.0.0.8 /usr/local/lib/libopenal.so.0 ln -s -f libopenal.so.0.0.8 /usr/local/lib/libopenal.so /usr/bin/install -c -d -m 755 /usr/local/include /usr/bin/install -c -d -m 755 /usr/local/include/AL /usr/bin/install -c -d -m 755 /usr/local/lib /usr/bin/install -c -d -m 755 /usr/local/bin /usr/bin/install -c -d -m 755 /usr/local/lib/pkgconfig/ /usr/bin/install -c -m 755 openal-config /usr/local/bin /usr/bin/install -c -m 444 openal.pc /usr/local/lib/pkgconfig/ /usr/bin/install -c -m 755 src/libopenal.a /usr/local/lib /usr/bin/install -c -m 444 ../include/AL/al.h /usr/local/include/AL /usr/bin/install -c -m 444 ../include/AL/alc.h /usr/local/include/AL /usr/bin/install -c -m 444 ../include/AL/alut.h /usr/local/include/AL /usr/bin/install -c -m 444 ../include/AL/altypes.h /usr/local/include/AL /usr/bin/install -c -m 444 ../include/AL/alctypes.h /usr/local/include/AL /usr/bin/install -c -m 444 ../include/AL/aluttypes.h /usr/local/include/AL /usr/bin/install -c -m 444 include/AL/alext.h /usr/local/include/AL /usr/bin/install -c -m 444 include/AL/alexttypes.h /usr/local/include/AL rampart:/usr/local/src/openal/linux# Checking the /usr/local/lib the files are there. Tried adding the files to /usr/lib and updating ld.so.conf and running ldconfig But the results were the same. Any suggestions where to look? Missing config argument? Using openal-9.9, think I have the latest version. Have not tried a new download from the openal website. Don't think that is the problem. Regards JW --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: tower.cxx
* Melchior FRANZ -- Thursday 13 April 2006 17:06: Can we *please* finally fix the notorious crashes in tower.cxx? And, yes, I really meant we. But as it looks, I'm pretty much on my own (apart from Olaf who did a lot of the hard work already). Now the cause for the segfault is proven. I've added some debug messages, and found that not only aircraft are at the same time in several state lists, such as: - depList circuitList trafficList - rwyList vacatedList - holdList vacatedList trafficList (quite frequent combination!) - circuitList vacatedList trafficList - holdList rwyList vacatedList trafficList - appList trafficList where each of the lines is one list combination for one aircraft during a one-hour test. But it's just an ugly bug, and wouldn't cause a crash. But this beats them all: - circuitList holdList vacatedList trafficList trafficList trafficList twice? That's a crash-condition! FGTower::RemovePlane() removes an aircraft once from each list (which is a design bug already) and then deletes the associated TowerPlaneRec! And when the code processes the other trafficList entry for that same aircraft, the pointer points to invalid memory. Everything can happen now. Quite often it's a crash. If nobody is willing to fix it properly, then I'll commit a crude workaround for this crash condition today at 2400. It won't fix the broken list shuffling, but only sweep the dirt deeper under the rug. I'm afraid the code can really only be fixed by its author. m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: tower.cxx
Melchior FRANZ writes: * Melchior FRANZ -- Thursday 13 April 2006 17:06: Can we *please* finally fix the notorious crashes in tower.cxx? And, yes, I really meant we. But as it looks, I'm pretty much on my own (apart from Olaf who did a lot of the hard work already). Now the cause for the segfault is proven. I've added some debug messages, and found that not only aircraft are at the same time in several state lists, such as: - depList circuitList trafficList - rwyList vacatedList - holdList vacatedList trafficList (quite frequent combination!) - circuitList vacatedList trafficList - holdList rwyList vacatedList trafficList - appList trafficList where each of the lines is one list combination for one aircraft during a one-hour test. But it's just an ugly bug, and wouldn't cause a crash. But this beats them all: - circuitList holdList vacatedList trafficList trafficList trafficList twice? That's a crash-condition! FGTower::RemovePlane() removes an aircraft once from each list (which is a design bug already) and then deletes the associated TowerPlaneRec! And when the code processes the other trafficList entry for that same aircraft, the pointer points to invalid memory. Everything can happen now. Quite often it's a crash. If nobody is willing to fix it properly, then I'll commit a crude workaround for this crash condition today at 2400. It won't fix the broken list shuffling, but only sweep the dirt deeper under the rug. I'm afraid the code can really only be fixed by its author. Hi Melchior, It hasn't dropped off my radar, honest guv! A spring-clean of tower.cxx is right at the top of my FG todo list, and hopefully I'll get it done before 1.0, since you've done a lot of fantastic work with the festival stuff and I'd hate to see it wasted due to segfaults from my side. *However*, fitting a sink into the bathroom is currently completely top of my TODO list :-( A certain person is gently insistent that I try not to get distracted by the computer so it's back to diy for now I'm afraid... Thanks for looking into this, please commit the crude fix, and I'm still there or thereabouts, in spirit if not in bug-fixes at the moment, Cheers - Dave --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re: tower.cxx
* Melchior FRANZ -- Saturday 15 April 2006 20:58: Apart from the crashes ATC worked and works nicely, and it would really be great if one could now have it enabled and not have to fear abrupt exits. Damn, I still get crashes in tower.cxx ... m. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: tower.cxx
Melchior FRANZ writes: * Melchior FRANZ -- Saturday 15 April 2006 20:58: Apart from the crashes ATC worked and works nicely, and it would really be great if one could now have it enabled and not have to fear abrupt exits. Damn, I still get crashes in tower.cxx ... What are you doing to crash it? So far I haven't been able to crash it at all in a reasonably long flight with AI set to 3 and interacting with ATC for the approach and landing. This is with your emergency fix. Cheers - Dave --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] New MP servers
With the new FG version 0.9.10, os released the new server code to be used as stable. So from now on we should redirect 0.9.10 users to the stable servers on port 5000. That also means that 0.9.9 users have to upgrade to fly online. We also updated the CVS users server. I added a patch that can be enabled by the server's owner to render the server tracked, meaning that users will be able to check out a detailed log of their flights. So far only mpserver03 and mpserver02 have this capability. So check your stats at http://fgfs.i-net.hu. (KoverSrac wrote the web server side of the tracker). Feel free to comment. Regards, Julien
Re: [Flightgear-devel] Fresh build problem
Usually you can check the config.log to see the exact error. Typically this is an ldconfig issue, but could be something else. Did you build openal with the same version of the compiler as you have installed now? Curt. John Wojnaroski wrote: Hi, I'm doing a fresh FG-0.9.10 build on a new machine with Linux Debian (sarge) and 2.6.15.. Building Simgear complains about the openal libraries: checking for library containing glutGetModifiers... -lglut checking for library containing alGenBuffers... no checking for library containing alutInit... no You *must* have the openal library installed on your system to build SimGear! Please see README.OpenAL for more details. configure aborted. Here's the output from the openal make install... make[1]: Leaving directory `/usr/local/src/openal/linux/doc' /usr/bin/install -c -d -m 755 /usr/local/lib /usr/bin/install -c -m 755 src/libopenal.so.0.0.8 /usr/local/lib ln -s -f libopenal.so.0.0.8 /usr/local/lib/libopenal.so.0 ln -s -f libopenal.so.0.0.8 /usr/local/lib/libopenal.so /usr/bin/install -c -d -m 755 /usr/local/include /usr/bin/install -c -d -m 755 /usr/local/include/AL /usr/bin/install -c -d -m 755 /usr/local/lib /usr/bin/install -c -d -m 755 /usr/local/bin /usr/bin/install -c -d -m 755 /usr/local/lib/pkgconfig/ /usr/bin/install -c -m 755 openal-config /usr/local/bin /usr/bin/install -c -m 444 openal.pc /usr/local/lib/pkgconfig/ /usr/bin/install -c -m 755 src/libopenal.a /usr/local/lib /usr/bin/install -c -m 444 ../include/AL/al.h /usr/local/include/AL /usr/bin/install -c -m 444 ../include/AL/alc.h /usr/local/include/AL /usr/bin/install -c -m 444 ../include/AL/alut.h /usr/local/include/AL /usr/bin/install -c -m 444 ../include/AL/altypes.h /usr/local/include/AL /usr/bin/install -c -m 444 ../include/AL/alctypes.h /usr/local/include/AL /usr/bin/install -c -m 444 ../include/AL/aluttypes.h /usr/local/include/AL /usr/bin/install -c -m 444 include/AL/alext.h /usr/local/include/AL /usr/bin/install -c -m 444 include/AL/alexttypes.h /usr/local/include/AL rampart:/usr/local/src/openal/linux# Checking the /usr/local/lib the files are there. Tried adding the files to /usr/lib and updating ld.so.conf and running ldconfig But the results were the same. Any suggestions where to look? Missing config argument? Using openal-9.9, think I have the latest version. Have not tried a new download from the openal website. Don't think that is the problem. Regards JW --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
