sundog

For those experiencing this, what is your overcast representation set to in your SkyMaxx Pro settings?

I would leave it on in order to avoid any sudden, disturbing changes in the weather around you. If you think the weather is out of sync, you can manually force an update using the "Force weather reload" option in the SkyMaxx Pro plugin menu.

Yes, you will need SMP and RWC installed to every PC.

If you have "never change visible weather" off in the Real Weather Connector settings, try turning it on.

The default sun texture won't be replaced after changing sky colors until you quit x plane and restart it. If its still gone for some reason running the x plane updater should replace it.

@oldflyguy - I wonder if it's stratus with a coverage set of less than 100%. That might explain why it's being represented that way. For example, if we were passed "BKN" with "ST" we would actually interpret that as a broken stratocumulus layer, since it's sort of odd for Stratus to be anything other than overcast (OVC). @thomascats1 - here's an exerpt from the revised RWC manual we've handed off to X-Aviation for distribution describing how the ASXP integration works; you want the "External Injector" option in RWC. FSGRW / ASXP / External Injector Use this setting if you are using an external weather injector that overwrites X-Plane’s METAR.rwx file, yet disables “real world weather” mode in X-Plane. FSGRW and Active Sky XP are examples, and similar future products may work the same way. In this mode, RWC will always read the METAR.rwx file in X-Plane to generate its clouds, even when “grab real weather from the net” is disabled in X-Plane. It will not attempt to download and use its own METAR data, unlike “Always” mode, and depends on an external add-on to keep the METAR.rwx file up to date. RWC will check for changes in METAR.rwx once per minute, and apply them as appropriate. When using FSGRW, you may wish to disable “Never Change Visible Weather” to ensure that the initial set of weather updates it produces at the beginning of your flight are picked up. When using Active Sky XP, be sure to configure X-Plane as described in the ASXP documentation. In the ASXP application, under Options / Simulator Depiction options, you should find a “Use SkyMaxx Pro depiction mode” option in recent versions of ASXP. Be sure this is enabled. Weather in X-Plane should be set to “from custom METAR (rwx) file” pointing to the METAR.rwx file, not “match real world conditions,” when using ASXP. You should not use ASXP’s “global static” mode with SkyMaxx Pro.

Looks to me like a layer of broken cumulus clouds, possibly in the distance as they appear faded out. Or ASXP might be specifying that you're still inside some haze causing the clouds farther away to look a bit soft. They do look a little too dark. I'm not sure if that's due to the time of day, but if it's early morning or early evening that might be what's going on. The cloud lighting became more complex in SMP 4.9.3. If these clouds are backlit by the sun that might explain why they are darker than expected.

Yes! You'll want to use the "external injector" option under Plugins / SkyMaxx Pro / Real Weather Connector to take advantage of this improved integration with ASXP. Be sure to follow ASXP's integration instructions for X-Plane as well; X-Plane weather should be set to "custom metar (rwx) file" pointing to the metar.rwx file in your X-Plane 11 folder. Then, enable SMP mode under ASXP's Options / Simulator Options / 'Use SkyMaxx Pro depiction mode" screen. More on this to come.

I don't know where you read that, but that would not have any effect on SkyMaxx Pro's cloud shadows. We don't use private controls, we only use API's approved for use by third parties by Laminar. Our shadows are completely independent from X-Plane's built in shadow system. They appear fine for me and for most other customers, so I'm kind of at a loss here to be honest.

Rain on the windshield is a function of the plane, not SkyMaxx Pro. We only draw the rain particles in the sky. You'll have to take this up with the makers of these aircraft.

Try tuning off cloud shadows in the SMP settings. If your system is stressed, that may be what's pushing it over the edge.

Increasing your "cloud draw area" setting in SMP should help. The problem is that we're trying to draw cloud shadows beyond the edge of where clouds are allowed to be drawn. If you have a small cloud draw area, and the sun is near the horizon, this can happen. Also make sure you've updated to the latest version of SkyMaxx Pro (4.9.3 as of this writing).

