• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

MSFS20 Understanding Virtual File System

E

eric_marciano

Messages
531
Country
france
I develop gauges in Javascript. As I came through a strange bug, I used the debugger to place breakpoints here and there. I happened to look into NavSystem.js, a source file provided by Asobo and when I saw it in the debugger, I realized the one I was using was not the original source file provided by Asobo. This is because the PMS50 add-on is installed in my Community folder, which also has his own NavSystem.js modified by its author.
I find this quite strange... I can't understand why MSFS takes this modified version instead of the original one. The way I use this file is by declaring it in my HTML file like this:

<script type="text/html" import-script="/Pages/VCockpit/Instruments/NavSystems/Shared/NavSystem.js"></script>
Click to expand...

I even think it is dangerous because the modifications made by the author may impact the way other add-ons work, there is no better way to bring incompatibility between add-ons...
In addition, I also have the Working Title CJ4, which also has its own NavSystem.js file, so how can they make sure their file is used instead of another one?

In fact, the main question is: How can I make sure the Asobo original source files are used with my add-on?
 
Hi,
In theory, I believe that addons are loaded last in the VFS, and it may be that if two files have been loaded, only the last one is taken into account.
Also a good programer don't use the same names that the ones provided by the software.

The best advice is to debug with any addon in the Community except the one being tested (it is the rule ;) that I apply on my workflow)
 
That's exactly what I believe: if a programmer modifies an existing Asobo source file, he should use it with a different name to make sure there is no conflict with any other add-on. That is not what was done with this NavSystem.js, modified by 2 add-ons while keeping the same name.
As you suggested, I will test again with no other add-on installed, but in the future I am afraid of add-on conflicts when mine will be released.
 
I was very surprised when I saw that too. I'm not clear on the load order, but it seems all community files overwrite the official files.

The big issue is if you want to mod one file in an Asobo instrument then you need to rename it and copy rename and mod EVERY file that depends on the one file you modded.

It is counter-intuitive that an instrument mod in a community plane can affect every other plane. A better design for planes would be the Asobo files are the common base and only a LOADED community plane updates the VFS.

We need a simple utility that scans the community folder looking for Asobo paths.
 
You're right, I didn't think about this issue about the dependencies. But as you say, it means that any add-on developer can (almost) break the sim by providing a faulty modified source code. Fortunately, uninstalling an add-on is easy, you just have to know the problem comes from the add-on. It also means that as an add-on developer, I should uninstall all other add-ons and keep only the one I am working on to make sure there is no problem with an Asobo source code modification.
As you say, the best solution would be to have each community plane have its own VFS when loaded, but I am afraid this would be such a big change in the VFS system that it will never happen...
Another solution, probably easier, would be to let us include the Asobo files only, whatever community add-on is installed.
 
You must log in or register to reply here.
Back
Top