Conversion questions using the Flight Toolkit

Hi folks,
First, a big thank you to Stonelance for creating the tools that now allow MS Flight (FLT) to be expanded. I very much appreciate the time consuming, hard work involved in creating & publishing these tools, and his continuing dedication to the game.

I've been experimenting with the latest version of the tools (v1.1.12.0), and have had some success in converting various objects into FLT. Here are some observations and a few questions that someone may be able to answer:
  • I've converted FSX generic airport buildings into existing FLT procedural buildings by using Airport Design Editor (ADE) by Jon Masterson. Here are the steps I took:
  • Open the airport
  • Remove all objects except the generic buildings
  • Export the "airport" as an XML file
  • Manually remove any remaining XML data in the file except for the generic buildings
  • Modify the remaining data in the file to comply with the FLT schema
  • Use the tools in the Flight Toolkit to compile and import just the file into FLT.
  • One can convert the generic buildings at an airport quite quickly this way once you know how to do it, and though it is not a solution for converting all the generic buildings at all airports in FSX (I believe stonelance is working on getting a future version of his ContentConverter tool to do this), it works well for those airports that one virtually flies to & from on a regular basis, & where no custom scenery is available.
  • I've also successfully converted "regular" scenery objects - such as a set of ships that I happen to have that I wanted to see in FLT, including the low-res FSX aircraft carrier (VEH_carrier01.mdl). Unfortunately, one cannot actually land on the carrier (or any other of my "landable" ships that I have in FSX & that I have converted to FLT - one just sinks through the deck...), which leads me to believe that the platform tag e.g.:
    <FSMakeMdlData version="9.0"> <name="_CONCRETE_0" surfaceType="CONCRETE" > </Platform> </FSMakeMdlData>
    is ignored and not converted to the FLT output file. So...
Question #1a: Is this a correct assumption?
Question #1b: If ContentConverter.exe does ignores the part, is there a way to create a landable platform for use in Flight, or use an existing generic Flight platform (if such a thing exists)?
  • I've created a very simple mission to teach myself how missions are built in FLT. Luckily, the XML format is very similar to that of missions in FSX (in fact, FLT missions can be opened by FSX Mission Editor by Jim Keir), though his tool obviously cannot understand the changes to the XML schema that has happened between FSX & FLT. I'm pretty sure one could update his schema files, but have not gotten around to looking into this yet...
    It would be nice to have a FLT Object Placement Tool (OPT) similar to that found in FSX, as looking at the FLT propdef files, there is one (Launch) that defines pretty well the same XML data found in FSX's dll.xml, so I'm guessing that there was a version of the OPT created for Flight that was used by the developers. One could create missions in FSX and then manually convert them to FLT, but it would be a tedious process!
  • In regard to aircraft conversion, I've had mixed results. I've found that ModelConverterX by Arno Gerretsen is a great tool to use to preview the conversion process. If his tool cannot open or export an aircraft model, ContentConverter or Addon Builder will generally not be able to convert it either (surprise, surprise!). One can also use his tool to clean up the model prior to conversion - for example, using the material editor to modify the materials such that the model is displayed correctly in FLT (Opaque glass or invisible exterior models is a common problem that can be fixed this way).

    Even though the tool does not convert aircraft sounds (since FLT uses a completely different sound system based on FMOD), I have been able to create the required sound files to point to existing .fev files that work pretty well as a temporary solution until I learn how to create new .fev & .fsb files that are tailored specifically for my models using FMOD.

    The conversion of the various aerodynamic properties from the aircraft.cfg file (?) does not always create a realistic (or aerodynamically flyable) aircraft. Luckily, since this data appears to all be stored in the various FLT simData files, they can be edited (and I have!) to create a better aerodynamic model.
Question #2: Does ContentConverter or Addon Builder use the FSX .air file at all, or is this ignored?

Question #3: In a Flight spb file for an aircraft livery, within the <Livery.Livery> section, what does the <ControlVariationID>{GUID NUMBER}</ControlVariationID> tag refers to and/or do? It appears that all the aircraft I've looked at so far use the same GUID: 45AAD43A-A9BC-40E0-96BA-A3E3577BBE53.

It appears that the FSX Virtual Cockpit textures (i.e. those preceded with $ & used for gauge placement) are not converted, presumably because the way the interior cockpits are modeled has changed.
Question #4: Is there any way to manually add gauges to the interior model of a converted aircraft?

In FLT, I've figured out the relationship of the <PanelID> elements in the livery file to the VcPanel.spb files in the panel folder, and the <GaugeReference GaugeId=...> to the appropriate gauge spb file that describes a particular gauge (for example, the handheld radio), but I'm missing the piece of the puzzle that ties the gauge to the model, so all my attempts at displaying a FLT gauge (from the CoreContent.pak file, for example) in a converted interior FSX model have failed.
Question #5: Am I right in thinking (guessing) that, for the MS aircraft such as the Icon A5, there is a GUID embedded in the model file (material slot name?) that maps to each GUID referenced in the <GaugeReference GaugeId=...> within the Vcpanel.spb file, and if so..

Question #6: Does this mean that one cannot display default FLT gauges (as an alternative to those that were used in FSX but are not converted) in a converted FSX model, since the converted FSX model has an empty set of virtual cockpit ($) material slot names, so no gauges can be mapped to them?

Question #7: Thus, converted interior cockpits will always be gauge-less. True, or False?
  • A couple of other problems I've come across with converting aircraft files (that I'm sure are already known) include:
  • Skipping unrecognized effects. I think one can get round this by remapping the effect to a standard FLT effect prior to conversion using ModelConverterX (or just deleting it), but have not tried it yet.
  • Bones in FSX appear not to be converted, presumably because Flight now uses Granny3D for its model and animation pipeline. For example, after the exterior model of the FSX Trike Ultralight is converted, the links between the pilot's hands & arms is broken, so when you move the aileron\elevator bar, the poor chap's hands, stuck to the bar, detach from his arms. Ouch!
    Wingflex is also not converted (for example, in the FSX glider).
  • Failing to convert sim script. This happens a lot - the Throttle script is a common error, but it also happens for many others. My guess is that some may be due to malformed script in the original model, some may be due to no equivalent mapping of the desired action in FLT, some may be because there is no code in the tool that recognizes the action that the FSX script is trying to perform.
