I believe You didn’t make it on purpose to stamp out community works. I hear You about current and proposed solutions.
I remain unconvinced they will match the speed and ease of access of the old ways, but maybe You guys can surprise me and I’ll eat my words.
As concerns the fate of 3rd party market, time will tell, we’ll see.
Best wishes 
Is the intention to integrate this into the in-sim toolset or as an external conversion tool like XnConvert? Are the specs used for your custom container published anywhere? I could not see them in the documentation?
Vote #1 on the importer. This is incredibly vital for livery makers to be able to make new liveries whether they be texture based or the preferred method of decaling with the new sim. Also, kind’ve vital if the package tool is going to enforce a requirement for an uncompiled model reference in its build process whether needed or not.
I’m going to add my voice to the seeming dissatisfaction about the route that developing is taking specifically within the Flight_Model area, having finally managed to get the game to open, stay open and let me build the SDK sample! The first point that I would like to make, and this is really fundamental to a lot of Flightsim dev work but especially so in regards to the topic of flight models, is that many (probably most) of the people working in this field are hobbyists. People that have real-world jobs that can take up a lot of their time and leave limited hours for this hobby. People to whom the idea of spending days, weeks, months even learning processes and areas of computing that they have never needed to use before is likely enough to turn them away from this hobby. I started working on flight models when I gave up real world flying because I was dissatisfied with the realism of sims at the time. Starting in FS9, I learnt from the likes of Pam Brooker and John Cagle and contributed to a hobby that required little more than an understanding of flight, an ability to translate that into text or air files and the ability to test that in game. Please bear that in mind when reading this and many other posts - your 3rd party devs are often not armed with the same level of resources or time that you have, but as has been proved time and time again (and referenced by others in this thread) they are key to the ongoing success of the MSFS franchise and my personal opinion is that every effort should be made to make things work for them, as much as for Asobo. @EPellissier your continued engagement here is very much a part of that and is appreciated, but there needs to be far more practical help in the area of the flight model - that is ‘my’ tagged subject here, so I will remain focused on that.
Taking points already made - IF the quick reload is replaced by a much faster Build Package button, then that may be okay. As a flight model developer, when I’m dialling in a figure (e.g. speed for rpm under a given set of circumstances), I could be making tens or even hundreds of tiny adjustments reloading and re-checking after each one. Quick reload was sub- one minute. That has to be what you are aiming for, and it has to be a one button press. Talk of ‘creating another package’ is no good for me - I do not code, I just work on how aircraft fly, as mentioned above 
Why would I want to do anything other than directly modify the flight models which are my responsibility to create for the companies which ask me to and who supply me with a package specifically to do this? I think the quote
perfectly describes the flight model dev environment as it currently stands.
It would be incredibly helpful to have a straightforward description of, and possibly even an example of, how the completely new bits that are not addressed at all in the SDK work (if they are in there, I have failed to find them and apologise, but again if they are there they should be clear and blindingly obvious):
First point is a massive change and a potential trip-up for any dev, so I have to ask why it was done this way - in the DA62 SDK build, the engine positions appear to be defined laterally, vertically then longitudinally (or it could be Lat, Long, Vert, it doesn’t say). This is a break from all previous location standards in both 2020, FSX and prior which have always defined points Long Lat Vert. Looking in the Aircraft Editor, there is no definition of which is which and it also means that we now have both of those position definitions within the one game, lack of standardisation.
The modular build in the flight model has some points that are probably straightforward (Dim Scale - dimensional scale, defining the actual shape?)
Surface Cx, fair enough but three numbers behind it? What do they refer to and how do tangent, normal and efficiency affect behaviours?
element_number = 6, 3, 20 total number of sub surface elements composing our surface template - what are 6, 3 and 20? How is that relevant to a flight model if they are sub surface (other than weight, which I believe is addressed elsewhere)?
Nothing I can find in the SDK addresses these, and again in the Aircraft Editor there is no information, just a series of boxes to fill in.
Things that may be seemingly simple to the people that built them, but when unleashed on Devs with no explanation take a lot of head-scratching and trying to reverse-engineer what’s been built into default aircraft (yes, another reference to Devs doing that as a standard, we’ve been doing it since pretty much FS5.1, because we have never really had such an SDK as you have provided us with but it’s still severely lacking where it matters!)
The Aircraft Editor - this is something which had many issues in 2020, and is something which I steered clear of for everything other than the ‘Gizmo’. Are we now to trust that this works with no issues? It adds nothing to the ‘clarity’ of the SDK - perhaps you could look at Aircraft Airfile Manager to see a truly useful tool for flight model development: displaying your lines of numbers (tables) as a graph, so that oddities are spotted quickly, decent notes that explain what each parameter does with clarity, accuracy and brevity, a simple layout that is (in my opinion) far more user-friendly than the aircraft editor.
I know what I have written probably sounds overly negative, but I have always spoken my opinion bluntly and truthfully (the day job requires it 
) and I find that trying to ‘be nice’ whilst getting a point across invariably masks the points being made. I will just add that I am in awe of what Asobo have created. I wish it was a logical, open and straightforward environment to work in.
I have a couple of commitments, but unless there is drastic improvement in clarity and simplicity, I believe I will be heading the same way. When the confusion and frustration outweigh the enjoyment, it is simply no longer worthwhile as a hobby. Given the issues but especially the UI of 2024, I will likely not even use it but instead use a combination of P3D and 2020 for ‘enjoyment’ when that time comes.
Every devs best option is to just make modules for 2020 then port to 2024 and scrounge whatever money possible from FS24 until this console-catered dumpster of a casual game meets its fate.
Very well put Phoenix! I sure hope Asobo listens. Without guidance the frustration will drive me away from 2024 as well. It’s unfortunate. I was so looking forward to all the flight model improvements that were being advertised. However, without guidance and functional tools to use them, I’ll be out this “game” as well.
I tried this flow, but either I am to dumb or there is a bug!
More of my findings when I find the time and I am in the mood to write a detailed error report.
Think I will stop with writing mods for MSFS until I can work at a pace I am used to. Until then, back to sim-racing modding.
These are some great points, especially when making “improvement mods” for the MSFS aircraft. Like my Bonanza Mod for 2020, for example, I’m starting to mod the G36, and at the moment, I have no option but to do a complete reboot of the sim every time I make a change!!!
I’m joining in with the scepticism about the lack of re-sync. It’s all very well to say that one “simply” remounts the assets in the VFS etc, but in reality the current SDK explanations are threadbare and it is clear that the VFS is deeply flawed in its current state.
For a long time (over 20 years) several iterations of flight simulator have had a quick reload function. I get that things are more complex now and I’m not against change. However I’m not a fan of some changes just for the sake of them.
The sheer volume of needed re-loads when modding or creating are not to be under-estimated. When re-designing, lights, liveries and flight models for FS2020 I typically had to re-sync thousands of times, and that is what is required if you want everything to be as perfect as possible.
Re-mounting assets looks to be a lot longer, and of course re-starting the sim is utterly untenable as such mods are going to take literally years rather than weeks or months, since re-sync is a few seconds but re-starting the sim and reloading the asset takes upwards of 6-8 minutes PER EDIT.
So in effect this means I and many others are not going to be modding anything any time soon.
Of course, as with many things related to MSFS 2024, things have not been thought through and clearly this is now an after-thought, if it ever gets adressed.
It is a nightmare! I’ve started making groups of edits to try and speed things up. Still, this process, in effect, takes even longer to implement as I am developing in the: read docs, kinda understand them, trial and error method of making a mod. My aim, like the 2020 version, was to make the G36 as true to real life as possible.
Bulk changing code (I’m currently working on the G36’s electrical system) rather than change, reload, change, reload is OK, but tracking down a bug in the code takes much longer.
Yes I feel your pain. Another issue is that many of the parameters have changed protocol or format but they are either woefully explained or not explained at all. Doing multiple edits per reload is a good idea and I have tried this but it still takes at least 5 times longer than a simple re-sync.
Eric talks about copyright/intellectual property of professional developers but in fact when I have purchased past aircraft for fs2020 outside of the market place not a single dev I spoke to wanted to encrypt their work and indeed welcomed mods with open arms (particularly liveries but also cfg file tweaks) as they realise that their sales INCREASE when they have accessible cfg files within their packages.
I get that some protocols in FS2024 are necessarily different, but I do not accept that the creation of a quick re-load function is any more difficult than it was before. After all you are just reloading the package, but in a much more efficient way.
100%
If only they could allow us to point to a VFS folder and reload that on command - that, for me, would be fantastic; otherwise, as you mentioned, my mod will take months to even get to the point of its first release.
I’ve debated doing it with groups of edits too (along with notes, comparisons, multiple copies of the files, etc) but there’s one key thing I’m missing in this as a (primarily) flight model modder - quick comparison. There are times I’ll edit a number up and down 0.05 or whatever until I find that sweet spot. The previous quick reload let me compare the new with the old directly after a 5-10 second refresh. No waiting for several minutes for a project re-sync. No sim restart. So even outside of the Projects flow proposed here, it’s now a much slower process
So we’re promised the Projects flow will speed up substantially. If this means down to a 5 second resync, ok. But somehow I don’t think that’s what it means.
However all this is temporarily moot for me personally as I’ve uninstalled FS24. I’d say I’ve gone back to FS20 but the sheer amount of bugs, annoyances, and frustrations with 24 has left me with very little desire to fly anything at all in any sim, let alone mod.
I’m working on an aircraft mod, changing the PIDS in ai.cfg of an existing aircraft. I can’t figure out the project rebuild thing, so I’m restarting the sim with each edit. Would someone be willing to share a video or write out step-by-step instructions that a modding novice could follow to get the project refresh thing working so I don’t have to restart the sim each time?
Also, I’m adding my voice here in asking for an easy, quick (less than 10 seconds) reload feature for someone making iterative tweaks or doing fine-tuning on an aircraft with a mod. Thank you!
Hello Eric,
To move the conversation forward a bit, I have tried doing these steps exactly with the goal of replacing the engine and flight model of the Carenado NGX with our own files.
When opening the VFS I see that the carenado folder only contains our own files (which is wrong) but also the default PC-12NGX still flies the same and uses the old FM data -seen in the debug windows.
Did I do something wrong, or does this only work with 3rd party packages?
Okay, to bump this one a bit further as it is now 15 days since my post (I know, festive break etc, but we are devs and just keep on ploughing through!)
You asked for specifics as to where the SDK was lacking, because you had heard that mentioned but never been given such specifics. I touched on it in my earlier post, but with the DA62 project open in front of me here are some pointers as to why people may be suggesting that the SDK is lacking in detail. Or actually, just lacking . . .
Obj ea1 surface:
Position ok
Direction ok
Span, sweep, incidence, dihedral, twist ok
Can dihedral take a negative? The tailplane couldn’t in 2020, but there are plenty of aircraft out there with such a thing so it would be nice to know anhedral is accounted for.
Stall alpha - okay
Stall alpha ff - Fuel flow? Free flight? We need to know what your abbreviations mean.
Element weight - ok
Element spacing - means absolutely nothing to me. I am defining one object. How does a single object have spacing?
Element width - ok
Element number - how is a coordinate relevant to this?
Size - ok
Relative position of the surface - ok, but could do with confirrmation that this is relative to the model centre position.
Surface Cx - ok
Surface Cx normal - well surely that is just Surface Cx, already defined?
Surface Cx efficiency - no idea at all.
Surface Cx nscalar - no idea at all
Surface Cx npower - no idea at all
It may interest you to know that a google of the three Surface Cx directly above gives nothing relevant to aerodynamics but the last one does lead me to an energy supplier for my electricity . . .
Compliance - no idea.
Damping - does not make sense to have a single damping effect without specifying in which directional plane it applies that effect.
Hard depth - absolutely no idea.
Front scalar, back scalar, front scalar ratio, back scalar ratio all mean absolutely nothing without explanation. The first two are already a scalar on something, and then a ratio on a scalar???
Dim Scale I mentioned previously - needs clarity or at least a note about how it functions.
Linked behaviour index - absolutely no idea.
Surface angle (deg) - no issue at all.
Modifier - modifier of what?
Modifier angle scalar - so that’s a scalar to the angle of the thing I don’t know?
Modifier position scalar - as above, but to the position of the thing I don’t know?
Modifier surface relative position scalar - do I really need to . . . ?
Group - presumably binary, but there appears to be no description anywhere of what each index is?
That is just ONE file out of several, which we are expected to use to build objects within the flight model. I would say that at leat 3/4 of it is not documented, not standard aerodynamic theory and not straightforward to understand.
This is where you get the comments along the lines of the quote in my previous post about flight dynamics currently being a “hostile environment”, combined with the fact that many flight dynamics questions in the later stages of 2020 (the last 18-24 months) were seemingly met with a wall of silence.
There is a strong feeling amongst developers that the SDK is inadequate. There is an even stronger feeling amongst those of us that work solely in flight dynamics that the SDK is pretty much non-existent where it matters. It’s very pretty, with descriptions and pictures of boxes around points. It is very comprehensive in the theory behind how it works. But it gives us NOTHING to tell us how to put Asobo’s ideas into practice.
To go a stage further and talk about the implimentation of defining the shape - how on earth are we at a stage where the simple shape of an aircraft requires the complex nature of all the confusion above? Why can we not just load the wireframe model in an editor and drag the points to surround the shape precisely? Then have a modifier file for aerodynamic behaviours?
I think “hostile environment” is an understatement.
The main problem is that we are dealing with a 25 year old flightmodel that has just had things added on top.
And then you get factors to control these new added features. Those are all those weird factors and configs.
I need almost 6° of wing twist to make my wing behave like the real one which only has 2°. I cant control the lift and drag curve of the wing. Its all precalculated by an excel formula.
Anyway, I was told by someone high up that im doing/expecting too much from MSFS. Hes definitely right. I understand why A2A have their own flightmodel now.
If you have created another package with the same name as the original one, you are essentially replacing it - what you need to do is to create another package named “sws-aircraft-mod-carenado-pc12” and add your files to it. The two files your package contains will override those of the original aircraft and the VFSProjector will show all the files (original ones + your modded ones).
Best regards,
Eric / Asobo
We know that the documentation is lacking in that field (and others), and there are many reasons why this is the case (which I won’t go into detail here). An effort is being made internally to improve the situation ASAP but there’s a lot going on right now and I can’t really give an ETA today. 
Please don’t hesitate to list the other aspects of the documentation that, according to you, are lacking and preventing you from doing your work - this helps putting priorities where they should be.
BTW I believe this discussion has deviated a bit too much from the original topic (see the title) - maybe we need new topics for each documentation aspect that is lacking information?
Best regards,
Eric / Asobo
A new topic is a great idea. This one has wandered off corse.
Here it comes…
I’m not altogether sure whether this discussion has deviated that much. But in terms of config files, encryption and quick reload I observe that nothing useful has come out of the discussion except more and more people confirming that available info in the SDK is woefully short of what it can be.
For now the only choice for many is going to be the creation of mods or whole aircraft using the FS2020 SDK or at least known parameters for each discipline.
In other words I cannot see any advantage at all creating or modding anything for specifically FS2024 when doing so for FS2020 is reasonably reliable, making such mods or creations reside in the community folder of FS2020 (by the way there are issues using the FS2020 “official” folders within FS2024).
It seems to me that not using the quick re-sync/re-load function has been a complete disaster for many people as what has replaced it is reliant on an already admitted broken or impossible to understand SDK.
Clear explanations are absolutely vital if an SDK is to be at all useful. Further up this thread are some eloquent descriptions of some really obscure parameters which do not make any sense at all. It is as though someone has invented their own non-standard language to describe something only they understand. That is not what any SDK or indeed any useful manual should have in its contents.
