Jim Wilson writes:
> The addition of this code on 10/23 to fg_init.cxx is what started the problem
> with the aircraft crashing on teleports:
>
> cout << "fgInitPosition()" << endl;
> double gs = fgGetDouble("/sim/presets/glideslope-deg")
> * SG_DEGREES_TO_RADIANS ;
> double od = fgGetDouble("/sim/presets/offset-distance");
> double alt = fgGetDouble("/sim/presets/altitude-ft");
>
> Further down in the funciton the onground flag gets set:
>
> // determine if this should be an on-ground or in-air start
> if ( fabs(gs) > 0.01 || fabs(od) > 0.1 || alt > 0.1 ) {
> fgSetBool("/sim/presets/onground", false);
> } else {
> fgSetBool("/sim/presets/onground", true);
> }
>
> Is this an abuse of the property system (from a design standpoint)? Somehow,
> somewhere the altitude as determined by this routine (fgInitPosition) is
> getting put into /sim/presets/altitude.
The way this was intended to work is that if you want to start on the
ground, you should set the altitude to -9999.
I think what we probably need is a slightly smarter set position
dialog box that knows how to set up the properties for what the user
is trying to do. If you specify a new airport and there are some
random left over values from a previous postition reset, weird things
are going to happen. What we are presented with now is a really raw
dialog box that exposes all the relevant properties, but doesn't
enforce or explain the rules so the user is very likely to stumble.
I have an external gui (perl-tk) setup for another project and it is
able to do some prevalidation of input data, and then when the user
clicks ok, it sorts out how to setup the specific /sim/presets
properties. That has been working really well for me.
However, exposing the raw /sim/presets properties to the end user
leaves a lot of room for them to make mistakes.
> If you select an airport, the altitude of the starting position of that
> airport gets placed into /sim/presets/altitude. Then when you teleport the
> above code detects the value, and sets "onground" to false. This causes the
> reinitialized aircraft to be dangled in the air at the altitude of the
> previous airport.
>
> Backing out this patch fixes the teleport problem.
But re-introduces other problems ... :-)
Is there any way to build smarter, higher level dialogs with our
current menu system, or are we stuck just being able to manipulate the
low level properties?
Maybe what we need is several menu items such as:
start at an airport on the ground
start relative to an airport in the air
start relative to a fix in the air
Then each of these could have separate call back functions tied to the
"ok" which configured the /sim/presets/ tree correctly before calling
the presets-commit function.
> Isn't the advantage/purpose of the property tree to offer and easy interface
> through the command line, network connections, and configuration files?
> (Rather than short-cutting C++ class definitions, that is.)
It's getting pretty late here, so I'm not following what you are
getting at with this last paragraph.
Regards,
Curt.
--
Curtis Olson HumanFIRST Program FlightGear Project
Twin Cities curt 'at' me.umn.edu curt 'at' flightgear.org
Minnesota http://www.flightgear.org/~curt http://www.flightgear.org
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
