Re: [Flightgear-devel] Startup position offsets (fg_init)

[Curtis O. <cur...@gm...>]

Hi James,

I think this was all done intentionally because it's quite common to want to
start a flight simulator on a 5 or 7 or 10 mile approach so you can practice
ILS landing.

The start-offset-m value I believe was added later to account for the
difference in aircraft size.  A starting position that works well to place
the C172 at the end of the runway, might put the back half of the 747 off
the end of the runway.

Regards,

Curt.


On Sun, Aug 24, 2008 at 3:53 PM, James Turner wrote:

> I'm writing some automated testing code for pieces of FG, so that I
> can experiment with changes to various internal bits of code with more
> confidence that I haven't broken anything. These aren't quite unit-
> tests (they test multiple areas of the code at once) and they're
> pretty crude, but any testing is better than none (and quicker than
> manual testing).
>
> Initially I've focused on the various things done by fgInitPosition,
> since this indirectly uses the Navaids and airports data, and
> potentially the environment code.
>
> Doing this, I came across something which seems counter-intuitive to me:
>
> There's a /sim/presets/offset-distance-nm property, which allows
> (logically enough) to offset the start position relative to, for
> example, a runway. What I've found is that for a runway, where the /
> sim/presets/heading-deg is initialised from the runway heading, the
> default azimuth to offset by is the *reciprocal* runway heading. This
> means to start 10nm 'out' from the threshold, one can use a positive
> value of 10 - I expected this to require a negative value.
>
> Line 771 of fg_init.cxx (double azimuth = heading + 180.0;) is the
> relevant piece of logic.
>
> I wonder if this is intentional, since it's the more common case that
> starting 'ahead' of the threshold, but equally it might be a bug - the
> azimuth is inverted to move from the runway centre 'back' to the
> threshold.
>
> Note there's also /sim/airport/runways/start-offset-m, which *is*
> 'forwards' from the threshold.
>
> Anyway, what makes me wonder if there's a bug here is the glideslope
> logic. In the case where a glideslope angle is specified, and also a
> preset altitude, we encounter the code at line 976 of fg_init.cxx.
> Now, the crucial observation is that this code does multiply the final
> distance by -1. As a result, the calculated offset-distance-nm would
> place the start position well down the runway - possibly some way
> beyond it, in fact.
>
> Anyway, that's my analysis, I'd love someone to check my logic and see
> if they concur or disagree.
>
> Regards,
> James
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Flightgear-devel mailing list
> Fli...@li...
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>



-- 
Curtis Olson: http://baron.flightgear.org/~curt/