I found a way to make it do what I want. Here's my version http://www.av8n.com/fly/fgfs/location-in-air.xml and the diff against the cvs version: http://www.av8n.com/fly/fgfs/location-in-air.diff
On 01/03/2007 05:19 PM, Curtis Olson wrote: > Only if you are relocating to a nearby position. If I relocate from MN > to CA (because there's some specific approach or navaid arrangement or > terrain I want to practice with, the difference could be as much as 15 > degrees.) That's a good point. I consider it a bug in what I've written. The canonical behavior is to use the magnetic deviation at the /reference/ point. Can somebody give me a hint how to obtain the deviation at the location of arbitrary navaids and airports? ==================================== On to a different branch of the discussion: > The flight dynamics are a "black box" as far as FlightGear is > concerned. / OK, black box it is. > You can't just change the position instantaneously inside > that black box because that movement would have incredble forces and > velocities associated with it an all sorts of bad stuff could ensue. OK, changing the rules and looking inside the black box now. a) I don't have any hard evidence, but my gut feeling tells me that the overwhelming majority of FDMs do *not* do it that way. I'll bet they integrate the acceleration to get velocity, and integrate velocity to get position (rather than differentiating position to get velocity). b) There are excellent and profoundly fundamental physics reasons why item (a) should be true. The laws of physics are the same in each and every place. You will break the airplane if you move /part/ of it to a new place and leave other parts behind ... but if you move everything together, there should be no observable consequences. This is connected vie Noether's theorem to the law of conservation of momentum, which is about as close to the heart and soul of physics as you can get. The only way the FDM could think there was a big velocity or acceleration is if it tried to /remember/ some sort of "previous" location. In that case we simply beseech the implementers to relocate the "previous" location when they relocate the current location. The rule is really quite simple: relocate everything together! > ) If the reset is in the air, > then there is code to "trim" the aircraft for straight and level flight > at the initial conditions. It does a rather poor job of trimming. Perhaps we can distinguish two cases: -- parking-to-air relocation, versus -- air-to-air relocation. In the latter case, not messing with the throttle, trim, etc., etc. would seem like a reasonable policy. > I believe that part of this trimming routine > sets the throttle position for level flight. If you have a joystick > throttle that will of course take precidence. Correction: /should/ take precedence. Having tried it several times, I assure you that my USB throttle position does not take precedence. The relocation xml code warps the power setting to 0.5, and the USB throttle does not re-assert itself until I _move_ the throttle. This is unrealistic and annoying. Again, for an air-to-air relocation, leaving stuff alone would seem like a reasonable policy. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
