Re: [Flightgear-devel] Addon livery handling

[James T. <ja...@fl...>]

> On 5 Jun 2023, at 11:18, mer...@al... wrote:
> 
>> I’m not sure what you mean by ‘additional layer' here, can you explain a bit more?
> 
> Another directory where stuff is in.
> Like $dir/Liveries/<aircraft-id> instead of simply using just $dir/<aircraft-id>

If we don’t have some agreed prefix name, then we can *only* have liveries in these directories; that what I try to avoid. Same idea as a scenery directories; we are able to add new types of data (navdata and buildings, most recently) without breaking anything. When we don’t have some intermediate directory name, the only way to know the contents type is:

A)	- explicitly stating that ’the only thing that can go in location X’ is liveries

(which is maybe your preferred approach)

B)	- have an agreed sub-directory name in one of the existing list-of-directories (scenery, aircraft or data)

C) - actually scan + parse the contents of each sub-dir which is *very* slow, especially on machines without an SSD or with anti-virus checks on file access

My concern with A) is we end up with a lot of different ‘lists of paths’ in the launcher UI, in the environment, in the config option list via —help. So I prefer B, especially since we’re already doing it for scenery paths with good success and (as I see) low user problems.

In principle I think the least confusing thing for the user would be to have a single ‘list of directories where Flightgear will look for stuff’: i.e if we only had ‘data directories’. We do already have the three kinds of directory though, so I picked the closest existing type (fg-aircraft) in my suggestion to you.

If/when we ever add support for say standalone AI models, they would likely go in

	$aircraft-dir/AIModel/<aircraft-id>

*Technically* aircraft actually go in the ‘Aircraft’ subdirectory of an fg-aircraft dir, i.e

	$aircraft-dir/Aircraft/<aircraft-id>

that’s the structure we use in FGData and FGAddon explicitly (and when we unpack packages into the downloaded-aircraft-location). Due to some poor decision by me a few years ago, we do allow adding aircraft paths *without* an ‘Aircraft’ dir inside, but we normalise to a standard format internally.

> 
>>> (Tho the ultimate goal would be a launcher like thing to download
>>> liveries automatically like for aircraft)
>> The package system can absolutely support that, only rule for a package is that it has some kind of property-xml that says what is inside the package so it can be indexed.
> 
> You mean like the hangar file for aircraft?


Technically it’s an (XML) catalogue of packages, right now the only package type is ‘aircraft’ but there is nothing preventing different types, or mixing aircraft and livery packages in a single catalogue.

To support this we’d likely extend the python scripts in FGMeta which currently scan an Aircraft/ tree for -set.xml files, to also scan the Livery/** dirs for their XMLs: probably called livery-metadata.xml to be consistent with the naming scheme Florent used for add-ons.

So we’d have

	$fg-aircraft-dir/
		Liveries/
			<aircraft-id>/
				livery-metadata.xml

			<another-aircradft-id>
				livery-metadata.xml

			…

And it would be easy to adapt the python scripts to create packages for these.

Since the package API is already exposed to Nasal, making a ‘install liveries for this aircraft’ UI would be pretty easy then.

Kind regards,
James