Idea

One reason to have 'all' animations in this, is that there are 'different parts' with similar animations. Example, some ailerons have percents, some flaps animate differently, so you could have 3 or 5 different animations for a part, so the list would need to include all versions of each animation, not just the one.
You could (would need to have these) in sections in such a master document, such as control surfaces, gauge needles for engines, landing gear, propellers, doors, etc...

Right now, it can take days, literally days, trying to find the name for a part, its 'Use Template' code block, the animation 'name' which is important as MSFS Asobo see's the code as an identifier and handles it accordingly. Without the right name for the animation (different then the part name) then it will not work, and some parts have a 01, or 1 at the end, etc. We need this valuable data in order to animate our planes, quick and fast.

Example; in FSX/P3D, your animations are all listed in one area, a XML part document which the compiler uses to make the model with. And in Max, it had a parts access window to that list so you could look up your animation and set it in Max.

With Blender, we have to look through tons of Behaviors (many, such as sub-behaviors), and when looking at the master behaviors, it is hard to see, figure out, what in the world we need. Its vaque. We just need the simple 'part name', 'animation name', the text date (code block) that we copy/paste into the model XML document of our plane, and the key frame amounts that the part is designed to use, and done! We animate the next part.

In FSX/P3D, we could have parts named and working in minutes to an hour for an entire plane. Presently in Blender for MSFS, it takes days to weeks. Literally...........


Bill

LHC

Agreed... this would be a great help

Maybe something to add to the sdk documentation?

But such documentation would mean that the APIs would need some stability guarantee. I am not sure that is a good idea at this stage. It might become a burden for future development. It is almost better that using Asobo's templates is "on your own risk".