Giles Robertson wrote:
That's much neater than what I suggested. How many of these variables do
we need so that the directory for the a/c does not have to be a
subdirectory of $FG_ROOT?

I haven't yet really looked into aircraft design/development, so I cannot really comment on the paths that are frequently used...

However, after having now looked specifically for various paths
in the corresponding files,  I think it would mainly come down to
providing variables for the following subfolders:

        - $FG_ROOT/Aircraft (possibly also FDM specific ?)

        - $FG_ROOT/Aircraft/Instruments (as well as maybe .../Textures)
        - $FG_ROOT/Aircraft/Instruments-3d

        - $FG_ROOT/Sounds

Folders that don't yet seem to be in use:

        - $FG_ROOT/Instruments
        - $FG_ROOT/Engine

Probably, using variables for the "Fonts" and "Huds" subfolders
would also come in handy ?

However, as a workaround it might be a good idea to simply support
an additional tag within aircraft XML-files that allows for dynamic
variable usage, something like:

<path-alias> <variable>$FG_HUDS</variable> <value>$FG_ROOT/Huds</value> </path-alias>

...might alredy be sufficient and still allow every aircraft
designer to use abitrary -unsupported- paths and variables,
still maintaining path integrity.

It will then very soon become obvious which additional folders
might need to be made available as $FG_* variables by running
a simple grep "FG_" against all aircraft files.

An additional advantage of such a <path-alias> tag would then
be, that it could simply be supported within the preferences.xml
file, too.

That way any future support for new subfolders would merely
come down to adding a corresponding <path-alias> entry to
preferences.xml instead of having to manipulate to source

What do you think ?

--------- Boris

Flightgear-devel mailing list

Reply via email to