Users are reporting all CGLs are no longer working im SU12 beta. Is there a
known change to the way CGLs need to be generated in SU12 or is this a bug
which will be fixed before release?
1 Like
Hello @Gobby , I was not able to reproduce this
using the sample āKaloAirportā SDK Sample. Can you send me your project ? [See
3) Private Content](https://devsupport.flightsimulator.com/articles/5483/how-
to-report-a-bug-or-crash.html) Regards, Boris
Hi @Boris1 , Being so close to SU12 release without
any confirmation this has been fixed is a little concerning. Iāve shared the
project file almost 2 weeks ago. This will break almost every 3rd party
airport in the marketplace.
Hello @Gobby We have been able to reproduce the
issue with your package but we havenāt witnessed it yet on any other package
for now so weāre not sure if itās project related or a more general issue. Do
you have other airport products on the marketplace that demonstrate this same
issue? Regards, Sylvain
Hi @FlyingRaccoon Some of our users are reporting it on all of our airfields
(and airfields from other developers) which use custom CGL. Itās most
noticeable on our Rochester (EGTO) as there are lots of aircraft parked on the
grass in the default ground textures. Its not affecting everyone, and some
users have been able to rectify the issue by removing other packages from
their Community folder, but it appears to be random whether it works or not,
and not linked to a specific ārogueā addon. I donāt know if anything has
changed in the way packages are loaded in a certain order since SU12?
Hi @FlyingRaccoon Has any time been allocated to look into this issue yet? We
are getting complaints from new users on a daily basis as it is affecting our
products in the Marketplace. From my own testing it seems to happen when there
are multiple packages in the Community folder using CGLās of the same region.
All of the UK addons have āCGL/031/sai313.cglā, but Iāve noticed in the
Virtual File System it will only ever show a single sai313.cgl file from one
of the packages. This suggests to be that MSFS combines the cgl files into a
single file during the loading sequence? If so, for some reason since SU12,
some of the files are being left out or forgotten in the combination process.
I could be talking out of my a** here though, but Iām struggling to see much
of a pattern.
Hi @FlyingRaccoon We are still struggling with users reporting this issue on a
daily basis. If youād like to check the package of our Goodwood scenery in the
Marketplace, it seems to be the most prevalent for this bug. I still believe
this issue lies in the way SU12 is loading multiple CGL files of the same name
during the boot sequence. Some files are being missed or ignored. This
behaviour appears to be based on which other packages are in the Community
folder, but after days of troubleshooting, Iām unable to narrow down this
behaviour beyond ārandomā. We tried a workaround of splitting the CGL file
into its own package, and although this seems to work for some users, it
doesnāt for others, and can even lead to other sceneries breaking which were
previously fine. Any assistance on this would be massively appreciated.
Naming convention in the Community folder does have an influence on what the
sim shows. And itās a bit counter-intuitive. 2 packages in Community. One a
Smiley face and another just a mustache to place over the Smiley face. Each
has a transparent background, and 32bit PNG source. A package named aaa-
rhumbaflappy-c59-aerial (just a mustache) will appear correctly over the
rhumbaflappy-c59-aerial (with the Smiley face). If the mustache package is
named zzz-rhumbaflappy-c59-aerial, the mustache will not appear. I believe
that alpha-numerically, aaa-rhumbaflappy-c59-aerial is loaded first and has
priority, with rhumbaflappy-c59-aerial added under it. The zip file has
the 2 packages. If you rename the aaa-rhumbaflappy-c59-aerial as zzz-
rhumbaflappy-c59-aerial, it will not show the mustache, as it is hidden under
the Smiley face. So the package name controls the order of the CGL appearance,
but it is inverse in nature. Community
Priorty.zip The problem here is
that if you are re-working an airport, your package name should probably be
prefixed something like zzz in order to load after any other addon of the same
airport. This is because of the excludes, and is the opposite of the CGL
project naming. So separating the CGL to a separate project is a good idea,
but it should load first in the Community by prefixing it aaa-, and the
airport package should be prefixed zzz-.
Hello @Gobby I wasnāt able to produce the issue on any of your Marketplace
products for now, even with other products defining the same cgl file
installed. Have you been able to narrow down the occurrence of this to a
specific set of installed packages? Having multiple packages defining the same
CGL file is not an issue, the expected behaviour is that the cgl content is
concatenated. Regards, Sylvain
@rhumbaflappy Thatās helpful when you have
overlapping textures, but MSFS should be handling multiple packages containing
the same CGL file, where each one contains textures of a different airfield,
without ālosingā some of them to the default textures.
Hi @FlyingRaccoon Iām still no closer to identifying the cause or steps to
reproduce the bug consistantly. I canāt find any correlation between package
folder name, other installed packages and which textures fail to load. If you
were unable to reproduce it on the Marketplace versions, is it possible that
packages loaded from the Community folder are treated differently to packages
from the Marketplace, which I believe are saved to a different location? Most
of our users would have installed directly to the Community folder, and Iām
not specifically aware of anyone having the issue with the Marketplace
version. Sadly I think this issue is a bigger problem than many realise. Iāve
seen YouTubers publishing videos with broken ground textures, without
realising they are broken. Its affecting many more users than those
complaining about it.
Hi Boris, As mentioned above, facts:
- The problem is not a single airport.
- Every single airport works fine.
- Combination of more airports (seems with 9 or more) within the same area in the community-folder is the problem
- This was not a problem before SU12
- This is now a problem since SU12
Kind regards, Marcel
Hi Sylvain, Like mentioned the problem lies within MSFS itselve since SU12,
not related to the addonās itselve. Have the same problem with several scenery
in the Belgian/Dutch area. Both payware and freeware sceneries containing
custom satmaps (sai202.cgl). Currently 9 installed, from the 9, 5 have missing
custom cglās. Maybe harsh yet there is something changed on your end with SU12
which causes these problems. Marcel
I can confirm I have the same issues after SU12
@Boris1
@FlyingRaccoon Seems still no progress to fix
this issue at your side? Any update you can give on this general problem and
not a scenery addon specific problem? Marcel
- The problem is not a single airport.
- Every single airport works fine.
- Combination of more airports (seems with 9 or more) within the same area in the community-folder is the problem
- This was not a problem before SU12
- This is now a problem since SU12
@FlyingRaccoon This issue obviously hasnāt gained much traction as not many
users will be installing custom scenery containing multiple CGL files from a
single region, but the problem is still there. Just to add, we now have
confirmed cases from Xbox users who have purchased scenery on the Marketplace.
So its not just the Community folder causing the bug. Something changed in
SU12 to how packages/CGL files are loaded into memory.
1 Like
More and more users are reporting this issue, affecting both PC and Xbox. We are losing customers as almost all of our airfields are in the same CGL region.
Any chance this will be taken seriously 5 months after it was reported as a new bug in Sim Update 12?
Greetings all,
This new thread seems to be an escalation of this issue which has been āin the airā (pardon the pun) for much longer than 5 months:
In our case the issue has now spread to all of our airports in addition to the one originally reported.
If itās of any help, I can confirm that they are also all within the same region.
We patiently await for the fix mentioned in the original thread to be released, whilst continuing to respond to an increasing number of Customer complaints regarding the issue, as well as it affecting reviews and product ratings, in not a good way.
Regards,
Chris
1 Like
Thanks for linking back @TheSecretStudio
We first spotted and raised this way back after SU9. There was a response from @Boris a long time ago about the dev finding a fix for this prior to SU12ā¦
but then confirming that it hadnāt made its way into SU12.
In the hope that the fix was the correct one but slipped through the net on implementation, can we track back to what happened there @FlyingRaccoon @Boris ?
Regards,
SFSimsDev