sundog

You mean if you click on a different sky color set, it does not highlight it? The screen itself looks correct to me. As explained in the text right above it, changes you make there won't take effect until you restart X-Plane. But you should be able to select a different choice there, close the dialog, and see the change applied after restarting X-Plane.

I think perhaps we don't understand the problem. We did not take away any functionality. Is there some sort of problem with the UI on your system? Perhaps if you shared a screenshot of what you're seeing it would help.

If you change the sky color set in SMP to default instead of Hoske-Wilkie, does the problem clear up? If not, then I don't think it's us.

He is referring to the SkyMaxx Pro manual.

SkyMaxx Pro and Real Weather Connector certainly should work on a Mac. Is it an installer issue?

I actually sent off a beta build of SkyMaxx Pro 4.9 to Cameron yesterday, with some minor fixes and several VR fixes. So yes, it's still being developed.

Also be aware that if you're in an area with broken clouds instead of overcast, we'll only draw rain when you're actually underneath a cloud.

Just pick a night with a new moon, or a time when the moon hasn't risen yet and the sun is well below the horizon, to see the clouds at their darkest.

On that day the moon was almost 3/4 full. So yes, I do think you would see the clouds at night under those conditions. If anything I think the ground should be brighter in that scene, not that the clouds should be darker. The don't look overly bright on my monitor here, so perhaps you just need to dial down the brightness on your monitor a bit.

Thanks, I didn't know about the fog issue. I'm planning to dive into VR again after the holidays and see what can be improved.

Whatever's going on here is complicated; your logs still indicate that the crash isn''t actually happening within our code, but it would seem that the delay introduced in rebuilding our cloud layers in response to setting changes or new weather data is causing something to time out and crash within X-Plane itself on your system. My best advice for now would be to reduce the cloud area setting in SkyMaxx Pro to make those delays shorter. Even reducing that setting by a little can make a big difference in the resources required to build the cloud layers.

Thanks. If you give it another try at some point, it might be interesting to see if the issue persists using X-Plane's stock aircraft. I think it might be specific to certain third-party aircraft somehow.

The log doesn't actually indicate that the crash happened within SkyMaxx Pro's code, but within X-Plane itself. The suggestion above is probably as good as any right now; apart from that, odd errors like this are often associated with overclocking. If you're overclocking, try reverting to your spec frequencies - I bet that clears it up.

This is the first I've heard of any sort of issue with 11.40; could you point me toward the other posts you saw? I'd have to see your log.txt file following a crash to speculate on the cause. It more likely has to do with changes to how X-Plane handles plugins than anything SkyMaxx Pro is doing.

SkyMaxx Pro simply makes the clouds and sky look better. It is not a source of weather data. FSGRW is. If you're happy with how your clouds look and you only want the ability to replay historical weather data, then you only need FSGRW. The combination of FSGRW, SkyMaxx Pro, and Real Weather Connector looks great, though.

If you have a moment, could you paste in a screenshot of your SkyMaxx pro main settings screen, and let me know what graphics quality setting you have set in X-Plane? I'm trying to look into this "flashing in the cockpit" issue again but I just can't get it to happen. I suspect it's specific to a certain combination of settings. Knowing which aircraft you're using might help too.

OK, so I looked into this. It seems that X-Plane's sun returns when you restart the sim after changing the sky colors. That's expected; it's why we say in the config dialog that you need to restart the sim for changes to take effect. When you select Hosek-Wilkie, SkyMaxx Pro draws the sky and sun over X-Plane's. When you select anything else, X-Plane draws the sky and sun and we don't mess with it. I think this is just a long-standing issue with X-Plane itself, but it's why we tell you to restart.

It's certainly possible that the way X-Plane's sky is drawn has recently changed such that it draws over our sun. When you select Hosek-Wilkie (our default), we also draw the sky which is why things work in that case. I'm planning to put together a minor bug-fix release soon, and I'll take a closer look at this. Thanks for reporting it.

I wonder if having used UWXP previously somehow manipulated some of these files in ways we didn't anticipate. When you re-installed X-Plane as a test, did you completely un-install it and delete its directory within steamapps/common before re-installing?

Tagging @Cameron ... I know that the latest MacOS release created incompatibility with many X-Aviation installers, but I don't know the details or where things stand with the RWC installer.

Thanks for taking the time to put this together! You really took the time to discover all SMP is capable of.

It seems like a file permission issue or perhaps a corrupt installation or drive at play here. I would install a fresh X-Plane into a directory where your user account has full permissions (not inside program files, for example), add SMP/RWC, and see if that works more reliably. Under the hood we are replacing X-Plane's sky textures with our own when SMP starts up and replacing them when we shut down, and something is going wrong in that process.

This is indeed odd behavior and it sounds like it's bigger than SMP. Let us know what you find.

Thanks, I may take you up on that.

The "white flashes in the cockpit" seems to only happen with certain aircraft. I did talk to Ben Supnik from Laminar about what is causing them, and unfortunately we didn't come up with a solution. It has to do with differences in how X-Plane handles the depth buffer in VR, and how that interacts with 3D plugins. I'm not entirely sure it's a problem we can solve. What's weird is that I've never seen it in my own testing (using a Vive Pro and default planes) so it's a tough thing for us to track down.