FlightGear 的 PropertyList XML

安装指南

1. ClawHub CLI 从源直接安装技能的最快方式。
   npx clawhub@latest install propertylist-xml
2. 手动安装 将技能文件夹复制到以下位置之一
   全局模式
   ~/.openclaw/skills/
   工作区
   /skills/
   优先级：工作区 > 本地 > 内置
3. 提示词安装 将此提示词复制到 OpenClaw 即可自动安装。
   请帮我使用 Clawhub 安装 propertylist-xml。如果尚未安装 Clawhub，请先安装（npm i -g clawhub）。
   更倾向于下载？
   获取包含原生技能文件的ZIP压缩包。
   下载技能 (.zip)

什么是

PropertyList XML 是 FlightGear 用于表示属性树、飞机设置、控制、仪表、面板、声音、动画和其他模拟器数据的结构化配置格式。此 Openclaw Skills 资源解释了必需的 PropertyList 结构、属性类型、隐式和显式索引、归档值、外部文件包含、别名以及 CDATA 区域。
它还记录了 SimGear 表达式和条件，使开发者和飞机创造者能够直接在 XML 中实现数学公式、插值表、裁剪、比较、布尔逻辑和可复用的参数化配置。该指南有助于保持干净、可扩展的 FlightGear 项目，同时将基于 PropertyList 的文件与 JSBSim 和 YASim XML 格式区分开来。

应用场景

创建或编辑 FlightGear 飞机 -set.xml 、FDM、仪表、面板、声音、HUD、场景和动画配置文件。
在可预测的属性树中存储字符串、数字、布尔值和其他模拟器属性。
通过包含外部 PropertyList 文件并在包含点重写参数来构建可复用的配置。
使用行为类似于符号链接的 alias 保持相关属性同步。
userarchive
属性在 FlightGear 会话之间持久化用户特定设置。
使用隐式顺序或显式
n
属性将重复的属性表示为索引节点。
在 CDATA 区域内安全地嵌入 Nasal 或其他非 XML 文本。
实现数学计算，例如求和、乘积、乘方、三角函数、裁剪、舍入变通方法和表插值。
添加运行时逻辑，利用
、
、
、
等运算符比较属性、计算表达式并组合条件。
组织飞机配置，以便在 YASim 和 JSBSim 飞行动力学模型之间复用。

工作原理

创建一个根元素为
的结构良好的 XML 文档。
使用表示 FlightGear 属性树中路径的标签名称添加子属性节点。
分配可选的类型属性，例如 string、float、bool 或其他支持的类型；未指定类型的数值默认为字符串或未指定值，并可能被透明转换。
将重复的子名称表示为索引节点，可以按文档顺序隐式表示，也可以使用 n="0"、n="1" 及后续索引显式表示。
当数值应跨 FlightGear 会话持久化时，用 userarchive="y" 标记它们。
使用 include 属性扩展现有配置，然后在包含文件中重写或添加嵌套属性。
当两个属性路径必须保持同步时，使用自闭合节点（如 ）创建别名。
结合 include 和 alias 来参数化可复用文件，允许调用方提供每个飞机或每个仪表的属性路径。
将包含 XML 标记（尤其是 Nasal 代码）的嵌入文本包裹在 CDATA 区域中，以避免 XML 实体转义。
为计算添加 树，使用诸如 、
、、
、、 或 等运算符。
使用属性、数值、表达式以及诸如 、、、 和 等运算符，为比较和布尔决策定义 树。
将每个文件放在适当的 FlightGear 目录中，并记住 JSBSim 和 YASim 配置文件使用的是它们自己的 XML 格式，而不是通用的 PropertyList 约定。

配置指南

