Wolfram Kuss writes:
> The XML files get IMVHO more and more confusing.
I think that it would be more accurate to say that FlightGear is
getting more sophisticated -- there's more to learn if you want to
customize things, but that's only because there's so much more that
you can customize.
The config files serve many different purposes; using the XML-based
property-list format for all of them helps a lot, since it allows some
common structure and reusable code among all the formats. Imagine if
we had one file format for preferences, a different one for panels
(say, with fixed-length fields), a different one for saving a flight
(perhaps a binary format), another one for sound configuration
(perhaps an INI file), a different one for top-level aircraft
configuration (perhaps CSV), yet another one for configuring 3D models
(perhaps embedded data strings in the 3D files themselves), etc. etc.
> I saw that for example the spelling of z-offset changed twice and I
> was told to use a third spelling. Also, it is not clear to me, what
> the different xmls are for (what does -dpm, -set etc mean? "set" as
> in set options? Don't all xmls set options?) and whether you can
> use all properties in all XMLs and whether you can use all on the
> command line.
Yes, we're still in early days with some of this. Again, these are
config files for totally different purposes, and the fact that they
all use XML is simply a convenience for programmers and customizers.
Here are some of the conventions that we've come up with so far,
partly ad-hoc (all paths relative to $FG_ROOT):
preferences.xml - the top-level default preferences
joysticks.xml - default joystick bindings, included by
preferences.xml
keyboard.xml - default keyboard bindings, included by
preferences.xml
Aircraft/*-set.xml - aircraft-specific settings, overriding the
defaults in preferences.xml (and
joystick/keyboard.xml)
As far as I can recall, these are the *only* files in the base package
that affect FlightGear's main property tree. Other files use the
property-file format for convenience to populate various data
structures, but they do not touch the main tree and are not accessible
through the property browser or through the command-line --prop:
option; it's just a coincidence that they also use the property-list
format:
materials.xml - define the materials (textures, colour,
lighting) for use in the scenery
HUDS/**/*.xml - configuration files to define the various
heads-up displays
Aircraft/*/*-sound.xml - configuration files to define sounds played
for various aircraft
Aircraft/*/Panels/*-panel.xml - configuration files to define 2D
panels for various aircraft.
Aircraft/*/Instruments/*.xml - configuration files for individual
instruments included by the 2D panels.
Aircraft/Instruments/*.xml - ditto
We also use some XML-based formats that do not (yet?) follow the
property-list conventions, including the following:
Aircraft/*/*.xml - JSBSim aero model config files
Aircraft/Aircraft-yasim/*.xml - YASim aero model config files
Engine/*.xml - JSBSim engine and thruster config files
> So, a UI that showed you what you can do would be very nice.
Agreed. Since the property-list format is used by most of the config
files, it will be a relatively easy job to write a generic browser for
all of those formats (like the property browser inside FlightGear).
Then all you need is a simple schema format (which can also be
property-list-based) to say what is and isn't allowed in each format,
and the UI will be dynamically reconfigurable.
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
