Sure, my point there was that the work Asobo put into the simulator in the name of security is not applicable to PC, where the user has total control of the machine.
I think what @EPellissier is getting at here is that broad definition covers the entirety of every package within the sim that hasnāt been added by a user or installed via the Marketplace.
Using that definition would mean no mods or add-ons affecting any sim default planes, avionics, or really anything provided by the platform itself would be possible, which Iām assuming is not the intent here. Thus, a smaller, more focused list of āthere is really no (or extremely limited) use case for modifying specifically these filesā is what I feel is the spirit of the ask.
I feel like stuff that falls into this category, from a JS standpoint, would be the VCockpit framework itself (so, VCockpit.js, Coherent.js, BaseInstrument.js, etc).
Thanks,
Matt
4 Likes
If we kept this to advisory warnings, we arenāt talking about blocking files. But, apparently this is will end in blocking some files? Iām sure almost nobody in this thread wants to block modification to the entire base sim. 
That suggestion goes hand-in-hand with the idea of starting with observability and then adding specific validation for identified problems.
We fundamentally believe the VFS enabling overriding these files is good and enables a type of modification that should be allowed (even if only for Community use). There are plenty of reasons to want to override even Coherent or VCockpit, but certainly not when submitted to the marketplace. We hope that distinction is meaningful for you folks too.
In this thread Registration is a live example. If a dev were doing that though, it would be an accident so a warning would be a great first step there. MapInstrument might still be a good candidate as small tweaks there seem to be common and the result could still end up causing avionics load failure/black screens depending on the edit made.
Itās probably right to consider a few base sim directories for marketplace full lockdown, but the issue is still that not having general observability into overlapping files is resulting in files included in a package that shouldnāt be there. That solution will only be solving the problem for the directories selected today, but weāre going to live with unexpected overlapping in the VFS for the duration of the title/series.
As for lists of filesā¦ it would be great to work backwards.
- Iām sure its possible for somebody at Asobo to acquire marketplace package file lists
- Exclude some types of files and then compare with an export of the base sim files. Weāre mostly talking about modelbehaviors and avionics that are able to tank other content, but exploring that topic is also a way to figure out what is critical and what is secondary. Most addons donāt override other content, so I am curious how large of a pile this is. Even if it is huge, attacking this set is the heart of separating righteous overlapping from accidental or invalid overlapping.
- Youāll have a list of every overlapping file in the marketplace, then start excluding paths and youāll know exactly the scope of this problem and which directories are posing problems in practice so they can get targeted for validation.
Probably a controversial opinion. Iāll put it here anyway for anyone to read and discuss.
The foundational framework within MSFS is an enormous complex machinery. Itās vulnerable to unintentional breakage. Modifying the core foundational framework whether via VFS or wherever causes issues across the board. Really only Asobo should be touching the core foundational framework files. Asobo only really knows what is going on behind the code.
The modding community really need to step away from MSFS. They are doing more harm than good. Every sim update changes lots of files. Many of the changes are undocumented in the public domain. Maybe that is for security reasons.
A good example, MSFS is 3+ age certified, but the modding community decided to abuse the light variables index to show multiple weapons in multiplayer. I mean, come on, what do you think Asobo is going to have to do? Try and block it. Microsoft says no weapons in MSFS.
As with add-ons there are other similar abuses happening and we pass it off as enhancements. I understand why developers do it. Push the boundaries as far as possible, great a superior add-on with more feature sets. But the unintentional side-effects are causing issues within the core foundational framework.
The VFS breakages is causing issues with complex add-ons. This is all happening at a larger scale than anyone realised and unlikely to stop anytime at all.
There really needs to be a changed in developers and modders thinking towards MSFS. Iām beginning to believe full lockdown of core foundational framework is critical for the long term. Different onboarding process to install add-ons within the MSFS file system to limit unintentional breakages. Modding in MSFS should be disallowed on the core foundational framework.
I also understand it will prevent developers including myself freedom of developing but maybe the best solution is the hardest most controversial solution.
1 Like
I donāt think this game would survive the removal of the 3rd party community.
3 Likes
@EPellissier Hi Eric,
This is a list of files and directories I consider should be protected from logical overrides āif possibleā given the limitations you and your team might find, etc. I have placed a description under each as the reasoning and what I have encountered in the wild so you guys can use the feedback during your internal meetings, discussions and possible action plans.
asobo-vcockpits-core
This folder contains Vcockpit.html, Vcocpit.js, VcockpitLogic.html and VcocpitLogic.js. Pretty much essential to the base systems. I have seen 3rd party add-ons overriding this for their own benefit, resulting in other aircraft now loading their custom code and breaking functionality that varies from GPS autopilot failing to work properly, click spots failing to operate around the cabin, JS Listeners to responding as they should, etc.
asobo-vcockpits-instruments
This folder in my opinion is the most important to protect, this folder contains all the required files that are necessary to create any custom HTML gauge / instrument.
I have seen 3rd party addons overriding baseinstrument.js, mapinstrument.js, maptinstrument.html, canvasutils.js, the basic Gauges .JS, the Waypoint.js, and others.
The results are that basically no custom instrument would work, you get touchscreen instruments missing the touching properties, they become unable to be pop out, they stop working with black screens, partial displays, missing functionality, etc.
Examples of custom instruments ceasing to work: EFBs, HIS, Clocks, Radios, and anything that uses baseinstrument.js.
It is important to clarify, the SDK documentation specifically state we should use these classes to build our HTML / JS Gauges (unless we wish to use the WT framework of course), so if these classes can be logically overridden, the documentation on these becomes quite frankly pointless. So either we instruct developers to do a custom copy of these and use custom files, or we protect these ones from being overridden by the VFS system somehow.
asobo-vcockpits-instruments-navsystems\html_ui\Pages\VCockpit\Instruments\NavSystems\Shared
These files are required by many instruments to work properly via nested dependencies, some 3rd party add-ons have been overriding the NavSystemTouch.js and NavSystem.js causing severe problems for many avionics since then they refuse to work properly.
asobo-vcockpits-instruments-wasm
This handles the linkage to WASM modules in the panel.cfg, should not be overridden by the VFS for obvious reasons.
asobo-vcockpits-systems
In here we have systems.js and systems_AS100.js, these re special plugins used by Asobo and WT Garmin units to handle reversionary mode. I have seen mods changing these causing reversionary to fail, units going off due to power handling modifications and other odd problems increasing frustration from users not understanding why certain things don work anymore.
asobo-vliveries
Contains registration.JS and other special files required for the dynamic registrations to work, this is a JS file specified in the SDK documentation with specific instructions regarding how it is supposed to work, parameters, etc. and how to use it in the panel.cfg.
IMO for that reason should be protected, or alter the SDK documentation so everyone writes its own version of this file to avoid breaking other aircraft.
fs-base-aircraft-common\ModelBehaviorDefs
Contains all the model behaviours also specified in the SDK documentation, I have seen mods overriding the indexes of these to point to their own libraries, and as a result it affects how many airplanes end up handling animations, input events, etc.
Since the SDK documentation makes specific reference to these files, I think mods type āAIRCRAFTā and Aircraft packages shouldnāt be allowed to override via the VFS any files in ModelBehaviorDefs
Special files mention:
/JS/coherent.js, /JS/common.js, /JS/Types.js, /JS/simvar.js, /JS/avionics.js, /JS/simplane.js, /JS/Services/GenericDataListener.js, DataStore.Js,
I found in certain occasions these files installed in the VFS system in a way to cause an override with custom files that causes for obvious reasons lots of troubles. I cannot think for the life of me with a 3rd party mod or software requires to override logically DataStore.js or Coherent.js for example, but anyway I think these files should be considered as part of the core as well.
Fonts
Not sure if they should or not be protected, but I have found many 3rd party mods trying to change the way some instruments or part of the system looks, and instead of trying to inject custom .CSS overrides or HTML pages, etc. what they do is to inject a custom font with the name they need, but the source file font is different. Let me explain, they want something to look like Arial-Bold for example, so they would put in the mod the structure to override robotto-light, by putting a Arial-Bold source font with the name of robottoā¦ is madness, the result is that anything that uses now robotto ends up looking like Arial-Bold causing many layouts now to get out of position and working incorreclty.
This is also happening via aircraft packages that are installing custom fonts with such names but the fonts are different from the base system, as a result, they override another aircraft font with a wrong type or an outdated version of the font or a newer version of font, which also ruins the layout of many products (including in game panels, EFBs, Tablets, HTML Gauges, etc.).
So perhaps Aircraft packages shouldnāt be allowed to override via the VFS these either.
This is my list, once again many thanks for taking the time to discuss this subject with all of us, if you have any questions, or you need some more information let me know.
I will trust your team judgement in any case to find some ways to alleviate some of the issues described above and at the same time leave the platform open to continue supporting the ecosystem that MSFS can offer, I am not proposing locking everything down, but I consider we need to find a way to balance things and bring much more stability to end users, who frustrations are understandable growing and growing to a point that many are considering abandoning MSFS entirely.
All the best,
Raul
CEO FSReborn.
5 Likes
Of course, I wasnāt arguing the removal of addons (simobjects) from 3rd parties. I was discussing about the modding community should step away from MSFS instead of destroying the platform with changes to the core foundational framework. The changes which cause problems for everyone including Asobo with every Sim Update.
1 Like
+1
I approve of this list of files to be restricted from being overridden in VFS.
+1 to this list you made, Raul (@SimbolFSReborn) !
Regards,
Carlos Gonzalez
NextGen Simulations
We have released our free tool to scan your sim VFS.
Simstaller (parallel42.com)
6 Likes
I am astonished this the response to a tool that will simply put help all the 3rd party community to identity problems to support our customers while Asobo can find ways to prevent this issue from happening.
Quite frankly anybody afraid of this tool is simply put an ofender and now is scared to be called out.
Good luck trying to send me to court because I point out via this tool (or the internal msfs VFS report which accomplish the same objectives and results) that a mod is causing issues with the base core files of msfs, quite frankly if I could sue the developer of the 787X mod for losses and damages due to their incredible bad developing practices I would!. But of course it is not the objective here, we know many developers are being caught by how the VFS system works and are doing this without understanding the consequences.
I have never seen a competitor producing a tool and making it available to all the rest of the competition so they could use it to ensure they are not having problems and also to help them with their own support handling. So quite frankly callin //42 anti competitive on this matter is incredibly ironic.
From my side I want to congratulate //42 for their efforts and for providing this tool as a stop gap, i have just helped 4 customers tonight which were clueless what was causing FSR500 EFB to not have clicks working, all them found the 787X mod installed which was the culprit thanks to siminstaller.
This was normally a 3 hour job of exchanges of emails with customers, reduced now to just minutes and very satisfied customers which knew immediately what to do.
Honestly I cannot thank //42 enough for this, and while the tool is out, given the reactions and accusations presented here, it highlights why we need also Asobo help to put this under control.
Thanks Keven and Edson for sharing your tool with all of us, keep up the hard work for the community.
Best,
Raul
CEO Fsreborn
7 Likes
The legal system is designed for people with tons of money to win. No small business can afford the law fees to cover all appeals and etc. Most small businesses give up and accept any conditions.
I donāt like that but thatās how itās setup. Indie cafe in Brixton takes on hedge fund-backed coffee chain over name | London | The Guardian
Ok looks like you want to sue me for telling people that a mod is preventing their Simulator from working properly?
You must be really looking this from a ver bad angle.
Might i ask what products do you develop? I am really curious now, you input in here is incredible negative, we trying to kepp the ecosystem working as it should, i have wasted more than 200 hours of support due to these conflicts so far, thats 200 hours i cannot sit and develop new products due to bad mods out thereā¦ a big lossā¦
I am not here to be lectured about legal systems, i am here to try to improve msfs ecosystem, if you want to discuss legal stuff feel free to contact my solicitors. I can provide you their details if you wish.
R.
You may believe I am negative but I am not. There is dishonestly. This exists in the flight simulation market. Anyone selling flight simulation products should be on the look out for dishonestly. Cheating your way to become number one is dishonest and anti-competitive.
Every closed source unity tool released by competitor that affects other competitor products must be looked into with caution. Thatās not negative behaviour. Thatās using judgement to realise that even good companies and individuals do bad even if they believe itās for the good.
Iām not going to discuss any products or who I am. That doesnāt help anyone.
There are two sides to each point or story, must be looked into with judgement.
Well, I believe your replies are negative. You have implied that //42 is cheating by stating
āCheating your way to become number one is dishonest and anti-competitive.ā
Yet, you will not come out of the shadows and say who you are. You talk about laws, well an accused has a right to face his accuser. Yes it would help, as people could see where you are coming from and why you are taking the position you do.
This is a simple file compare utility. Nothing more. How does this utility āaffect other competitorsā? You are again implying that //42 has done something bad. It merely points out conflict files in the VFS.
I asked ASOBO two years ago about best practices for modifying and using their templates and was told that there was āno riskā, yet here we are. And now someone develops a tool to help the entire flight sim community fix this issue and you turn it into a conspiracy to take advantage.
6 Likes
Hello everyone,
Please stay on the subject.
If this discussion turns more about competition law and lawyers contact exchange than the VFS, Iāll have to lock it.
Regards,
Sylvain
5 Likes
I would like to begin my reply by congratulating @OMGEDSON and @runshotgun from Parallel 42 for their Simstaller tool. Iām going to give it a try on both my development laptop and my pre-production testing desktop PC, especially on the VFS conflicts check.
Itās possible that Iāll make it part of the Support protocol for my users, in order to identify the issues found. And if the user refuses to use it, wellā¦ itās up to him/her but he/she must be aware of the problem.
Also, and in case Simstaller detects possible conflicts on my products, I will acknowledge it and perform the required fixes. And, depending on how well it performs, I will perform a VFS conflicts analysis to a pre-production package before deploying, so that I can make sure I do my best not to cause conflicts with other addons, like the ones produced by other really amazing and talented developers like Raul (@SimbolFSReborn) and you //42 guys (@OMGEDSON and @runshotgun ) and modders like @N6722C from WBSim
Thank you so much for such an amazing tool! Great job!! 
Regards,
Carlos Gonzalez
NextGen Simulations
4 Likes
Thank you!
We welcome any feedback towards it as well. If you think something isnāt right, feel free to get in touch with us!
1 Like
@runshotgun Thank you ā Thank you and again Thank You 
Just downloaded you SimStaller Tool and ran it, and of course it detected all the āUsual Suspectsā
Delighted to confirm that we did NOT make the āUsual Suspectā List.
Those that did, I guess need to be āDealt withā !!
Personally, I can either remove them or āattempt to fix themā, but in the long term, what process can be put in place to :-
- Let the developers know they are overwritting system files
- Incentivize developers to fix those issues.
- Maybe, keep the MSFS Community aware of those products that form a Overwrite risk
N6722C (Skipper-Geoff)
WB-SIM Dev Group
3 Likes
Great feedback!
The mission to inform offending developers is not our fight to lead. The goal of Simstaller is knowledge and awareness of whatās happening in your sim. Knowing is half the battle, and before Simstaller, consumers likely had no idea how many add-ons battled over a single font or light FX file.
What they choose to do after identifying harmful conflicts is on each customer, the same as it is with each developer to care enough to do something about it. Oftentimes, the developers arenāt aware of the impact some of their development practices have on the simulator as a whole. Letting them know would be a nice gesture and could lead to an update fixing the issue if there is one. But thatās something customers will need to take on.
1 Like