[VFS] We need to find a way to stop this madness

[SimbolFSReborn]

Dear Asobo,

The VFS systems is incredible powerful and very useful indeed, and I think it has great advantages, however we must try to do something to protect key and important core base MSFS files.

There is not a single day when I do not get support tickets with customers complaining with:

• Black screens / avionics due to failed coherent modules thanks to 3rd party content overriding base .JS MSFS files that shouldn’t be touched.

• Touch screens failing to work due to clicks spots not working thanks to 3rd party modules overriding base MSFS files.

• Weird behaviours in avionics and systems due to 3rd party content interfering with core MSFS files, for example reversionary mode failing.

• Missing airplane registrations due to 3rd party content overriding MSFS core files.

Every single time I get these (100% of times!!!), is due to another add-on which fails to understand how the base VFS system works, and is overriding base core MSFS causing severe problems for customers, who obviously blame our products for their entire simulator issues not knowing they had a rogue software using bad developing practices.

So far I have encountered 3rd party add-ons out there overriding the following:

• Registration.html, developers are putting this file under HTML_UI\Pages with their mods and modifying it to their own needs, not understanding this breaks the base registration.html file causing all airplanes in the system to fail to produce the registrations!.

• BaseIntrument.JS, I mean what else can I say, why on earth any developer would need to fiddle with such an important base core file is beyond of my comprehension. But by doing so they destroy clickable EFBs, touch screens, etc. causing very bad problems for many developers.

• Base .HTML files that would cause instruments to start failing… I mean why, why someone has to override base .HTML files that do not belong to them?

• Found also add-ons overriding the base data store classes for JavaScript… this was nasty… it was corrupting customers clouds accounts and wiping their data… again, why overriding such file?

And the list goes on and on… it is like the wild west out there… but the issue is this not only affects the reputation of our products with customers upset because they do not understand what is really happening, it drains our resources, many times users even refuse to clean their community folders because they are fixated you are the problem… this is also affecting Asobo and Microsoft resources, I can’t even imagine the amount of tickets raised on MSFS Zendesk as a result of such bad developing practices.

As the list of free and payware mods out there keeps increasing, we must take steps to avoid this doom loop spiral, I believe the VFS system should protect base core sim files from being overridden, stuff like Registration.html, BaseInstrument.JS, Coherent.JS, DataStore.JS and many other IMPORTANT BASE FILES should be totally excluded from the VFS system override… this is getting out of control.

Thanks for listening to my feedback, I am more than willing to help to test solutions and improve MSFS, this seriously cannot continue guys, the system is broken like this…

All the best,
Raul

[cdgonzalezgo]

First, thanks Raul (@SimbolFSReborn) for fixing the acronym, I was going to tell you about that
Now, regarding the subject, I thought I was alone in this regard, because I also had lots of support cases with the same problem, especially nowadays where I updated all digital instruments of my EMB-110 to HTML and WASM, and facing the same problems you described (black avionics screens, unusable instruments, unusable EFBs, etc).

Now that you mention that, there are some mods that override the base JS files, especially the ones belonging to the BASE HTML instruments framework, makes me feel worried and angry at the same time. I mean, it’s welcome any improvement, but altering the base framework without at least having some control can cause these headaches to us the developers. Not to mention the bad coding practices and possible syntax errors on the road, because those can make the Coherent engine to act like everything crashed, and in “Domino effect”. This is a headache to me, unfortunately

In my right mind, I NEVER alter those base JS files. Come on, it’s the base framework. The only thing I do is opening them in an editor like Visual Studio Code (prior backing up to a separate folder, of course), and just looking for the methods, calls, functions, and whatever I need in order to achieve the results I look for. But, if I need to create a more complex functionality on a base instrument (let’s say the KR87 ADF), I prefer copying the base HTML or JS to anywhere else (a custom VFS location), without altering the base one in its original location. I did that for my EMB-110 to create a more custom functional KR87 display, copied the original source and pasted to my own package and modified what I needed, without messing up the original instrument.

Anyway, this madness MUST stop.

Regards,
Carlos Gonzalez
NextGen Simulations

[SimbolFSReborn]

Hi Carlos,

