A SHA-256 file integrity check on all core dependencies on MSFS start-up. Replace all modified and corrupted files which do not pass the file integrity check. But log all changes in a readable format.
VFS system cannot be overridden on all core dependencies.
A shared self-containment area with dedicated shared folder within the MSFS Community Folder for mods but all shared mod code is run in isolation. Even if the shared mod code fails to run it doesn’t cause a MSFS wide failure as default core dependencies will take over. The mods in the shared self-containment area can be disable by addon developers using a simple Boolean on/off switch contained in aircraft.cfg. AllowSharedMods=false.
Are we sure that files installed by MSFS itself are even being overwritten here, or is that a misunderstanding? Shouldn’t the normal Windows protection mechanisms, and installation repair mechanisms, be able to cope with that just fine? No need to invent new mechanisms, just rely on existing functionality. Or is the existing functionality not usable for software installed through the Windows Store or Steam?
(But yeah, already the fact that MSFS has its own package system and doesn’t simply use any existing Windows one makes me think that there is a certain amount of NIH here and that MSFS doesn’t necessarily use Windows functionality even where it would exist. Maybe because it needs to run on Xbox, too. Just a wild guess.)
VFS system cannot be overridden on all core dependencies
That I certainly agree with. It should be possible to derive from it, in a programming language sense, though.
AllowSharedMods=false
I would avoid the vague word “mod”. Unless it is explicitly and exactly specified what “mod” means in the context. End-users call almost anything a “mod”.
Core MSFS dependencies should be protected from modification in VFS and within the MSFS folder. SHA-256 file integrity check on all core dependencies on MSFS start-up solves the second problem. VFS system cannot be overridden on all core dependencies solves the first problem.
The shared self-containment area with dedicated shared folder within the MSFS Community Folder is for MSFS mods files on core dependencies. That shared self-containment area can be disable by addon developers to prevent shared mods files from causing their addons to fail.
This means mod developers can enhance MSFS core dependencies but these mod files must go in the dedicated shared folder within the MSFS Community Folder. These enhanced MSFS core dependencies can be disable by addon developers who prefer to use default core dependencies.
If these enhanced MSFS core dependencies fail to run successfully the fallback is default core dependencies. MSFS doesn’t crash. Addon don’t fail.
So you are seriously suggesting that MSFS should implement such a check by itself, and disregard any such functionality that Windows offers? Should each Windows app have its own file integrity check system? Doesn’t that sound a bit like duplicate effort?
Also, where would you keep the list of expected checksums? In a file? If some rogue add-on can modify the files “protected” by the checksums, it can modify that list containing the expected checksums as well.
Asobo already does the file integrity check during installation, updates and Marketplace purchases. It can be easily extended to check more files. The protection functionality that Windows normally offers for general applications such as MSFS can be overridden by administrator mode.
Actually, many applications from Visual Studio, Adobe Photoshop, Windows, and, etc all use some integrity checks to verify non tempering of core files. It’s not new.
Actually, MSFS core installation (which you download from Stream/Microsoft Store) around 2 GB contains all the checksums for the entire installation of MSFS.
Yes, it’s true. This is also done internally by those apps, including those DLLs that manage the licensing side. I think this is done through digital signatures and file hashes (checksums)
I don’t think we are using “overwritten” in the normal context of a file physically overwritten here. But in the context of the VFS, even if the original file is not touched, a package containing this file in its own package:
It’s overwriting the stock file, without any need to overwrite it on the real filesystem, obtaining the same result.
A better term might be the file has been “shadowed”, as in many programming languages, where a local variable in an inner scope shadow another one with the same name declared in an outer scope.
That’s what the VFS is all about and, when used properly, it’s a particularly useful method, because you can easily go back to the stock file by removing the overriding package.
The problem is more like knowing what has been overwritten/shadowed, which is not that simple considering how many files are involved. So we’d definitely need some kind of reporting tool, maybe integrated in the existing VFS tool in DevMode, something like a button to show all files that has been shadowed, and by which packages.
Exactly, the shadowing or “logical override” of core system files such as BaseInstrument.js is one of the biggest problem with the current VFS implementation. I also found DataStore.JS being logical overridden like this and to make matters worse was obfuscated so you could not even know what they were trying to do, but it wiped Cloud store data for users!!!. Coherent.js was another, which damaged listeners and core system functions.
Anyone trying to do custom avionics that requires changing these type of core files can simply do their own version and reference them in their project, achieving the same results without breaking MSFS and the entire ecosystem for other 3rd party developers. Working title avionics framework has also create the plugin system, which allows developers to inject their variations of functions without having to shadow their base files (another behaviour I been finding… people shadowing WT GarminSDK.JS, MSFSSDK.JS, etc., destroying any airplane avionics functionality for the entire fleet of the user!!).
These are other CORE files that should not be shadowed like this, specially when you read the SDK instructing you to do something such as for example, how to put dynamic registrations on your aircraft, which says use a VPAINT in your panel.cfg and use the registration.html to achieve your result. Is part of the instructions that any 3rd party developer will follow and will be working just as explained in the documentation.
Then some random developer (intentionally or un-intentionally), decides to MOD and shadow / logically override the base registrations.html file so it works for their own purposes, destroying the entire ecosystems and causing all registrations to stop working as per SDK for everybody else.
Similarly with other key .JS and .HTML files in the system, this is what is breaking coherent constantly and why I am requesting such important core files to become protected in a sense that they stop being overridden by the VFS as it is happening now.
It would seem that Caenado is one of the worse offenders, overwritting “registration.js”, even when they have their own version that they are actually referencing and using. (CustomRegistration.js)
Or maybe I HOPE I am mistaken here ?
This is very dangerous, as a plane could be using their own version of a file, yet still be overwritting EVERYONE else’s, who are not using their own version.
This seem to be what Carenado is currently doing, leaving an old modified copy of “Registration.js” in their plane folder structure ?
If I am wrong here, I apologize … someone please correct me. …
With either Carenado and other planes that overwrite registration.js removed
OR
With those plane’s registration.js REMOVED (deleted), as they use their own CustomRegistration.js
Obviously rebuild the layout.json files of those plane you remove the registration.js from, or put up with a “Failed to load” error in the Dev Console.
Indeed, and pay closer attention to their PC12, they are overriding avionics (airbus, boeing, core, all sorts!!), icons and much more.
And this is going into official folder, not even the community folder… asking any customer to clear their community folder have zero effect when these files are being installed by an official 3rd party developer into the msfs official folder.
Have also a look at the amounts of custom fonts overrides with wrong font names, is incredibly bad.
It is becoming impossible to develop any aircraft with advance avionics in this sim with such fundamental core flaws and such bad development practices.
I am considering ditching any glass cockpit futures development and sticking to only dumb gauges, unfortunately even if i follow this path, you still get issues with other core files being destroyed…
We really need to hear Asobo views on this and what is planned to address this problems properly.
@OMGEDSON has pretty much everything installed on his computer so it’s a good base to start from. In a report generated from his PC, Those are some examples of overrides that could cause issues without any devs being aware.
