Re: [Flightgear-devel] Helipad thresholds

[David M. <dav...@gm...>]

That sounds like the right plan, Florent. If scenery has overridden an
airport in a custom apt.dat, then only supporting files (thresolds, etc)
from the same place should apply.

D

On Thu, Jun 29, 2023, 5:22 p.m. Florent Rougon <f.r...@fr...> wrote:

> Hi David,
>
> I'll tell what I believe based on a quick look at the code, but beware
> that I'm not familiar at all with the startup position and
> {threshold,ils,...}.xml loading code. I had to use gdb to “quickly” find
> which-place-I-know calls FGAirport::loadSceneryDefinitions(). Here it
> is, but there may well be other cases:
>
> #0  FGAirport::loadSceneryDefinitions() const (this=0x555559908ea0)
>     at .../flightgear/src/flightgear/src/Airports/airport.cxx:606
> #1  0x0000555555829394 in FGAirport::loadRunways() const
> (this=0x555559908ea0)
>     at .../flightgear/src/flightgear/src/Airports/airport.cxx:535
> #2  0x000055555582809e in FGAirport::findBestRunwayForHeading(double,
> FGAirport::FindBestRunwayForHeadingParams*) const
>     (this=0x555559908ea0, aHeading=270, parms=0x0)
>     at .../flightgear/src/flightgear/src/Airports/airport.cxx:205
> #3  0x00005555561115c9 in
> flightgear::setPosFromAirportIDandHdg(std::string const&, double)
> (id="LFNA", tgt_hdg=270)
>     at .../flightgear/src/flightgear/src/Main/positioninit.cxx:173
> #4  0x00005555561155d4 in flightgear::initPosition() ()
>     at .../flightgear/src/flightgear/src/Main/positioninit.cxx:663
> #5  0x00005555560f341c in fgIdleFunction() ()
>
> David Megginson <dav...@gm...> wrote:
>
> > 1. A threshold file will always override apt.dat for starting position
> on a
> > runway.
>
> This seems to be the case.
>
> > 2. If the Terrasync scenery has a threshold file, and my custom scenery
> has
> > only apt.dat, the Terrasync threshold file will determine the aircraft
> > starting position.
>
> Ditto.
>
> > Does that sound correct? It matches my observations, at least.
>
> *.threshold.xml files and similar seem to be located using
> XMLLoader::findAirportData() — see for instance
> flightgear/src/Airports/airport.cxx:613 in next.
> XMLLoader::findAirportData() is easy to understand: it goes through each
> non-empty element of globals->get_fg_scenery() in sequence and returns
> the first existing path that follows the naming pattern
> Airports/I/C/A/ICAO.⟨stem⟩.xml using the specified ICAO and ⟨stem⟩ (such
> as “threshold”).
>
> Maybe we could:
>
> 1) Extend APTLoader::readAptDatFile() to store in a global map M — or
>    some better place, I don't know — made of (ICAO, p) pairs. Each pair
>    would correspond to an airport for which the actually-used apt.dat
>    data comes from p/NavData/apt/whatever.dat[.gz].
>
> 2) Based on this map, XMLLoader::findAirportData() could be modified to
>    only consider XML files under scenery path M[ICAO] when the ICAO is
>    in map M.
>
> The effect would be that if an airport has its data defined by an
> apt.dat snippet from custom scenery, only “corrective XML files”
> (threshold, ils, procedures, etc.) from the same scenery path would be
> used for it. Airports for which the data comes from
> $FG_ROOT/Airports/apt.dat.gz would still benefit from “corrective XML
> files” located in any scenery path because there is no “NavData”
> component in $FG_ROOT/Airports/.
>
> This is maybe a bit complicated but that's the simplest idea that comes
> to mind in order to achieve what I perceive as the desired goal...
>
> Regards
>
> --
> Florent
>
>
> _______________________________________________
> Flightgear-devel mailing list
> Fli...@li...
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>