We still need a solution from the core perspective.
Keven shared a full report with me yesterday and honestly I wanted to hide in a dark room after…
Things are worse than I though.
R.
If you have a repo, I would love to clone immediately. Looks like what you have is already quite useful.
OH – so that was you in the “dark room” with me !!!
I don’t have the tool (yet 
) , but just using “Anywhere”
- (almost Instant search manager, with very powerful filtering and sorting - a “MUST HAVE” Tool)
I can see so may VFS overwrite conflicts, that I am no longer surprised, that so many with different planes in their Hangar, are having so many strange up to now, unexplained issues.
Please could you share a repo of this tool with me to build and check for myself? I’ll sign an NDA if needed.
This is why Eagle Dynamics completely locked down their core folders and enforced all community mods to User/Saved Games folder, like 8 years ago. Any changes to core folders will fail the multiplayer integrity scanner. This mostly put an end to people making bug reports based on community mods.
This is really great to hear @runshotgun !!
Please let me know as well when you have it ready, because this would serve as a very important tool to check for issues with the core Coherent files, and in the hope of reducing support cases related to this.
I am very angry to see Carenado is making such an offense with this bad development practice.
Thank you!!
Regards,
Carlos Gonzalez
NextGen Simulations
Yea and that’s also why we aren’t developing for DCS
1 Like
Let’s also, though, not forget that we would never have even been able to get started on our mods if all those core avionics files were locked down at the time. We would have just moved on and WT would never have even gotten started.
There’s a fine line between what counts as core and what doesn’t, and that line isn’t obvious nor will it mean the same thing to everyone.
Certainly, I, as an affected developer, can empathize, but no obvious solution jumps out at me that wouldn’t very adversely affect some party.
2 Likes
Your loss. Devs there have less headaches than ones here. 
Hi everyone,
We are discussing this topic internally but as Matt wrote above we haven’t found an obvious solution yet to how such a system would/should work (thanks for the suggestions though).
One thing we’d be interested in is a list of files you would like to see locked - we expect this list will be different for each of you but that would be good starting point.
Thanks for your help!
Best regards,
Eric / Asobo
2 Likes
Hey Matt,
Of course, but I am not asking them to be locked as not accessible for people that want to mod, I am asking some modules to be protected from the VFS system logical override, as, they should stay as the latest in the system for all airplanes since they are from the core coherent systems or SDK requirements. Anyone wanting to create a custom mode can easily copy / fork and create their own versions, mods should never come at the price of the system stability as it is happening now with things out of control.
I doubt very much your team would ever override stuff like the way we seeing thought, you guys have always followed best developing practices.
I will provide a list for Eric this week as he is requesting, mostly are the required javascript files to be able to create a basic HTML / JS instrument as per SDK, the VFS override of these it is what breaks most of everything out there.
Thanks to you and the Asobo team for your attention on this matter.
Best,
Raul
2 Likes
On one hand, thanks to you Matt (@MattNischan) and you Eric (@EPellissier) for your answers in this regard, guys. On the other hand, and just like Raul (@SimbolFSReborn) said, the purpose is not locking those JS files from being modified because this would also disencourage modding in some way, but instead make the sim NOT to allow overriding those base files with the ones from existing mods, so that the Coherent engine, especially regarding HTML instruments does not get corrupted, allowing for both proper functionality of existing instruments, as well as the development of, even, a very basic HTML instrument like explained in the SDK documentation.
We all feel really tired of seeing those bad development practices that we explained (and thanks to researches and findings as well from, for example, @N6722C), and which led other users around to “throw buckets full of ice water” (like we in Colombia, where I am from, use to say) on us the developers who follow those good development practices, just like Raul explained from the very beginning of this thread.
By the way, Raul (@SimbolFSReborn), if you need help with the list of files, I can help you as well. For me, I would like that even the JS files that the navigation, DataStore and other sub-frameworks which compose the main Coherent framework get this overriding protection, but at least with the ones used for a basic HTML instrument would be a good point of start 
Thank you all for your responses, and lessons from this topic, and hoping this issue can be solved.
Regards,
Carlos Gonzalez
NextGen Simulations
2 Likes
@cdgonzalezgo - I am not sure I understand this statement. One thing we really would like not to see anymore is add-ons modifying core files directly - to me this is even worse than overriding through the VFS!!!
So when you write “the purpose is not locking those JS files”, do you mean “please do not encrypt them” (which we would agree with) or “please let us rewrite them if we want to” (which we should disallow)?
I think “locking” (in the senses “make them non-overridable”) some core files makes sense - we were not planning to encrypt them so that developers cannot see their content anymore.
Best regards,
Eric / Asobo
2 Likes
Hello Eric (@EPellissier),
Sorry if I was not clear with my explanation, but this is what I was trying to say. Just like you, we all do not want anybody alter (modifying) the core files, even if including their own modded version AND while retaining the same folder structure as in the original core files, because that IS the main reason why those failures happen. Please let me give you an example to better illustrate what I am trying to say:
Let’s say the sim has the following core file: html_ui\Pages\VCockpit\Instruments\Shared\BaseInstrument.js
Now, let’s say there is a modder X who wants to “update or improve” some Y functionality into that JS file, and what he/she does is copying that same original core file into his/her own package Z, and improve it in his/her own way, but decides to retain the same folder structure, instead of creating his/her own folder structure for that purpose, hence having this path:
html_ui\Pages\VCockpit\Instruments\Shared\BaseInstrument.js
Currently, when the sim loads the VFS, it loads the original core file, but then ALSO loads the “modified” JS file from the custom package Z. This causes the sim to rely on the modified code instead of the one you (Asobo Studio devteam) made. So, if that modified code is bugged and/or full of syntax errors, this leads to a “Domino effect” of literally damaging the instruments experience.
Now, what if the sim’s VFS loads ONLY the original version of the JS file I put in the example, and ignore the modified JS file with the same folder structure in the package Z, hence leaving the engine code’s intact?
Regards,
Carlos Gonzalez
NextGen Simulations
The problem with this approach is that it prevents core avionics mods entirely.
It is all well and good to say “modders should copy out their modded files to a different path”, but this seems to be missing how those files get used at all in the first place. They’re imported from the root HTML file of the instrument itself, so copying the file out for their own purposes would mean they would also need to create a different root instrument HTML that imports the new file. Unfortunately, because panel.cfg in an aircraft is what tells the plane which HTML file to load for the instrument, this means only aircraft which have been told to use this new HTML could have this mod appear. Or, alternatively, mod the original base instrument HTML file, but then you’re in the same purportedly bad place.
This would mean you could never build a mod for an existing avionics system; in fact this fact alone would make the beta process we used for the NXi and GNS impossible, wherein we made an opt-in Marketplace package available that used this ability to replace the core avionics files of any aircraft past or future that referenced the AS1000 or AS430/530 instruments.
So, it’s not clear exactly how the proposed system would work here.
Thanks,
Matt
2 Likes
Mmm yes, I almost forget that you guys achieved those cool avionics mods of yours, and which I want to congratulate you Matt (@MattNischan) and all your Working Title team for such an amazing work, work that I love so much, through this kind of solution, let’s say, and which I know this is part of how Working Title humbly began.
So, taking your statement into consideration, what can be done then? 
Of course, the purpose is not disencouraging modding, and it’s not my intention to go into that direction (if I have sounded that way, please apologies), but taking care of what the sim loads, so that it does not collapse the instruments’ engine, provided the numerous mods available.
Regards,
Carlos Gonzalez
NextGen Simulations
1 Like
If all Devs, who wanted to “MODIFY” a core sim file, gave their Modded file a new name, (Ideally identifying the Dev & Plane) and then they referenced that file, instead of the base file, in their product, then the base files would not get overwritten,
ie Registration.js becomes Car_182_Registration.js for the Carenado C182, as opposed to a lot of more generic Custom_Registration.js, used in multiple planes, (that may not all be the same)
IN addition if all base files were checked by the system, against a Database of hashes, and any they were modified, at least clearly Flagged.
One Dev is already developing a FREE Tool, to check for Core File overwrites – this would at least give other Devs no excuse for overwriting Core Files without being able to test if they were doing so,
Of course, this does not 100% cover a DEV, who BOTH creates a new Registration.js, calling it CustomRegistration,js, and then references this correctly, BUT still keeps the original registration.js ( potentially outdated) in their end product !!!
REF:
We are building a tool that will be released for free that creates a VFS report for users.
Even in early development, we have seen a lot of very very interesting stuff going on in the VFS system.
So far, Carenado is the worst offender, replacing a lot of avionic components, fonts and tail number registration files.
NOTE: ALL product sold on the Market Place SHOULD be QC checked by MS/ASOBO, to NOT be overwritting Core Files
1 Like
In some situation, overriding core files is required to introduce a functionality. Utilities are just that… mods that modify the core behavior of the sim, either for avionics, nameplates, menu mods and many other things we haven’t seen yet.
That being said, under no circumstances should an aircraft/scenery override functions that affect all other aircraft/sceneries.
1 Like
YES if a DEV wants to uses a Modified COPY of a Core file in THEIR product, the consequences are down to them, but they should not be actually Modifying the Original File in its original location the VFS.
This has multiple issues:
- It goes against the new MSFS guidance that proper testing is the responsibility of the product developer
- There are valid scenarios to be overwriting core files, for example, Flow’s UI, or replacement avionics products, etc. This would prevent, say, a paid upgrade of the sim KAP140 (or really any other avionics system). It would also, as mentioned above, have made the NXi and GNS Marketplace packages impossible
- It would place an undue burden on the Marketplace team (just in my opinion), to try and suss that out
I wish I had a silver bullet here. The very system that makes good and responsible uses of this possible also by its very nature will make irresponsible uses of it possible. In some sense consumer knowledge, inter-developer policing, and the free market have to take care of this. Certainly I don’t disagree that instances of conflicts could be better surfaced to the user, but at the same time most users wouldn’t have the technical expertise to understand what those conflicts mean.
It’s a complex issue without any clear solution, in my very humble opinion.
Thanks,
Matt
3 Likes