I've still had no luck on reproducing the issue. If you're not seeing cloud shadows even in OpenGL with HDR off and the cloud shadow slider all the way up, I really can't explain that. The only other Idea I would have would be to start with a fresh installation of nothing but X-Plane 11 and SkyMaxx Pro / Real Weather Connector and see if that works. Sometimes re-installing everything clears up weird issues like this.

I mean the settings in the screen you get when you select Plugins / SkyMaxx Pro / Configure Clouds. A screenshot would do.

The log shows that X-Plane crashed within X-Plane's code, and not within SkyMaxx Pro's - so it does seem that SMP is somehow pushing things over the edge for you. The main thing I notice in your log is a lot of custom scenery which might be contributing. If you can post a picture of your SkyMaxx Pro configuration screen, it might tell us more about the memory situation on your video card which I think might be the underlying issue. 8GB can fill up quickly with custom scenery. If your cloud draw area has been cranked up in SkyMaxx Pro and/or you have VRAM-intensive graphics settings such as anti-aliasing cranked up, it could cause you to run out of video memory on your card which may lead to a crash.

We don't make any sudden changes in how clouds are drawn based on their distance. Although I still haven't been able to replicate these issues myself, I did code up a few tweaks to our VR support that *might* help. When 4.94 goes out (soon, I think) we can see if it makes a difference for you.

Hm, I just checked and they are at least working in beta 9 under Vulkan (see attached image). That said, cloud shadows can be finicky. Some things to try: - Reduce your graphics setting to "medium." X-Plane's HDR processing has a tendency to wash out our cloud shadows, regardless of how dark we draw them. This will also alleviate some memory pressure on your system, which your log is complaining about. Without HDR, cloud shadows are much more distinct. - Make sure you are not in an area of low visibility. We don't draw cloud shadows over hazy terrain, as the haze would diffuse them. - Try a different time of day. If the sun is low in the sky and you're facing in the wrong direction, shadows might not be visible because they are being thrown in the opposite direction from where you are looking. Based on your screenshots though, I suspect HDR is to blame. I took this screenshot with HDR on, but there might be something about your custom scenery that's making the shadows even harder to see.

If you're running tight on memory (which is likely under Vulkan) what may be going on is that memory is swapping as we load up new weather conditions. "Never change visible weather" should make that happen less often and is worth a shot. If that doesn't help, try reducing your cloud area setting in SMP to reduce the number of clouds it needs to generate. Or you could free up memory in other ways, for example reducing your AA settings.

We've never been able to reproduce this on our end, but there are some more VR changes queued up for 4.9.4 that I'm hoping will address whatever is going on.

Did you update to SkyMaxx Pro 4.9 or newer? That's needed for Vulkan support.

I wouldn't call 130 milliseconds a huge pause! But if your cloud draw area setting is all the way up in SkyMaxx Pro, it can take a few seconds for it to initially populate the clouds. If it's taking longer than that, it may indicate that you're tight on memory. Turning down the cloud draw area might help. That said, most issues with long startup times are associated with Vulkan pre-compiling its shaders, which it needs to do whenever you change your graphics settings. Long startup pauses in 11.50 or even hangs are much more likely due to that, and not SkyMaxx Pro.

We're actively working on offering more of a variety of TCU and CB clouds for more realistic stormy conditions.

Thank you! I've been doing some flying around Oregon this morning trying to replicate this... eventually I hit upon an altitude where a line near the horizon seemed to be flickering; sort of an aliasing problem. I disabled SkyMaxx Pro via the plugin admin, and the flickering continued. So whatever I was seeing looks like an 11.50 beta issue with X-Plane itself. There are also some cases in low visibility in mountainous regions where you might see missing terrain polygons near the horizon, but if that were the issue switching to the default sky should have cleared it up. So I don't think you're seeing what I originally thought the issue was. Filing this with Laminar is the right thing to do.

Actually I was also curious about why @seth is using both FSGRW and ASXP together with SMP/RWC. Can't argue with the results but are you somehow combining the strengths of both of those add-ons? Keep the screenshots coming folks, we love seeing them!

I didn't mean to come across as defensive; just stating the facts. It really would be helpful if you could file a bug report with Laminar since it's not something I'm noticing here.