|
From: <mer...@al...> - 2023-06-05 11:21:23
|
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
|