Re: [Flightgear-devel] Addon livery handling

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

> On 8 Jun 2023, at 11:21, TheFGFSEagle <the...@gm...> wrote:
> 
> Since it's two separate command line options, I think it would make sense to also have two separate lists.
> 

Well, the alternate view: if we’d always had data dirs since 20+ years ago, we would not add aircraft-dirs as a special case of them. 

(I am leaving scenery out of the discussion, but that is a logical extension)

We do need to keep command line compatibility, but from my perspective best case would be when we move to talking about ‘places where Flightgear looks for stuff’, and the user doesn’t care whether it’s an aircraft or AI model or Livery. That’s already the case internally for many places; even the package download dirs (which right now only download aircraft zips) have the Aircraft/ prefix in their paths, so actually coudl be treated as data-dirs.

(Which also means, downloading Livery zip packages to them will ‘just work’...)

So I would be considering replacing aircraft-dirs with data-dirs as the user-facing concept in the launcher, providing the UI can be made clear enough about what is possible. Keep in mind it’s very easy in the launcher, when adding a path, to do some sanity checks, we already do this for scenery paths (check they contain at least one scenery named dir, eg Objects/terrain/Buildings).

Essentially there’s three kinds of path users try to add using the UI: (again ignoring scenery)

A)	- a specific aircraft dir (eg, C:/Foobar/Boeing-747)
		: this is an error case, but we can detect it easily because the added directory contains a -set.xml file. Right now we show a prompt and block adding it. (There’s a separate argument that it would help usability to support this case)

B)	- a directory containing aircraft directly (eg, C:/MyFavouriteAircraft which contains Boeing-747, Airbus-320, etc)
		: this is supported, becomes an fg-aircraft dir

C)	- a directory containing an ‘Aircraft’ subdirectory (and of course, any other subdirs, such as Liveries or Fonts or Sounds)
		: today we map this to the case above (jumping down one level)

Right now we map case C to B. I’d propose to instead support both B & C, but pass B on to FG as —fg-aircraft, but pass C on as —data 

There are of course some weird edge cases here, where the user adds a path as type B), but then goes and makes a ‘Liveries’ dir next to it; of course we have no way of knowing that happened, and we can’t start searching siblings of added paths for particular names on the user’s file system, that’s invasive behaviour. 

The advantage of having a separate UI box is that it would make the type-B vs type-C paths explicit. I can think of some other ways to do that in a single box (eg, an icon) … but given the UI is scroll-able … hmmm. Not sure.

Kind regards,
James