I believe the mount point is effects… and indeed it will logically override it…
I always create my own effects names to avoid clashing with anything for this reason.
R.
I think the fact that we are not even sure of this fact is a good indication that some easy-to-understand VFS documentation would be great 
Considering we have two options to place the effects I would think that this is a conflict-prone mount point:
VFS:\effects\
But that this is a “safe” location and not treated as a mountpoint:
VFS:\Simobjects\airplanes\myaircraft\effects\
But I agree with always creating own names to be safe!
1 Like
Not in this context since it is part of the aircraft folder?
I think it does, like html pages… if the effect folder was inside of the SimObject folder then maybe. As far as I understand it is overriding it, like FSTL is affecting effects for global objects
@FlyingRaccoon can you help us to understand this particular case with the effects packaged with our products?
Thanks,
Raul
But it is in the simobjects folder
1 Like
FSLTL uses the top level folder
VFS:\effects
To avoid having to have effects folders inside each simobject or reference them in the .cfg, which is why they override defaults. If they used the local effects folder in each simobject folder I don’t think it would overwrite.
1 Like
Imagine having to keep a manually created blacklist of other developers’ work and telling your customers that they need to uninstall them to enjoy your creation.
This hurts my soul. It’s ultimately bad decisions at the top, turning devs on devs.
There are 2 fair options.
Fix this at its root by continuing the conversation here and get Asobo all the data they need to make a change.
OR
Empower users with enough knowledge about their ecosystems to make a choice, and don’t encourage a community of “peers” that keep a blacklist and tell customers to uninstall other things they may have paid for.
We chose the latter in the interim; the last thing we want is friction with the peers we value.
1 Like
That effects example, has a starting point of simobjects. There is no conflict there.
Hello everyone,
Wombii is right, the VFS paths are not conflicting in this case.
Keep in mind you have the Virtual File System tool to help you.
If this was in conflict, only one instance of this fx file would be visible and the package name in yellow would be the package mounted last.
Also have in mind that you can still have a conflict when VFS path is different and there is some implementation specific logic to account for.
Best example would be two ModelLib asset groups with different VFS path referring to a common GUID.
Regards,
Sylvain
7 Likes
Thanks Sylvain for the help 
,
Best,
Raul
Exceptions to the rule … ok, enhancement request for simstaller. Check every GUID in the sim. 
1 Like
This would be death
3 Likes
I’ve just gone through a lengthy thread filled with information, and as a new developer in the field, I find myself quite green when it comes to these matters. Currently, I’m working on developing planes, specifically the Navions. Recently, I watched Two Tone Murphy during //42video featuring the //42 Sim Installer mod, and my Camair was the first on the list due to its “behaviors.” - https://youtu.be/d_KB6CLaGyo?si=uwnjGpp7p6mqTtag&t=417
I’m trying to understand if my plane has conflicts with other planes or with Asobo’s default settings. The challenge lies in identifying these conflicts and understanding if they have a significant impact. As a developer, my focus is on creating and not necessarily on testing for conflicts. I usually have very few aircraft, mostly my own, loaded at a time.
It seems that the only reliable way to assess this is by comparing with a comprehensive set of mods owned by someone who has extensively tested for conflicts. The question is, are these conflicts severe enough to break the simulation entirely, affecting other mods with similar functions? Or are they more isolated, altering the simulator defaults?
I’m a bit confused on this matter, and I certainly don’t want my products to end up on any negative lists. If there are conflicts, I’m open to learning and fixing them. On the other hand, if it’s not intended to work this way, clear communication on the expected behavior would be helpful. If there are conflicts, please feel free to reach out to me, and I’ll do my best to address and rectify the issues.
I’m also really not comfortable putting myself out there on here, but I’m willing to stick my neck out and say what needs to be said for other new and upcoming developers. I have a long way to go to get to the level some of you are at, but I know the community is pulling for the little guys like me. And yes, I have had some feedback with mods affecting mine, but usually they are freeware by nature, but very hard to figure out for an end user when I don’t have everything their personal PC has and its only been PC issues so far as Xbox I have had none so far other than my own mistakes which have since been fixed.
I am thankful for other dev’s hard work, but as far as conflicts go, I don’t want there to be any and I see this as an opportunity not only for all developers but for Asobo/Microsoft themselves to rise up and take the lead on this matter. Has there been an update as to what is going to happen going forward? Or did I miss it in this thread?
Best regards.
Nick(B4Gunner)
Hangar Studios 713
1 Like
Hi Nick,
I’m not familiar with your specific aircraft but if it has conflicts in the Behaviors category, it means that it is overriding files that the sim uses across all other aircraft in the sim (default and 3rd party).
This means that, if you modified the files listed under that category, it will affect all other aircraft in the sim that are using the same templates. Often times, those files aren’t needed in the aircraft package and were simply copied by mistake.
If those files weren’t modified, it might work correctly now but will break if Asobo decides to modify those templates in a future update or if another mod (maybe one that targets a specific behavior) tries to modify the same files.
If you have farther questions, don’t hesitate to reach out on Discord, we can assist on this topic.
Thanks for your response. Another dev contacted me and I’m working on a fix right now. I definitely did change the sim behavior file and now that I know what I did going forward it won’t be an issue after I update it. Simple fix, but I can see now how this can be a problem. My most recent aircraft has the fix already installed. Still learning and thanks for the heads up!
Nick
3 Likes
Try UNINSTALLING “all” Carenado aircraft, and it looks like your perceived overwrites will go away ?
it look (to me) more like a Carenado issue than your plane.
if you open up any of those down arrows on these Carenado planes, you will show the files that have been overwritten.
I suspect most are to do with Registration or it’s fonts.
It’s Carenado overwriting those core sim file, the core sim file YOU expect to use in your plane.
Sorry Carenado, if you are reading this post – I have removed all by Carenado planes, and will not purchase anymore, till you fix your planes …
1 Like
Packages showing in this list are overriding core sim files.
Conflicts between packages aren’t shown in this list (but are if you expand a particular package)
I’m Trying to understand and correctly interpret these reports …
So is BFG’s plane CAUSING an overwrite issue, or it it SEEING an overwrite of Core sim files it is expecting to be original core files, but are being overwritten by some other plane ?
Packages listed in Advisories are causing overrides of core sim files.
OK, I get it BFG had not opened the pull down under their aircraft in that screenshot, to show what they were overwriting …