Setup and configuration
This skill is a technical reference rather than an installable runtime package. No additional dependency or command-line installation is required. Add it to the coding agent's skill collection, then use the documented conventions when creating or reviewing FlightGear XML files.
Identify whether the target file is a PropertyList-based configuration or a separate JSBSim/YASim XML format.
Start a PropertyList document with the XML declaration and
root element.
Place shared defaults and reusable parameters in separate XML files where appropriate.
Connect reusable files with the include attribute and provide local overrides beneath the included node.
Use explicit property types, indexes, aliases, expressions, and conditions only where they clarify the intended property-tree behavior.
Store aircraft-specific files under the relevant $FG_ROOT/Aircraft hierarchy and follow the project's established naming conventions.
Test included paths, property aliases, expression operand order, ascending table inputs, and condition operands in FlightGear.
Minimal file
Hello FlightGear!
Project conventions
defaults.xml: top-level default preferences.
joysticks.xml: default joystick bindings, commonly included by defaults.xml.
keyboard.xml: default keyboard bindings, commonly included by defaults.xml.
Aircraft/-set.xml: aircraft-specific settings that override defaults.
materials.xml, HUD files, sound files, panel files, instrument files, and model animation files: additional PropertyList-based configuration uses.
FlightGear 的 PropertyList XML 数据架构与分类体系
Document structure
Element or attribute Purpose
Required root element for a PropertyList XML file.
Property tag name Defines a node in the FlightGear property tree.
type Optionally declares the property's type, such as string, float, bool, or double where supported.
n Explicit index for repeated properties. Without it, identical sibling names are indexed by appearance order.
userarchive Marks a property for persistence between FlightGear sessions; use y to enable archiving.
include Loads another PropertyList file and enables inheritance-style reuse and overrides.
alias Makes a property path reference another property so both remain synchronized.
File taxonomy
Core property-tree configuration: defaults.xml, joysticks.xml, keyboard.xml, and aircraft -set.xml files.
Scenery and interface data: materials.xml and HUDS/**/.xml.
Aircraft presentation and behavior: Aircraft//-sound.xml, Panels/-panel.xml, Instruments/.xml, and Models/.xml.
Separate simulator XML formats: JSBSim aerodynamic and engine files plus YASim aerodynamic configuration files. These are XML, but they do not follow the general PropertyList conventions.
Expression schema
Expression arguments are evaluated in the order they appear. Supported operations include absolute value, trigonometric and hyperbolic functions, logarithms, exponentiation, arithmetic, minimum and maximum, modulo, unit conversion, property, value, table, and clip. A table contains ascending elements, each with an independent input and dependent output. Inputs outside the table range use the first or last table row.
Condition schema
Conditions can compare properties, values, or expressions. Comparisons include equals, not-equals, less-than, greater-than, less-than-equals, and greater-than-equals. A behaves as an implicit AND of its children; explicit , , , , and elements provide additional boolean structure.

高级特性

使用嵌套的
include
节点和调用方提供的重写来实现参数化继承。
通过 alias 同步属性路径，包括指向同一文件或其他已包含子树中声明属性的 alias。
可复用的飞机架构，将基础的 -set.xml 元数据、FDM 特定配置和独立于 FDM 的设置进行分离。
重复属性节点的隐式或显式类数组索引。
userarchive
属性实现的持久化设置。
用于嵌入 Nasal 代码或包含 XML 标记符号文本的 CDATA 支持。
丰富的 SimGear 表达式树，包含算术、三角函数、对数、乘方、单位换算、裁剪和基于表格的插值。
表格外推行为，将超出范围的输入限制在第一个或最后一个定义的行。
在缺乏原生舍入元素时，使用对数值加
floor
计算的舍入变通方法。
复合条件，结合属性比较、表达式、布尔运算符以及静态 true 或 false 数值。
通用 PropertyList 文件与专门的 JSBSim 或 YASim XML 模式之间的明确分离。

name: propertylist-xml description: Provides usage details for PropertyList XML files, including property storage, expressions, conditions, and more.

The PropertyList format

The root element of each file is always named

. Tags are almost always found in pairs, with the closing tag having a slash prefixing the tag name, i.e , just like in any other XML dialect. The exception is the tag representing an aliased property. In this case a slash is prepended to the closing angle bracket:

Minimal example

A minimal example of a complete property list encoded XML file, looks like this:

Property node tags and attributes

Each node in a tree is specified using a single tag that can take attributes describing various things about it:

Welcome to FlightGear! This is a string as a property

Property type attributes

Property typing is optional, all properties are by default string/unspecified and are transparently converted by the property tree, but it never hurts, especially when including spaces around numbers:

