Scenery causes hang on "Checking for Updates" in SU12 on some systems

I received a report that several of my sceneries, along with several other
products from other developers, causes MSFS to hang on the “Checking for
Updates”, starting in SU12, on PC. I have been unable to reproduce this
behavior, and there is only one report. There is nothing out of the ordinary
in these packages, just models, textures, and ortho imagery. I was wondering
if anyone else has encountered the same, or has any advice? Thank you!

Hello @XCodr_Designs , When you say, “there is only one report,” does that
mean that only one of your users has experienced a suspended loading issue,
but with some of your sceneries along with other products? I’m not entirely
certain about the cause in this situation, but you can ask your user to
generate a crash dump file when this behavior occurs by following these steps:

  1. Open the task manager
  2. Click the Processes tab
  3. Select flightsimulator.exe
  4. Right-click on the process name and choose “create dump file.”

After generating the dump file, you can share it with us by posting it in a
private comment here. [See 3) Provide Private
Content](https://devsupport.flightsimulator.com/articles/5483/how-to-report-a-
bug-or-crash.html) Regards, Boris

​What are you using for filenames and paths? If you have a file called
“modellib.bgl” or are just using “mycompany” etc, etc as paths, you could be a
part of a VFS file interference issue with another of the user’s sceneries
that are using the same filenames as you. Make sure your files all have unique
paths to get to them. Be that changing the names of files to unique names, or,
at least, making unique path to all of your files so they don’t interfere with
anyone else’s.

Hi @FlyingsCool , Thank you for the suggestion! All my objects have a unique
prefix (ie XCD_ or KSEZ_ etc). All the build paths (except for CGLs, which I
believe are unique for each location (?)) have unique paths. So if you look in
the layout.json in the built package, everything has a path of //. So I don’t
believe that is the issue here, unless the CGLs don’t have a unique naming
scheme and are the issue… Sincerely, Connor

To be clear, we’re talking VFS file paths. For instance, everything after
Simobjects\Airplanes, or scenery\world\scenery So, looking in the layout.json,
files such as scenery/world/scenery/modellib.bgl often cause conflicts. or
materials/mycompany/Library.xml might be another example I often find in
packages. People literally name their files these things because they don’t
bother to change the defaults that the SDK suggests. replacing mycompany with
your company name may not be enough, if you have two different sceneries with
the same name Library.xml. So I always change mycompany to flyingscool_ icao
for each airport to assure the filename path is unique for each airports’s
materials library. I also would change modellib.bgl to icao _modellib.bgl.
If the file is meant to replace default files of that name, then it shouldn’t
be an issue. Another problem might happen, though… if another package is
replacing the same file as you are replacing and it comes later in the
community directory, then, another issue ensues in that your update to the
file will not be used, and will be replaced by the other file.

@Boris1 Apologies for the delay, I was finally able
to get in contact with the user (we had some email issues, on both ends), the
issue is now resolved. It turned out to be an issue with having more than 1024
items in the community folder. This question can now be closed. Thank you for
your help! Sincerely, Connor

Hello @XCodr_Designs , Thank you for the
feedback :slight_smile: Regards, Boris

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.