Re: [Flightgear-devel] Addon livery handling

[<mer...@al...>]

On 05.06.2023 12:48, James Turner wrote:
>> 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)

Yeah

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

Well... if we would do that with the aircraft dir and with a similar 
approach to the scenery, we'd be changing where aircraft are rn as it'd 
be, to my understanding like
$aircraft-dir/
  - Liveries/
    - /...
  - Aircraft
    - /...

> 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.

Yeah, I get that... but if we really do it like with scenery, we'd break 
backward compatibility, see above!

> 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>

But this isn't the case rn, right?
I've gotta point it directly to the dir containing the aircraft.

> 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.

So it wouldn't break compatibility? *confused*

>> (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.

Can't we just scan for the normal livery xmls? So we don't add another 
thing to look for?


> 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.

Okay, I'll take a look at that fgmeta stuff

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

Great

regards,

Nia