It has not returned - I think the issue around the airports is different to
what I was having, which was caused by Online Functionality being
completely off.
Hi @Boris - Has there been any progress on this? Is it related to online
functionality or something we can change at our end? Thanks, SFSimsDev
Hello All, Just joining the White Christmas Club. One of our customers has
raised an issue whereby our CGL’s are showing as white whilst descending into
one of our airports. 
We have
tested separately both the scenery with no CGL, and CGL as a stand alone
project without the airport scenery and associated WASM modules, SimObjects
and all other paraphernalia. The issue only occurs with the CGL project, and
occurs on a repeatable basis regardless of the rest of the items that make up
the product. If data is online or offline, or if the rolling cache has been
cleared makes no difference to the results. We have spent some time doing some
further analysis, at a constant altitude FL40 approaching and passing over the
area, whilst monitoring the tile status using the debug tool. What we have
found is: Approaching the area: Everything is visually normal, with the
questionable tile out of range of the debug tool it’s not possible to
determine which LOD is being displayed. Looking at the data from it’s direct
neighbors being LOD13 we are guessing it’s LOD14 or above, which visually
looks correct from the cockpit. As soon as the tile comes into range of the
debug tool, it turns white and shows up as LOD13. As we pass over the area,
the tiles gradually split into four smaller ones with a LOD of 12, the LOD12
tiles are not white and contain the correct imagery we expected to see.
Departing the area: Again everything is visually normal and we see the LOD
slowly increase with distance. Once the transition from LOD12 to 13 is
reached, the whiteout occurs, and eventually disappears again with distance.
We’re not doing anything differently to what we have implemented previously
with our other airports which don’t have any issues, and our next release
currently under development and testing also with custom ariel is working as
expected. Sorry that this isn’t an answer but just to add our findings to this
unusual and seemingly random occurrence, and to ask if any progress has been
made to let us know why it’s happening, so we can report back to our
customers.
Hello there, A fix has been made in the AAU1 update about secondary aerial
that could solve this issue. You can test it in the AAU1 beta or wait the
final public release and tell me if it’s better. Regards, Boris
Hello, So it seems that the behavior is still present in AAU1 but the good
news is that the developer just told me that he found where the problem is. No
ETA for a fix yet but I’ll let you know as soon as I have more information
@SFSimsDev. thanks for the feedback in private
comments 
Regards, Boris
@Boris1 Did the fix make it into SU12? I can’t see a
reference to it.
Hello @SFSimsDev , For some reasons, I’m afraid
the fix is not in SU12. I’ll let you know when I know more. Regards, Boris
Are all the fixes locked in already or can it be added during the next patch
to the beta flighting?
Hi @Boris . Is there a fix for this or are we doing something wrong at our end?
Did you have any luck with this or is it continuing to be an issue for you?
Hello.
No luck at all unfortunately. In fact the issue has spread and now affects all of our other products too, some of which seem to suffer the ‘white out’ at a much closer range than we reported after our initial investigation.
We are getting a few customer complaints about it, and questioned as to when we will ‘fix it’, to which we cannot provide an answer.
We can only wait for the correction mentioned in previous posts, to be released, as it seems to have not yet been included in any of the recent Sim Updates.
All the best,
Chris
1 Like
Hello @SFSimsDev
Sorry for the delay,
I’m afraid there is no news on this subject, but I will let you know if anything comes up.
Regards,
Boris
Thanks @Boris - Is it on a list to investigate anymore? It was being looked into last year but seems to have been binned?
I can confirm that this issue is in our backlog but hasn’t been prioritized yet. At this point, we can’t provide further details on it but rest assured, I’ll notify you as soon as I have any updates.
Thanks for your understanding 
Are your compiled tiles only at LOD19? What happens if you make a CGL with tiles from LOD11 through LOD19?
SimpleAerial (flightsimulator.com) The SDK documentation calls for LOD20 which is what we’ve switched to (mentioned in the original post - but without impact). We haven’t tried anything else. I’m not sure how/if the devtools will pick up having all LODs in the aerial_images folder or how much of a storage space impact that would have… is it something you’ve experimented with @rhumbaflappy ?
I do recall using lods 13-20 for a stubborn area. This will increase your package size astronomically. It might be worth a try to see if it works in your case.
I ended up with a similar white area with using multiple LODs. 
The only other thing I can find is the package microsoft-airport-tncm-princess-juliana has a \CGL\032\sai300.cgl Perhaps that causes a conflict. I made a smaller single-LOD aerial in the Virgin Isles and it displayed just fine. Perhaps there is a memory limit per sai###.cgl files?
Yeah it’s intruiging. There’s a limit on CGLs for Xbox but not generally. I’ve noticed it seems to be more apparent when the network is slow. It’s as if the engine knows it has the LOD20 so deprioritises pulling the lower LODs across the network.