Hello

3.14 true

Indexed nodes

Indexing happens implicitly for identically named properties:

Hello

Hello

Hello

so that the three foo tags become foo[0], foo[1], foo[2] in the property tree, but you can also use explicit indexing by setting the n attribute of each tag:

Hello

Hello

Hello

Though the above two examples are equivalent, we tend often to include "n" anyway, just to help people keep track of where they are. That's most important when there are a lot of subproperties, not in a simple list like the above.

Archived properties

To make property settings persistent in between FlightGear sessions, use the userarchive attribute:

Hello

Including external PropertyList files

We can also create new PropertyList files by subtyping existing ones using the include attribute. For example, if someone made a DC-3 model for JSBSim, we could subclass from the YASim config file like this:

DC-3 (JSBSim).
jsb

Emmanuel Baranger's models tend to use this technique a lot and often have several XML files: the first (the -set.xml) contains very basic information, often just author and version number, and includes the next; the second is for FDM-specific properties (the -yasim-cnf or -jsbsim-cnf); and the last has FDM-independent things like flap settings (the -base.xml). This structuring allows for maximum reusability between FDMs and makes it easier for someone to come along and add another FDM to a model.

Aliased properties

Properties can alias other properties, in a similar way to symbolic links in Unix. When one of them changes the other one changes as well.

For example, this

46

will be functionally identical to

46 46

except that bar and foo will always be identical.

A PropertyList file can begin with a property subtree that are aliased later in the file.

/radios/comm1/frequencies/selected
/radios/nav1/frequencies/selected

number-value

Aliasing combined with inclusion

The combination of aliasing and inclusion allows for parameterization, which can be of great help both for debugging and maintenance. The above example could for example instead be split up into

/radios/comm1/frequencies/selected
/radios/nav1/frequencies/selected

and

number-value

The parameters can be overridden at inclusion

/radios/comm1/frequencies/selected
/radios/nav1/frequencies/selected

/radios/comm2/frequencies/selected
/radios/nav2/frequencies/selected

CDATA

Whenever you need to embed text that isn't valid XML, because it may contain XML tokens, you need to wrap the whole section in a CDATA section, this is typically done with Nasal code, so that it doesn't need to escape XML entities:

PropertyList-based configuration files

We have 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):

defaults.xml - the top-level default preferences
joysticks.xml - default joystick bindings, included by defaults.xml
keyboard.xml - default keyboard bindings, included by defaults.xml
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:

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
Aircraft//Models/.xml - animation files for a .ac file, oodles of nodes!

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

YASim and JSBSim each uses its own XML format, which is different from the XML format used by the rest of FlightGear.

Expressions

Expressions (or SGExpressions) are a feature of the SimGear library and provide a nice way of implementing complex math formulas using XML syntax.

They are supported in many systems within the FlightGear code.

Sample Expressions

This is a sample expression for c = sqrt(a*a + b^2). Children/arguments are parsed in the order they appear in the file (or the order in which they are set via property methods).

/value/a

/value/a

/value/b 2

Supported elements

Table

The table expression uses the following syntax, similarly to the element:

0.0 0.0

...

The entries must be sorted by the independent (input) variable strictly ascending. If input is outside the range of the table, output will be determined from the first / last table row.

Example

The table:

Input (ind) Output (dep) 0.0 5.0 0.5 7.5 0.9 -5.0 1.0 25.0

translates to the following code:

0.0 5.0

0.5 7.5

0.9 -5.0

1.0 25.0

Clip

An expression to limit e.g. rotation:

-45 45

orientation/pitch-deg

Hints and tips

Rounding

While there is no element for rounding, this workaround can be used for that:

your/property/here 0.5

Conditions

Sample conditions

This is a sample expression for checking if the throttle on the first engine is above half:

/controls/engines/engine[0]/throttle 0.5

Supported elements

Each comparison (like less-than or greater-than-equals) requires either two
elements (the first with index=0 and the second with index=1) or a
(considered first) and (considered second); booleans compare each of their child conditions. A element itself functions as an element; that is, it can have several children, all of which must be true to make the whole condition true. Instead of
or you can also use an .

nasal-library-props
产品页面设计师