Does this mean that users who do not yet have the beta (versions prior to 1.6.25) will not be able to see or use this add-on?
Or is compatibility still guaranteed by the line:
“minimum_compatibility_version”: “6.25.0.156”
I would like to understand whether it is safe to publish the scenery now or if it is better to wait for the public release of build 1.6.25 to avoid loading issues for non-beta users.
Hi Gobby,
thank you for your response to my question on the forum. You confirmed my fears, so I decided to force the manifest.json with the following parameters:
Unfortunately, this decision creates some complications in the product release process, especially in terms of compatibility and version management on the marketplace.
You really shouldn’t do this: there are reasons why a package built with SU N should never be used with SU N-1 - doing what you described may lead to crashes on the player’s end.
If you want to release your package on SU3, then build it with SU3.
If you build it with SU4, then wait for submissions to be accepted for SU4 from the Marketplace Team.
Reading this, I think we’ll end up including some kind of CRC/hash in the manifest to spot such tweaks and reject submissions that use them.
This is only comprehensible if it was clear exactly which files get modified by a “Package Build”, i.e. layout.json and the texture files, but anything else ? I understand the SDK UI will edit a CFG file if you change some value in a UI textbox, but it’s unclear whether files might get modified as a result of ‘load project’.. ‘build project’. TBH having a build process modify files that a developer has editted would be extremely unusual, for good reason.
Any output file can be changed, as is the case with any compiler - why would only layout.json or texture files be changed?
Here you are speaking of editing the package sources while your previous question was about the built package (compiled files).
Loading a project may upgrade some source files but you should be warned about it:
Building a project may upgrade some or all compiled files but not source files.
And unless I am mistaken, we don’t do this - but what is the link to the original topic/question?
Thanks Eric for the clarification. I fully understand the risks of forcing compatibility and have no intention of jeopardizing player stability.
My concern stems from the fact that the add-on I’m developing benefits greatly from the improvements introduced in SU4. If I compile it for SU3, I’ll inevitably lose some of these improvements; if I wait for SU4, however, I risk slowing down distribution.
It’s the reality you face with any platform when you work towards getting your product ready for the next iteration of the said platform through one of its beta version.
My point is it is not clear which are the ‘output filles’. For a compiler it is clear - the input file is “.c” and the output file is “.exe” and the compiler never changes the “.c” file. There are linting tools that may look at the ‘C’ from the programmer, but there is no suggestion those would change the C file.
In a MSFS package there are lots of files - cfg, js, css, bin, png, json, xml - many of which are expected to be editted by the programmer, i.e. they’re akin to the .c file input to a compiler.
For example, what’s the status of the .cfg file in MSFS ? Is that an input file or an output file? If it’s an ‘output’ file can a programmer still edit it, which wouldn’t make sense if it’s an output file.
The relevance is fairly central - the difference between an “SU4” and and “SU3” package that a programmer has to watch out for is specifically relevant for files considered an “output” of the build process.
Your project is made of Asset Groups which specify an “AssetsDir” and an “OutputDir” - anything from the “AssetsDir” is considered as “package sources” while everything that will be processed and generated in the “OutputDir” should be considered an “output file”.
Not trying to be pedantic but that may be useful later on in the discussion:
The compiler input files are “.c” indeed - however its output files are “.obj” (on Windows at least)
The linker input files are “.obj” and its output files are “.exe” or “.dll” (and “.lib”)
The reason I am mentioning this is that it is important to understand that what we call input or output depends on the tool we are talking about.
For instance, a glTF is a source file (and a target/compiled file too!) with respect to the MSFS PackageBuilder. But the glTF source file is also the output file of our glTF Exporter.
As per my explanations above, it’s both! You edit your CFG “source” file through the SimObject Editor (or VSCode or Notepad for those who don’t like the editor), and upon building your package you get a processed/compiled CFG in your package.
We have warned against editing built packages since MSFS 2020 was released - which did not prevent developers/users from doing it. So to answer your question: you should never alter an output file in a built package. The method to change it depends on the situation:
If you are the package creator, change your source file and rebuild the package
If not, create a project that will produce a package that can use VFS overriding to replace the file
If you build with SU3 the “manifest.json” will state that the package is valid for SU3 and higher.
If you build with SU4 the “manifest.json” will state that the package is valid for SU4 and higher.
Since we advise against fiddling with a built package, including “manifest.json” and “layout.json”, I still don’t see the relevance.
The programmer doesn’t have to know the difference between the output files - he has to know which version of the sim he wants to target, or at least the features he wants to use which will dictate the version he targets.
