1,089
edits
PropertyList XML files: Difference between revisions
Jump to navigation
Jump to search
no edit summary
m (→Aliasing combined with inclusion: - corrected xml closing tag) |
No edit summary |
||
| Line 5: | Line 5: | ||
{{Note| | {{Note| | ||
{{FGCquote | {{FGCquote | ||
|any --prop: argument can be just as well added to | |any --prop: argument can be just as well added to defaults.xml<br/> | ||
For that, you only need to understand how properties are mapped to XML space and vice versa: | For that, you only need to understand how properties are mapped to XML space and vice versa: | ||
<syntaxhighlight lang="xml"> | <syntaxhighlight lang="xml"> | ||
| Line 13: | Line 13: | ||
</sim> | </sim> | ||
</syntaxhighlight>these can be expressed using <nowiki>--prop:/sim/foo[0]=teddy and --prop:/sim/foo[1]=tiger</nowiki> | </syntaxhighlight>these can be expressed using <nowiki>--prop:/sim/foo[0]=teddy and --prop:/sim/foo[1]=tiger</nowiki> | ||
You should however not edit $FG_ROOT/ | You should however not edit $FG_ROOT/defaults.xml directly - which should be considered readonly, instead, use $FG_HOME, which will be treated as an overlay (on top of $FG_ROOT/defaults.xml). | ||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=234298#p234298 | |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=234298#p234298 | ||
|title=<nowiki>Re: Command line arguments with 3.4 launcher?</nowiki> | |title=<nowiki>Re: Command line arguments with 3.4 launcher?</nowiki> | ||
| Line 272: | Line 272: | ||
Here are some of the conventions that we've come up with so far, partly ad-hoc (all paths relative to $FG_ROOT): | Here are some of the conventions that we've come up with so far, partly ad-hoc (all paths relative to $FG_ROOT): | ||
* | * defaults.xml - the top-level default preferences | ||
* joysticks.xml - default joystick bindings, included by | * joysticks.xml - default joystick bindings, included by defaults.xml | ||
* keyboard.xml - default keyboard bindings, included by | * keyboard.xml - default keyboard bindings, included by defaults.xml | ||
* Aircraft/*-set.xml - aircraft-specific settings, overriding the defaults in | * Aircraft/*-set.xml - aircraft-specific settings, overriding the defaults in defaults.xml (and joystick/keyboard.xml) | ||
Basically, these are the main 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: | Basically, these are the main 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: | ||
| Line 301: | Line 301: | ||
There are several places to look for properties; one is in the aircraft files, another is all Nasal files, and the last place (and often most useful!) is grepping (searching) through the C++ code. To determine how a property works and what it does often requires looking through any code that uses it. This is a part of FlightGear that we could certainly document better. | There are several places to look for properties; one is in the aircraft files, another is all Nasal files, and the last place (and often most useful!) is grepping (searching) through the C++ code. To determine how a property works and what it does often requires looking through any code that uses it. This is a part of FlightGear that we could certainly document better. | ||
As for the relationship between XML and the Property Tree, in some cases in FG (most notably | As for the relationship between XML and the Property Tree, in some cases in FG (most notably defaults.xml and each AIRCRAFT-set.xml file), the <PropertyList> format directly defines properties in FlightGear's global property tree. In other cases, like the animation files given by /sim/model/path, those do not define properties but the <PropertyList> format is used as a matter of convenience so that FG can parse all of its XML files using the same mechanism and to keep the fundamental structure the same. XML has a lot of different dialects, and having only one for FlightGear really makes it easier, especially since it is very intuitive | ||
== Related content == | == Related content == | ||