The way you state this makes it look like overriding is an issue while it is the very reason the VFS exists!
One thing to keep in mind: since such a “conflict detection tool” depends on what’s installed on the machine it is run on, it will provide different results depending on what add-ons are present on your MSFS instance - although it could be useful for your end users to provide a faithful snapshot of their install, I am not sure it will solve the issue highligted here.
The topic here is about “add-ons overriding core system files and making other add-ons fail because of this”. In that view, a “conflict detection tool” should flag at build time which core system files are overridden or not - which brings me back to my previous query: what does “core system files” mean to you?
So you think that just indicating “File XXX overrides the same file in package ABC” without further explanations will be enough for all developers to understand that they’re making a “global change”?
1/ This is not true - just think about overriding a single texture in an aircraft package!
2/ If we want to make sure this is a global change, we need to know what package the overridden file is in - which brings us back to… well you know!
You’re forgetting all the cases where overrriding files is exactly what’s intended. A good example is the marketplace mods that enable split PFDs for the G3000s. Do you consider them defects?
I’m actually one of those very much in favor of the VFS and I’m suggesting that the solution to conflicts is to add observability so people can expend minimal effort in figuring out addon conflicts, which today are labor intensive to discern. We like the VFS and want it to remain powerful, but with tools that meet that power.
Yes, but all of the issues in this thread (Registration, BaseInstrument, Coherent) are in every sim, so this doesn’t seem to be practical problem. Either way, the target could in theory be a hard-coded list which is the minimal sim installation (that’s going to work better on CI infrastructure for package validation, if you’re thinking about something like that), focusing mostly on what is needed for avionics. This doesn’t help downstream for the community to de-conflict two addons.
Actually I suggested multiple ways to address it more broadly:
store validation
build time validation
end user
The end user is important as they can verify the situation and file bugs. Right now the end user that wants to help would be overburdened, with a tool it is either an actionable bug report or an “yes we override foo.js because we need to” conversation. I do think developers with proper guidance will check the log, but it’s important to have multiple low-effort ways to identify this very common problem (unexpected overlapping files). (the devs can fail and we still end up moving the trend the opposite direction)
Per this topic, all of the errors identified are not malicious, they are accidents. I think the intentional overrides are all working well. The issue is people plolp a Registration.js into their package and the build isn’t warning them that they are actually replacing it for everybody. They just don’t know, they are not malicious.
This ends up being a global change (a livery that edits the base aircraft so now that texture is an override for every livery for that aircraft). It’s something to be aware of, but is likely what the user wants. That’s why I say awareness and emphasize all files.
I think the sticking point is just that there are two problems:
A tool to identify things locally. I really think this can’t be list based and is important for the ecosystem.
Some rules for build time/store ingest time - this I see where you are thinking.
For validation rules, I’d suggest these directories (each of the files in the package) to have some kind of warning when the VFS entry matches an entry in the selected package.
Above includes modelbehaviors templates, VCockpit, Coherent, BaseInstrument, MapInstrument and quite a bit more.
I think probably it would still be practical to throw the warning (more aggressive: require human approval on store ingest) based on a list of [all the avionics in the base sim], whether you export the list or however it is attained.
From my perspective, the overall issue here is lack of proper version control for core packages.
Simobject packages depend on specific versions of core packages during runtime. When these core packages are modified it causes compatibility and failure issues at runtime. Developers need a consistent core platform to ensure packages based of core packages are going to run correctly for all users at runtime. Developers really need selective control of which core package versions is required for their simobject packages to run correctly at runtime. If developers want their simobject packages to use any modified core packages they should select that option or be default at runtime.
Similarity, to how certain runtimes are required to be installed during installation of Windows applications. These Windows applications have runtime version dependencies.
Maybe MSFS is heading down this route of packages requiring multiple specific runtime versions of core packages to solve missing dependencies.
Let’s leave the end user out of this conversation, there are 12 million end users of all ages and technical skills who uses MSFS. Some end user don’t understand what VFS means or how to file bug reports or how to fix issues. If you think end users putting pressure on developers to solve this issue is going to fix this, you are wrong! It will cause more problems.
For example, if I wanted to ensure my addon works correctly all the time and solve end users complaints, I would take @runshotgun tool and modify it to scan for VFS issues that cause my addon to fail then delete the other developers offending files (I really don’t care about if their addon fail, let them take the end user compaints) and replace the core packages with my own set of files.
My take is that there should be strict and very precisely defined (and documented) rules, and that they should be enforced for Marketplace add-ons before distribution, and by running optional checks for off-Marketplace add-ons, and that if being rejected or named and shamed then causes more work for some add-on developer (despite them probably defending their actions with “it works fine for people who just want my add-on”), that is sad for them but best for the majority of add-on developers and end-users.
I think Eric made it clear, before taking any action he requires the list. I am compiling mine and will be submitted this week.
Regarding the conflict tool, etc. You guys are forgeting we having 3rd party official developers doing these overrides and breaking all airplanes, their products go installed into MSFS official folder including on XBOX.
Good luck trying to run any external tool on XBOX to troubleshoot… IMO the tool will be useful to start finding out developers that are offenders, nothing else it will fix nothing… I am sure many devs are doing this without malicious intent, but the results are devastating. There are files that definitely do not need to be changed, I consider these the ones required by the SDK to make a product work and also any file pointed out in the SDK documentation to build instruments, registrations, and other products.
Although I sympathise with the view of moders, I had enough of wasting time fixing peoples PCs and receiving hates email from Xbox users when stuff don;t work thanks to these core issues. In hence why I came here seeking the help from Asobo, which they are now kindly extending.
@EPellissier many thanks for your views, I agree with all of them, expect my list of files before the end of the week and I will trust your and your team judgment to find an suitable solution to alleviate or improve the situation. Many thanks for taking your time to respond to our concerns and questions.
To be honest we are not planning to support multiple versions of the same package in the VFS. Of course this could change in the future but this isn’t really something we want to do.
Note that there would also be drawbacks to such a mechanism: say the G1000 package is fixed/upgraded - if another package explicitely references the bugged version, it will never benefit from the fixes.
As a side note - I don’t think there’s an issue with version control and core packages - every time a package changes, its version number is bumped.
According to me the fact that you cannot specify which version of a core package you would like to use in your add-on is not directly related to version control. I see how you could call this a “missing feature” but not really a “version control issue”.
There are already rules that are enforced through the PackageValidator (which is incomplete BTW but we’re working on it). I think the discussion here is about “additional rules” that we may have a hard time to agree on.
I don’t believe this is a drawback of the mechanism, the G1000 package would have been tested by the developer and the developer’s beta team to ensure the G1000 package is fully compatible before public release. Future updates to the G1000 package version, would have to go through the same beta testing cycle before changing the G1000 package version to the latest.
It does put work on the developer to up keep their products but the developer would have to do this with every Sim Update Release. Ensure compatibility.
I understand where you are coming from. But I do believe this approach is a proven design in how to maintain absolute package compatibility without breaking changes.
With the current design of the VFS system, every end user is a beta tester.
There is no stable foundations to build on. There should be at least in the VFS system a version of original core packages that matches the SDK specification exactly which a developer can choose from in their project.
This would be a nightmarish support scenario for us, with probably an entire range of G1000s floating around because the last thing developers want to really be doing is having to update old products with every bugfix. The reality of this solution is that nobody wins, most especially not the users or the avionics developers attempting to make sense of all the bugs reports and versions and versions.
We all work hard here on the MSFS teams to maintain backwards compatibility, and I think it would be simply impossible to support products across years of sim updates worth of package versions.
Having worked extensively in the OSS space I do understand how this solution feels like it would make sense, and it works very well in that context, because the ecosystem is considered by its consumers to be multiple independent products. If OpenSSL has a bug, users of CURL don’t take their bug reports to OpenSSL; they probably don’t even know it exists in most cases.
But here the context is much, much different: users experience the whole as just Flight Simulator. If the G1000 is broken in some aircraft, the users are reporting that to the sim teams. If developers have to update their aircraft for each completely backwards compatible change (as they are all intended to be), then the net result is most devs won’t (or eventually won’t/can’t/doesn’t make financial sense), and users are mad at the platform.
I can’t even begin to imagine the user confusion trying to determine which featureset of an avionics system some Marketplace airplane might have. Do we give users the accompanying version numbers of every referenced package? Would they be able to make educated decisions based on that?
We are in this position now with developers mistakenly adding files causing VFS issues across the board and support teams from MSFS and other developers are having to deal with these issues that shouldn’t have been done in the first place.
No one is willing to block mods. There won’t be enough locked files for mods to not cause issue within MSFS, so the only solution from my viewpoint is versioning. Two versions of core files in VFS. First version set for user and developer mods. Second version set only containing the original Asobo and MSFS core foundational files.
Developers choose which one is most suitable for their project. Both sets will change with every SIm Update version. No long term support for old version sets from MSFS or Asobo. But at least this system gives developers a way to ensure their product works as intended.
I know there is a tool coming for VFS but it’s as useless as anything. It doesn’t fix the long term issues. Only changes a dozen developers thinking towards VFS management. Mods will abuse the system and cause problems. End users will install these mods again and again. Blame the developers and Asobo for the issues. A permanent solution must be look into. Even if that permanent solution changes the way developers do things.
I have a feeling this is the case already for you, multiple G1000 versions floating around GitHub and other places causing ever ending support issues.
I never really intended to propose this idea but from experience in other open source communities it sounded as it might just work here. You are completely right, such as solution would probably not work as intended. Although, there should be two sets of versions in VFS. One set that is official version based on the SDK specification from Asobo which is updated with each Sim Update. One set for mods to use but doesn’t ensure compatibility.
With all these issues with VFS, we are treating end users as beta testers. That really isn’t good for long term usage. MSFS is a complex game of TBs of source code. I think Asobo really needs to examine the whole process of how addons and mods work with MSFS to prevent issues for happening.
I believe the solutions documented by @davux3 are practical and require minimal effort. After gathering concrete, quantifiable data with a VFS tool, the community can reassess the situation and begin to self-report and self-regulate. If required, they can escalate matters to Asobo/Microsoft, and a representative could make contact with the authors.
(Has there been any communication with Carenado, for instance, to inform them about their negative impact on others and to understand how this situation occurred?)
I don’t think we’re at the point where VFS changes are needed.
I don’t believe that constructing such a list is productive. Given the ~infinite possibilities for customizing the game, every file could be considered both useful to modders and potentially disastrous to others. It seems impractical to make judgement calls on what can be ‘blocked’ using data from a handful of folks in this thread.
Fair, however this isn’t relevant to PCs where modding is most prevalent and where there are no security boundaries.
Developers investigating the simulator’s modding capabilities are not going to approach you to report game restrictions that led to missed opportunities. They’re going to just move on to a more interesting game.
Core system files are the files provided by the base game and are common across all installations. I’m not sure how else that could be interpreted.
There are fail safes in the operating system and programs to protect certain files from being overridden. Let’s not fall for the ‘free for all’ scam. Times have changed.
The mod community are against any form of restrictions on files. I know this to be true. There are issues right now with the VFS system which need to be sorted. The community can’t self-manage this. That will cause more issues.
