The current aircraft config-file approach is a major improvement over
what we had before, since the user can use a single option,
--aircraft, to get the right aero, panel, sounds, etc. However, it is
not easy for the user to provide aircraft-specific overrides. For
example, c172-set.xml has
<panel>
<path>Aircraft/c172/Panels/c172-vfr-panel.xml</path>
<visibility>true</visibility>
</panel>
Let's say that I want to use a different C172 panel by default. If I
simply add
-prop:/sim/panel/path=Aircraft/c172/Panels/c172r-panel.xml
to my .fgfsrc, I'll get the alternative C172 panel for the C172, but
I'll also get it for the C182, C310, DC-3, etc. etc.
There are a couple of possible approaches. The first one is to have
the --aircraft option load properties from a user directory after it
loads from the base package, so that
--aircraft=c172
will first try to load $FG_ROOT/Aircraft/c172-set.xml, then will try
to load something like $HOME/.fgfsd/Aircraft/c172-set.xml for local
overrides (it might actually use a $FG_PATH variable to search any
arbitrary number of directories). This is the most flexible approach,
but will take a bit of work.
A simpler but more ungainly alternative is to use aliases in the
aircraft config files, so that we have something like this:
<aircraft>
<c172>
<panel>
<path>Aircraft/c172/Panels/c172-vfr-panel.xml</path>
<visibility>true</visibility>
</panel>
</c172>
</aircraft>
<panel>
<path alias="/sim/aircraft/c172/panel/path"/>
<visibility alias="/sim/aircraft/c172/panel/visibility"/>
</panel>
and so on. Then, in .fgfsrc, the user can specify
--prop:/sim/aircraft/c172/panel/path=Aircraft/c172/Panels/c172r-panel.xml
and the new panel will be used for the C172 but not for any other
aircraft. No C++ code changes are required for the second approach --
we can start using it right away.
Comments?
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
