# Model XML Examples This section contains examples of the contents of the [`[model].xml`](Model_XML_Properties.htm) file for various different situations.     ### Complete Model XML Example The example below shows a complete model definition for an aircraft in Microsoft Flight Simulator 2024. After this we will show some shorter example code related to specific features from the model XML, some of which are not shown in this full sample (since not all the XML elements will be required by all models, and it will depend on what the purpose of the model is, ie: human, aircraft, vehicle, etc...): ``` xml elevator_percent_key L_aileron_percent_key R_aileron_percent_key rudder_percent_key 1 Prop1 prop1_anim prop0_still prop0_still_frost prop0_slow prop0_blurred PROP_SIDE_BLUR True 320 570 c_tire_anim WHEEL_C_STILL_KEY WHEEL_C_STILL_BLURRED_KEY l_gear l_tire_anim FRONTWHEEL_L_STILL_KEY FRONTWHEEL_L_BLURRED_KEY r_gear r_tire_anim FRONTWHEEL_R_STILL_KEY FRONTWHEEL_R_BLURRED_KEY c_wheel True True MERGED HANDLING_RudderPedals_1 HANDLING_RudderPedals_2 HANDLING_RudderPedals_1_Brake HANDLING_RudderPedals_2_Brake HANDLING_RudderPedals_Brake_L HANDLING_RudderPedals_Brake_R ```     ### LOD Example The model XML file contains a list of {{< glossterm >}}lod{{< /glossterm >}} definitions, ordered from high quality to low quality. Every LOD defines a `*.glTF` model and a minimum size for display selection. For the purposes of LOD selection, the current size on screen of a model, is the vertical size on screen of the model's bounding sphere.   The size on screen of a model is determined by the camera position, the camera's field of view and the actual size of the model. The size of the model is calculated by accumulating the bounding volume extremes of all LODs in their default non-animated state. From the extremes, a bounding sphere is calculated. Since the sphere encompasses the extremes, the actual size on screen of a model is usually slightly larger than one might expect.   The selection process is as follows: starting from LOD 0, going down, the first LOD with a `minSize` smaller than the model's current size on screen will be selected for display. The selection will also take into account forced and disabled LODs as configured by the model options. {{< callout context="note" title="NOTE" icon="outline/bulb" >}} The last lod of any given model will always be displayed, until smaller than a certain hard-coded size. This size is scaled by the object LOD graphics setting within the sim. As such, it is important for the last lod to be as light-weight as possible (i.e. a single draw call). This usually means one node, one mesh, one material and less than 100 triangles. See the section on model [LODs](../../models-and-textures/modeling/landscape/lods/) for examples and more information. {{< /callout >}}   Below you can see an example of a LOD definition: ``` xml ```     ### Submodels And Animations The following example shows how the `` element can be used to merge submodels on a LOD as well as reference one (or more) animation gLTF: ``` xml FireTruck_LOD1_02.gltf FireTruck_LOD1_03.gltf FireTruck_LOD1_04.gltf FireTruck_LOD1_05.gltf ..\animation\FireTruck.gltf ``` When loading a LOD from the `[model].xml`, the system will merge each of the given gLTF models one by one, starting with the base model specified in the `` element. In the above example, it first creates the base model using "`FireTruck_01.gltf`", and then adds "`FireTruck_02.gltf`", etc... before finally loading the animation file.   You can find more information on submodels here: - [Submodel Merging](../../models-and-textures/submodel-merging/)     ### Model Attachments Below is a simplified, schematic example of how we use the `` element to attach independent model XML files to the main model being defined: ``` xml attachment_point ..\model.child\model.xml ``` The following is a "real world" example of how an actual XML file would look when working with multiple model attachments: ``` xml ..\livery\DA62_LiveryFS_LOD00.gltf SomeNodeName ..\..\..\..\Instruments\SomeInstrument.xml chair1pos ..\..\Shared\Misc\FancyChair.xml ``` You can find more information on model attachments here: - [Model Attachments](../../models-and-textures/model-attachments/)     ### <NodeAnimation> Example Below is a short example of how we use the `` element to add wing-flex to the model: ``` xml WING_BONE_LEFT_01 WING_BONE_LEFT_02 WING_BONE_LEFT_03 WING_BONE_LEFT_04 WING_BONE_RIGHT_01 WING_BONE_RIGHT_02 WING_BONE_RIGHT_03 WING_BONE_RIGHT_04 Engine_PIVOT_LEFT_1 Engine_PIVOT_LEFT_2 Engine_PIVOT_RIGHT_1 Engine_PIVOT_RIGHT_2 ```     ### <BlendTreeState> Example Below is a short example of how we use `` element to blend various animations together based on the return `` of an expression: ``` xml 1 (A:MARSHALLER AIRCRAFT DISTANCE DIRECTION Z PARKINGSPACE, METERS) 5 / - ```     ### <Transition> Example The `` element is used to set the conditions under which two previously defined animations should be "merged" and transition from one to the other. The example below shows a sample of how this is setup in the XML, in this case it's part of the transition setup for a Marshaller: ``` xml (A:MARSHALLER AIRCRAFT DISTANCE DIRECTION Z PARKINGSPACE, METERS) 500 < (A:MARSHALLER AIRCRAFT DISTANCE DIRECTION Z PARKINGSPACE, METERS) 0 > and (A:MARSHALLER AIRCRAFT DISTANCE DIRECTION Z PARKINGSPACE, METERS) 500 > (A:MARSHALLER AIRCRAFT DISTANCE DIRECTION Z PARKINGSPACE, METERS) 0 < or (A:MARSHALLER AIRCRAFT DISTANCE DIRECTION Z PARKINGSPACE, METERS) 300 < (A:MARSHALLER AIRCRAFT DISTANCE DIRECTION Z PARKINGSPACE, METERS) 0 > (A:MARSHALLER AIRCRAFT DISTANCE DIRECTION X PARKINGSPACE, METERS) abs 50 < (A:MARSHALLER AIRCRAFT HEADING PARKINGSPACE, DEGREES) abs 95 < and and and ```     ### Jetway Example The following snippet is an example of setting up the Jetway inverse kinematics (IK) using the `` and `` elements: ``` xml Rotation_Base Pivot 0.4 3 Bone05 Contact 0.4 30 Bone07 Bone09 10 90 Rotation_Base Bone01 Bone02 Bone03 Bone04 Bone05 Bone07 Bone08 Bone09 ```     ### Simple Animation Examples Standard animations are not reliant on code or physics and can run on loop, useful for ambient animations, run cycles and actions (for example). These are easy to include and require a single line in the XML: ``` xml ```   The section of XML below is a simple example that triggers an animation when the flaps move inwards: ``` xml False ```   For *legacy* animations that are for FSX SimObjects, you would need to accompany each animation with a ``, for example: ``` xml c_gear 200 GEAR ANIMATION POSITION:0 keyframe ```     ### XML Program Examples Within the model behavior files for models you can use "XML programs" to adapt the result of a component behavior or an input event depending on different factors, like a conditional check, or the current state of a value, etc... These programs are created using specific XML elements which are described on the following page: - [Program Template Definitions](modelbehaviors/program-template-xml-properties/) The examples below show how some of these elements are used within a behavior component or input event.   #### <Condition> Example The example below shows a simple `` check that will do nothing if the test resolves to`False`, or it will call the template "`ASOBO_GT_Update`" if the test resolves as `True`. The check itself is testing whether the parameter "`STATE0_TIMER`" exists, *and* has a value greater than 0: ``` xml STATE0_TIMER 0 True (#SWITCH_POSITION_TYPE#:#SWITCH_POSITION_VAR#) 0 == if{ 1 (>#SWITCH_POSITION_TYPE#:#SWITCH_POSITION_VAR#) } ```   #### <Switch> Example The example below shows a simple `` check that will go through each of the cases until the "case" check resolves as "True" - performing the actions within that case - or until the "default" case is met: ``` xml (A:CONTACT POINT COMPRESSION:#ID#, Percent) (A:CONTACT POINT POSITION:#ID#, Percent) (A:CONTACT POINT COMPRESSION:#ID#, Percent) + 0.5 * (A:CONTACT POINT POSITION:#ID#, Percent) ```   #### <Loop> Example This example shows a simple "do" `` that creates a variable (`AP_ID`), sets it to 1, then increments it by 1 each iteration through the loop until it reaches the value from the input parameter (`#AP_COUNT#`), at which point the loop will end and perform the "then" action: ``` xml AP_ID 1 1 #AP_COUNT# #RESET_CODE_T# #AP_ID# #ID# != if{ 0 (>L:XMLVAR_Autopilot_#AP_ID#_Status) } #RESET_CODE_T# ```     ### Input Event Example The following example illustrates the `` element that is used to perform some form of calculation and return a value when any instrument input is detected. In this case, we're detecting any interaction with a cockpit control to change the volume of COM1. Note the use of [InputParams](modelbehaviors/usingbehaviours/model-behaviors-component-overview/#InputParams) and the general format of the XML, as this is the most basic way that an input event should be structured: ``` xml ROTATE PRIMARY_DOWN+X_AXIS X_AXIS 1 (R:1:@TT_Package.AUDIOPANEL_KNOB_COM_VOLUME_ACTION) @sprintf (B:SOUND_COM_1_Volume, percent) '%d%%' @sprintf percent (O:MyValue) (A:COM VOLUME:1, percent) (>O:MyValue) (A:COM VOLUME:1, percent) p0 + (>B:SOUND_COM_1_Volume_Set) p0 5 * (A:COM VOLUME:1, percent) p0 - (>B:SOUND_COM_1_Volume_Set) p0 5 * p0 0 max 100 min (>O:MyValue) (O:MyValue) (>K:COM1_VOLUME_SET) p0 ```     ### Parameter Function Examples The following example illustrates the creation of [Parameter Functions](modelbehaviors/usingbehaviours/model-behaviors-component-overview/#Parameter_Functions). In this case it's a function that can be used in multiple different components to setup parameters for use with buttons: ``` xml #IE_SOURCE#_Button XMLVAR_#IE_SOURCE# True True @TT_Aircraft.TT_PLACEHOLDER_DESC @TT_Aircraft.TT_PLACEHOLDER_TITLE #ID# '%02d' @sprintf #BASE_NAME#_#PREFIXED_ID# #IE_NAME_BASE#_#PREFIXED_ID# #BASE_VAR_NAME#_#PREFIXED_ID# Push #IS_AIRLINER# #IE_NAME_BASE# #BASE_NAME# #BASE_NAME# #BASE_NAME#_Cover #BASE_NAME#_Cover #IE_NAME_BASE#_Cover p0 (>L:#BASE_VAR_NAME#) (L:#BASE_VAR_NAME#) sp0 #BASE_VAR_NAME# #TT_DESCRIPTION_ID# #TOOLTIP_TITLE# ``` This function would then be used in behavior something like this: ``` xml ID 1 1 18 EPU OVH_PUSH_EPU ID 1 1 2 OPD_LV_BAT OVH_PUSH_OPD_LV_BAT ID 1 1 2 OPD_LV_MAIN OVH_PUSH_OPD_LV_MAIN ID 1 1 2 ESU OVH_PUSH_ESU ```     ### Update Frequency Preset Example Update presets are used to define how often a model behavior component updates based on the size of the SimObject on screen. This example shows a basic preset definition, and you can find a full explanation of the XML elements used from the page on [Update Frequency Preset Definitions](modelbehaviors/update-frequency-preset-xml-properties/): ``` xml My_Default_Update .1 .01 .01 ```     ### Legacy Code Animations The animation in the example below shows only if the N1 is rotating slowly and sets the correct position of the model animation for *legacy* FSX aircraft. The `` parameter outputs a value between 0 and 100, which is then divided by the `` - 100 to sample the model animation at the correct position. The model animation simply defines a rotation from 0 to 360 degrees: ``` xml N1_2_still prop_anim 100 (A:ENG N1 RPM:3, percent) 6.25 < if{ 1 } els{ 0 } (A:ENG N1 RPM:3, percent) 0.01 > if{ (A:GENERAL ENG RPM:3,degrees per second) (E:ABSOLUTE TIME, second) * 360 % 3.6 / } els{ 0 } ``` For more information on the coding language used for the conditional expressions, see the section on [Reverse Polish Notation](../../programming-apis/reverse-polish-notation/).     ### Legacy Simulation-Driven Material Animation Example {{< callout context="caution" title="IMPORTANT!" icon="outline/alert-triangle" >}} Material animations are an experimental feature and may undergo significant changes in the future. {{< /callout >}} Simulation-driven material animations currently only support animating the emissive parameter and should return the intensity of the light emitted. The value returned should be 0 or higher, where 0 is no emission and 1 is fully emissive. Values above 1 may be used to induce strong bloom effects. The `` parameter is not necessary for Material animations to function.   Below is a short example of this kind of animation: ``` xml switch_landing_light (A:LIGHT LANDING, bool) (A:LIGHT LANDING ON, bool) and 100 * ```     ### Legacy User Interaction User interaction is defined with the `` element. They may change simulation variables through key events, or local (`L:`) variables directly. These simulation variables are used to animate the relevant parts. Many examples may be found in the plane packages provided with the game.   The below example animates an instrument that, when moved by the user, changes the rudder trim position: ``` xml btn_rudder 100 BTN_RUDDER {7E10EDEC-E1BD-4221-87F3-C00775D5281D} (L:LastPos) 0 == if{ 50 (>L:RudderTrimtabPos) } (A:RUDDER TRIM PCT, percent) (L:RudderTrimtabPos) 50 - 30 / + (>L:NextValue, percent) (L:NextValue, percent) -100 > (L:NextValue, percent) 100 < and if{ (L:NextValue, percent) (>K:RUDDER_TRIM_SET) } (L:RudderTrimtabPos) 50 Grab WheelUp+WheelDown+LeftDrag+LeftSingle+MoveRepeat+LeftRelease+Leave (M:Event) 'LeftSingle' scmi 0 == if{ (M:X) (>L:LastPos) } (M:Event) 'WheelUp' scmi 0 == if{ 0 (>K:RUDDER_TRIM_RIGHT) } (M:Event) 'WheelDown' scmi 0 == if{ 0 (>K:RUDDER_TRIM_LEFT) } (M:Event) 'LeftDrag' scmi 0 == if{ (M:X) (L:LastPos) - 5 > if{ (L:RudderTrimtabPos) 2 + (>L:RudderTrimtabPos) (M:X) (>L:LastPos) } (M:X) (L:LastPos) - -5 < if{ (L:RudderTrimtabPos) 2 - (>L:RudderTrimtabPos) (M:X) (>L:LastPos) } } (M:Event) 'LeftRelease' scmi 0 == if{ 50 (>L:RudderTrimtabPos) } (M:Event) 'Leave' scmi 0 == if{ 50 (>L:RudderTrimtabPos) } ```