Re: [Flightgear-devel] auto-coordination broken
Ron Jensen wrote: 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 think all that is required is that we make clear that auto-coordination is designed to help people without any rudder control axis, and that a proper rudder axis (or even a twist axis on a joystick) is preferable. I'll do that in the documentation. However, to hijack the thread further ... ;) There was some previous discussion about the fact that we have manual controls and some autopilots all mapping to a single set of control properties (/controls/flight/[aileron|elevator|rudder]). This is realistic, but because of the limitations of the simulator environment, this can cause them to fight for control - the classic example being someone moving their joystick while the autopilot is switched on. I think if we every fix that, we should consider auto-coordination as another channel into that control mixer. -Stuart -- 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
S Andreason wrote: 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. From the sounds of things, you're attempting to use the Generic Autopilot, GPS and Route Manager on the c172p. That won't work because the c172p has a KAP140 A/P, and no GPS has been integrated. So, I wouldn't expect the Route Manager or GPS to work at all. Just as the Autopilot-Autopilot Settings menu item is disabled for the c172p, so I think these keys should be disabled (and possibly any other aircraft that disable that menu item), or re-assigned to the equivalent KAP140 functions. I'll investigate how to do that, and also ensure that our documentation makes clear that aircraft may not implement the entire suite of Route-Manager/GPS/AP. Of course, once we have a C172 with a G1000 panel, then we'll have support for these goodies ;) 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. The wing leveler and heading autopilot that are part of the KAP140 work well for the c172p. However, using the generic autopilot instead is not something that I would expect to work, so they should be disabled for the c172p. Effectively, you're using the wrong autopilot. 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. AFAIK the c172p does not contain any GPS, and certainly not one that's integrated with the KAP140 AP. And if I can't figure it out, I doubt any first-time flyers will. The tutorials section of the manual describes how to use the KAP140 autopilot in some detail. http://www.flightgear.org/Docs/getstart/getstartch9.html#x15-1650009.3.1 -Stuart -- 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
Moving the joystick or throttle should override the autopilot/autothrotle and cause it to disconnect. Yaw dampers, stick pushers and other stability augmentation demands are added to the pilots´s joystick/rudder input, they would not normally override it. In a training mode there is a case for letting the autopilot automatically re-engage when the pilot has stopped playing around so that the aircraft returns to stable flight. The Ercoupe and certain other aircraft (e.g. TSR2) may have an aileron-rudder interconnect, but this is very aircraft specific and should be part of the aircraft FCS model. Surely the deadspace function of the joystick configuration is meant to cope with noise problems.. Alan -- From: Stuart Buchanan stuart_d_bucha...@yahoo.co.uk Sent: Tuesday, December 22, 2009 9:35 AM To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] auto-coordination broken Ron Jensen wrote: 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 think all that is required is that we make clear that auto-coordination is designed to help people without any rudder control axis, and that a proper rudder axis (or even a twist axis on a joystick) is preferable. I'll do that in the documentation. However, to hijack the thread further ... ;) There was some previous discussion about the fact that we have manual controls and some autopilots all mapping to a single set of control properties (/controls/flight/[aileron|elevator|rudder]). This is realistic, but because of the limitations of the simulator environment, this can cause them to fight for control - the classic example being someone moving their joystick while the autopilot is switched on. I think if we every fix that, we should consider auto-coordination as another channel into that control mixer. -Stuart -- 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] parking.xml files under scenery/Airports
On Mon, 21 Dec 2009 22:17:03 +0100 Csaba Halász csaba.hal...@gmail.com wrote: I wonder if these files are there by mistake or if there is some reason. Only thing I know 'bout them is Martin's mail bout this: http://sourceforge.net/mailarchive/message.php?msg_name=g87kri%24u4q%241%40osprey.mgras.de hth Alex -- Alex D-HUND f...@beggabaur.de -- 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/22/2009 02:35 AM, Stuart Buchanan wrote: I think all that is required is that we make clear that auto-coordination is designed to help people without any rudder control axis, and that a proper rudder axis (or even a twist axis on a joystick) is preferable. On 12/21/2009 08:59 PM, Curtis Olson wrote: 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. In order to document it as a game feature we need some basic information. What do gamers actually use the auto-coordination feature for? -- what game? -- what model aircraft? -- what benefit are they getting from this feature? Out of the 358 aircraft available in my copy of FG, I can think of only a handful that I would expect to have better coordination with auto-coordination enabled. No, the Ercoupe is not one of them; it has an aileron/rudder interconnect even without this feature, and does not benefit from the feature. Even the Sopwith Camel, which in the Real World was notorious for its unharmonious controls, in the Sim World benefits only slightly from the auto-coordination feature. I doubt most gamers would notice. Most modern aircraft come from the factory with reasonably harmonious controls. That is, under cruise conditions, they fly just fine with feet on the floor (as opposed to feet on the pedals). Such aircraft handle distinctly worse with auto-coordination turned on. As for the default c172p, auto-coordination might not make it much worse ... but that's only because the model's basic aerodynamics is so messed up. It has an order of magnitude too much adverse yaw at cruise. Rather than messing with auto-coordination and all the attendant limitations and bad side-effects, it would be mch easier to use a saner set of aero coefficients ... especially when you consider that some users have rudder pedals, and use them, and want to use them with more realism. A patch to improve the c172p is available. If we are going to document the auto-coordination feature, we must document the restrictions. The user must a) have no rudder-axis input devices, or b) unplug all rudder-axis devices, or c) make sure any rudder-axis devices have zero noise, or d) edit the .xml driver to discard rudder events, or e) never use the auto-coordination feature Chez moi the preferred option is (e). The only other option would be (d), since my joystick has an integrated rudder axis that cannot be unplugged. Its noise level is just low enough that when sporadic events come in, they are surprising. I suspect that most gamers would be pretty unhappy with options (c) and (d). I suspect that most people on this list stick with option (e). Also the user must: x) make sure the aileron input device has zero noise, or y) rely on CWS (control wheel steering) to the exclusion of other steering features (e.g. keyboard insert/enter), or z) never use the auto-coordination feature. All in all, it's hard to come up with plausible use-case scenarios for this feature. We've heard how this feature was intended to be used. If anybody knows how it is actually used, please let us know. As I asked before, how hard would it be to implement a feature that actually improved coordination, perhaps something that works more like a yaw damper? Or is it better to forget about the whole topic, and let rudderless gamers rely on the natural feet-on-the-floor behavior of the aircraft? = I won't bother to ask why some people consider a discussion of auto-coordination to be hijacking an auto-coordination thread. I reckon we all know the answer to that one. On 12/22/2009 03:04 AM, Alan Teeder wrote in part: Yaw dampers, stick pushers and other stability augmentation demands are added to the pilots´s joystick/rudder input, they would not normally override it. Quite so. Also, the aileron/rudder interconnect on aircraft such as the Beech Bonanza is springy such that you can overpower it using the obvious technique, by pushing the yoke one way and pushing the pedals the other way. This allows you to slip the aircraft e.g. for a crosswind landing. The auto-coordination feature does not provide a good model of this. Evidently it was never intended to do so. The pilot is out of luck if he needs to make a crosswind landing. This makes a certain amount of sense from the developers' viewpoint, but from the users' viewpoint it is all quite mysterious and unhelpful. -- 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
Re: [Flightgear-devel] parking.xml files under scenery/Airports
Hi Alex, Csaba, On Tuesday 22 December 2009 12:44:41 pm Alex D-HUND wrote: On Mon, 21 Dec 2009 22:17:03 +0100 Csaba Halász csaba.hal...@gmail.com wrote: I wonder if these files are there by mistake or if there is some reason. Only thing I know 'bout them is Martin's mail bout this: http://sourceforge.net/mailarchive/message.php?msg_name=g87kri%24u4q%241%40 osprey.mgras.de By default, FlightGear reads parking positions from AI/Airports/[ICAO]/parking.xml. However, in order to be more flexible in developing scenery, we are currently working on moving a lot of data to the scenery tree. This consists of startup info, but also the ground networks, as well as a few other files related to AI (rwyprefs.xml). Because the latest release of FlightGear doesn't support reading data from the scenery tree, we are still providing limited support for adding ground networks to the base package. With flightgear/CVS, you can choose which set of data to use, by changing the property: /sim/use-custom-scenery-data Whenever this boolean property is set to false, ground network data will be read from AI/Airports/[ICAO], and when set to true, it is read from scenery/Airports/[I]/[C]/[A]/[ICAO].groundnet.xml. Currently, this property controls the following: - Reading of startup information: When set to true, the runway dimension data in apt.dat are overwritten by those in the scenery/Airports/[I]/[C]/[A], so that we have more flexibility in regenerating the terrain tiles without having to force the updated runway positions back into apt.dat. - Use of ground networks - the runway use files. Currently the /sim/use-custom-scenery-data property defaults to false. Hope this helps, Cheers, Durk Cheers, Durk - -- 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] Generic autopilot issues
On 21 Dec 2009, at 18:55, Curtis Olson wrote: 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. That's really an orthogonal issue - I only use the airport location if you neglect to specify a runway. For using these features as a flight planning tool, the first waypoint is my departure runway, which sequences when you cross the threshold / midpoint (not perfectly, I have a known bug to fix in that area). Adding the *destination* airport as a waypt seems useful, even if no runway is selected, because it yields a useful trip distance estimate (and hence, ETA), and I assume people can thus navigate to the vicinity of their destination, and conduct whatever kind of approach they like. A few things that will certainly help: - not adding the departure airport if no runway is selected - not adding the departure airport for an in-air route activation I'll do these today (hopefully) - I already fixed the GPS - autopilot drive, and have been doing some reading and testing with the generic autopilot XML, dialog and code. There's quite a few things behaving strangely (especially in the Alphajet), and I don't think most of them are my fault - famous last words! - but I'm getting to grips with it. Will post back here once I have some more definite conclusions, especially regarding why heading hold is being so strange. Incidentally, the PID parameters in the generic autopilot are pretty bad for the alphajet (and many other aircraft, I guess). It'd be lovely if there was a way to tune the response rates for a particular aircraft, but still inherit the basic controller structure (i.e the control laws) from the generic definition. I don't suppose the Autopilot XML loading code could cope with that? 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] auto-coordination broken
On 22 Dec 2009, at 12:23, John Denker wrote: I won't bother to ask why some people consider a discussion of auto-coordination to be hijacking an auto-coordination thread. I think that comment was because you replied to the 'autopilot broken' thread to start the auto-coordination discussion. At least, that's what my mail client thinks happened, in terms of its threading display. 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] Generic autopilot issues
On Tue, Dec 22, 2009 at 8:10 AM, James Turner wrote: 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. With the old route manager, the first way point is where I want to go for my first destination, because I just put it in there with that specific goal in mind. The 2nd waypoint is also where I want my second destination to be, again, because I just put it there. Same for all the other way points. Another nice feature we used to have in the original route manager was the ability to insert and delete waypoints from the middle of the route, allow us to update and change the route in mid-flight if we changed or mind (or something like weather changed it for us.) What I liked about the old route manager is I could decide I want to fly to A then B then C then D, I added those waypoints and off I go. I feel like I have to fight the new system to get it to do something like that, and then every time I open up the dialog box, I'm never sure if it's going to change the route on me or add the original airport back in again (even if it might already be there.) I haven't tried using the route manager in a few weeks now, so perhaps some of these things were bugs that are now resolved. I think there was a simplicity and a determinism in the original system (as unrealistic as that was) and I struggle with the new system trying to understand how to get it to work and not make unexpected changes or additions to the route. That's really an orthogonal issue - I only use the airport location if you neglect to specify a runway. Ok, for the original route manager when you specified an airport as a waypoint, you got this computed center point (average or runway center points.) For using these features as a flight planning tool, the first waypoint is my departure runway, which sequences when you cross the threshold / midpoint (not perfectly, I have a known bug to fix in that area). Adding the *destination* airport as a waypt seems useful, even if no runway is selected, because it yields a useful trip distance estimate (and hence, ETA), and I assume people can thus navigate to the vicinity of their destination, and conduct whatever kind of approach they like. Right ... I've always flown with the mindset of the route manager getting me to the airport and then at some point I'll break off the route and setup the approach to my own chosen runway and land manually. A few things that will certainly help: - not adding the departure airport if no runway is selected - not adding the departure airport for an in-air route activation I'll do these today (hopefully) - I already fixed the GPS - autopilot drive, and have been doing some reading and testing with the generic autopilot XML, dialog and code. There's quite a few things behaving strangely (especially in the Alphajet), and I don't think most of them are my fault - famous last words! - but I'm getting to grips with it. Will post back here once I have some more definite conclusions, especially regarding why heading hold is being so strange. Incidentally, the PID parameters in the generic autopilot are pretty bad for the alphajet (and many other aircraft, I guess). It'd be lovely if there was a way to tune the response rates for a particular aircraft, but still inherit the basic controller structure (i.e the control laws) from the generic definition. I don't suppose the Autopilot XML loading code could cope with that? The alphajet has it's own autopilot configuration. I wouldn't characterize it as generic since it is specific for this aircraft. Perhaps some of the gains could be tweaked, but it behaves pretty well for me. One thing to note is that many YASim jet aircraft can be over speeded at lower altitudes and if you do that, you can get really weird negative stall type effects ... especially if you have flaps deployed. This has always been a gripe of mine with the YAsim flight dynamics engine. Generic autopilots are difficult. Different aircraft have wildly different systems and capabilities. Different types of sensors, actuators, etc. A generic autopilot would be about as realistic as our original route manager. :-) And then stuffing in about 50-60 tunable parameters into a generic structure also sounds pretty messy. I've always preferred the autopilot to be defined on a per-aircraft basis, and if the aircraft author wants to copy a config file from another similar aircraft as a starting point, that's fine. 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
Re: [Flightgear-devel] Generic autopilot issues
James, From what I've read, and like the original, your route manager uses the airport center point as the destination. What is the reason for selecting a runway? If the destination point is center-runway of the specified runway, I'm not sure of the benefit over center-airport. Like you mentioned I would tend to break off to enter a manual approach. An option to consider : At the moment if I were to choose a runway, my preference would be to have the destination point be the turn-in point for an ils approach, for both ils equipped and non- precision approach equipped airports. (The documentation would need to reflect the difference in points so the user realized it) Just a thought- Peter Sent from Smooth Water Sports, your Malibu Boat Dealer -Original Message- From: James Turner zakal...@mac.com Date: Tue, 22 Dec 2009 14:10:25 To: FlightGear developers discussionsflightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Generic autopilot issues On 21 Dec 2009, at 18:55, Curtis Olson wrote: 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. That's really an orthogonal issue - I only use the airport location if you neglect to specify a runway. For using these features as a flight planning tool, the first waypoint is my departure runway, which sequences when you cross the threshold / midpoint (not perfectly, I have a known bug to fix in that area). Adding the *destination* airport as a waypt seems useful, even if no runway is selected, because it yields a useful trip distance estimate (and hence, ETA), and I assume people can thus navigate to the vicinity of their destination, and conduct whatever kind of approach they like. A few things that will certainly help: - not adding the departure airport if no runway is selected - not adding the departure airport for an in-air route activation I'll do these today (hopefully) - I already fixed the GPS - autopilot drive, and have been doing some reading and testing with the generic autopilot XML, dialog and code. There's quite a few things behaving strangely (especially in the Alphajet), and I don't think most of them are my fault - famous last words! - but I'm getting to grips with it. Will post back here once I have some more definite conclusions, especially regarding why heading hold is being so strange. Incidentally, the PID parameters in the generic autopilot are pretty bad for the alphajet (and many other aircraft, I guess). It'd be lovely if there was a way to tune the response rates for a particular aircraft, but still inherit the basic controller structure (i.e the control laws) from the generic definition. I don't suppose the Autopilot XML loading code could cope with that? 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] parking.xml files under scenery/Airports
On Tue, Dec 22, 2009 at 2:35 PM, Durk Talsma d.tal...@xs4all.nl wrote: Whenever this boolean property is set to false, ground network data will be read from AI/Airports/[ICAO], and when set to true, it is read from scenery/Airports/[I]/[C]/[A]/[ICAO].groundnet.xml. Exactly. So the file scenery/Airports/[I]/[C]/[A]/[ICAO].parking.xml will *never* be loaded, as FG only looks for groundnet.xml. parking.xml files should only live under AI/Airports and not under scenery/Airports. Hence my question about K/N/U/KNUQ.parking.xml or L/F/P/LFPG.parking.xml. -- 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] parking.xml files under scenery/Airports
On Tuesday 22 December 2009 06:10:48 pm Csaba Halász wrote: Exactly. So the file scenery/Airports/[I]/[C]/[A]/[ICAO].parking.xml will *never* be loaded, as FG only looks for groundnet.xml. parking.xml files should only live under AI/Airports and not under scenery/Airports. Hence my question about K/N/U/KNUQ.parking.xml or L/F/P/LFPG.parking.xml. Oh sorry, I totally misread your question... As far as I know, the files that are still called [ICAO].parking.xml are the ones that were initially imported from the AI directory, while setting up the new infrastructure. Subsequently, we agreed on a better name, and the files that are still called parking are the ones that I still need to rename / improve / verify. the file for LFPG is probably still the original one that I made; I'm not sure, off the top of my head, where KNUQ.parking.xml comes from. But, I'll have a look tonight/tomorrow. Cheers, Durk -- 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
Stuart Buchanan wrote: The wing leveler and heading autopilot that are part of the KAP140 work well for the c172p. However, using the generic autopilot instead is not something that I would expect to work, so they should be disabled for the c172p. Agreed. And the help keys removed from the help window. And [F11] disabled? Effectively, you're using the wrong autopilot. Ah, that makes sense now. Thanks, 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,
James Turner wrote: 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. Yes, and it works now. Thank you very much! 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] Generic autopilot issues
On Tue, 2009-12-22 at 14:10 +, James Turner wrote: A few things that will certainly help: - not adding the departure airport if no runway is selected - not adding the departure airport for an in-air route activation Perhaps a quicker workaround, just set the /autopilot/route-manager/current-wp to a higher value, I think it is better to be consistent with what WPs are always in the route, and so it should always contain a departure/arrival airport. S. -- 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 Tuesday 22 Dec 2009, Alan Teeder wrote: [snip...] The Ercoupe and certain other aircraft (e.g. TSR2) may have an aileron-rudder interconnect, but this is very aircraft specific and should be part of the aircraft FCS model. The YASim BAC-TSR2 doesn't/didn't/shouldn't have an aileron-rudder interconnect. In fact, it only has flaps on the wing and lacks proper ailerons and instead it uses the slab elevons for roll control (although fully floating, in real life the fully floating tailplanes also incorporated powered flaps but these aren't modelled in the YASim BAC-TSR2 config. The tailfin lacks any actuated control surfaces but is entirely fully floating, like the tailplanes, so the whole thing twists. Anyway, I didn't include any link between the roll and rudder controls in the BAC-TSR2. Also, I was under the impression that auto-coordination was a JSBSim feature and did nothing when enabled for other FDMs. LeeE -- 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] RFC: Committing conditional compile patch for ATCDCL
Hi All, As we've discussed before, I'm working on merging the old ATC/AI code from David Luff (ATCDCL) with our AIModels system. As part of the rewrite, I have added a new --disable-atcdcl option to my configure script. The default behavior is that ATCDCL will be enabled. Disabling the build of this library currently results in a broken compile, because the alternate code isn't ready yet. Since the default behavior doesn't really affect the compile process, I'm wondering whether there would be any objections to committing it to CVS. I'm asking, because I recently saw some patches being applied to ATCDCL, and I don't want my development tree to get out of sync too much. I don't see any obvious negative side effects, but this seems to my a case of better being safe than sorry. :-) Cheers, Durk -- 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
