@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.