Hi, I’m wondering whether this kind of file structure can still cause a
problem with duplicates still today?
In other words, you have an
addon scenery with the following file:
“mycompanyscenery/Scenery/texture/ASPHALT.PNG.DDS” And then you have another
addon with the exact same file structure but a different file content. Are
they both segregated correctly in-game or is one superseding the other still?
Thank you!
i’m also interested in this!
but using the wizards, is unlikely you end up with that dir structure,
actually default output dir is mycompany-mypackagename/Scenery/
mycompany-(mypackageName) /whateverTheSource
unless every other guy use myCompany as companyName, the uniqueness of the
assets should be guarantee, isn’t it?
This is a good point, but please note the file structure I’m showing here is
for reference only, just to illustrate the question in using a simple one. The
main question really is whether 2 addons with the same relative file path and
filename are still colliding or not with SU9.
And indeed, mycompany must be a very successful add-on vendor because it you
can read this vendor name in many add-ons even on the marketplace:
https://devsupport.flightsimulator.com/t/4287
And what about mymateriallib ? Ahaha The root of all that problems was the
missing documentation at first release, than some tutorials not explaining the
right way of how to create a package (suggesting to clone the dir structure
from the samples and so on) Maybe the Devs can include in the validation
process a check to ensure that those values are not the default One! Something
like “your company name: “mycompany” is not allowed. Please use your real
company name. If you haven’t a company, please put your full name” Anyway I’m
pretty sure that projects with the same file structure and file naming will
still override each other based on the loading order. It is a core feature and
It is a great way to allow mods without default file modification ( or other
mods file). But people doing mods should be aware of this, so they can pack
their work wisely. And if not, the Devs should force them to be wise!
Here’s a similar observation with no reply from Asobo:
https://devsupport.flightsimulator.com/t/3997 We don’t know how the sim
sorts folder names, file names, and GUIDs… so there is no way to properly ID
assets or their folders. From a developer standpoint, it’s just a guess. Even
the naming of Community packages is a guess as is the order of packages in
Content.xml… or whether that xml is used at all.
Here’s an attached example of the confusion. Simple box with a colored face.
1Blue, 2Red, 3Green. All have identical object names and GUIDs. 2Red contains
the placement. Put the packages in the Community folder. Start the sim. Start
the flight at one of the parking places at C59. Which color do you see?
Probably not red, although that was the modelLib compiled with that scenery
placement. Go ahead and play with the Content.xml and the order thay are
placed in the Community folder. Change some active to false in the
Content.xml. Have fun. ID_Test.zip
I find the Content.xml rules what shows as far as duplicates… and we have no
way of helping an end-user resolve these types of problems. I actually had a
duplicate GUID with one of the default fs-base objects (chances similar to
winning the lottery). First in Content.xml is what shows. I suspect SimObjects
are worse. In the placement XML, they are named, not GUID’d. As far as Package
folder name, modelLib folder name, object name (or SimObject name), and GUID,
I believe they should all be unique. Then the end-user is assured what is
placed is what will be seen. I am not well-versed in aircraft, but the same
general principle should apply. DEMs and Aerials may have their own issues due
to the naming format, and in those cases, I think the Content.xml will control
all placement for the end-user.
Hello, The VFS (or virtual file system) is a core component of the simulator,
which makes overloading and modding possible. Packages with files that exist
in the same relative path will overwrite each other, with the package that is
loaded last taking precedence. The load order is Official (alphabetically),
then Community (alphabetically). This information is available in the Using
The
SDK
section of the official documentation.
Edited for more testing… Renamed the packages as mycompany-scenery-!green,
mycompany-scenery-red (contianing the placement xml), and mycompany-scenery-
zblue In Content.xml: If …shows zblue If: …shows !green If …shows red
If …shows red Content.xml is controlling the display if identical folder
names modelLib names, asset collection names and GUIDs. If you delete the
Content.xml, and let the sim rebuild it on starting, then the packages are re-
ordered as the SDK claims. If you edit the Content.xml to remove !green (yet
leave it in the Community folder), then on restarting the sim, it rebuilds as:
ang shows red. So it is apparent, that assests need unique GUIDs, and will
benefit from unique object names, unique modelLib names, and unique scenery
folder names, and unique package names… probably in that order of
importance.
@FlyingRaccoon , Is there any tool in the SDK that can help 3rd party
developers getting a warning notification whenever they are packaging an add-
on which is using a “default” folder or file name ? i.e. pre-assigned like:
".\MyCompany" or “mylibrary.xml” etc… Is there also any tool in the SDK
which 3rd party developers can use once the game is running and fully loaded,
that would list any conflicting name? I’m thinking of something that would
list all files and/or folders which were superseded by other files and/or
folders. regardless it is their own project/add-on. This would be a more
general dev mode tool which can therefore also help any FS2020 user checking
up their community folders prior contacting support for example. As for the
documentation about the VFS, there seems to be many add-ons with conflicting
files/folders, even some actually sold on the Marketplace today, that maybe it
would need revisiting the explanations, or giving more concrete exemples? More
generally I’m wondering how many bug reports and crash dump reports you are
automatically receiving only because users are purchasing 2 add-ons on the
marketplace with one overriding the files of the other?!
From a user experience perspective that is a daily struggle in my real life
job here, I suggested in another post to have the option to initiate a project
in a way where user enters their company or developer or any name identifying
them and this is used as prefix to default folder and file names… Now if 2
dev or companies happen to have the same name and both develop scenery well
they need to do something about it 
It is unlikely that an object would share the same GUID. But SimObjects are
placed by name, I think, so that might be a problem… and that could include
aircraft as well(?) The Microsoft ‘bespoke’ airports sometimes have duplicate
models/GUIDs, and duplicate modelLib names… naughty Microsoft.
Content.xml is read and stored in alphabetical order in FilelistIndex.DAT. 000
first - last.
Another one I’ve seen quite often:
So if I understand correctly,
there are a number of add-ons still sold on the Marketplace and elsewhere
harboring the ubiquitous “modellib.bgl” file, and everyone is stepping on the
toes of each other. @FlyingRaccoon , can you or anyone please assist with
this? Re:
Is there any tool in the SDK that can help 3rd party developers getting
a warning notification whenever they are packaging an add-on which is using
a “default” folder or file name ?i.e. pre-assigned like:
".\MyCompany" or “mylibrary.xml” etc…
Is there also any tool in the SDK which 3rd party developers can use once
the game is running and fully loaded, that would list any conflicting
name?I’m thinking of something that would list all files and/or folders which
were superseded by other files and/or folders. regardless it is their own
project/add-on. This would be a more general dev mode tool which can
therefore also help any FS2020 user checking up their community folders
prior contacting support for example.As for the documentation about the VFS, there seems to be many add-ons
with conflicting files/folders , even some actually sold on the
Marketplace today, that maybe it would need revisiting the explanations, or
giving more concrete exemples?
Unless your “Driveletter:\Microsoft Flight Simulator\Community\Foldername” is
the same (which should be a very low change) nothing should interfere anymore.
Every add-on has it’s own unique Foldername and scenery path stored in the
fileindex.dat.
@Cygnific this seems to contradict what @mattnischan and/or the docs are
saying, or I did I fail to understand what you wrote?! This is confusing me
LOL
Check the fileindex.dat file. Every Community/foldername is unique and can’t
be used twice. Scenery.bgl files are also “protected” files and can’t have
their assets (like textures) modified by another add-on. (same for a couple of
Asobo files) with the exception of exclusions , which should be loaded after
a add-on you want to exclude. Aircrafts are more open, else you can’t make
liveries. Edit: It would be nice to have a list of the highest/lowest priority
in the hierarchy though. Hope it makes sense. 
Which “fileindex.dat” is this?!
%LocalAppData%\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\SceneryIndexes
FilelistIndex.DAT Sorry for the mismatch on filename I wrote earlier… Even
Microsofts new packages are just using Modellib names for Scenery stuff. It’s
the Edited: -Root- Foldername that really matters.