Be aware that copying them “with the same name” under the folder HTML_UI\Pages and using the same folder structure as inside of MSFS Official, will cause the VFS system to mount yours in preference of MSFS base files, overriding the base files entirely, is exactly part of the problem.

You need to either use a different folder structure and reference yours, or simply put rename them to something else and reference yours instead.

But yes, this is causing real havoc… this add-on for example, which was releases as a freeware and stopped being supported is one of the worst culprit (GitHub - Heavy-Division/B78XH: B78XH is an open source and free modification of default Boeing 787-10 in Microsoft Flight Simulator.)

Anybody with this installed, will have touch screens not working at all… look what the mod is doing:

This is forcing all sort of base MSFS files to use its custom .JS code for all airplanes in MSFS… and they were modified before SU10 release… you can see how bad this can lead to problems.

And this is just one example of over 50 I have at my hand!, we need somehow to start protecting these base core files from being overridden by the VFS… it beyond madness.

Best,
Raul

[TangoMikeLima]

One would have thought that Microsoft, of all companies, with its long experience of “DLL hell” etc (that luckily has been fixed now, in modern Windows versions, as far as I know), would have known to anticipate 3rd-party developers not understanding what they are doing and causing problems for other 3rd-party developers… unless the system prevents it.

[cdgonzalezgo]

Hi Raul (@SimbolFSReborn),

Be aware that copying them “with the same name” under the folder HTML_UI\Pages and using the same folder structure as inside of MSFS Official, will cause the VFS system to mount yours in preference of MSFS base files, overriding the base files entirely, is exactly part of the problem.

Thanks a lot for your advice, and for reminding me that! Anyway, that’s precisely what I did on my case. Below I can show you:
The first one is the folder structure of the original Asobo’s KR87, with its standard folder structure (html_ui\Pages\VCockpit\Instruments\Generic\Radios\KR87)

Now, on my EMB110, this is the folder structure (html_ui\Pages\VCockpit\Instruments\NextGenSim\EMB110\ADF)

So, you can see the original instrument remains unaltered, and my aircraft calls the custom one in my package instead.

But yes, this is causing real havoc… this add-on for example, which was releases as a freeware and stopped being supported is one of the worst culprit (GitHub - Heavy-Division/B78XH: B78XH is an open source and free modification of default Boeing 787-10 in Microsoft Flight Simulator.)

Oh Jesus Christ! That’s totally a problem! And its the MapInstrument. I guess my weather radar wouldn’t work at all, if this gets installed, because it heavily relies on that class.

Yes, and since this base code evolves with every MSFS SU/AAU, and if it’s not accordingly AND correctly updated, of course this becomes a headache

Thanks again!
Regards,
Carlos Gonzalez
NextGen Simulations

[dev]

@SimbolFSReborn

As the list of free and payware mods out there keeps increasing, we must take steps to avoid this doom loop spiral, I believe the VFS system should protect base core sim files from being overridden, stuff like Registration.html, BaseInstrument.JS, Coherent.JS, DataStore.JS and many other IMPORTANT BASE FILES should be totally excluded from the VFS system override… this is getting out of control.

There isn’t much Asobo can do at the moment to protect core system files for MSFS. Any 3rd party application or user can overwrite a file with the right account permissions.

Any locks placed on modifying files within MSFS will cause community retaliation against Asobo, Microsoft and any developers who support the change.

But Asobo could start SHA256 integrity file check on every base file every time MSFS starts against a known list of good SHA256 hashes and download a replacement copy if the integrity check on a file fails.

You can do the same too, write a program which contains an known list of SHA256 hashes from your own clean installation of MSFS and integrity file check each user installation of MSFS and replace the modified files with clean versions to solve support issues. Must sure to digitally sign the program with a CA issued code signing certificate. Also open source the program for security researchers.

[SimbolFSReborn]

This is not the case, is not like people are overriding the base files by overwriting the files…

We talking about the VFS system which makes files with the same names to take preference in the loading order in the system. Basically imagine you had my.DLL file inside C:\Windows\System32 and because another 3rd party dev, puts another file inside another folder C:\myfolder\System32\my.DLL that file takes preference causing a “logic override” of my.DLL.

