Version: *1.3.7.0
Frequency: Consistently
Severity: *Low
(Low - quality of life, workflow optimization, rare enough to not impact production, etc…
High - critical but workarounds are available, important feature not working as expected, frequent enough to impact production
Blocker - prevents from working on the project, prevents from releasing the product)
Marketplace package name: if applicable
Context: What package? When editing or mounted from Community? In main menu or in flight? etc…Creating an aircraft Project
Similar MSFS 2020 issue: insert url here if applicable
Bug description:
WHen creating an Aircraft project the Presets folder is populated with
default and preseta folders
Default contains config folder with aircraft.cfg
preseta contains config folder with aircraft.cfg and attached_objects.cfg
This folder structure is different from the SDK docs for presets folder.
Repro steps:
Attachments:
Private attachments: Send a PM to @PrivateContent with the link to this topic and the link to download your content
1 Like
Hi, @DA40CGDFQ
I share the same type of problem that you reported in your two other recently created topics, because the Packagebuilder does not correspond to the documentation.
In my case, there are no texture subfolders created and several errors are returned, without a clear path to follow. I believe it could help if the DA62 sample example were more specific and clear about liveries and versions of the same aircraft linked to different model files, as this is not found in the documentation or in the sample example.
In short, at the moment it is impossible to create an aircraft using the Packagebuilder provided for 2024. My ready-made 2020 product simply does not compile even applying the same folder structure indicated in the documentation.
Better guidance in this regard would be welcome, even if it were just in a simple sample to help us better understand how to structure the files with the new PackageBuilder provided.
Regards,
Rodrigo
Hello @DA40CGDFQ
You are referring to this page, right?
The documentation describes what the folder can contain, not necessarily what will be created by default.
I fail to see how the default and preseta preset folders do not match that description. I know there are ongoing discussions about what’s mandatory vs optional.
What bothers you exactly? What content would you expect?
Regards,
Sylvain
The statements in the SDK docs on that page say:
Modular aircraft SimObj have a very specific package and folder structure that must be adhered to.
MUST
Then
The image below shows the essential contents of the folder for a modular aircraft package before being compiled
essential
then
Here you can see that there are 4 sub-folders within the modular aircraft package. Each of these folders is required for the aircraft package to be valid.
required
If liveries is not require to build the project - then it is not a MUST or Essential or required.
Just state that liveries is an optional folder when your project has liveries.
The issue regarding the livery being presented as required when they’re not is already tracked here: [2024] SU1 Beta - liveries folder not created in project setup - [MSFS 2024] Bug Reports / SDK: Tools/Samples/Documentation - MSFS DevSupport
I thought this one was about the content of the preset folders specifically.
If this is still about what’s required vs optional, that’s an ongoing discussion.
Also, some content might build but not give a working aircraft.
For example, nothing prevents you from building a ModularSimObject package containing only a common folder. This will not trigger any error on build, but you will not have a selectable aircraft in the menu.
Just like you can create and build a scenery with an empty BGL.
Ok sorry - I 've written way too many bug reports. Going to stop now - as I can no longer keep track of them all.
This new modular simobject stuff is way too complex - I just wanted to help make it less complex. Seems I am just causing you more work than is necessary.
Just pointing out that if you follow the SDK docs and actually do the steps needed and compare to what is in the SDK docs, they sometimes don’t match exactly - this caused me to question what is correct.
You can close this.
That’s ok, your reports are always useful and you often find things we overlooked. 
I just sometimes need a bit more explanation as I switch between subjects a lot and sometimes lack context to quickly understand a particular problem.
1 Like