Re: [Flightgear-devel] Autopilot and violent roll
On Saturday 10 Oct 2009, Pete Morgan wrote: Roy Vegard Ovesen wrote: On Saturday 10 October 2009 22:33:01 Curtis Olson wrote: Really, this is all in how the autopilot is tuned and configured. FlightGear doesn't model realistic control surface deflection rates so it's possible to command an instantaneous deflection of the control surfaces. Control surface deflection rate can be limited by inserting a low-pass filter between the output of the final PID-controller and the control surface. THis is done in the autopilot config file. I expected FlightGear to crete the realistic mdel.. and deflection rate.. So your response cofirmas a few facts... ie if u stick in a new value to the FDM then it will react.. That sucks in my oioiion.. I how have to create my own craqo to make the model. that sucks to me.. pete You really need to chill a bit. Just moaning about things isn't the best way to go about getting stuff fixed. Anyway, in short, this 'problem' such as it is, is largely due to the rates at which the autopilots are run within FG. In real life, autopilot controllers, and the sensors that feed them the data they need to work with, run at much higher frequencies than are possible within the FG framework. Ideally, you want to be able to run the autopilots at several to many kHz but in FG, although you can specify very high rates in the autopilot config, you are effectively limited by the frame rate, so not only do they run much more slowly than is desirable but they also run at varying rates as the frame rate changes. This isn't ideal, of course, but running an entire flight simulator on a single PC is always going lead to compromises. Having said that though, there are a number ways of working around most of the problems. There isn't really a problem with the autopilot code or the FDMs in flight gear, but that doesn't mean that individual FDMs and autopilots are always optimally configured. As Jon said, JSBSim incorporates actuator simulation, and I know that YASim allows you to set control surface deflection rate limits. These should really be set up in the aircraft FDM config and it is down to the developer to do this. However, few of the people developing aircraft for FG could be described as professionals in this field so you shouldn't expect everything to be absolutely perfect. So first of all, have a look at the FDM configs for the aircraft you're using and, depending on which FDM is being used, find out whether the actuators or rate limits have been set up correctly. The next thing to do is to look at the autopilot config. When the 'new' PID/PI autopilot was introduced, Roy set up a basic 'example' autopilot configuration to show how the new controllers could be used and this has formed the basis for most of the autopilots since then. The basic autopilot that Roy set up used two-stage controller cascades, where the output from the first stage controller was fed into the second stage. For example, in the true-heading-hold mode, the first stage controller would look at the true-heading-error-deg property and generate a desired roll setting to turn the aircraft and reduce the true-heading-error-deg to zero. The second stage would then take the desired roll setting and generate an aileron deflection to achieve the required roll. As the aircraft turns and true-heading-error-deg starts to approach zero, the controller will detect this and command a reduced degree of roll. Similarly, the second stage controller will look at the current degree of roll and compare it with the required degree of roll and if the two are very different the second stage controller will command a large deflection (this is where the jerkiness come from). Then, as the difference between the current roll and required roll reduces, the controller will command less deflection. The jerkiness then, can occur when the first stage controller sees a large difference between its current state and the state required, and quite reasonably commands the maximum change it is allowed. For example, if you're flying level and then tell the autopilot that you want to fly in the opposite direction it will quickly decide that it needs to command maximum roll. Now the second stage controller, which controls the ailerons to achieve the desired rate of roll, has to be quite aggressive in the way that it works if it is to tightly control roll, both because it has to operate over a much shorter time span than the first stage controller (to turn an aircraft through 180 degrees may take several minutes but to achieve 40 deg of roll may only take a few seconds) and also to prevent the aircraft from 'over-rolling' and then see-sawing as it then corrects itself, but this means that when it is told to change the current roll from zero to, 40 degrees say, it sees a very large error, just as the first stage controller has seen, and command its maxmum
Re: [Flightgear-devel] Autopilot and violent roll
-Original Message- From: leee [mailto:l...@spatial.plus.com] ie if u stick in a new value to the FDM then it will react.. That sucks in my oioiion.. I how have to create my own craqo to make the model. that sucks to me.. pete You really need to chill a bit. Just moaning about things isn't the best way to go about getting stuff fixed. Anyway, in short, this 'problem' such as it is, is largely due to the rates at which the autopilots are run within FG. In real life, autopilot controllers, and the sensors that feed them the data they need to work with, run at much higher frequencies than are possible within the FG framework. Ideally, you want to be able to run the autopilots at several to many kHz but in FG, although you can specify very high rates in the autopilot config, you are effectively limited by the frame rate, so not only do they run much more slowly than is desirable but they also run at varying rates as the frame rate changes. Lee First, thanks for the quick into to Flightgear´s autopilot. I think that your premise that autopilots need to run at very high frame rates is not realistic. When I first got into autopilots and simulation, back in the 60´s, all of our models had as the final element a 0.1 second low pass filter which simulated the control surface actuator. This turns out to be a reasonable approximation for most actuators and is very simple to implement both in a analogue computer (which is all we had then) and in digital ones. As there is such a filter in the inner loop means that there is no need to simulate anything which has a faster response time than this. Therefore there is no need to run the autopilot at high frame rates. 10 or 20 per second is perfectly adequate. Many of the outer loops (e.g. the heading mode) of the autopilot can in practice be run at much slower frame rates as the response of the aircraft is quite slow. Alan -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sound system committed
Alan Teeder wrote: Sorry to be the messenger, but compilation of soundmgr_openal.cxx and all flightgear files using soundmgr_openal.hxx fails under VC90. See attached build log. I am using the 3rd part libraries as per flightgear/source/projects/VC90/README.msvc. i.e. (Precompiled librairies and headers for compiling Win32 executables with VS2008 : ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/fgfs-win32-VS90- 3rdParty +OSG-20090628.zip) Same error with more recent fgfs-win32-VS90-3rdParty+OSG-20090820. Do I need a more recent version of OpenAL? Alan -Original Message- From: Erik Hofman [mailto:e...@ehofman.com] Sent: 05 October 2009 08:45 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] New Sound system committed Curtis Olson wrote: Hi Erik, One quick question: will the sound configuration xml files need to change to match the new system or will there be backwards compatibility? It's backwards compatible. I do plan a new format change to be able to position the sounds in 3d-model space instead of OpenAL/OpenGL space. That will require adding a a new version/ xml tag but the omission of it will still mean the previous format. I finally got around to updating FG/SG to Head. As we know - it fails under MSVC9. Here's how I fixed it: Downloaded and installed OpenAL 1.1 Core SDK from Creative Labs. Downloaded freealut-1.1.0 from Creative Labs. Compiled it by converting the MSVC 7 project files supplied to MSVC9, and including OpenAL 1.1 Core SDK. Put the generated alut.dll in the active path. Patched soundmgr_openal.cxx/hxx and sample_group.hxx with +#elif defined(_WIN32) +# include al.h or +#elif defined(_WIN32) +# include al.h +# include alc.h +# include AL/alut.h as appropriate. Built FG/SG with \freealut-1.1.0\include and \OpenAL 1.1 Core SDK\include. Linked FG to \freealut-1.1.0\admin\VisualStudioDotNET\alut\Release and OpenAL 1.1 Core SDK\libs\Win32. As they say here in the UK simples. Does it work - yes, except FG now crashes on exit. I can now hear excellent sound, and nice new 3D clouds, with almost no impact on framerate. I expect Fred can come up with a better, easier way. Vivian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot and violent roll
On Sun, Oct 11, 2009 at 3:39 AM, Alan Teeder wrote: First, thanks for the quick into to Flightgear´s autopilot. I think that your premise that autopilots need to run at very high frame rates is not realistic. When I first got into autopilots and simulation, back in the 60´s, all of our models had as the final element a 0.1 second low pass filter which simulated the control surface actuator. This turns out to be a reasonable approximation for most actuators and is very simple to implement both in a analogue computer (which is all we had then) and in digital ones. As there is such a filter in the inner loop means that there is no need to simulate anything which has a faster response time than this. Therefore there is no need to run the autopilot at high frame rates. 10 or 20 per second is perfectly adequate. Many of the outer loops (e.g. the heading mode) of the autopilot can in practice be run at much slower frame rates as the response of the aircraft is quite slow. I think what Lee(e) may be observing is that when you tune an autopilot to behave well when the update rate is 60hz, and then fly into an area of complex scenery + effects the frame rate in FlightGear can drop substantially. In this situation, the autopilot (which is running at the same update rate as the graphics) can go unstable, leading to wild oscillations. Presumably this is an entirely different issue than what Pete is dealing with, and neither of these contradict anything you have said. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] multiplayer.nas - About the pilot list and other multiplayer problems.
Testing the patch works here . Pilot list matches multiplayer list , and no more looking at empty spaces where the player vacated in model view. Committed, thanks for the patch and for testing. Torsten -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot and violent roll
On Sunday 11 Oct 2009 4:30:08 pm Curtis Olson wrote: I think that your premise that autopilots need to run at very high frame rates is not realistic. When I first got into autopilots and simulation, back in the 60´s, all of our models had as the final element a 0.1 second low pass filter which simulated the control surface actuator. This turns out to be a reasonable approximation for most actuators and is very simple to implement both in a analogue computer (which is all we had then) and in digital ones. As there is such a filter in the inner loop means that there is no need to simulate anything which has a faster response time than this. Therefore there is no need to run the autopilot at high frame rates. 10 or 20 per second is perfectly adequate. Many of the outer loops (e.g. the heading mode) of the autopilot can in practice be run at much slower frame rates as the response of the aircraft is quite slow. I think what Lee(e) may be observing is that when you tune an autopilot to behave well when the update rate is 60hz, and then fly into an area of complex scenery + effects the frame rate in FlightGear can drop substantially. In this situation, the autopilot (which is running at the same update rate as the graphics) can go unstable, leading to wild oscillations. Presumably this is an entirely different issue than what Pete is dealing with, and neither of these contradict anything you have said. Interesting. I would have imagined that the autopilot logic were synchronized with the FDM and hence slow downs should not cause an issue as they would both slow down together. But it seems that the autopilot logic is synchronized with GUI frame paining code. Is there any literature that lists out the sequence? I'm curious to know how the network IO is synchronized. Not having a common time base reference for the various subsystems can lead to varying performance based on the underlying hardware on which flightgear is run. The PID/Autopilot tuning for a given model should not vary based on the hardware on which flightgear is run. Should it? Or did I get this all wrong? -- Cheers! Kishore -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Selectable ignore for MP chat
On Fri, 28 Aug 2009, Anders Gidenstam wrote: Hi all, I'm not that frequently on the multiplayer network but I heard this feature request on IRC. This patch to Nasal/multiplayer.nas adds an ignore checkbox to each player entry in the pilot list. Once checked MP chat messages from that callsign will be ignored until unchecked or to the end of the session, whichever comes first. Hi all, Here is a new diff for the MP-chat ignore feature since multiplayer.nas has been updated: http://www.gidenstam.org/FlightGear/misc/tmp/add_MPchat_ignore-20091011.diff Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sound system committed
Hi Vivian, Vivian Meazza wrote: Patched soundmgr_openal.cxx/hxx and sample_group.hxx with +#elif defined(_WIN32) +# include al.h or +#elif defined(_WIN32) +# include al.h +# include alc.h +# include AL/alut.h I've added these to the latest commit. Here is a status update of the new Sound System: All positions, orientations and velocity vectors are checked and correct now. While the orientation of the aircraft is correct the direction of the sounds is not. All sounds now face forward from the aircraft without honoring the direction tags in the configuration file. I could need some help here; I can't seem to orientate the sound-direction vector with the aircraft orientation properly. Also, Anders was right; the sounds that are tied to the listener still have the Doppler effect. So I'll have to look at that. Erik -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sound system committed
On Sun, 2009-10-11 at 15:49 +0200, Erik Hofman wrote: Geoff McLane wrote: I hope this makes it into CVS sometime soon... Was his soon enough? ;-) Erik So slick and quick... thanks... Geoff. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Selectable ignore for MP chat
Here is a new diff for the MP-chat ignore feature since multiplayer.nas has been updated: Committed, thanks. Torsten -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Selectable ignore for MP chat
Hi Anders, thank you very much !! ( I knew I was forgetting someone for T-shirt award suggestions) This is a feature I've grown to love and live by, as I like to fly near KSFO :) Many thanks, Cheers, Nic -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Towards release 1.9.2
Hi Folks, Just wondering: Suppose we're aiming for another release by the end of the year, would it be feasible to go ahead with our original plan and release a 1.9.2-beta version just before FSWeekend? We've seen are few relatively major code overhauls in the recent past, so if we do continue with planning a new release, would it be an idea to call for a feature freeze by say mid-October (that would be, ahem, next weekend). FWIW, I would like to build a minimum base package this time, which only consists of one aircraft, no AI, and a minimal set of shared models. AI and other aircraft can be released as a separate ADDON packages, or via CVS. Likewise, shared models are now maintained via terrasync/SVN, so that is also taken care of. Thoughts, Ideas, Cheers, Durk -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Towards release 1.9.2
Durk Talsma wrote: Hi Folks, Just wondering: Suppose we're aiming for another release by the end of the year, would it be feasible to go ahead with our original plan and release a 1.9.2-beta version just before FSWeekend? We've seen are few relatively major code overhauls in the recent past, so if we do continue with planning a new release, would it be an idea to call for a feature freeze by say mid-October (that would be, ahem, next weekend). Sounds good, but this requires the audio direction code to be functional. I'll try to get it working this week. Erik -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Towards release 1.9.2
On Sun, 11 Oct 2009, Erik Hofman wrote: Sounds good, but this requires the audio direction code to be functional. I'll try to get it working this week. Hi Erik, Sorry to put more work on you, but it would be good if JSBSim could be updated to JSBSim/CVS too. Some piston engine configurations are misbehaving with the version currently in FlightGear/CVS but should behave better with the code in JSBSim/CVS. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Towards release 1.9.2
Ron Jensen wrote: On Sun, 2009-10-11 at 20:56 +0200, Durk Talsma wrote: Hi Folks, call for a feature freeze by say mid-October (that would be, ahem, next weekend). I would love to see JSBSim synced before the feature freeze... There are some tweaks to the piston code; ram-air, better throttle control and better boost handling, and the gear code now allows gears to be aligned in arbitrary directions. I'll test and commit it first thing tomorrow. Erik -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Towards release 1.9.2
Hi Durk, Durk Talsma wrote: FWIW, I would like to build a minimum base package this time, which only consists of one aircraft, no AI, and a minimal set of shared models. AI and other aircraft can be released as a separate ADDON packages, or via CVS. Likewise, shared models are now maintained via terrasync/SVN, so that is also taken care of. The current state of Base Package Scenery (w12[2,3]n37) is referencing just 38 Shared Models only. I'll try to provide a daily list of files to include (I'll have to check which files are being referenced from outside the Scenery), Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New route manager?
On 9 Oct 2009, at 01:06, Curtis Olson wrote: Is there still a missing connection in the code, or is the missing connection in my head? :-) Given that there is probably a beta coming up, I've just committed a 'fix' (more like a hack, but it's all about your point of view) that restores the critical connection from the route-manager to the AP. It should even work for altitudes (un-tested!). The behaviour can be disabled via a new config-flag, so realistic systems can stop the route-manager upsetting them, but the default value is 'on', for minimal surprise to existing users. Note I haven't (yet) fixed the filtering, so starting at KLAX one does still get the heliport, I'll fix that in the next day or two. Since the dialog updating bug is fixed, you can now enter KLAX-KPHX, hit 'activate', and use true-heading-hold in the generic AP as before. (Note the route-manager doesn't calculate some values until you are airborne, at present, to avoid numerical weirdness when speed and heading are unclear). I may also make the GPS fully generic, and then add a similar config flag (or more likely, share it) so that any aircraft can use the functionality - again, this will take a couple of days for me to convince myself about the ramifications for modelling realistic devices. Regards, James -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Towards release 1.9.2
On 10/11/2009 08:56 PM, Durk Talsma wrote: Hi Folks, Just wondering: Suppose we're aiming for another release by the end of the year, would it be feasible to go ahead with our original plan and release a 1.9.2-beta version just before FSWeekend? We've seen are few relatively major code overhauls in the recent past, so if we do continue with planning a new release, would it be an idea to call for a feature freeze by say mid-October (that would be, ahem, next weekend). FWIW, I would like to build a minimum base package this time, which only consists of one aircraft, no AI, and a minimal set of shared models. AI and other aircraft can be released as a separate ADDON packages, or via CVS. Likewise, shared models are now maintained via terrasync/SVN, so that is also taken care of. Thoughts, Ideas, I think this is a good idea. My major work in the pipe -- effects for models -- will be checked in by next weekend. I strongly recommend that we make the code portion of the beta and release from the master branch on gitorious. Tim -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New route manager?
On Sun, Oct 11, 2009 at 4:53 PM, James Turner zakal...@mac.com wrote: On 9 Oct 2009, at 01:06, Curtis Olson wrote: Is there still a missing connection in the code, or is the missing connection in my head? :-) Given that there is probably a beta coming up, I've just committed a 'fix' (more like a hack, but it's all about your point of view) that restores the critical connection from the route-manager to the AP. It should even work for altitudes (un-tested!). The behaviour can be disabled via a new config-flag, so realistic systems can stop the route-manager upsetting them, but the default value is 'on', for minimal surprise to existing users. Note I haven't (yet) fixed the filtering, so starting at KLAX one does still get the heliport, I'll fix that in the next day or two. Since the dialog updating bug is fixed, you can now enter KLAX-KPHX, hit 'activate', and use true-heading-hold in the generic AP as before. (Note the route-manager doesn't calculate some values until you are airborne, at present, to avoid numerical weirdness when speed and heading are unclear). I may also make the GPS fully generic, and then add a similar config flag (or more likely, share it) so that any aircraft can use the functionality - again, this will take a couple of days for me to convince myself about the ramifications for modelling realistic devices. Hi James, Thanks for looking into this. I'm going to be tied up with work and out of town most of this coming week so I probably won't get a chance to test this out until next weekend or the week following. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Selectable ignore for MP chat
Oh, it has a select all then? :) :) :) Robert M. Shearman, Jr. Transit Operations Supervisor, University of Maryland Department of Transportation also known as rm...@umd.edu From: Nicolas Quijano nquij...@gmail.com To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Sent: Sun, October 11, 2009 2:45:33 PM Subject: Re: [Flightgear-devel] [patch] Selectable ignore for MP chat Hi Anders, thank you very much !! ( I knew I was forgetting someone for T-shirt award suggestions) This is a feature I've grown to love and live by, as I like to fly near KSFO :) Many thanks, Cheers, Nic -- Be Kind. Remember, everyone is fighting a hard battle. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Selectable ignore for MP chat
On Mon, Oct 12, 2009 at 3:13 PM, Rob Shearman, Jr. rmsj...@yahoo.com wrote: Oh, it has a select all then? :) :) :) I think someone is being anti-social. :-P :-P Regards George -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
