sundog

You shouldn't have to care about who does what; it should just work. But since you tagged me, we don't have any control over Gizmo either. We just make TerraMaxx / SkyMaxx Pro / etc., which also depends on Gizmo for licensing. To the best of our knowledge, the issue has nothing to do with TerraMaxx itself. So, we're waiting for a fix, just like you are.

There are some conditions where we don't draw cloud shadows, such as if you're inside a lot of fog or haze. Turn up the slider all the way to 1, and as a test, try flying above some broken clouds (so you're above the haze) and over a body of water. The cloud shadows tend to show up best over water. If you don't even see them in that situation, then there's something definitely wrong.

There is a known issue with RWC in "Always" mode, due to NOAA changing its download protocol to https without warning. RWC relies on the Gizmo plugin to download this data, so we're dependent on a Gizmo update to fix this. I don't know when that is planned for. The other solution would be to update to some other weather setup, such as using X-Plane 11.32 and RWC in "automatic" mode, or using FSGRW or ASXP with RWC in "FSGRW / External Injector" mode.

METAR.rwx is downloaded by X-Plane when you have real-world weather enabled. Again, this is currently broken in X-Plane unless you update to X-Plane 11.32. All you need to do is select real world weather conditions when setting up your weather scenario, and X-Plane should download this file for you. Real Weather Connector simply reads it, and translates it into cloud placements for use by Skymaxx Pro.

Yes, SMP and RWC works with Active Sky XP. We only tested it with ASXP's initial release, but I'm not aware of any reason it would not work with their latest update as well. You should set RWC to "FSGRW / External Injector" mode when using ASXP. At one point we provided a build to X-Aviation of 4.7.3 that still read 4.7.2. I'm guessing our corrected build with the version number fix didn't make it out for some reason. I'll follow up with X-Aviation on that.

It's the "post FX" checkbox in the TerraMaxx configuration.

SMP itself has nothing to do with weather downloading - that is a function of X-Plane. I suspect you're running into the issue where NOAA without warning switched its weather data to HTTPS protocol, which broke real world weather in X-Plane. You will need to update to X-Plane 11.32 to fix that. If you are using a third-party weather injector, including Real Weather Connector configured to "always" mode, it may be affected by the same issue.

This is a limitation of the interface X-Plane presents to plugins; the depth buffer we're given in VR isn't what we expect it to be. As you said I think they broke a few things in VR in 11.30, at least as it pertains to third party plugin integrations.

We're aware of this and awaiting a change to Gizmo to allow us to download the data via https. Meanwhile if you can use "automatic" mode together with X-Plane 11.32, that should get the weather data flowing again.

If you can turn around 180 degrees after it happens, and it happens again when you fly over the same point from the other direction, that would make it pretty definitive that it's the one degree tile boundary you're hitting.

What is your RWC setting for "never change visible weather?" That might be the culprit.

Some images, together with your log.txt and fsgrwrsmp.rwx files, would be helpful.

Did some testing, and things seem to be working as they should here. My guess would be that you're crossing a one-degree tile boundary, which can cause the clouds to visibly and suddenly shift in position a little as X-Plane moves into a new coordinate system. Or, you might have the "cloud area covered" setting in SkyMaxx Pro's configuration set too low. That might cause new cloud layers to appear too close to your viewpoint, which might be distracting. For reference, a properly configured FSGRW / SMP / RWC setup should look something like this. This was taken just now near Seattle. If your clouds don't look like that, it may indicate a configuration issue.

Ah, I misunderstood. I thought you had it on based on your original message. Looking at the code, new clouds should fade in over 10 seconds when you have "never change visible weather" unchecked. You might be crossing a tile boundary as I described. We'll do some tests to make sure it's working as expected.

With "never change visible weather" on, cloud conditions don't fade in and out surrounding you, but you'll only see new cloud formations as you fly into them as the appear over the horizon. If that option is on, the only case where the clouds themselves should change is if you suddenly move to a new location, or if you cross a one-degree tile boundary in X-Plane which can cause the local coordinate system to shift slightly, and cause the clouds to move slightly as a result. If however visibility is suddenly changing, then that would affect what clouds you see or don't see from the viewpoint suddenly as well.

Real Weather Connector and SkyMaxx Pro only handle the clouds and precipitation, not visibility or winds. I'd report this to the developers of FSGRW.

It appears the data in this file does not match either the conditions shown in your FSGRW screenshot nor the conditions represented: GCTS 041648Z 08014KT 7000 NSC 24/10 Q1019 That says clear skies, with no clouds at all - and the time stamp is from the day after when you saw the issue. Seems FSGRW overwrote this file, destroying the "forensic evidence" we need. If it happens again, please copy the log.txt and fsgrwsmp.rwx files immediately so we can try and catch it in the act.

Hm, as far as I can tell from your log, we did receive data from FSGRW and processed it successfully. If you still have the fsgrwsmp.rwx file from that flight in your X-Plane folder, we may be able to track it down further with that. I'm not really sure if it's their issue or ours.

If it happens again, please provide your log.txt - it might shed some light on what's going on.

Is RWC set to FSGRW mode, and "never change visible weather" unchecked? If so, sometimes it can just take a minute for new weather conditions to be reflected in the scene.

It does not work in native VR. Laminar does not provide the SDK hooks needed for it. Unless that changes, our hands our tied.

Rain in the cockpit in VR is another problem that was introduced in 11.30. I believe it exists with the default rain as well, but it's less noticeable.

Make sure you have the cloud/terrain blend setting turned up in the SkyMaxx Pro settings. If that doesn't help, I think it's related to a change in X-Plane 11.30 that prevented us from accessing the depth buffer in VR that tells us where the ground is. Rolling back to 11.26 would be your only potential fix if that's the case (or waiting for Laminar to address the issue in a future X-Plane update.)

"Broken stratiform" (as well as solid stratiform) use a lot of video memory. So, my guess would be that it pushed your system over the edge - once you run out of video memory, all sorts of bad behavior can start in X-Plane. It's not a bug per se, just pushing your system too hard. As you correctly diagnosed, sticking with the default "HD puffs" setting is the right thing to do in your case.

It's very unusual for Real Weather Connector to be fingered in the crash log - in fact that's the first time I've ever seen that. The RWC plugin itself doesn't actually do much; mostly it enables functionality within the SkyMaxx Pro plugin. So, I think the most likely explanation is that memory became corrupt, most likely due to VRAM or RAM becoming exhausted on your system. TerraMaxx can be demanding on memory, so it's plausible that you simply ran out of memory due to having TerraMaxx's seasonal textures loaded up - and this pushed your system over the edge. All you can really do is try to minimize X-Plane's memory usage - disable add-ons you aren't using, try flying with a default plane, reduce graphics settings, etc.