Here, for example, is a portion of the log file when converting the FSX Trike Ultralight:
Converting model, materials and textures from "C:\Documents\_MS Flight Testing Folder\FSX Aircreation_582SL\model\AirCreation_582SL_Exterior.mdl"
Converting MDL to Flight .Model...
Error: Failed to parse instruction tree '{ l0 (A:THROTTLE LOWER LIMIT, part) / 1 + 50 * }' in script '{ (A:GENERAL ENG THROTTLE LEVER POSITION:1, part) s0 0 >=
if{ l0 -50 * 50 + }
els{ l0 (A:THROTTLE LOWER LIMIT, part) / 1 + 50 * }
d (>L:Engine1ThrottlePosition, percent)
Error: Failed to parse instruction tree '{ (A:GENERAL ENG THROTTLE LEVER POSITION:1, part) s0 0 >=
if{ l0 -50 * 50 + }
els{ l0 (A:THROTTLE LOWER LIMIT, part) / 1 + 50 * }
d (>L:Engine1ThrottlePosition, percent)
}' in script '
(L:EmergencyThrottleInUse, bool) 1 !=
if{ l0 -50 * 50 + }
els{ l0 (A:THROTTLE LOWER LIMIT, part) / 1 + 50 * }
d (>L:Engine1ThrottlePosition, percent)
els{ (L:Engine1ThrottlePosition, percent) } '
Error: Failed to convert RPN script '
(L:EmergencyThrottleInUse, bool) 1 !=
if{ l0 -50 * 50 + }
els{ l0 (A:THROTTLE LOWER LIMIT, part) / 1 + 50 * }
d (>L:Engine1ThrottlePosition, percent)
els{ (L:Engine1ThrottlePosition, percent) } '
Converting model, materials and textures from "C:\Documents\_MS Flight Testing Folder\FSX Aircreation_582SL\model\AirCreation_582SL_Interior.mdl":
Converting MDL to Flight .Model...
Error: Failed to parse instruction tree '{ l0 (A:THROTTLE LOWER LIMIT, part) / 1 + 50 * }' in script '
(A:GENERAL ENG THROTTLE LEVER POSITION:1, part) s0 0 >= if{ l0 -50 * 50 + } els{ l0 (A:THROTTLE LOWER LIMIT, part) / 1 + 50 * }
Error: Failed to convert RPN script '
(A:GENERAL ENG THROTTLE LEVER POSITION:1, part) s0 0 >= if{ l0 -50 * 50 + } els{ l0 (A:THROTTLE LOWER LIMIT, part) / 1 + 50 * }'

In each case, this results in a constantly moving objects (such as the throttle lever, ailerons, flaps, skids, spoilers, reverse thrusters, etc. etc.) in the interior or exterior visual model in FLT.

Perhaps the solution here would be to open up a user-input screen that would allow the user to manually map the failed parsed instruction to a standard script instruction set in FLT, or ignore the instruction & skip to the next script entry. E.g., for the above error, the user could chose to replace the failed parse script for the throttle lever movement with a generic throttle lever movement script that would be recognized by & acceptable to the converter.

ModelConverterX by Arno Gerretsen has such an option sort-of-like this (though his is for the SCASM Reader importer). You can see how he allows the user to choose how to handle imported variable by looking at the Options/Importer Settings window. Here, the user is given a set of choices for replacing variables and conditions (see the last two entries under the SCASMReader section).​

Anyway, it has been fun trying out the new tools, and hopefully, some of you may be able to answer one or more of the above questions - Thanks!
FS Tester.

PS: A note on communicating with me: I live in a remote, rural area with no Internet access (so all my flying in FLT is offline - no aerocaches for me!). I use a public Internet access point when I visit the nearest large town, which is usually only once every week or so. So, please do not expect a speedy response from me - it might be 2-3 weeks before you get a reply!
Generic building conversion should already be happening as part of the v1.1.12.0 scenery conversion. Curious as to why you are converting them manually? Are you converting custom generic buildings that are not part of the base FSX scenery?

1: Yes, because Flight doesn't use platforms at all and that system was removed. Object collision geometry in Flight is handled via Havok. For Flight the artists had a tool to automatically generate the simplified collision geometry from the actual model, and aircraft could land on anything with collision geometry (it didn't have to be specially marked platforms, as in FSX). Since the Havok data format is proprietary I haven't added any code to generate it during the model conversion. It may be possible to write similar code to auto-generate it similar to what is done in Flight since the PC tools for Havok are free, but I haven't looked into it yet (and the PC tools are a very big download too)
1b: There was no OPT for Flight. We used a different method which we called FSCIPC that was kind of a replacement for SimConnect and we had a standalone C# mission editor that would host the Flight process inside of a child window and control it via FSCIPC. Unfortunately all that code is compiled out of the released version of Flight.

2: Yeah it uses the .air file and aircraft.cfg to do the best job it can. I never intended the aircraft conversion to result in a perfect replica of the original since the two codes are so different. I always expected that it would need manual editing after conversion, as you are doing.

3: I think that is the ID of the SimControls.controlMap file that allows specifying custom controls per aircraft (should be a simprop file you can open).
3b: I don't think I wrote any code to try to convert the gauges from FSX to Flight, so I just didn't bother converting those textures.

