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
code.
What do you think ?
---------
Boris
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