This can be easily prevented by modifying the VFS system to skip base core files that should be protected, quiet frankly, nobody should be overriding coherent.JS, DataStore.JS, BaseInstrument.JS, MapInstrument.js, etc. it only causes trouble and instabilities for the entire ecosystem, I don’t want to sound rude, but, I don’t care if any developer gets upset because MSFS starts preventing them to override a file that is protected… they can easily fix this by writing their own library and referencing things correctly.

What we have now is an ecosystem growing into instability, causing users to be fedup of CTDs, add-ons breaking with each update (due to unsupported mods overriding these files) and many users are quitting the hobby, is becoming to difficult to keep their system stable.

This is not helping the flight sim community…

R.

[TangoMikeLima]

Tongue in cheek: Maybe the thinking is “Oh, Windows, well that is what Windows gamers and enthusiasts want, to be able to ‘mod’ anything, even if risky, if people want absolute stability and security they should stick to running this on Xbox”…

[dev]

I agree. It’s definitely a massive problem but not simple to solve. There must be reasons why the VFS logic acts in this way. Only Asobo knows why.

[dev]

The problem is, it’s not even funny, this is a massive security hole that requires closure.

No other modern game gives developers unrestricted modification of files without proper containment. Many MSFS developers are simply not educated in modern security frameworks to rewrite years old modules of FS code. I known there is WASM support but I see few MSFS developers use this. Maybe code old style is preferred to get the job done. But forcing users to install background applications to run addons is backward in terms of modern security.

Also having all these background applications running to run MSFS addons certainly causes stability issues. That’s why clearing the community folder doesn’t help sometimes to fix issues. It’s the background application itself causing MSFS to CTD. I know this post is beyond the issues Raul is facing with VFS system. But there is more that needs to be done overall to increase stability and security in MSFS for the long term.

[cdgonzalezgo]

I think the following should be the “right way” for the core MSFS JS types. It’s my opinion, you all can correct me if I’m in the wrong direction.

The coherent.js, and DataStore.js (if I’m not mistaken) are located within the packages of the core application (where the main EXE is). The other types (MapInstrument, BaseInstrument, etc.) should be located there as well. Like Raul (@SimbolFSReborn) said, these must be protected and not touched by the community. Those files together build the MSFS’s Coherent framework, the sim’s UI, assets, in-game panels, instruments, etc., and whatever tampering is made (and if not made carefully) can cause Coherent not to work correctly. Plus, rescuing @dev ‘s idea (which is a good one), the sim should also perform that integrity check, especially in case any of the JS types’ files is tampered.

Again, the purpose is to both protect that code from breaking changes and those side effects that Raul cited at the beginning of this thread, and increase the sim’s stability.

If this isn’t going to be taken into consideration for the current release, this at least should be taken care of for FS2024.

Regards,
Carlos Gonzalez
NextGen Simulations

[bagolu]

I’ve also had my share of debugging to find out the very common B78XH mod used to interfer with base system. It may have been corrected since but who knows how many old versions of the mods are still in community folders here and there ?

Protecting base (asobo) directories in VFS, preventing overrides, could be a solution in that case. It would also make the old versions of thoses mods harmless.
But it would probably break other kind of mods like p42 flow, menu replacements, etc.

[dev]

Maybe the temporary solution to the issue @SimbolFSReborn @cdgonzalezgo is to write an if/else or try/catch statement in your addon preloading state to check if the existing file loaded in the VFS system is not modified by using SHA256 file integrity. If the VFS loaded base file is modified then use a backup version contained in your code to ensure your addons are working.

[SimbolFSReborn]

You can’t… once coherent is broken nothing works! All crashes… even the check code will fail to run.

Besides it is not our mission to perform the health checks, it is the mission of the core sim… in hence me raising this issue here…

Best,
Raul

[N6722C]

@dev

But Asobo could start SHA256 integrity file check on every base file every time MSFS starts against a known list of good SHA256 hashes and download a replacement copy if the integrity check on a file fails.

I 100% support the SHA258 check part, but if it finds a altered/corrupted file then the action taken should be carefully considered, and at least a log generated to highlight any failed files, so both Developers and Users can check to see which addons are doing the core file overwrite-- so that appropriate actions can be taken, by both Users & developers.

