#2407 Scenery packages: no way to disable airport XML files

If airport XML files, such as Airports/I/C/A/ICAO.{ils,threshold,twr}.xml already exist in TerraSync, or other scenery package, those files will be used if the package that provides this airport does not have them, which means there is no way to use the package's apt.dat and nav.dat without having to copy their data into the XML files.

An attempt to just add empty XML files like:

<?xml version="1.0" encoding="UTF-8"?>

to packages seems to do the trick, but launcher will complain like:

   25.55 [WARN]:navaid     USSSloading ils XML failed:no element found
 at /home/mike/src/git/ap/USSS/scenery/Airports/U/S/S/USSS.ils.xml,
line 2, column 0

etc., and I think I remember it even crashing (but not anymore).

Example: https://gitlab.com/mdanil/USSS/-/tree/master/scenery

[James Turner]

Hmm, this is a side effect of allow per-scenery nav.dat and apt.dat we didn't consider. And quite hard to solve :(

[James Turner]

@frougon any ways we improve this? I can't think of an easy one.

[Florent Rougon]

Hi,

I really don't have time to work on this, but two things come to mind:

1) Naïve. When .dat(.gz) files are loaded, it would be easy to add a flag telling the loader function called from NavDataCache::loadDatFiles() whether a given .dat file corresponds to a custom scenery path or to the default scenery (the latter would be for the all the default .dat files from $FG_ROOT, including the “hot fixes” from $FG_ROOT/Scenery/NavData). The flag would be set from NavDataCache::NavDataCachePrivate::findDatFiles() in flightgear/src/Navaids/NavDataCache.cxx. I think a way to make it known to the loader function called from NavDataCache::loadDatFiles() would be to modify the following struct defined in NavDataCache.hxx:

struct DatFilesGroupInfo {
  DatFileType datFileType;  // for instance, DATFILETYPE_APT
  PathList paths;           // SGPath instances
  std::size_t totalSize;    // total size of all these files, in bytes
};

Instead of a PathList, the 'paths' field would have to be a vector of std::pair or some other struct, so that 'paths' would conceptually be a list of (SGPath, flag) pairs, where 'flag' is what I described above. Once this is done, each loader function could be modified to populate its own list of airports that “have custom scenery apt/nav/fix.dat” (or we could assemble a unique std::unordered_map that gives the three flags for each airport that has custom (apt or nav or fix).dat).

Now, the loading of a given ils.xml file could be disabled if the corresponding airport is in the list of airports that “have custom scenery nav.dat”. Similarly, I imagine (needs verification!) that loading of .threshold.xml files could be disabled if the airport is in the list of airports that “have custom scenery apt.dat”. And ditto for twr.xml, according to what it is used for (I'm fairly ignorant of this, sorry).

Potential downside: this technique would make custom scenery unable to use the .{ils,threshold,twr}.xml files. I haven't checked if these files can effectively be used in custom scenery with the current code, though.

2) I recall some discussions we had about these files (esp. ils.xml ones), so here are some links:

a Not much there, but a pointer to one of the following ones.

b Tells where the ils.xml files are (or were) loaded from; note that according to (a), alignLocaliserWithRunway() is now gone.

c Szymon Acedański is the person who extended my apt.dat-related code to load per-scenery-path fix.dat and nav.dat files; I reviewed and merged it. You can see that he seemed to consider the .ils.xml and .threshold.xml files as annoying, legacy things that we should probably get rid of in the end, since they are at least partially redundant with the .dat files. But this requires someone motivated enough to:

• investigate everything that can be done with these XML files;

• convert those present in TerraScenery to .dat snippets, or show that they can be dropped without bad consequences (I imagine this is not the case, with our old .dat files).

Maybe this should be considered under the light of WS 3.0, too. Sorry if all this is not very concrete.