TBH… they’re not doing it themselves.
2 Likes
In the General Options - Experimental there is a Section → MSFS State Report - Create report. Put the Check for conflicting VFS files there. That way a txt file can be created and either the customer can figure out why and perhaps remove the offending product. Or the txt file can be emailed to the developer getting the error to “see” what conflicts there are, and help the customer fix their issue. The txt file can be sent to the developer/company that is actually causing the problem.
Bad publicity will soon fix these problems.
1 Like
Well you couldn’t guess it but BGL files are handled differently so this is not really an issue : every time a package is mounted into the VFS it is scanned for BGLs in its “scenery” and “modellib” subfolders - no other package can interfere through the VFS here.
That being said I would prefer if those files obeyed the same rules as others.
Best regards,
Eric / Asobo
2 Likes
That’s not what the Virtual File System panels says. Are there any other exceptions to the rules of the VFS system?
1 Like
I also assume this to be true for materiallibs as well?
I like that idea, but I don’t think that is how VFS works. The VFS is read a sim start, and last in takes precedence. Maybe I’m wrong here.
VFS can be modified when loading in a custom built simobject package from dev mode. Maybe there is room to expand the VFS functionality to provide developers a choice over which framework should be loaded.
First and foremost… It’s been 3 years and this title still lacks a file integrity repair tool. The installer/launcher only detects missing files, not modified files. Such tool should list all modified core files.
1 Like
I strongly advise against any sort of file-based lockdown. This could potentially limit the modding potential of the game by restricting the ability of modders to modify certain files, thereby limiting the extent to which the game can be fixed, customized, or enhanced.
There are legitimate reasons why a developer might want to replace core files. For instance, they might want to introduce new features, fix bugs, or improve the game’s performance. Waiting for Asobo to do these things is untenable.
With a tool already being developed to detect potential conflicts between add-ons (see above), it’s not clear what issues remain to be solved.
3 Likes
Hi @EPellissier - we really hope you don’t go the route of blocking files from override. The MSFS ecosystem is a strength and the VFS is a creativity multiplier.
Here is another potential path forward that will be resilient as things change:
PROBLEM
- Some developers are unknowingly adding override files to their packages. This results in other products failing.
- The trend is the wrong direction due to lack of insight/detection of these conflicts.
GOALS
- Drive down conflicts between marketplace packages.
- Avoid extra burden on the marketplace ingestion process.
PHILOSOPHY
- VFS is a long-term decision that has already been made. It enables powerful interactions in the game and is a foundational part of the ecosystem.
- Community is capable and able to understand package dependencies (for addon case).
- Developers want to do their best and will update their products accordingly.
- Marketplace is the gatekeeper and has a responsibility to ensure addons function so that users can have a good experience and purchase more.
SOLUTION
- Add a VFS conflict detection tool to MSFS (this allows viewing all conflicted files against a selected package).
WHY: We can’t solve this problem without first having a good view of the conflicts. This empowers end-users and developers alike to examine addon conflicts. - Allow reporting content-conflict errors on the MSFS forums for marketplace content. These reports would be sent back to the developer.
WHY: Community feedback will be specific and actionable, making it a good candidate for reporting through the forums.
Things to also consider:
3. Add conflict detection to package build time or marketplace at ingestion time.
WHY: Common errors can be flagged with a description but not fail the process. All conflicts visible and listed.
4. Proactively engage top-offending vendors.
WHY: Put water on the fire directly.
4 Likes
This window is correct - if you were to “fopen” the file from WASM you’d access the “shapes.bgl” of this package. However it is not how we treat BGLs upon mounting packages.
Actually for each single path in the VFS we maintain a list of all “matching” packages - it allows us to let other vendors override things in “free flight” that we don’t want overridden in say “Maverick missions”.
That being said, as stated above, I’d rather see all packages making a clear distinction on VFS file paths if the intent is not to override any other file!
Best regards,
Eric / Asobo
Not sure about this one, I’ll have to dig into the code to confirm or not.
My initial guess would be that only BGLs are treated like this but I could be wrong.
Best regards,
Eric / Asobo
A few comments on this diagram:
1/ It focuses on aircraft packages - there are other kind of packages and there’ll be even more in the future. If we are to implement a complex system such as that described, it should address all of them.
2/ It looks like this diagram only considers one aircraft wanting to use a custom version of the framework - what if 2 or more packages install their own custom frameworks, possibly in separate packages? Are you suggesting they now specify the package in which their framework is installed?
3/ Let’s say you answered “yes” to my last question: what happens when a vendor shares a framework with multiple aircraft and the framework evolves with time but introduces breaking changes without older aircraft being updated? Are you suggesting a version of the framework is also specified? (reminder: only one version of the package can be installed at any time).
To cut a long story short: this diagram probably solves the problem you are trying to address but I think it is too focused on this very problem to make it viable for the whole sim.
Best regards,
Eric / Asobo
1 Like
As explained in one of my previous answers, we maintain a list of all packages for each VFS path, and we then apply rules to find the “active” version - although the main rule is that the “last mounted package wins” indeed, there are exceptions which can vary depending on the sim context (mainly free flight vs missions).
Best regards,
Eric / Asobo
1 Like
I fail to see the point of having a different VFS behavior between the DevMode and the main sim - surely a vendor testing his add-on through DevMode is planning to distribute it later on so we must ensure that everything works the same in both cases?
Best regards,
Eric / Asobo
2 Likes
Surely you are aware that installation/update times of the packages are not the most appreciated feature of the sim - if we were to run an integrity check on all packages every time the sim is launched we’d probably receive hundreds of reports (rightly) flaming us.
That being said you are certainly right that an “integrity check” feature to be run manually would be useful to detect issues - I’ll talk to the team in charge to check if something is scheduled on this topic.
Best regards,
Eric / Asobo
2 Likes
Your comment is one of the reasons why I asked people here to provide a list of files that they believe should be blocked from being overridden. When we get such a list we can discuss the pros & cons of locking them - I don’t believe in statements such as “everything should be locked”, but I don’t believe either in opposite statements such as “everything should be unlocked”. Let’s see what comes out of from this discussion before being worried.
By the way, there are already some files you cannot override (for security reasons) or for which overrides are ignored in specific contexts - and I’ve never heard anyone complain about it.
Best regards,
Eric / Asobo
1 Like
Comments on the “SOLUTION” section:
-
I keep reading about a “conflict detection tool” - great, but what do you consider being a conflict? This takes us back to the list I mentioned earlier which would list the files considered (for some people here) as “to be locked” or (in your case) simply triggering a “conflict”.
-
This depends on the list mentioned in 1 but could be implemented as part of the package validator (used both at build time & ingestion time).
Best regards,
Eric / Asobo
The tool needs to identify any overlapping files in the VFS (maybe excepting .bgl due to their nature). It is essentially the same as what runshotgun has created earlier in this thread. There’s no reason to start with a hard-coded list, and that list will become stale in the future. The point is that ANY overlapping file is a cause for concern (even if only for awareness) but not necessarily an important defect to resolve. The issue we need to address is that developers are not aware they are making global changes for their aircraft. If they had a list of a conflicts (and a little user pressure), the right things will get done without any heavy handed actions.
Important in this solution is that we are accounting for both marketplace content and also providing a way for the community itself to understand conflicts between addons. Addon conflicts outside of the purview of the marketplace will be accounted for this way by having the tool raise any overlapping files between a selected package and and 1) the internal sim Packages source, 2) Official source, and 3) Community source.
2 Likes