[Flightgear-devel] TaxiDraw
Three quick TaxiDraw questions for someone in the know - There is no information in the TaxiDraw wiki regarding runway and taxiway smoothness, but there is a roughness box as a surface parameter in Taxidraw. I am trying to determine if this is on a 0-1 range, as I have only seen existing values of about .25. The second item is that it does not appear to accept roughness data for taxiways or aprons, only runways. Anyone know if this is true, and if so, can it modified to accept a rough taxiway surface? The last question is regarding TaxiDraw itself. I was told that the WED.app would not work with FG due to FG not being able to recognize curved shapes (and perhaps more?). Although TaxiDraw is a great simple tool, it lacks functions and tools for efficient design speed. I assume it's a very low priority, but at best I'm looking to entice additional airport use from the users and at minimum correct the layouts. Does anyone know what the future holds for this? Thanks, Peter Brown -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Autopilot broken, Eric maybe?
Hi, Why is the autopilot broken? Specifically on my models like bluebird (or ufo if you prefer), I started to implement a requested feature, but found it does not work like it used to. The property: /autopilot/settings/true-heading-deg acts like it is being set by something else that shouldn't. When pressing the Heading Hold button on the panel, my aircraft flies in circles, because this property is constantly changing. Or with c172p press [F11] to load autopilot settings, click True Heading, and attempt to give it a heading to follow! I am surprised the c172p is broken as well, so it is not just my models. Is there a reason the Autopilot on the top menubar is greyed out? I narrowed down the time frame when this changed. It works correctly Aug.11 and early Aug.12 (stays nil until set, and stays as set), and is broken Aug.13 Changes include: P source/src/Airports/simple.hxx P source/src/Autopilot/route_mgr.cxx P source/src/Cockpit/hud.cxx P source/src/Environment/environment_ctrl.cxx P source/src/FDM/JSBSim/ 105 files updated by ehofman (Is that you Eric?) P source/src/Instrumentation/** 5 files If you press [/] right after the scenery starts loading, then quickly click down 2 directory levels, you can watch when this property starts getting set. Throttle up and the autopilot heading starts changing faster and faster, slows down at 180 from current heading, then speeds up as fast as 10 degrees per second. Quite wild. I also searched the last few months of messages, but can't find anything relevant to this. Stewart -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] ..FG as airport engineering design tool, was: reversible ILS
On Sun, 20 Dec 2009 10:21:22 -0700, John wrote in message 4b2e5d12.1080...@av8n.com: On 12/20/2009 09:15 AM, stefan riemens suggested: How about making allowing one to set the proposed preferred-approach-deg property, but not requiring it. It's already not required. It has a reasonable default. Most users will never even know it's there. This is in line with real-world reality. There are some real-world pilots, including virtually all VFR pilots and even some instrument-rated pilots, who have never heard of reversible ILSs. ..some people will want to _change_ e.g. approach routing, into say a gliding spiral at night in the summer so people can sleep with their windows open, or some such political scenario. That means overriding whatever defaults FG got from Robin's airport feature listing, and probably close to run-time ideas like How much noise do we make at 5.5 and 6 degree glides if we go 500 feet left and then weave back right the last mile?. We have all bits in place? -- ..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. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
Hi, There were major changes on the GPS and Route-Manager since August (3 Months ago already!) So this has affected the the use of the autopilot as well. All aircrafts using the generic Autopilot-panel are affected, but not those with an own written flightdirector like Syds Aircrafts (Citation Bravo works perfect) or with own configured autopilots like the senecaII, c172p, PA24-250. True-Heading can be used with the DTO-Mode in the GPS-menu in the Menubar. I think James can tell more! Cheers HHS Hi, Why is the autopilot broken? Specifically on my models like bluebird (or ufo if you prefer), I started to implement a requested feature, but found it does not work like it used to. The property: /autopilot/settings/true-heading-deg acts like it is being set by something else that shouldn't. When pressing the Heading Hold button on the panel, my aircraft flies in circles, because this property is constantly changing. Or with c172p press [F11] to load autopilot settings, click True Heading, and attempt to give it a heading to follow! I am surprised the c172p is broken as well, so it is not just my models. Is there a reason the Autopilot on the top menubar is greyed out? I narrowed down the time frame when this changed. It works correctly Aug.11 and early Aug.12 (stays nil until set, and stays as set), and is broken Aug.13 Changes include: P source/src/Airports/simple.hxx P source/src/Autopilot/route_mgr.cxx P source/src/Cockpit/hud.cxx P source/src/Environment/environment_ctrl.cxx P source/src/FDM/JSBSim/ 105 files updated by ehofman (Is that you Eric?) P source/src/Instrumentation/** 5 files If you press [/] right after the scenery starts loading, then quickly click down 2 directory levels, you can watch when this property starts getting set. Throttle up and the autopilot heading starts changing faster and faster, slows down at 180 from current heading, then speeds up as fast as 10 degrees per second. Quite wild. I also searched the last few months of messages, but can't find anything relevant to this. Stewart -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
S Andreason wrote: Hi, Why is the autopilot broken? Specifically on my models like bluebird (or ufo if you prefer), I started to implement a requested feature, but found it does not work like it used to. The property: /autopilot/settings/true-heading-deg acts like it is being set by something else that shouldn't. P source/src/FDM/JSBSim/ 105 files updated by ehofman (Is that you Eric?) It is me indeed, but I just synchronize JSBSim CVS and FlightGear at that point. If JSBSim is the cause (which I find hard to believe at this point) then there' s something severely wrong since JSBSim has no business updating anything under /autopilot. Erik -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
On 21 Dec 2009, at 16:33, Heiko Schulz wrote: There were major changes on the GPS and Route-Manager since August (3 Months ago already!) So this has affected the the use of the autopilot as well. All aircrafts using the generic Autopilot-panel are affected, but not those with an own written flightdirector like Syds Aircrafts (Citation Bravo works perfect) or with own configured autopilots like the senecaII, c172p, PA24-250. True-Heading can be used with the DTO-Mode in the GPS-menu in the Menubar. I think James can tell more! The issue / feature here is that the route-manager code has 'always' (for years, at least) directly set /autopilot/settings/true-heading-deg based on its internal route-following logic. Personally I don't think it's a great feature, but people do use it (the route manager) in conjunction with the generic autopilot dialog to quickly navigate between waypoints. When I broke the feature by accident, it was noticed, and people asked for the feature back. As far as I know, the old route-manager code behaved much the same as my code does now - but it sounds as if you disagree? For the record, my perception is that entering a value in the generic autopilot dialog for 'true heading' has never worked, because the value would **always** be over-written by the route manager. What *has* changed is that the value now actually comes from the GPS code, not the route-manager. Both are equally 'generic' (just like the autopilot itself), it was just simpler from a code design perspective to handle the autopilot interaction in the GPS code, and keep the route-manager separated. Does this fit with what you're seeing? Regards, James -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
Hi, Why is the autopilot broken? Specifically on my models like bluebird (or ufo if you prefer), I started to implement a requested feature, but found it does not work like it used to. The property: /autopilot/settings/true-heading-deg acts like it is being set by something else that shouldn't. The GPS code sets the property /autopilot/settings/true-heading-deg if /instrumentation/gps/config/drive-autopilot is true (which is true by default). I don't know much about the details of the new gps code from James Turner, maybe he could chime in for some explanation... Greetings, Torsten -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
On Mon, Dec 21, 2009 at 11:17 AM, James Turner wrote: For the record, my perception is that entering a value in the generic autopilot dialog for 'true heading' has never worked, because the value would **always** be over-written by the route manager. This would only have been the case if there were any pending waypoints in the route manager. If all waypoints had been reached, or no waypoints have been entered, then the 'old' route manager should not have touched the true-heading-target value. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
Heiko Schulz wrote: Hi, There were major changes on the GPS and Route-Manager since August (3 Months ago already!) So this has affected the the use of the autopilot as well. All aircrafts using the generic Autopilot-panel are affected, but not those with an own written flightdirector like Syds Aircrafts (Citation Bravo works perfect) or with own configured autopilots like the senecaII, c172p, PA24-250. Citation Bravo does not work :-( True Heading goes in circles pete -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
Hi James, As far as I know, the old route-manager code behaved much the same as my code does now - but it sounds as if you disagree? Yep, and Torsten already decribed it well: The GPS code sets the property /autopilot/settings/true-heading-deg if /instrumentation/gps/config/drive-autopilot is true (which is true by default). I don't know much about the details of the new gps code from James Turner, maybe he could chime in for some explanation... On the 737 and other aircraft (except those I mentioned in my previous posting) I have to use the DTO-Mode. Otherwise it won't fly to the next waypoint. So several Aircrafts needs fixing. The other thing, but I already mentioned it in the IRC-Chat, is that NAV1-Heading-hold and NAV1-GS-Hold isn't working anymore. Only the one with nasal-scripted Autopilots. We haven't got much of them For the record, my perception is that entering a value in the generic autopilot dialog for 'true heading' has never worked, because the value would **always** be over-written by the route manager. It worked as long we didn't use the Route-manager. Like Curt already said, with pending waypoints the values are overwritten, but only then. That hasn't changed. What *has* changed is that the value now actually comes from the GPS code, not the route-manager. Both are equally 'generic' (just like the autopilot itself), it was just simpler from a code design perspective to handle the autopilot interaction in the GPS code, and keep the route-manager separated. Does this fit with what you're seeing? Yep, but though a lot of aircrafts has to be fixed before release, or otherwise we will really have a debacle! Cheers HHS -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
Hi, Heiko Schulz wrote: Hi, There were major changes on the GPS and Route-Manager since August (3 Months ago already!) So this has affected the the use of the autopilot as well. All aircrafts using the generic Autopilot-panel are affected, but not those with an own written flightdirector like Syds Aircrafts (Citation Bravo works perfect) or with own configured autopilots like the senecaII, c172p, PA24-250. Citation Bravo does not work :-( True Heading goes in circles pete Really with current CVS? It is the only aircraft I can use for realistic approaches, SIDs and STARs, Route-flying ... CVS 11/27/2009 Cheers HHS __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
One note on using route manager - in a 12/13 CVS - if includes the departure airport as a waypoint automatically. If you activate it on the ground it will move past it on the takeoff roll and proceed to the next waypoint. If you don't activate it until in the air it will circle back to the departure airport as the first waypoint. Peter On Dec 21, 2009, at 12:17 PM, James Turner wrote: On 21 Dec 2009, at 16:33, Heiko Schulz wrote: There were major changes on the GPS and Route-Manager since August (3 Months ago already!) So this has affected the the use of the autopilot as well. All aircrafts using the generic Autopilot-panel are affected, but not those with an own written flightdirector like Syds Aircrafts (Citation Bravo works perfect) or with own configured autopilots like the senecaII, c172p, PA24-250. True-Heading can be used with the DTO-Mode in the GPS-menu in the Menubar. I think James can tell more! The issue / feature here is that the route-manager code has 'always' (for years, at least) directly set /autopilot/settings/true-heading-deg based on its internal route-following logic. Personally I don't think it's a great feature, but people do use it (the route manager) in conjunction with the generic autopilot dialog to quickly navigate between waypoints. When I broke the feature by accident, it was noticed, and people asked for the feature back. As far as I know, the old route-manager code behaved much the same as my code does now - but it sounds as if you disagree? For the record, my perception is that entering a value in the generic autopilot dialog for 'true heading' has never worked, because the value would **always** be over-written by the route manager. What *has* changed is that the value now actually comes from the GPS code, not the route-manager. Both are equally 'generic' (just like the autopilot itself), it was just simpler from a code design perspective to handle the autopilot interaction in the GPS code, and keep the route-manager separated. Does this fit with what you're seeing? Regards, James -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] navaids update
Martin Spott a écrit : Salut Jean, jean pellotier wrote: Is nav.dat supposed to be updated from robin X-plane database? If nobody else is going to do that, I'll be updating the file from Robin's most current package during our pre-release phase (however this is going to be defined ). I see the update is done, thanks, (and sorry for windows users waiting for a compatible binary build :) ). It appears that Atlas don't like the new nav.dat.gz, and crash on start up, because some navaids contains empty field for the balise name (i guess it's the balise name). here's a diff where the missing fields are replaced with IXXX. may be the real name is available, but i didn't found the few i checked. and Atlas don't crash anymore. jano 12062c12062 4 47.49051500 -111.20608600 3526 10950 18 238.500 KGFA 21 ILS-cat-I --- 4 47.49051500 -111.20608600 3526 10950 18 238.500 IXXX KGFA 21 ILS-cat-I 12103c12103 4 38.85886700 -094.55694100 1090 10930 18 11.886 KGVW 01 ILS-cat-I --- 4 38.85886700 -094.55694100 1090 10930 18 11.886 IXXX KGVW 01 ILS-cat-I 12393c12393 4 46.5362 -087.54817000 1419 11050 18 76.841 KMQT 08 ILS-cat-I --- 4 46.5362 -087.54817000 1419 11050 18 76.841 IXXX KMQT 08 ILS-cat-I 13389c13389 4 70.33308600 -149.56581800 67 10970 18 107.900 PAKU 05 ILS-cat-I --- 4 70.33308600 -149.56581800 67 10970 18 107.900 IXXX PAKU 05 ILS-cat-I 14125c14125 5 45.29766700 -072.73483300375 11070 18 36.999 CZBM 05L LOC --- 5 45.29766700 -072.73483300375 11070 18 36.999 IXXX CZBM 05L LOC 14255c14255 5 35.27726300 -089.66926600312 11155 18 153.681 KLHC 15 LOC --- 5 35.27726300 -089.66926600312 11155 18 153.681 IXXX KLHC 15 LOC 14372c14372 5 70.25181500 -148.35802800 45 10970 18 106.500 PUO 05 SDF --- 5 70.25181500 -148.35802800 45 10970 18 106.500 IXXX PUO 05 SDF -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
On 21 Dec 2009, at 17:59, Heiko Schulz wrote: It worked as long we didn't use the Route-manager. Like Curt already said, with pending waypoints the values are overwritten, but only then. That hasn't changed. Okay, so that's where the bug has come from, I need to fix the logic to only drive this property when GPS 'leg' mode is active. Yep, but though a lot of aircrafts has to be fixed before release, or otherwise we will really have a debacle! It is not my intention, or expectation, that many aircraft should need to be changed at all. Aircraft that used the old gps or route-manager directly will need changes (eg, the 787, and Concorde INS code, but that's non-functional anyway) but my *intention* was always that most aircraft, whether using the generic autopilot, or a customised XML autopilot, would work exactly as before. With the aircraft I test with, that's what I see - the C172, the Seneca, the B1900 and, to a lesser degree, the 777-200 (though it has some other problems). I guess the problem may be, that all of those aircraft have quite well developed, non-generic autopilots. Aside from the GPS setting true-heading-hold when it shouldn't, what problems are people seeing with heading-hold and nav1-hold? Please let me know the specific aircraft, steps to reproduce, expected behaviour and actual behaviour. I will assume people are testing with latest data/ and FG/SG sources. Regards, James -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
On 21 Dec 2009, at 18:10, Peter Brown wrote: One note on using route manager - in a 12/13 CVS - if includes the departure airport as a waypoint automatically. If you activate it on the ground it will move past it on the takeoff roll and proceed to the next waypoint. If you don't activate it until in the air it will circle back to the departure airport as the first waypoint. I thought I'd fixed that back at the start of October, soon after the initial commit - Curt complained that h couldn't start a route 'in-air' so I removed the need for departure/destination airports. Ah, I get it - you're specifying a departure airport, but then not activating the route until airborne. Hmm. I'm not sure that's actually a bug. Activating a route starts a leg to the first waypoint ... regardless of wether that's 'behind' you in the route or anything. In real-life I'd activate the route, then select the enroute waypoint I wanted to 'start' from, and 'DTO' on it, to head straight there - that's exactly how I fly departures where ATC vector me, then clear me to a SID waypoint. What do you think would be a sensible course of action, in the situation you describe? Even if I choose not to add the departure airport for in-air route activation, there's no guarantee that the first route waypoint is where you actually want to be going. Regards, James -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
On Mon, Dec 21, 2009 at 12:43 PM, James Turner zakal...@mac.com wrote: It is not my intention, or expectation, that many aircraft should need to be changed at all. Aircraft that used the old gps or route-manager directly will need changes (eg, the 787, and Concorde INS code, but that's non-functional anyway) but my *intention* was always that most aircraft, whether using the generic autopilot, or a customised XML autopilot, would work exactly as before. With the aircraft I test with, that's what I see - the C172, the Seneca, the B1900 and, to a lesser degree, the 777-200 (though it has some other problems). I guess the problem may be, that all of those aircraft have quite well developed, non-generic autopilots. Aside from the GPS setting true-heading-hold when it shouldn't, what problems are people seeing with heading-hold and nav1-hold? Please let me know the specific aircraft, steps to reproduce, expected behaviour and actual behaviour. I will assume people are testing with latest data/ and FG/SG sources. Hi James, The one aircraft I enjoy flying is the Alphajet ... that uses the generic autopilot/route manager system. My one comment with the new route manager is that I've had some variability in the results of building a route. Maybe I'm not understanding the interface correctly, but sometimes my starting airport gets added, even when I'm in the air. Sometimes it gets in there twice. After creating a route, I always need to go in and manually clean up extraneous stuff before I get what I hoped for. (Sorry for using the word always, maybe I should say I feel like I always have to go fix the route manually.) :-P Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken
Hi James, There were major changes on the GPS and Route-Manager since August (3 Months ago already!) I had not noticed because I have not tried using the autopilot for many months. written flightdirector like Syds Aircrafts (Citation Bravo works perfect) or with own yes, Citation Bravo works for me too. configured autopilots like the senecaII, c172p, PA24-250. Well yes, but I expected the default aircraft to work. Since the manual and help windows give instructions on using Ctrl-A, Ctrl-W, Ctrl-H, etc, and F11 does open the autopilot settings, I would expect these to work. True-Heading can be used with the DTO-Mode in the GPS-menu in the Menubar. Ok, I figured out how to give a destination. The issue / feature here is that the route-manager code has 'always' (for years, at least) directly set /autopilot/settings/true-heading-deg based on its internal route-following logic. Personally I don't think it's a great feature, but people do use it (the route manager) in conjunction with the generic autopilot dialog to quickly navigate between waypoints. When I broke the feature by accident, it was noticed, and people asked for the feature back. As far as I know, the old route-manager code behaved much the same as my code does now - but it sounds as if you disagree? I guess I do. In the past this property stayed nil until set by somebody wanting autopilot to navigate on a specific heading. Or yes, if route-manager gets Activated, then it did and does set true-heading-deg as you said. As long as route-manager was deactivated or had no waypoints set, it looked like the right place to tie in my buttons on the panel. For the record, my perception is that entering a value in the generic autopilot dialog for 'true heading' has never worked, because the value would **always** be over-written by the route manager. No, it is not overwritten when route-manager is disabled. And if it never worked, then how did the Ctrl-W, Ctrl-H ever work?? I still think something in this part is broken. What *has* changed is that the value now actually comes from the GPS code, not the route-manager. Both are equally 'generic' (just like the autopilot itself), it was just simpler from a code design perspective to handle the autopilot interaction in the GPS code, and keep the route-manager separated. Does this fit with what you're seeing? Yes. Without a destination, the gps code sets wild headings into true-heading-deg, and makes the old autopilot controls act broken and confusing. With a destination set, the GPS code works. Should the old autopilot dialog be ripped out of the c172p? and have all references to using the autopilot removed? I don't think so. The wing leveler and simple heading autopilot had value. Is there a way to set a steady heading without writing my own code, which I thought was discouraged reinventing the wheel :) Maybe I am supposed to study and borrow the flight director code or some part of it that makes smooth turns to a set heading? Actually, flying the c172p (in yesterday's CVS) around in circles for 10-15 minutes trying to get the heading to go on autopilot, even setting the GPS destination, did not work for me. If it isn't really broken, it sure looks like it. And if I can't figure it out, I doubt any first-time flyers will. Maybe the fix for half of this, is to Deactivate the New gps code when it has no destination set. Stewart -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
On Mon, Dec 21, 2009 at 12:48 PM, James Turner wrote: I thought I'd fixed that back at the start of October, soon after the initial commit - Curt complained that h couldn't start a route 'in-air' so I removed the need for departure/destination airports. Ah, I get it - you're specifying a departure airport, but then not activating the route until airborne. Hmm. I'm not sure that's actually a bug. Activating a route starts a leg to the first waypoint ... regardless of wether that's 'behind' you in the route or anything. In real-life I'd activate the route, then select the enroute waypoint I wanted to 'start' from, and 'DTO' on it, to head straight there - that's exactly how I fly departures where ATC vector me, then clear me to a SID waypoint. What do you think would be a sensible course of action, in the situation you describe? Even if I choose not to add the departure airport for in-air route activation, there's no guarantee that the first route waypoint is where you actually want to be going. Conceptually, including the starting point in the route seems like it could always be problematic.The airport location is some random point on the airport grounds (probably the average of the center points of the runways.) Even if you haven't taken off yet, it would be possible in some circumstances to not fly close to the center of the airport on take off. Then you would get routed back to the starting point before you could continue on to the next way point. I think we are just getting lucky when we fly close enough to the center of the airport in most situations for most runways to satisfy the route manager and it clicks on to the next waypoint. The KSFO airport layout is very friendly in this regards, but other airports like DFW and DEN are more sprawling. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
James, this is what I've found too. Perhaps I don't understand the proper setup method, but I tend to clean it up as well. Sometimes I get a FL value, others times the point adds with a zero altitude. (or two dep. airport waypoints, one with each altitude) It may be a result of most times the route manager loads with the departure airport already listed. For the time being configure it to not load a depature airport on opening? Peter On Dec 21, 2009, at 1:51 PM, Curtis Olson wrote: On Mon, Dec 21, 2009 at 12:43 PM, James Turner zakal...@mac.com wrote: It is not my intention, or expectation, that many aircraft should need to be changed at all. Aircraft that used the old gps or route-manager directly will need changes (eg, the 787, and Concorde INS code, but that's non-functional anyway) but my *intention* was always that most aircraft, whether using the generic autopilot, or a customised XML autopilot, would work exactly as before. With the aircraft I test with, that's what I see - the C172, the Seneca, the B1900 and, to a lesser degree, the 777-200 (though it has some other problems). I guess the problem may be, that all of those aircraft have quite well developed, non-generic autopilots. Aside from the GPS setting true-heading-hold when it shouldn't, what problems are people seeing with heading-hold and nav1-hold? Please let me know the specific aircraft, steps to reproduce, expected behaviour and actual behaviour. I will assume people are testing with latest data/ and FG/SG sources. Hi James, The one aircraft I enjoy flying is the Alphajet ... that uses the generic autopilot/route manager system. My one comment with the new route manager is that I've had some variability in the results of building a route. Maybe I'm not understanding the interface correctly, but sometimes my starting airport gets added, even when I'm in the air. Sometimes it gets in there twice. After creating a route, I always need to go in and manually clean up extraneous stuff before I get what I hoped for. (Sorry for using the word always, maybe I should say I feel like I always have to go fix the route manually.) :-P Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flight Pro Sim Statement (v1.3)
Q: I have purchased Flight Pro Sim. Can I get a refund ? A: That is something you will have to take up with the distributors of Flight Pro Sim. Change makers to distributors Bob -- Delusional Mail (http://www.delusionalmind.com) -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flight Pro Sim Statement (v1.3)
On Mon, Dec 21, 2009 at 1:00 PM, Bob Faulkner wrote: Q: I have purchased Flight Pro Sim. Can I get a refund ? A: That is something you will have to take up with the distributors of Flight Pro Sim. Change makers to distributors I believe flight sim pro may be using a distributor/partner sales model, so distributor might be the most appropriate term here? Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flight Pro Sim Statement (v1.3)
On Mon, Dec 21, 2009 at 1:30 PM, Curtis Olson wrote: On Mon, Dec 21, 2009 at 1:00 PM, Bob Faulkner wrote: Q: I have purchased Flight Pro Sim. Can I get a refund ? A: That is something you will have to take up with the distributors of Flight Pro Sim. Change makers to distributors I believe flight sim pro may be using a distributor/partner sales model, so distributor might be the most appropriate term here? Affiliate is the word I was looking for ... Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
Hey, could we all agree it's not my fault? :) Erik -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
Erik Hofman wrote: Hey, could we all agree it's not my fault? :) Sorry Erik, You are only guilty of submitting the most number of files in that 36 hour period. :) I guessed wrong. Stewart -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
Hi, Hey, could we all agree it's not my fault? :) Erik Only if you will correct the airport name: http://wiki.flightgear.org/index.php/File:Tu154Innsbruck.png - pretty flat for LOWI ! :-P Cheers HHS __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken
I'll have to add also that I'm a bit confused by the recent changes (I'm sure I'll eventually figure it out) , but how is this new route manager dialog supposed to work ? I try the normal k...@35000 , and hit activate , and then I get my departure airport suddenly added to the list , which causes the aircraft to go back home again before contuing on to the destination Ive also had cases where takeoff is suddenly taken over by the autopilot , usually disasterous , but I haven't looked very closely at that one yet ...could be something Im doing wrong now... Any light shed on the new code behavior , changes , what we should and shouldn't be doing , would be really helpful. I dont like surprises , when they affect my work ;). Thanks -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] auto-coordination broken
The –enable-auto-coordination feature never worked very well, but now it even more broken than it used to be. I observe different symptoms in different aircraft. In the default c172p, it appears to have no effect at all. In the SenecaII, the most observable effect is that it makes it impossible to steer when trying to taxi. In the air it does not noticeably improve the coordination. Sometimes I see an intermittent flutter in the rudder, suggesting that one process is trying to throw the rudder hard over while another process is trying to center it. This is one of approximately 62 bugs listed at http://www.av8n.com/fly/fgfs/htm/bug-list.htm If anybody knows of anything that should be added, removed, or changed on that list, please let me know. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] parking.xml files under scenery/Airports
I noticed that some airports have parking.xml files in the scenery directory such as K/N/U/KNUQ.parking.xml or L/F/P/LFPG.parking.xml. As far as I can tell, the loader either picks up parking.xml files from data/AI/Airports (if use-custom-scenery-data is false) or groundnet.xml files from scenery/Airports. I wonder if these files are there by mistake or if there is some reason. -- Cheers, Csaba/Jester -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination broken
Hi, The –enable-auto-coordination feature never worked very well, but now it even more broken than it used to be. I observe different symptoms in different aircraft. In the default c172p, it appears to have no effect at all. If so, then it must be something happened recently. With CVS from 11/27/2009 the Auto-Coordination I see no problems, it shows the excepted effect. In the SenecaII, the most observable effect is that it makes it impossible to steer when trying to taxi. In the air it does not noticeably improve the coordination. Sometimes I see an intermittent flutter in the rudder, suggesting that one process is trying to throw the rudder hard over while another process is trying to center it. Did you try to turn on/off jaw damper? All those aircrafts named here are JSBSim- how do YASim-aircrafts react? Cheers HHS __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination broken
On Mon, Dec 21, 2009 at 3:21 PM, Heiko Schulz wrote: Did you try to turn on/off jaw damper? Hah, I tried that on my wife and it didn't work ... :-) (jaw being a bone in the mouth, yaw being side to side motion.) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination broken
Did you try to turn on/off jaw damper? Hah, I tried that on my wife and it didn't work ... :-) (jaw being a bone in the mouth, yaw being side to side motion.) Curt. -- Upss...Lol! :D Maybe I used this word instead because thinking of my own jaw which still pains a bit after surgery last week! ;-) Well, of course I meant Yaw-damper! Sorry! Cheers HHS __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination broken
On Mon, 21 Dec 2009, John Denker wrote: In the default c172p, it appears to have no effect at all. In the SenecaII, the most observable effect is that it makes it impossible to steer when trying to taxi. In the air it does not noticeably improve the coordination. Sometimes I see an intermittent flutter in the rudder, suggesting that one process is trying to throw the rudder hard over while another process is trying to center it. Hi, It seems to work ok here. Are you sure you don't have some noisy input device like a joystick or pedals connected that might affect the rudder axis? If two input axes are bound to the same control the last write wins. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot broken, Eric maybe?
Heiko Schulz wrote: Hi, Hey, could we all agree it's not my fault? :) Only if you will correct the airport name: http://wiki.flightgear.org/index.php/File:Tu154Innsbruck.png - pretty flat for LOWI ! :-P Admittedly I already wondered about it :) But i never thought it would be Schiphol. Anyhow, the filename isn't changed but the corresponding text is. Erik -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flight Pro Sim Statement (v1.3)
On Mon, Dec 21, 2009 at 1:30 PM, Curtis Olson wrote: On Mon, Dec 21, 2009 at 1:00 PM, Bob Faulkner wrote: Q: I have purchased Flight Pro Sim. Can I get a refund ? A: That is something you will have to take up with the distributors of Flight Pro Sim. Change makers to distributors I believe flight sim pro may be using a distributor/partner sales model, so distributor might be the most appropriate term here? Affiliate is the word I was looking for ... Curt. I wouldn't argue too much over which term to use, but since the GPL covers distribution, distributor the word I picked. Bob -- Delusional Mail (http://www.delusionalmind.com) -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination broken
On 12/21/2009 02:36 PM, Anders Gidenstam wrote: It seems to work ok here. Interesting Are you sure you don't have some noisy input device like a joystick or pedals connected that might affect the rudder axis? If two input axes are bound to the same control the last write wins. Thanks for the hint. That helps. It makes sense from a developers' point of view. However ... we still have a bug from the users' point of view. The documentation explicitly mentions the case where the user has a rudder input device but lacks the skill to handle the proper ratio ... and recommends --enable-auto-coordination in this case. If users are required to have zero-noise ailerons and zero-noise rudders, this is quite a serious restriction. This should be prominently mentioned in the documentation. Users will not be pleased. = I just now spent some time looking into this, and found a few surprises. When auto-coordination is turned on: 1) The feature is implemented as an aileron-rudder interconnect with a fixed ratio (half a unit of rudder per unit of aileron) in the aileron-rudder direction and not vice versa. This is not very sophisticated or very useful. In almost every aircraft I can think of, it is literally worse than useless in cruising flight. It makes the coordination worse. If this is the desired behavior, I would hate to see what undesired behavior looks like. The documentation indicates that auto-coordination is supposed to make the coordination better. It doesn't. 2) It has the remarkable side-effect that while taxiing, you can steer by deflecting the ailerons! This is unrealistic and unhelpful; better ways of doing the steering are readily available. 3) While taxiing, you can steer using the rudder in the usual way, overriding auto-coordination ... provided you don't touch the ailerons! That is counterintuitive, undocumented, and unhelpful. The FAA says you should be deflecting the ailerons when taxiing, if there is any crosswind. You must not touch the ailerons, and must hope there is no noise on your joystick aileron axis. This is in addition to the previous requirement for no noise on your rudder axis. = How hard would it be to replace all this with something useful? I notice that several of the aircraft models have yaw dampers. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination broken
On Mon, 2009-12-21 at 17:45 -0700, John Denker wrote: On 12/21/2009 02:36 PM, Anders Gidenstam wrote: It seems to work ok here. Interesting Another thread hijacked. Are you sure you don't have some noisy input device like a joystick or pedals connected that might affect the rudder axis? If two input axes are bound to the same control the last write wins. Thanks for the hint. That helps. It makes sense from a developers' point of view. However ... we still have a bug from the users' point of view. The documentation explicitly mentions the case where the user has a rudder input device but lacks the skill to handle the proper ratio ... and recommends --enable-auto-coordination in this case. If users are required to have zero-noise ailerons and zero-noise rudders, this is quite a serious restriction. This should be prominently mentioned in the documentation. Users will not be pleased. O.K. I guess the documentation should say to remove your rudder pedals when auto-coordinating, or perhaps joysticks configs could pick up on it and not try to drive the rudder. = I just now spent some time looking into this, and found a few surprises. When auto-coordination is turned on: 1) The feature is implemented as an aileron-rudder interconnect with a fixed ratio (half a unit of rudder per unit of aileron) in the aileron-rudder direction and not vice versa. This is not very sophisticated or very useful. In almost every aircraft I can think of, it is literally worse than useless in cruising flight. It makes the coordination worse. If this is the desired behavior, I would hate to see what undesired behavior looks like. This is the behavior in the rudder pedal-less Ercoupe. And that aircraft flies with FAA approval. The documentation indicates that auto-coordination is supposed to make the coordination better. It doesn't. 2) It has the remarkable side-effect that while taxiing, you can steer by deflecting the ailerons! This is unrealistic and unhelpful; better ways of doing the steering are readily available. 3) While taxiing, you can steer using the rudder in the usual way, overriding auto-coordination ... provided you don't touch the ailerons! That is counterintuitive, undocumented, and unhelpful. The FAA says you should be deflecting the ailerons when taxiing, if there is any crosswind. Again, the behavior in the rudder pedal-less Ercoupe. And that aircraft flies with FAA approval. Seriously, if you're trying for an FAA level of realism when taxiing why are you flying with auto-coordination at all? You must not touch the ailerons, and must hope there is no noise on your joystick aileron axis. This is in addition to the previous requirement for no noise on your rudder axis. In my view --enable-auto-coordination is a game feature, and usable for people without a rudder axis control. A group you seem to have completely overlooked. = How hard would it be to replace all this with something useful? I notice that several of the aircraft models have yaw dampers. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination broken
On Mon, Dec 21, 2009 at 9:54 PM, Ron Jensen wrote: In my view --enable-auto-coordination is a game feature, and usable for people without a rudder axis control. A group you seem to have completely overlooked. Yup, it's never been intended to be more than a simple work around for people without rudder pedals or a twist grip on their joystick. A game feature is a good description I think. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] navaids update
Jean == jean pellotier writes: Jean I see the update is done, thanks, (and sorry for windows users Jean waiting for a compatible binary build :) ). It appears that Jean Atlas don't like the new nav.dat.gz, and crash on start up, Jean because some navaids contains empty field for the balise name Jean (i guess it's the balise name). Jean here's a diff where the missing fields are replaced with Jean IXXX. may be the real name is available, but i didn't found Jean the few i checked. Jean and Atlas don't crash anymore. Thanks for the fix. Although it doesn't really matter, Robin is in the habit of indicating no ID with ''. I've written to him about the navaids in question, since having a blank ID field seems to violate his file format specification. Brian -- Brian Schack 19 Xǔchāng Street 2Fphone: 2381 4727 Taipei 100 fax:2381 2145 TAIWAN -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
