On 1/3/07, John Denker <[EMAIL PROTECTED]> wrote:
I'm coming at this from the perspective of an instrument flying
lesson. Being able to reposition the aircraft a few miles from
the initial approach fix saves a lot of time.
And that is a perspective we fully want to support and promote .
The reposition dialog box doesn't do any nasal, it just sets a bunch of
> property values and calls the reset function.
Yeah, I noticed that. The reset function is brutal. It trashes
the pilot's trim settings and who-knows-what-all else. Also,
currently location-in-air.xml trashes the throttle settings. The
code doesn't explain why. Does anybody have an explanation? Is
it to prevent the reset function from doing something even worse?
The flight dynamics are a "black box" as far as FlightGear is concerned.
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.
Instead we tell the flight dynamics to "reset" at a new location in the
world (either on the ground or in the air.) If the reset is in the air,
then there is code to "trim" the aircraft for straight and level flight at
the initial conditions. 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. There are some non trivial issues
because FlightGear can't move your throttle for you.
I'm not sure thinking in terms of "reset" is the right approach.
How about implementing a nice _relocate_ function, splitting it
out as a function unto itself ... just changing location without
resetting other stuff. The reset function can then make a structured
reference to this relocate function.
You'll have to take that one up with the flight dynamics authors. :-) But
realize that any change in the api (if possible to impliment) has to have
underlying support from all the different flight dynamics modules. Also,
you probably want to change location and heading and speed all at the same
time, right? You can't just change any of these instantaneously in the
internal math model without a cascading series of effects. You can't just
instantaneously change the direction of the aircraft 45 degrees without
incurring tremendous side loads for a few moments until everything settles
out. Be aware that in numeric integration, you need to save current value
and last value and perhaps even a few past values to make all the math work
out. This creates a pipeline that is difficult to interrupt without causing
all kinds of side effects.
Doesn't it suffice to look at the /environment/magnetic-variation-deg
node?
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 what I did in my attempt, i.e.
http://www.av8n.com/fly/fgfs/location-in-air.xml
I suspect that if <offset>...</offset> were working at all, the
magnetic-variation-deg part would have been OK. Or am I overlooking
something else?
Xml is xml, but this get's parsed into a hierarchical structure in
FlightGear. However the specific code that interprets that structure needs
to be designed to honor the <offset> tag. Animation code does honor that
tag, but not dialog box code (as far as I know.)
I still don't understand why <offset>...</offset> didn't work. I
would have thought the property-setting that goes on in dialog boxes
would be handled the same way as property-setting everywhere else.
Is there some fundamental limitation here, or just an easy "opportunity
for improvement"?
Possibly there is an opportunity for improvement here, but we would need to
proceed carefully. It seems like it would make a lot more sense to just ask
the user to input the number in the units/frame that the code wants rather
than asking for it in some other frame of reference and then translating
it. There is some complexity and potentially hidden/unexpected behavior
that would be introduced here that I'm not sure I'm 100% comfortable with.
I'd rather we just ask the user to input the number that the code wants in
the first place. Or change the code to require a different unit/frame of
reference and then change the question to match.
Regards,
Curt.
--
Curtis Olson - University of Minnesota - FlightGear Project
http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/
http://www.flightgear.org
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
-------------------------------------------------------------------------
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
