Recently, a third party studio encountered an issue with their WASM modules not behaving as expected when publishing their package on the marketplace. This was caused by the module accessing data in some of the package files like engines.cfg. Although this works for a Community package, some files are no longer accessible once the package is encrypted. Please make sure you are following these guidelines:
It is important to note that when publishing your packages to the Microsoft Flight Simulator Marketplace for PC (this does not apply for Xbox), an encryption system is applied to protect the package contents. This encryption system means that your WASM modules can no longer access certain files within the package, meaning the module will not be able to retrieve the information it requests. It is because of this that you should never rely on parsing the files listed below when designing your code.
For SimObjects, you shouldn’t try to access any file that ends with the following:
For Sceneries, you shouldn’t try to access any files with the following extension:
*.bgl
If there is information within these files that is required by your WASM module, we advise you to copy this information to a different file that is known to remain unencrypted (ie: a file that is not of the type listed above), and include that file with your package.
NOTE: This system may be reviewed, updated, and improved upon in future releases.
Thanks for reading this post, we hope it will save you a lot of headaches.
Could developers, publishing on the MS-Store , have the option to request that their .cfg file NOT be encoded… as was recently implemented for the Premium/deluxe planes ?
Our team personally doesn’t care about encryption to begin with and just utilize the marketplace because it’s the best place to sell on both PC and Xbox.
So an option to “Completely Remove” encryption is also something we want. I would rather give our PC Community the ability to dig into their own files. One of the main reasons they buy directly from our website vs the in-game marketplace is because if they use programs like Spad.Next that require digging into XML files for LVar trigger events, they need to open those core files for cockpit building.
An option to submit without any encryption is something our team has always wanted. Plus, this needs to be the standard for freeware submissions in the future (If you ever go down that route, we have over 12 addons just waiting in our freeware section to mass distribute in-game).
Modding community is huge in MSFS, most ignore ingame marketplace mainly because of encryption (even if some other reasons exist). If the option to not apply encryption will exist - we definitely are going to use it.
Considering a WASM module can only access files in its own package anyway, wouldn’t be easier to just transparently allow access to the encrypted files in its package ? This way, the module would behave the same in testing and release.
In any case, I would be pretty much in favor of a way for developers to tag files in a certain way, and decide what should be encrypted and what not.
I guess it might be done using some kind of token access.
However, as you said, since the encryption itself has been cracked anyway, it wouldn’t make much difference allowing transparent access to WASM to files in its own package, it will just make the whole testing process more reliable and, there might be add-ons that would need accessing their own files, which ended up being broken only after a submission.
I would assume the encryption would be re-enforced eventually. Reducing security for our products is never a good idea, better to implement proper solutions for the required objective.
As I do agree with your statement, encryption has been cracked for over a year now. If they are working on this issue in the background, I sure hope they address us soon or at least update us that they are aware and working on it.
Otherwise, as mentioned above, if the MSFS 2020 encryption is set-in-stone and new methods won’t come until MSFS 2024, then why encrypt all the files required for a clean WASM test between testing and release?
does it mean this limitation can be used by WASM script to determine is add-on launched from packages folder (if it encrypted/not readable) or community (can be parsed)?