If the system is going to consider reverting altered files back to the Core originals, they should probably also be an option in the dev console, to control this, maybe with the default action to be overwrite.

There should also be a Prominent section in the SDK, WARNING of this Overwrite issue, and outlining how to avoid this, by , if using your own version, using it in the way it will not affect other assets,

There is a lot of ignorance about this, even by some 1st party Devs !!

[SimbolFSReborn]

We are well pass this stage… we cannot afford sitting everyday asking an user to enable dev mode, checking a console, asking for logs, is just a waste of resources when the reality is, there is absolutely no excuse to override base msfs files such as coherent.js or BaseIntrument.JS for example.

Besides this is now even happening with official content pushed via marketplace! So when it reaches xbox, there is absolutely zero chance to troubleshoot this with any customer.

I am sorry guys, but we must put developers in place here and prevent these bad developing practices.

R.

[N6722C]

100% agree, but give :“uninformed” Devs the tool to test if they are mistakenly overwriting base file.
I think many are doing so without knowing it.

That’s why it is called DEV Mode !!

[davux3]

P3D had an almost untenable addon situation with various configurations and folders spread inside and outside of the sim directory.

MSFS by contrast has utterly obliterated that problem with the VFS. Addons that run in-sim are now a known quantity. The addon files live together and are easy to compose into or remove from the sim.

This is great and a huge step forward. As a result of this change, the addon ecosystem in MSFS is and has been absolutely bustling since 2020 was released.

Now, developers here and everywhere else are interacting with customers that have taken advantage of the new addon structure and enabled them to trivially compose their sim from many addons. I also interact with customers daily and the majority of problems are down to addon interactions. I keep hearing the same from everybody I talk to who also does support.

I see options for us to act independently of Asobo or the platform:

Be proactive on isolation where possible
We should avoid using shared files when we have the ability to use an override (without changing a base file to accomplish an override). This limits the conflict to the actual sim base files that shouldn’t be touched. I did this with one aircraft many SU ago and it’s not needed any maintenance since.

Work together to reduce support burden
I would suggest that we develop a tool that end users can run that looks for conflicts between packages.

In order to discover VFS composition issues, the tool would:

• Locate and process Official and Community VFS source paths to create a correct VFS view without running the sim
• Discover and view conflicts between VFS files

End users can run the tool and report a log, or most could read the errors themselves. In practical terms if a user removes every conflicting addon from the list, all VFS conflicts will be removed and the likelihood of the products working is pretty high. Developers that don’t know better will also be pushed toward the tool and can run the tool on their own addon and see the list of specific files that are in conflict, which will lead them to fix their addon no matter their skill level.

Dave

[dev]

@SimbolFSReborn

Besides it is not our mission to perform the health checks, it is the mission of the core sim… in hence me raising this issue here…

Asobo is not totally to blame here, you have shared responsibility, so use your standing within the FS community to force minimum standards for addons. Community RFC policy.

[SimbolFSReborn]

I am really sorry, but I totally disagree with your statement… I am following the SDK to the letter, and due to this core system flaw which allows anything to override core system files, I have been punished with angry customers, hundred of hours of support cases wasted due to rogue software which I am not responsible for and bad ratings on my products due to rogue software which I am also not responsible for.

And in exchange it seems, in the view of some developers here, now it is my responsibility to have to spend my entire time trying to fix issues generated by other 3rd party content, and even waste resources creating add-ons to perform health checks, just because we have 3rd party software breaking the sim.

My responsibility ends with my own add-ons, not troubleshooting faulty software created by others. I have better things to do that sit all day long answering anger messages from customer with broken simulators and asking them to delete their entire community folders + official folder in order to find out what broke their Microsoft simulator.

I will await for Asobo to review my request to improve the situation, even if it can only be done by MSFS 2024. Any 3rd party developer here creating aircrafts with advance avionics knows very well the amount of time we are wasting with these issues, and is a pretty fundamental problem with the way VFS works, not the way we are building our own aircrafts in the first place, even default asobo / Microsoft airplanes avionics are affected by this issue.

Best,
Raul