In this example, those 2 packages (C172 and C152) are overriding (maybe) the same fsarchive files.
Without proper documentation on the VFS about this file format, it is unclear if those are treated differently in the VFS process (like BGLs), if both are loaded independently or if they do override each other. Until we get clear answers on this file format and possible others, we are making them part of the reports without a warning notice.
Edit on the above⌠We will be removing .fsarchive files from the scan in the next update since those donât show up in the VFS panel in-sim and seem to be treated differently.
Itâs a problem for sure, though I do agree a tool like this should be fully open sourced.
Itâs a simple way to bypass any potential arguments over conflicts of interest.
I also think all developers need to make plain on their own product pages if they do impact any core files in their products. I know a few developers do this intentionally (like me - see below - and P42 as they mention themselves with Flow/Stripr), but thereâs also the case of unintentional use or hacks to get things working which can also have unintended consequences downstream.
For example, my own two addons - due to the unique nature of modifying the non-extensible main UI - modify some core MSFS UI framework files out of necessity, but I tried to limit that as much as possible.
I also explain on my product pages the need to do this in my FAQ, as well as document any known conflicts in the Known Issues sections on my products pages (which have come up from time to time via users).
eg: >
Q: How do Aircraft Manager/Location Manager work, and are there any sim breaking risks?
Aircraft Manager and Location Manager are unique addons designed to improve the UX (User Experience) that are enabled by integrating custom code into the core files that make up the MSFS UI system. The MSFS UI system has not been designed as an extendable system to incorporate 3rd party additions such as AM and LM, so the only way to extend it to provide these UX improvements is to override the core MSFS UI files with the custom code. The benefits are obvious, with a vastly improved UX to solve many pain points that the user community has recognised, but there are also a couple of risks you should be aware of, and how to mitigate them if you have issues.
- There is limited abiliy to interoperate with other addons that might try to extend the main MSFS UI, so you will have to make a choice between products that wish to do this. See Known Issues for more specific info on known conflicts.
- The MSFS Core UI files are checked with every release to ensure they are up to date with any changes Asobo may have introduced. AM and LM are also tested prior to any SU beta releases to ensure they work ok, and the main UI is still consistent. If issues do occur they will be rectified asap and updates to AM/LM released if needed.
- If you have any problems, you can always deactivate AM/LM at any time to return to the current MSFS base UI system with no impact.
- Please contact support via the form at the bottom of this page if you require further clarification or have an issue to report.
Aircraft Manager for MSFS - Sonicviz
Location Manager for MSFS - Sonicviz
Maybe MSFS 2024 will be a little more extensible in this regard.
What would be useful would be a central addon register, which could list this and other info as well as links to explanatory/mitigation info that devs have as well.
In datastore.js case I commented out some console logging that was still enabled.
Apart from that I donât see any other reasons.
Agreed. A community-maintained tool that is fully open to everyone would be a positive step.
Why not building one yourself then?
I am waiting for a solution from asobo on this regards, as i explained in high details since the beginning on this topic.
I am thankful for the tool provided by //42 in the meantime which was build free of cost, and made available to all of us for free as well. I am not going to sit here and demand them how to make it and on which terms.
If you are not happy about it, you can simple put build your own open source tool yourself and make available to everybody.
The results will be the same regardless, we still have this big issue and elephant in the room, the VFS system is breaking the ecosystem giving how it works.
Regards,
Raul
Iâve raised similar but related issues in the past about SDK madness, more to do with a single source of aircraft truth but no less an issue in my view:
Weight and balance synch bug was fixed in SU14, so some progress there!
I didnât demand anything, I merely said open sourcing is:
A community is a spectrum of views, not just yours or mine btw.
A community tool should also respect that.
Detection of issues is only one part of the solution though.
Mitigation and handling of identified issues is the bigger problem, and that depends on the scope of the problem and the area it affects.
I actually raised a potential conflict issue with P42 themselves a while back, and they took 2 months to respond to my report and request for dialog. Thatâs ok, Iâm just a minnow swimming between the big fish, but Iâd moved on by then with an alternate solution and I raise it purely to illustrate that mitigation is as big a problem to address as identification, and it would be best if this was handled in an open friendly manner all round.
Ideally youâd want some categorization of identified issues and the status of products both causing issues and products being affected somehow I would think.
Some of the products, like the heavy plane addon (and another UI addon I had conflicts with) no longer appear to be supported but many users still seem to use them, unware of their support or live status. Other addos may well be current and just need some panel beating and cooperation to smoorth out issues.
Itâs not a simple issue, is my point, when you start going wide with a community approach.
That would be ideal, but as mentioned it needs solutions for both identification and mitigation. Additionally, it should also incorporate data synching standards as I mention for single source of aircraft truth in addition to core file usage issues.
Paul,
I think you missing the point entirely, Eric asked for a list of files we consider it should be excluded from VFS logical overrides since they should be considered part of the MSFS CORE and should be locked away from the VFS system. So far only Hyper Performance Group and myself have provided such list, here is mine: [VFS] We need to find a way to stop this madness - #126 by SimbolFSReborn.
I assume since nobody else did a proposal of such files for 22days, our proposal is enough, and Asobo is now working with such list on ways to provide âMitigationâ.
Nobody else on this topic asked anything else, //42 from their own initiative created a detection tool, this can help as a stop gap while Asobo works on possible solutions if there is even the possibility of any. //42 has released the tool, explained what it does and also posted here on this very topic what is their search and filter criteria.
They are being incredible open about it, the tool only reports data, in the same way the MSFS SDK VFS Debug tool does, SimInstaller is just presenting the information in a much easier manner so end users can use the tool and send the report to 3rd party developers for analysis helping users and developers with the troubleshooting process.
//42 Didnât had to waste any of their time or resources doing this, yet they have done so. They didnât had to share it with 3rd party developers, yet they have done so, I am incredible baffled about these conspiracy theories that there is a conflict of interests for a tool that just displays a list of folders and files that the VFS system will be loading in preference of the default MSFS core files, thatâs it, it is all it does, nothing else.
If anybody has concerns, then by all means go ahead and create an open source project and create another tool. I see lots of people mentioning this over and over again criticizing //42 for creating the tool in the first place but nobody taking any action in creating their tool.
My stance is simple, the current implementation of the VFS system is causing far too much pain in support and MSFS system instabilities, even end users are tired of this situation with their system breaking suddenly without any apparent explanation from their point of view, this is not healthy for anybody (Asobo, Microsoft, users and 3rd party developers). Simply put the energy users have to put to maintain the MSFS Ecosystem is bigger than the time they spend enjoying and flying, driving them out of the hobby and for any 1st and 3rd party developers being freeware or payware, the cost in support handling is escalating where it is now affecting the amount of time you can spend developing new things.
This is why I am asking Asobo help on this matter, if someone creates a freeware tool that helps with users support until a possible mitigation process is in place, well quite frankly it is very well welcome and I am happy for it, doesnât mean it is the solution, we still and will require Asobo help on this matter.
Best,
Raul
CEO FSReborn
No, I understand. Believe me, I have experienced this one from both ends myself.
However, itâs just part of a bigger issue re: lack of adherance to standards when it comes to developing addons, whether thatâs core file modification, bi-directional data synching, metadata, naming standards. or [insert here].
I appreciate your passionate advocacy for this specific aspect, but itâs just one aspect of an overall bigger issue that needs to be addressed by Asobo is my point, which flew right over your head. Itâs their system, they need to provide the tools that define and enforce the standards of content production, or at least document and communicate best practices with scanning tools to veryify adherance to standards. Itâs not easy, obviously, and they have been chipping away at it, so addressing this aspect is a good addition however itâs done.
A bit bizarre to tell me this when it was me who actually came here asking specifically for Asobo help on this matter in the first place, and I just re-iterated few minutes ago that we still require their help to address the problem.
I think is time let Asobo work on this matter, we have provided what they asked, and accordingly the ball is on their court.
R.
To all commenting on //42âs business decisions, app directions, status in the industry, and or ticket response times for non-customer issues, this is not the place. If you want this thread locked, youâre on the cusp of making it so, and then all of Raulsâs hard work getting Asoboâs attention and our hard work creating the tool to feed this critical discussion will have been in vain.
We will not be strongarmed by our peers to open-source our work. We built the equivalent of a Norton Antivirus; itâs asinine to think that weâd sabotage other Windows software just because we build Windows software too, especially given our track record as a company and our contributions to the community both on the development and consumer sides.
Simstaller has absolutely NOTHING to hide; ALL reported data can be verified RIGHT THERE ON YOUR OWN MACHINES OR IN YOUR OWN DEVELOPMENT FILES. Doubt us? Cross-check the results on your own time, or build yourself a tool and compare the results.
Scared of what the tool has exposed? This fear is one for YOU to weigh as a developer. Your practices arenât our problem to fix; our duty is to help the community with awareness. We simply present knowledge that was once hidden and, in many cases, even innocently unknown to developers. This is outlined very clearly in our âNow What?â page that is presented when conflicts are found: â ď¸ I see potential conflicts, now what?
We televised the revolution; now what are WE, as developers, going to do about it? I only know where //42 stands, and itâs not to resist best practices. Youâre next.
If you wish to have further discourse, you can contact us DIRECTLY with your concerns: Support
Edson Soriano
Managing Director, //42
EDIT: @FlyingRaccoon thank you for your patience and support in this discussion. Hopefully, we can get back on track to assisting MS/Asobo with awareness to stop this crack in the windshield before it gets way worse.
This is what weâre battling⌠Iâm glad we made this tool.
REF
I swapped the last letter in the fsarchive filename in the C172, and then rebuilt the layout with MSFSlayoutGeneratir.
The C172 appears to continue to work as before, including the Internal Model LOD0, that I assume is one of the encrypted files, and no longer has the same fsarchive filenames as the C152. (Not that I believe it really matters, or is affecting either planes) ?
*Not an Ideal final solution, but it is proof of content, so it should be something that Asobo could do Officially. ? *
Obviously when (and IF) Asobo update the C172, that temporary fix will get overwritten, but the C172SP only gets updated very rarely these days, so its not a big concern to me ⌠I can edit it again if I see that SimStaller starts to detect that file match again.
=========================================
Just read
We will be removing .fsarchive files from the scan in the next update since those donât show up in the VFS panel in-sim and seem to be treated differently.
But good to know the fsarchive filenames do not seem to be critically named.
And I can see itâs also useful to see when someone has âborrowedâ files and not even changed the names so they definitely will conflict. Thank you 
I donât think thatâs how VFS works. Itâs a combination of same name AND same folder structure. The 172 152 issue above has theses files in the simobjects folder. If they were not in that same folder, there would no conflict, and you will not see âborrowedâ files
Weâre talking about
/SimObjects/xsmxpysk.fsarchive
Not
/SimObjects/Airplanes/Asobo_C152_Aerobat/xsmxpysk.fsarchive
They are both at the same location. But as mentioned previously, they seem to be loaded by the sim differently and live completely outside of the VFS. *.fsarchive have been removed from the reports in the latest version of Simstaller.
Unfortunately, in my case itâs an old top level âeffectsâ folder that I definitely should move into the simobjects folder to avoid future conflicts.
The only people that are fully aware of these VFS conflicts are the developers of the add-ons themselves. 42âs tool simply exposes it to the public. From there, the developer can either A) choose to adhere to community standards and fix it, or B) the customer can either refund (given time period) or uninstall and never touch their product(s) again.
You claim to want transparency but yet scared of it at the same time. 
I am trying to understand this stuff, so maybe someone can correct me if I am wrong
for example â while it does NOT show up in SimStaller as a conflict
1. Looking in OFFICIAL only
(Using a great tool called Everywhere)
Are not these two file overwriting each other in the VFS, ?
Same name in /effects
They do have different content â some of the parameter values in the two files are different.
Probably not enough to even notice when running the sim, but they do seem to be overwritting each other ?
2. Looking in COMMUNITY only
WAY too many addons guilty, !! but at this point, I am more concentrated on OFFICIAL
Maybe Developers should be encouraged to Cusoimize the names of these file with some indication of what Developer name and plane name,
Both Developer & Plane being required, so a developer is also not overwritting their own files in their own planes.
ASOBO have done this in many cases (In OFFICIAL) , so maybe theirs is an example to follow.
eg
Not at all; all of the source code is freely available on GitHub. I donât know how to be more transparent than that. We took an alternate approach and simply maintain a blacklist of addons that clash with our files, and anybody with a GitHub account is free to open a pull request against it. If any of these blacklisted addons are found when users install or update they will be notified.
1: No, because they are in different locations. I am shortening the foldernames for clarity and lazyness:
VFS:\Simobjects\AP\as_g2\effects\light_asobo_cockpitspot.fx
VFS:\Simobjects\AP\as_KA350\effects\light_asobo_cockpitspot.fx