4: Yes, haha. It is pretty easy once you know how. In the material, instead of using the ID of a texture for a material texture slot, you use the ID of the panel. (The ObjectBrowser may be useful to track down quickly what ID is what file). Think of the panel as a texture sheet, and each gauge as a list of gauges that are drawn into the texture. You can then UV your model to use a single panel texture, but place a gauge from the panel anywhere in your model (so they don't have to be contiguous). We usually try to use only one panel material per aircraft to reduce the number of draw calls. You may see two different panels (such as mask, and albedo) for the same\similar set of gauges. This was done to get the "glowy" night time look of the gauges. They are both referenced from the same material.

6: You should be able to use default Flight gauges from other aircraft. You don't even need to copy the files to your aircraft, just reference them by ID. You would possibly need to change the UVs of the model though to get them to appear correct in the 3d model.

7: Yeah, I know about all of those. Your are pretty much right on all of them. Many effects in FSX are not in Flight, Flight didn't support IK to allow the pilots hands to connect properly to the yoke, many variables are not available in Flight, some I just don't know about and haven't mapped yet, and some scripts might be too complicated for my conversion to handle. I tried to improve the conversion process recently, but I don't think it made much difference. Converting RPN to lua is not easy unfortunately. My original plan was not to spend much effort into conversion, because I'd rather spend that time developing a code path that allows someone to import any FBX file along with a set of matching animation scripts per node, and avoid the whole conversion mess. I don't think Flight supports wing flex.

It is nice to see someone else getting so deep into the guts of Flight. Thanks!
Hi Stonelance,
Many thanks for your reply.

w.r.t. Generic building conversion, If my memory is correct, I did the manual conversion of FSX generic buildings to procedural objects using the prior released build of Flight Tools (.6 build). I've since installed the .12 build, but was so engrossed in seeing how other aspects of Flight (like missions, aircraft, etc.) could be added to that I have not flown around the FSX world since the installation! I'll fire up Flight and check out a few FSX-World airports & see what's around, building-wise.

Q#1: Thanks for the platform explanation, which also explains why aircraft can taxi through my converted custom buildings too! I seem to recall downloading some Havok dev programs a few years back, not that I played around with them much. I may still have them on DVD, or, as you mention, can always download the latest version from Havok (

Pity about OPT. So, it looks like my idea of creating missions in FSX & porting them to Flight may be the easiest route until a new custom OPT is created (which I think will be a long time, if at all).

Q#2: Since I posted this thread, I had a look inside some of the air files (using an old FS9 tool that allows one to view them), so concluded that your conversion tool was pulling data from them. I can't say that I understand the aerodynamic physics that lies behind the data in files - more stuff to learn, I guess!

Q#3 Thanks - I'll check that out.

Q4 & 6: Oh, this is good! I'll try out your explanation & see what happens.

Q7: Thanks for that info.
w.r.t. effects, am I right in thinking that the conversion tool compares the name of an effect in a model to be converted - an aircraft or static scenery object, for example - to a list of default Flight effects included within one of the conversion tool dlls?

In other words, it does not parse the various default or addon .pak files & create a list of currently installed effects.

If it finds a match with one listed in the conversion tool dll, it keeps the reference to the effect in the converted model. If it does not find a match, it skips the effect - i.e. the reference to the effect is not included in the converted model?

If so, that would mean that I could add a series of new effects to Flight by creating a new addon .pak file containing them (effects in Flight are basically the same to those in FSX, though textures are referred to by GUID rather than by name, as far as I've seen so far), but any converted model would never show them, as the reference to the new effect would be removed during the conversion process.

If true, perhaps the solution to this would be to separate out the list of effects from the dll into an xml file that was parsed during the conversion process. In this way, one could add new effects to the xml file that matched the reference to the effect in the model that one was converting. Then, the converted model, plus effect, could be included in either a single .pak file, or separate .pak files, if, for example, one wanted to create a new "effects library" that could be used by anyone.

Another thing I did since posting this thread was open up the modeldef.xml file to compare the data in it with that of the throttle error. As you are no doubt aware, the problem appears to be a simple typo (shown in bold, underlined, red) where a lowercase letter "L" has been used instead of the numeral "1" in the code: if{ l0 -50 * 50 + }

Here too, it looks like the conversion tool is reading the modeldef.xml information from one of the conversion dlls. Again, having the tool parse an external XML file would allow greater flexibility in future if anyone wanted to add to the default modeldef.xml

Another aircraft conversion oddity that I've noticed when converting the standard FSX Cessna 172, as well as a couple of 3rd-party FSX aircraft, was that the converter correctly converted the .anim instruction set for the left aileron & flaps, but not the right. The left side of the converted aircraft would correctly respond to joystick, button & key commands, but the right side aileron & flaps would stay static.

All the models would animate correctly in FSX & in ModelConverterX by Arno Gerretsen, so I have no idea why this would be, as some other FSX & 3rd-party aircraft do not have this problem once converted, so it may not be a problem with the tool, but the way the aircraft was originally animated. So far, it is always the right side of the aircraft that is affected, which is sorta weird.

Thanks again for the reply,
FS Tester
Another aircraft conversion oddity that I've noticed when converting the standard FSX Cessna 172, as well as a couple of 3rd-party FSX aircraft, was that the converter correctly converted the .anim instruction set for the left aileron & flaps, but not the right. The left side of the converted aircraft would correctly respond to joystick, button & key commands, but the right side aileron & flaps would stay static.
You need to manually edit FlightControls.simData to account for the right aileron and flaps by adding the correct code.

For Ailerons:
For Flaps:

The values that I have used are just examples which I used on a different aircraft.... :)
I think I just have a hard coded mapping from FSX effect to a Flight effect. If you make additional ones, I could add them, but it sounds like if all the conversion requires is to replace a texture name with a guid, then they should be easy to convert automatically with the conversion tool. for some reason I think it may not be that straight forward though. Not sure. We didn't make many changes to the effect code for flight.

l0 is probably not a typo. I think it means to load from register 0.
KavindaJD - Thanks for that tip - I'll try that out.

Stonelance - Adding more hard-coded effects would be more work for you (though thank you for the offer!), and not a scalable solution. I need to investigate effects a bit more, I think. I did notice that one could add an effect via one of the simdata files (I can't recall which one right now), so maybe more can be added that way. If I get really stuck & feel I just gotta have an effect, I may take you up on your offer later.:)

w.r.t. the throttle issue. Hmm. I don't have the FSX modeldef.xml file on this laptop, but I'm 99% sure that, in that file, it is a numeral 1 & not the lowercase letter L. Then again, I may have totally taken the wrong troubleshooting path here. It often happens! I have a theory, follow it along, & find out later that my theory is based on a completely incorrect premise.:mad:

w.r.t my question about the <ControlVariationID> GUID of 45AAD43A-A9BC-40E0-96BA-A3E3577BBE53, you are right - the GUID references the SimControls.spb for the Icon A5, and is also referenced in the standard.xml file located within the players controls folder (e.g. C:\Users\<username>\AppData\Local\Microsoft\Flight\Players\905EE2FEA2F28FAE\Career\Controls\Standard.xml, on a windows 7 machine). Thanks for that tip.

w.r.t Generic Building conversion, I checked a few airports in Flight and no generic buildings are appearing. Take, for example, the small Brazilian airport Francisco De Assis (SBJF). It has one generic building, as shown in this screenshot from Airport Design editor:

The xml code for the building is as follows:

In FSX, it looks like this (month=July):

Closeup of the Generic Building:

Looking at the log of the v1.1.12.0 build, the following message is logged multiple times:
Warning: Generic building conversion is not supported currently. Ignoring these objects:

Looking at the airport in Flight (Scenery Density & Quality = High), from roughly the same location, it looks like this:


Based on the log file, it looks like the code to convert generic buildings is still TBD.

This airport does, however, show another of those landclass anomalies in Flight. SBJF is located in Dir #404, File#3639.

In FSX, the Airport Boundary Texture GUID is: 46BFB3BD-CE68-418E-8112-FEBA17428ACE
and the landclass around the airport, looking down and going clockwise from the north is:
111 (Large City Suburban Non Grid Wet)
35 (Corn & Beans Cropland)
58 (Fields & Woody Savanna)
34 (Tropical Degraded Forest)

In FLT the Airport Boundary Texture GUID is still 46BFB3BD-CE68-418E-8112-FEBA17428ACE, but clearly is displaying the wrong (snowy) texture.
The season is 0 (Mild Winter).

Here are a few more observation on aircraft conversion:

When converting the FSX DG-808S Glider, Addon Builder crashes when trying to create the livery file, because in the FSX aircraft.cfg section, the engine type is "2":
engine_type = 2 //0=Piston, 1=Jet, 2=None, 3=Helo-Turbine, 4=Rocket, 5=Turboprop
Addon Builder does not understand what to do with engine_type 2. Changing the type to "0" allows the conversion to complete, though obviously one needs to do some manual editing of the FLT simdata files afterwards.

Not surprisingly, Addon Builder also does not know how to convert the TOW RELEASE HANDLE and WATER BALLAST VALVE scripts, but also fails on CANOPY OPEN. How is opening the canopy of the Icon A5 handled, I wonder? If no direct mapping is available, perhaps the FSX command could be mapped to opening Door:0?
Here is a snippet of the conversion log (I don't know what the two unknown riff sections refer to):
Converting model, materials and textures from "C:\Documents\_MS Flight Testing Folder\Aircraft (FSX Input)\FSX DG-808S\model\DG808S_Interior1.mdl":
Loading MDL...
Warning: Skipping unknown riff section: MREC (size: 1012).
Warning: Skipping unknown riff section: MREI (size: 44).
Determining optimal material set
Converting MDL to Flight .Model...
Error: Unknown FSX sim var: TOW RELEASE HANDLE
Error: Failed to convert RPN script '(A:TOW RELEASE HANDLE, percent) 2 / '
Error: Unknown FSX sim var: WATER BALLAST VALVE
Error: Failed to convert RPN script '#100#
(A:WATER BALLAST VALVE:1,number) 100 *
Error: Unknown FSX sim var: CANOPY OPEN
Error: Failed to convert RPN script '
(A:CANOPY OPEN,percent) 2 /
Error: Unknown FSX sim var: CANOPY OPEN
Error: Failed to convert RPN script '
(A:CANOPY OPEN,percent) 2 /

For fixed-wheel (non-retractable) aircraft, the ContentErrors.log will record this error when the aircraft is loaded:
(0.000000, 0.000000): Contact point extend and retract times must be positive

The solution is simply to delete the <Retraction> section in the ContactReaction.simData file - for example, you would delete this whole section for each non-retractable wheel on the aircraft:

The category of "Glider" is not supported in the <CategoryFlags> section of the livery file. The ContentErrors.log will record this error:
(0.000000, 0.000000): Invalid SimObjectFlagName: Glider
so I'm just listing the FSX DG-808S Glider as "FixedWing". It is not really a problem, but I was surprised, as within the CorePropDefs file propLivery.xml, the <CategoryFlags> entry is listed as type "Text", which suggested to me that any text descriptive of the aircraft would be accepted. I guess not!:(
name = "CategoryFlags"
id = "{5D4B4E90-BCF8-4D94-B7E9-D3B54B759D04}"
type = "TEXT">

I'd like to suggest a design change request to the Flight Addon Manager. Within the "Installed" pane on the left, would it be possible to be able to sort the list of content by name? As the number of addons has started to increase on my system, the "random" display of addons is getting somewhat messy!
Even better would be able to sort by category type (aircraft, mission, scenery, etc), installed/not installed, and name. Not a "Priority 1" DCR, more of a nice-to-have, really.:cool:

Your explanation on gauge panels helped a lot. Here is a couple of screenshots of my current conversion test, the Beech Baron 58:

The external model is coming along nicely. I still have to fix a minor environment texture error with on the landing gear (notice the green area that should be chrome-looking), and the propeller cover, which also appears greenish when the propellers are rotating. I also still need to fix non-animation issue on the right flaps, ailerons, & gear (KavindaJD's tip should help here.)

The internal model needs a lot of work on the gauges, but I'm getting there:

Since Flight now uses the LUA scripting language, which I've never used, converting the FSX scripts within a gauge to their LUA equivalent in Flight is a very slow process, with lots of testing involved. The content log has been really useful in pinpointing my many errors! It does not help that not all scripts can actually be converted, as, as you well know, some FSX functionality is not available in Flight. Since I know of no definitive list that shows what FSX functionality was & was not included in Flight, I'm sometimes am unsure if a problem is due to my bad scripting ability, or non-functionality in Flight, though the errors listed in the content log can be helpful.

Once the gauges are done, I'll still need to create the checklist, sounds, and make serious refinements to the Aerodynamics.simData file. The Baron at the moment has a serious tendency to pitch up sharply after takeoff, causing an immediate stall & crash!

FS Tester.
I'm pretty sure I added Generic Building conversion to the SceneryConverter. DO you have the latest version of the toolkit, and did you rerun the scenery conversion after installing it? It could be that I have local changes that I have not released publicly and I am just forgetting. It has been a while since I touched any Flight related stuff.

I really like seeing your progress on aircraft conversion. I stopped when I had trouble figuring out why I was having so much trouble converting twin engine aircraft. I expected it to work since there is one already available in Flight. I was later chatting with some of the aircraft devs from Flight, and they said they actually implemented that aircraft as a single engine... so that might explain why I had trouble. The twin engine code was done, but Flight was shutdown before it was released. We could potentially do the same for some conversion aircraft, but it would obviously not be very realistic any more...

Edit: Just looked and it looks like there is a good chance the generic building conversion was not checked in. I'll look into finishing that soon, but I am working a lot so I'm not sure when I will get to it. Might not be for a couple months.
Last edited:
Answering some other questions:

Yes I think the canopy in the Icon is a door. I probably just don't have that listed in my mapping. I built the mapping by just converting a bunch of models that come with FSX and filling in missing things as I saw them. If you have an idea on some mappings that are missing, let me know.
KavindaJD - w.r.t. the flaps & ailerons, I actually had already looked at the FlightControls.simData file & seen the entries you mention. What one needs, of course (as you suggest) is TWO entries, one for each side of the aircraft. So the code for the ailerons is, for the Baron:


Once I added the additional flap & aileron entries, hey presto! the Baron now has working right-side flap & aileron animations! What I find interesting is that the FlightControlType does not require a different id for each side (e.g. aileron.0 & aileron.1). If it did, and I had seen just an "aileron.0", I'd have realized that you needed another entry (which is sorta how I figured out how to get the second engine & fuel tanks operational). But as I saw just one <FlightControlType>aileron</FlightControlType> entry, I thought that it handled both sides of the aircraft, like the elevator & rudder....
What is weirder to me is that both aileron entries are identical. Since ailerons move in opposite directions, I would have expected the Max & Min values in each section to reflect that, but no, they are the same! Clearly, I still have a lot to learn about the inner logic that drives Flight <grin> Thanks again for the tip!

Stonelance - Thanks for providing the .13 release. I've downloaded it & will install & check out the generic building conversions this week.

w.r.t twin engine aircraft. Yup, based on what I'm seeing, it does appear that creating a "true" twin-engined aircraft is problematic, to say the least. However, I've never considered Flight as a simulator, so slaving Engine.1 to Engine.2 is OK as far as I'm concerned. If I want hi-fidelity aerodynamic flight modes, failures, etc., I just start FSX;)

There is clearly code listed in the corepropdefs file that applies to twin-engined aircraft, but when testing it, Flight either does nothing or refuses to load the aircraft.

w.r.t your comment on mappings: I've actually started a list of conversion mappings. It's a bit of a hodge-podge of a file right now. Once I get a bit more done on the Baron, I'll clean it up and post it here. This should give you a good idea of what other mappings it would be useful to have in the converter.

For example, I was trying to determine the Flight equivalent for this FSX variable. This is how it is defined in the FSX SDK:
Simulation Variable Description Units
GENERAL ENG EXHAUST GAS TEMPERATURE:index Engine exhaust gas temperature. Rankine

I tried a number of options such as: S:Engine.ExhaustGasTemperature in my gauge .spb file, but the content log considered all of them as an "Undefined Simulation Variable". The variable may not be modeled in Flight at all, in which case I'll have to modify my translation of the FSX gauge so that it does not appear (the gauge shows right now, the needle, with no code, stays stuck on zero!)

I still cannot find a way to animate the wheels retraction in the Baron. Each wheel already has a retraction setting in ContactReaction.simData (so, 3 entries in total), e.g.:

When I start a flight on the ground in the Baron, the wheels are extended (as expected). When I start a flight in the air, they are also extended (not expected). Interestingly, if I start a flight in the air in the Icon-A5, then exit the flight, go to the hanger & switch to the Baron, then restart the flight, the gear is retracted, so the animations appear to be correctly modeled in the model - I just cannot activate them using the joystick button or keyboard "G".:mad:

Similarly, I'm having issues animating the 2nd propeller & mixture levers. I can see in SimDataEditor that the mixture for both engines is working from the MixtureLeverPercent position info, so I'm assuming the propeller lever settings are OK too (propeller data is not displayed in SimDataEditor), but while the #1 engine propeller & mixture levers animate correctly, the # 2 engine ones do not, except, again, at the start of the flight, when it appears the physical setting of the animation is determined by the MixtureLever & PropellerSystem lever float settings in the players CurrentSituation.SPB file. So again, the animation appears to be correctly modeled in the model.

And, of course, the throttle levers are still moving, as per my original post.

On the plus side, I've fixed the external texture error with on the landing gear and the propeller cover, which appeared greenish. The problem, I believe, is the way the shader file handles the default specular texture. I created a new specular texture file - all-white, 64x64 pixels, dds1 - with it's corresponding meta file & GUID, and updated the appropriate material file to point to this new specular. Now the gear & propeller covers display their "Chrome" visuals very nicely. I've also got about half the gauges working, though none have click-able mouse areas at the moment.

More later,
I thought I had a list somewhere of all the variables available in the sim for Flight. I'll see if I can find it anywhere.
Sounds like you are making great progress!
I thought the propeller data is also shown in SimDataEditor in one of the other drop downs? I can look into adding that as well.

One useful thing for debugging may be if you can find a unofficial leaked version of the Granny3D SDK. I know there is one version that has a gr2_viewer that can open flight .model files, but I don't remember the version number. It will let you look at the various scripts for each bone in the model. I could also see if I can write something that will spit out the existing scripts from a .model, and allow you to replace them.

Probably won't get to any of this for a while.
I thought I had a list somewhere of all the variables available in the sim for Flight. I'll see if I can find it anywhere.
Haha! You do - you've released them! Under "Flight Tools\Flight Toolkit\SimPropSymbols\Flight" ;)

One useful thing for debugging may be if you can find a unofficial leaked version of the Granny3D SDK. I know there is one version that has a gr2_viewer that can open flight .model files, but I don't remember the version number.
With the Granny files I've found, gr2 viewer only opens .GRN files and not .model so a bit of "Hex Editing" is required! Even if you do get the model open, it will only show animations and nothing else. :(
Last edited:
The files in Flight Tools\Flight Toolkit\SimPropSymbols\Flight are the schema files for the xml and spb format. They are not the same as the variable the sim uses. I looked and I found the file I made a while ago with the sim vars.

I checked, 2.9.1 works mostly. You won't be able to see some of the extended data.


Well, I managed to spend a few more evenings working on the Baron this week. Here are some more observations:

w.r.t the discussion on 2-engine aircraft in Flight, based on my gauge work:
It looks like one is unable to create a separate generator for the second engine (confiming Stonelance's comment about 2-engined aircraft being modeled by duplicating the #1 engine).
The <EngineIndex> entry in Electrical.simData as defined within propElectricalSystem appears not to have any effect. So having two entries:
<Generator IsLinkedToBatterySwitch="True" IsAlternator="True">

<Generator IsLinkedToBatterySwitch="True" IsAlternator="True">

to drive 2 generator\alternators, one on each engine, makes no difference. Thus, trying to display the amperage from each generator in a gauge using the script variables:
return (varget ( 'S:ElectricalSystem.BatteryCharge', 'amps',0) )
return (varget ( 'S:ElectricalSystem.BatteryCharge', 'amps',1) )

where 0 & 1 refer to the first & second engine respectively, results in only the first gauge being operational. As a work-around, I'm linking both gauges to engine.0

For the same reason the Prop_Sync_Spinner in the Baron will never spin. Since the 2 engines & propellers are modeled in Flight as one system, the Propeller RPM % for both engines will be identical. I've just modeled the spinner as a static bitmap & will remove the switch animation from the interior model file.

Gear Animation
w.r.t. the gear animation issue, I've resolved that. The solution is to create a new simData file called "RetractableGearSystem.simData", and reference its GUID in the aircraft livery file. The simData file itself is empty, apart from the standard XML header information. The Icon A-5 has one of these files that you can reference if you don't want to create a new one for your aircraft. It's asset.metadata id is: 160BBBB4-104E-441E-9763-6666552E3AD2.

Throttle Lever Animation
w.r.t. the throttle animation issue, I've resolved that too. The solution is a bit more complex, using ModelConverterX to remap the two throttle levers to a new custom animation definition in the FSX modeldef.xml file.

As I mentioned earlier in this thread, Addon Builder fails to parse the instruction tree '{ l0 (A:THROTTLE LOWER LIMIT, part) / 1 + 50 * }' that is part of the code for the throttle levers in modeldef.xml (there are actually five entries for throttle levers in the file: one generic lever -: lever_throttle, and four others, each for a specific engine -: lever_throttle0, lever_throttle1, lever_throttle2 & lever_throttle3. Unfortunately, all five entries basically use the same code).

What Addon Builder CAN parse is a generic variable such as: GENERAL ENG PROPELLER LEVER POSITION:<index> or GENERAL ENG MIXTURE LEVER POSITION:<index>. Luckily, there is one for the throttle too: GENERAL ENG THROTTLE LEVER POSITION:<index>

So, the solution is to:
  • Create and add a new, custom animation that references this generic variable to the default FSX modeldef.xml file, then save modeldef.xml with a new filename.
  • Update a ModelConverterX option setting to point to the modified modeldef.xml file.
  • Use ModelConverterX to map the throttle lever animations in the interior model of your aircraft to the custom animation, and save the modified model with a new filename.
  • Update the FSX model.cfg file to point to that new file.
  • Run Addon Builder as usual.
The custom animation consists of two parts. Part 1 is:
<Animation name="_MSFLIGHT_lever_throttle" guid="B37B5587-EF17-44bd-A48C-E64D76B10FF4" length="100" type="Sim" typeParam2="_MSFLIGHT_lever_throttle" typeParam="AutoPlay" />
  • The animation name / typeParam2 must be the same, but can be anything - I use the '_" character to place the name at the top of the animation drop-down list in ModelConverterX, followed by "MSFLIGHT" to identify what uses the animation, followed by what the animation does - in this case manipulate the throttle lever, but you can name it anything you like.
  • The GUID must be unique, so you need to create one for each animation that you add to the file.
For a detailed explanation of each of the parameters, see the "Creating a New Animation" section within the "Using Modeling Tools" topic in the FSX SDK.

Because this is a type "sim" animation, there is a second part to the animation. Part 2 is:
  • The name must be the same as you specified in part 1.
  • The units must be "part". The actual unit in FSX for this variable is "percent", but Addon Builder will not recognize this. It expects "part".
  • The scale must be -100, and the bias 100 for the animation to work correctly for the Beech Baron. You may need to modify these values for other aircraft and/or other animation that you might want to modify.
  • Note that there is no <MouseRect> section. As far as I can tell, this section is not parsed by Addon Builder, so there may not be any need to include it in the custom animation, though I may be proven wrong on this point if or when I am able to get MouseAreas to work in my converted model! (see below for more on this..)
I also add a comment line in the modeldef.xml file before each of the two new entries to remind me why the entries are there, but this is entirely optional:

Once you have added the new animation, save the file with a new name (it's never a good idea to modify an original SDK file, just in case you mess up & have to revert to the original file!) - e.g., for this example: MSFlight_Modeldef.xml

Start ModelConverterX. Open the options window, and in the FS related settings section, change ModelDefPath to point to the location of your modified MSFlight_Modeldef.xml file.
This change will not take effect until you restart the application, so close the application.

Restart ModelConverterX and open the interior model of the aircraft you wish to convert. Click on the animation editor button. Click the Select None button to de-highlight all the checkboxes, then scroll down the list until you see entries starting with lever_throttle. You may see one or more entries, depending on the number of engines for your aircraft, and how they were animated. Select them all.

In the animation type dropdown box, select your custom animation. In this example, _MSFLIGHT_lever_throttle (This entry should be at the top of the list). Click the Assign animation type button to change the animation. If you scroll down the animation list, you should see that entries starting with lever_throttle now say _MSFLIGHT_lever_throttle. Close the animation window, then export the model. I'd suggest saving it as a new file, rather than overwriting your original interior model file.

You can then use Addon Builder to convert this new model version of your aircraft. Don't forget to modify the FSX model.cfg file to point to the new model file if you created one with a different filename than the original.

w.r.t my observation that the category of "Glider" is not supported in the <CategoryFlags> section of the livery file, I have discovered that there is a defined list of permitted categories, located in the SimObjectFlags.spb file (part of the CoreContent.pak. It should be possible to add to this file, though I have not tried it yet.

Creating Lights
Does Addon Builder support attached objects at all? If I try to convert an aircraft with an attached object, it seems that irrespective of the FSX GUID, the following error is logged:
Can't convert unmapped FSX library object to Flight: {GUID_NUMBER}

The reason I'm asking is that I'm trying to think of a way to add lights to a converted aircraft. As you know, aircraft in Flight do not use effect files to display lights - they use models and lightmap textures. Thus, there is no equivalent [Lights] section in Flight that you can use to add or modify light effects for Nav, Strobe, Beacon, Landing, Taxi, Panel, Cockpit, etc.

In any case, effects are (as I understand it) not converted either at the moment - Addon Builder warns:
Warning: Can't convert unmapped FSX effect to Flight: <effect name>

If the tool could be modified to support more than empty attachments, one could then add attachments for the lights to the FSX aircraft in ModelConverterX prior to conversion. ModelConverterX allows the following library object attachpoint parameters to be added or modified in an FSX model:

FSX Parameter_______Proposed AddonBuilder__Comment
Attachpoint Name__________Copy unchanged_______Some attachments (for example, those used in checklists) are referenced by name, not GUID.

Orientation (X,Y,Z)_________Copy unchanged ______Would any transformations be required?
____________________________________________If so, should be doable, as they must already be being done to other co-ordinates in the model.

Position (X,Y,Z)____________Copy unchanged ______Would any transformations be required?
____________________________________________If so, should be doable, as they must already be being done to other co-ordinates in the model.

Object GUID_______________Copy unchanged______The GUID for each attachpoint would refer to the GUID specified in the
____________________________________________metafile of the model for the FLIGHT light -:
____________________________________________e.g. 4A3BE341-9F1D-4825-81A4-544655FA641A for the Icon_A5_LightGlow_Left.model light.
____________________________________________Leaving it unchanged would allow us to create new models (& GUIDS) for flight attachments.

Scale (can vary)_______________1_______________I seem to recall reading somewhere that the scale must be 1 for a converted object,
____________________________________________so it should be set to 1 in ModelConverterX

If Addon Builder does support attached objects, is there a list of mapped objects available?

I know that there is no Autopilot in Flight, but do you know if ADF modeled in Flight? The ADF entries in the Radio.simData, RadioSystem.xml and Propgauge.xml files suggests that it is, but information on this gauge, as well as the Marker gauge is pretty well non-existent. <Update: Oooo! - I see a lot of ADF stuff in the SimVariables file! I shall check this out....:wizard:>

SimDataEditor Propeller Data
In my previous post, I said that "propeller data is not displayed in SimDataEditor". Well, in the .13 build of the tool, it certainly is! It might actually have been in previous builds too. It is not unknown for light photons from a computer monitor to pass straight through my eyes & get lost inside my head without encountering any intelligent, cognitive regions of my brain at all (especially late at night)! :)
<Update: HaHa - Stonelance - you are right, of course (and thanks for uploading the simvars list!)!>

Mouse Clicks
I have not been able to enable MouseAreas or MouseClicks in any of my gauges, despite having the necessary code in the gauge's .spb file. I don't think it is my code, as if I import an existing gauge with mouse areas into my panel - e.g. bendix-king-com0.spb - then the MouseAreas/Clicks in that gauge do not work either, even though the rest of the gauge is functional. Any ideas of why this would be? The inability to get this functionality working so far has prevented me from completing the code to operate switches, dials & levers in the model.

I think I've figured out how this works in Flight, & how to get it to work with converted models. Only one switch works in my test checklist right now (see pic, below). This is going to be a very time-consuming job to complete, as each referenced item requires an attachpoint to be added to the model. Luckily, these attachpoints can be empty, which means that AddonBuilder already can accept them without throwing an error/warning notice.

Design Change Request #2
I'd like to make another DCR, following on from last week's request to have a "sort" capability in Addon Builder. When converting aircraft in Addon Builder, the tool displays a status log during conversion. However, if the tool crashes, the focus of the tool changes to an error window that states: "AddonBuilder has stopped working.. Close the program." Unfortunately, this means that one cannot copy the contents of the status log, as that window is greyed-out. Would it be possible to either allow the contents of that window to be copied, even if the tool has crashed, or have an option for the tool to create a log file as it is running, so that one can review the file even if the tool crashes?

A couple of new pics showing my progress. Note that it took a lot of effort to keep the Baron flying in the first pic. It is still a highly unstable aircraft, and prefers to nosedive & auger into the ground at any opportunity!


Last edited:
MouseAreas do work in Flight and I don't think they changed too much from FSX, but I don't think my tools convert them right now. I think there may be some requirements that the model itself has in order for the Flight code to ray cast into the gauge to figure out where you are clicking. It may not work if there are no mouse rects in the rest of the model.

My code probably doesn't handle converting attached objects, because by default I would think it would need to also convert whatever model it was pointing at as well and I just didn't do it since it is not super common in FSX

It should be relatively straight forward to convert effects from FSX to Flight and attach them to models, but I'm not sure.

For checklists, I think you can reference any bone name, it doesn't have to be an attach point, but I'm not 100% sure.

It shouldn't be too hard to change the conversion to write out a log file as well.

From your documentation it seems like there are several things that could be done to the conversion process that would make it a lot easier to convert things without having to modify animation scripts and models before conversion. I am working like 60-80 hours a week right now though, so I won't be able to work on anything for a month or two at least. I really like seeing your progress and hopefully if we can gather together a list, once I have some time I can bang some of this out.
Is there any way to get something similar to the modeldef.xml file, from a MSFlight .model file? Animation script is displayed in Granny Viewer but it is hard to piece everything together.
Steve, your idea of having a .model "script extractor" may help with this. Instead of editing modeldef.xml and running the conversion again, you could quickly add animation script to the bones you want.
Hi Stonelance, KavindaJD
w.r.t. mouse areas - thanks for that info. I'll do some more investigating...

w.r.t. attachpoints - my idea was not to convert actual library objects, but allow the entry of the FLIGHT GUID of the object - to be used primarily for lights, or for effects. One could use existing FLIGHT effects, or convert FSX effects & add the effect & meta file to the pak file. I've done that with the engine start-up effects, and it works well, but FLIGHT only references start-up & ground-contact effects within spb files. All others appear (looking at FLIGHT aircraft in granny viewer - Thanks for uploading that, KavidaJD -) to be attachments to the model.

You are correct w.r.t. checklists. Your tool does allow "empty" attachments - i.e. it only consists of a name - to convert. I've added about 30 of these to the model, and all work as expected, enabling the green "highlight" effect that you see in the checklist to appear.

w.r.t updating the tool - yup, this would indeed be the preferred method. Most folks will likely be put off converting models if it requires this level of pre-processing, though they are going to have to do some to get the panels working. Technically, I can see how one could write code to convert panels, but it would be a heck of a job to do!

On the Baron front, it has been another week of progress, mainly in the areas of Checklists and Aerodynamics.

The checklists for "Before Engine Starting" and "Engine Starting" are pretty well complete & operational. During testing I came across a problem with left & right magneto switch animations. All five entries in the FSX modeldef.xml file use a variant of the partinfo shown below (just changing the engine index number), and use a depreciated variable "OLD ENG STARTER", which I do not think is mapped into MS Flight (it is not even listed in the FSX SDK).
<Code>(A:OLD ENG STARTER:1, enum) 0 max 4 min 25 *</Code>

The Baron Left & Right Magneto/Starter switches each have five settings: Off, Left, Right, Both & Start.
In MS-Flight, the available variables are:
{"Engine", "LeftMagnetoSwitch", "BOOL", 0,3}
{"Engine", "RightMagnetoSwitch", "BOOL", 0,3}
{"Engine", "StarterSwitch", "BOOL", 0,3}

(I'm puzzled as to why these functions are listed as "BOOL", when they can have four index settings (min=0, max=3)? I'd have thought that they would be of type "ENUM").

I'm not sure which FSX variable mapping, if any, is made in AddonBuilder to FLIGHT's LeftMagnetoSwitch & RightMagnetoSwitch variables. Any ideas?
If we can get that mapping to work, then the four positions (0,1,2,3) for each switch can be animated to Off, Left, Right & Both.

The switch still would not animate to the Start position, but this is a toggle, so reverts back to Both after a couple of seconds, so it is not a major visual problem. The lack of any Cowl Flap variables in MS-Flight is a much bigger issue IMO!

My limited testing, so far, of {"Engine", "StarterSwitch", "BOOL", 0,3} shows that it works, but only indexes engine 0 which, if confirmed, adds to the "single-engine-in-Flight" theory, discussed in previous posts.

I have not spent any time this week working on the mouse animation & lights problems. For the latter, I think the only solution will be to get AddonBuilder to handle GUIDS as discussed last week. I've worked out the index numbers for some of the lights (strobe, navigation & landing), but still need to identify the indices for beacon, taxi, panel, recognition, etc.