I know, but i keep forgetting because this wasn’t necessary for the past 4 years (and probably the 20 years before)
1 Like
The problem is that it’s impossible to do everything from the ground up. One example is liveries. Currently, modders only have access to LOD1 models, not LOD0 models. This limitation creates multiple problems that cannot resolved.
Another example is avionics. Mods such as the FlyByWire enhancement of the base A320 would not have existed if the planes had been encrypted as they are now. The same applies to Working Title, ironically. This situation is a significant discouragement to modders who are not affiliated with Microsoft or who might have wanted to start contributing to FS2024.
1 Like
Since the layout.json file appeared with MSFS 2020, the probably the 20 years before statement is certainly correct. Having the file sizes in this file is important for a variety of reasons, one which being that it avoids unnecessary disk access which can take time (even if it’s less of an issue for SSD). The fact that MSFS 2020 allowed for more flexibility was a mistake.
We should probably stress this in the documentation but the only official & supported way to create a package is through the included Package Builder. It may have its flaws (which we are happy to work on when they are reported) but it does a few checks (not enough yet) on the source material that avoid a Marketplace submission to be rejected much later on, or the “manually fiddled & built” package to crash the sim.
As others have said it is easy to create your own project that overrides files found in one or more packages. I think the main issue right now would be for people working on their own package: each package build triggers a reloading of the VFS (because priorities have to be recalculated), which triggers a reloading of many systems, which can take (significant) time. This is being worked on.
Best regards,
Eric / Asobo
Since MSFS 2020 also had encrypted LOD0 models (except for Standard aircraft - which will also be the case in 2024), how did you create your liveries in this version of the simulator?
Best regards,
Eric / Asobo
If we want a quick reload button, then the layout.json needs to behave like it used to.
1 Like
YES please, we NEED a quick reload option, without a doubt! Without this modding will literally die and a huge part of the community will be very upset and angry.
1 Like
I’m not who you asked, but 2020 aircraft with encrypted LOD0 usually only got texture liveries (by modifying the texture files). This was made a lot easier if you had access to the model to paint over using a program like Blender. Often the LOD1 was good enough for this (787-10)
To make liveries the recommended way (using model merging) you need the unencrypted LOD0 to model the livery over.
At the moment we still don’t have a way to open the GLTF’s that come with the game, so doing liveries the recommended way, or the texture way via blender, isn’t possible.
The only way to make a livery at the moment is with Photoshop and hand editing the texture files. Which is very labour-intensive, especially since you need to build the KTX2 via package builder to see the results.
Not being able to open LOD0 GLTF also means we can’t add handmade objects to aircraft via presets which is IMHO the best new feature of the modular aircraft system. I would love to add the correct aerials, fuel tanks, other random variations using the presets system and our own objects, but this cant be done with the LOD0 GLTF being locked down.
I took a look on VFS Projector with lastest update, and now all Standard Aircraft is now unencrypted
They are infact decrypted but, the Behaviour files are the compiled ones, so unable to use them to learn how things are done, and the GLTF are compressed, so not able to be opened till someone figures out how to uncompress them.
I don’t think this will happen - the layout.json is in there for a reason and we won’t change the way it works. It is unlikely we will add another “Quick Reload” button either - it wasn’t working the way you may think it was anyway, was not reliable when using base containers, and it definitely won’t work properly with modular aircraft.
There is an official pipeline to create packages which should be used by everyone - our work & aim is to make it as reliable & quick as possible when building a package that only changes specific files. We will probably add shortcuts to its logic so that a “Build package” gets eventually as fast as the old “Quick reload”, but we must ensure that your built package is mounted in the VFS the same way as the shipped version, so that you don’t see different behaviors between editing the package and loading it normally into the sim.
Best regards,
Eric / Asobo
Our standard aircraft use the Compiled version of Behaviors indeed (for performance reasons) - unless we distribute their sources (which I don’t think is possible for all of them for legal reasons), I am not too sure what we can do to help. Maybe you have precise questions on what you are trying to achieve?
As for compressed GLTF I thought there were already tools around to look into them - I’ll talk to the appropriate people to clarify.
Best regards,
Eric / Asobo
Yikes, that’s not good news.
1 Like
thats very dissapointing, i guess i wont be making any FS24 specific aircraft…
2 Likes
Ideally, the sources that can be made available, would be made available. Either through the SDK samples or by keeping them in the game packages.
Asking a question on how something is done on this forum is okay, but it’s much slower than us being able to just go look. It turns a 10 min job into a 3+ day one.
Things like the button on the C172 mixture control that moves when the control is moved, or the lock on the C188 spray handle that requires two mouse inputs to move. I can think of a way of using the Mouserect template to do both of these things, but a part of me thinks there might have just been a variable in a template that achieves these. Unfortunately atm, there is no way to check that suspicion since you can not open their behaviour XML to examine them. (not that the C188 would fall into the decrypted category anyway 
)
Yes, that’s why you have the DA62 & Cabri G2 included in the SDK.
Can you elaborate please? Are you saying you want to go on working outside of the official pipeline even if it is made as efficient as a trick that wouldn’t even work with certain asset types?
Best regards,
Eric / Asobo
Those aircraft obviously don’t use every template that is available to us. They don’t even use all the basic ones. Neither use templates you might use in a turboprop or a jet
Hypothetically, I’m a new dev and want to see how the mixture lever on the C172 works. I go to the Templates SDK and search for Mixture, I get three things, none of which mention anything about any buttons. There’s no comments explaining what any of the fields do and what is needed or what is not needed.
Whereas in 2020 I open the C172 behaviour XML and I straight away see a <BUTTON_NODE_ID> field, use it and I’m on to the next part of my project
4 Likes
Hi Eric @EPellissier ,
Can we at least access the model behaviours sources templates to analyse them?
As a feedback, so you understand why people would like to access standards planes, it is to see example about how to do things, the biggest difficulty is the documentation in the SDK regarding model behaviours is very scarce, hard to follow and very, very hard to understand in most cases.
Most of developers when developing an aircraft would follow a process / line of thought similar to this:
A) I have this 3D model (in the cockpit or external) I need now to animate this button or aircraft part and put it linked to a model behaviour file so MSFS allows me to click it or shows it animating, show a tooltip, have an input event, etc. The next logical question in our brain is is, ok how I do it?
B) We would find an aircraft from the base sim that has done something similar, open it up to inspect it and find it what default model behaviours it is using in the templates.
C) We call the same template for our aircraft now, examine the model behaviour template and work out how the animations should be named in 3DS or Blender.
D) Perform the changes, export the Animations and see our new button work, etc.
There is a similar approach to implement avionics as well.
Now, we have to face the reality Eric, we do most things by reverse engineering how default airplanes are being done, the technology on the platforms move faster than the documentation and unfortunately, the DA62 example and the calibry are not enough for people to understand and work out how to do something.
Take MSFS 2020 SU15 patch as an example, the changes in the avionics and core were very fast (new G3X, new G1000, new ground physics, and much more), the flighting lasted almost 3 months and you guys needed our feedback to ensure things were working. While the flighting was in place, no documentation about the new ground physics parameters were available, neither how to configure the new G3X avionics as working Title was still performing changes on the fly… and yet we were required to start testing these changes in order to ensure things were working.
This was only possible because we were able to open the default C172 to check the changes in the flight model and find out the new ground physics parameters in the flight model.cfg so we could start experimenting.
We were also able to open the default Xcub to find out how panel.cfg, panel.xml and the model behaviours files were required to be implement in order to use the new G3X.
Have all these being encrypted or compiled, we would have been sitting in the dark unable to do anything until documentation was available, which happened many months after the flighting started (and I am going to be honest, the documentation is not enough in most cases, we need specific examples, it is just too hard to understand what we need to do in many occasions and circunstances).
This is why you getting the reactions you seeing on this topic, people are now very concerned they will be unable to understand how to do anything… MSFS 2024 changed so many things, model behaviours, modular airplanes, etc. and our previous knowledge of how to do many things are pretty much now not helpful at all, we need to re-learn pretty much everything, in hence the need to be able to explore how default aircraft are being done. Take the soft body, CFD points airframe definitions as an another example, the current SDK documentation says, coming soon… so we have no clue what to do… same with how to implement bug splatter, mud, dirt, etc.
I hope my post helps you to understand better the concern of the community, they are not asking for premium products to be totally open or anything like that, but I think having at least 1 aircraft type available to allow us to understand how to do things should be done would be much more beneficial to the ecosystem, 1st party developers, 3rd party developers and the overall mod community.
I am more than happy to go into further details with you, Seb and Jorg if required so you guys understand much better our workflow, I think it is important the SDK team at Asobo understands how we work, after all, the SDK is designed for the community and if you guys don’t understand how we work, what difficulties we face, what are our challenges, etc, we can end up with SDK tools that despite of their power and how amazing they are, we would be unable to fully utilise to their full extent.
Thanks for coming here to address our question and concerns,
All the best,
Raul
15 Likes
They are distributed with the MSFS 2024 SDK in the ModelBehaviorDefs folder.
I am well aware of the issues some 3rdP developers are facing right now, but thanks a lot for the detailed explanation 
.
I don’t think reverse engineering is the right solution though (for a number of reasons - let’s name at least IP protection & wrong assumptions when reverse engineering something). I strongly believe that more documentation and more complete samples are the way to go, but then you either need time to produce these OR legal agreements to distribute sources.
Anyway, I am discussing ways to improve the situation internally - don’t expect too much feedback on this before January because of the holiday period, but we’ll see how we can promptly address those concerns in early 2025.
Unless I missed something this is also possible in 2024 since 1.2.7.0 - of course the issue of CompiledBehaviors being used also comes into play here.
Regarding these topics I have just talked to our technical writer who will update the relevant pages with the information he has. For insect splatter, you can find some information here: Windshield And Windows
Best regards,
Eric / Asobo
2 Likes
Correct, how we know what to configure for the Avionics button to work etc? for example back in MSFS 2020, for configuring the G1000 units, we could open the Cessna caravan and see how the AP buttons behaviours should be, then the G1000 buttons, dials, knobs, etc, should be.
Similarly for the G3000 in the TBM, etc.
With these compiled, now we unable to understand how to fully do it… this would apply for many types of avionics, for example, imagine I want to use now the new avionics used for the PC12 NGX and PC24… how I do it?
Or imagine I would like to use now the new UNS-B avionic units? how I would configure the buttons, etc.
We need to aim to keep consistency for people that use key bindings (due to real hardware implementations they do), so being able to hock up with the default key binds and behaviours o the core planes is a bit advantage not only for 3rd Party developers but users overall since we give them the best end user experience.
Feel free to ping me at any time and ask me for examples, the better it helps you and the team to understand how we work, the better for everyone.
I wish you and the team a great Christmas and holidays Eric, thanks again for always being so transparent and helpful towards us.
Best,
Raul
9 Likes
Yikes. This is terrible news
“Quick Reload” was indeed working the way many people intend. It would happily resync assets changing most things, such as xmls, cfgs, and other aircraft changes reliably in a few seconds. The only thing it wouldn’t resync is liveries since a few years ago this “feature” was removed, devs citing lack of interest. There was interest and no one listened when there was pushback on it. It feels very familiar.
You say there are ways to resync aircraft through a project. Discounting the fact that many, many people don’t even have a project to “reload from files”, I’ll kindly ask you to describe, step-by-step, in-detail, how one goes about resyncing things like cfg and xml files in an aircraft or aircraft mod without having the entire project. The SDK documentation is severely lacking in this area and, in several cases, still references the quick reload button.
4 Likes