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)
Folders that don't yet seem to be in use:
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:
...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
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 ?
Flightgear-devel mailing list