sundog

Broken clouds are just scattered cumulus clouds, and as such a layer of broken clouds won't have a fixed "top" to it. The bottoms of cumulus clouds will be near the base altitude specified, but the tops will vary from cloud to cloud. We simulate how large the clouds are in nature and size them accordingly. In your example, you'd be limiting cumulus clouds to 2km in height, which is much smaller than they would be in the real world. If you create a solid cloud layer such as stratus or overcast, then we honor the top altitude as well as the bottom, since these types of clouds are "slabs" where that makes sense to do.

We're waiting on Laminar to address some issues with how VR interacts with plugins still. Until that happens we're stuck on VR support I'm afraid.

Neither FSGRW nor X-Plane's built in weather system has access to precise real-world placement of storm cells. The best they can infer from the METAR data is "there are storms North of the airfield" (or some direction,) but more often it's just "there are storms around here somewhere." In that case, RWC just scatters them about randomly surrounding the station reporting those conditions for lack of anything better that it can do. If you have SMP configured to take control of precipitation (see its precipitation control panel), you should at least see precipitation visual effects where it should be associated with SMP's individual clouds. But there is no way for plug-ins such as SMP or RWC to communicate back to X-Plane to tell it where it positioned individual CB clouds, so it can create a consistent experience with winds and the radar. Laminar contacted us a long time ago about extending their plugin API to allow us to do that, and we even wrote some code into SMP to support it - but that feature hasn't made it into X-Plane yet. So for now, it's behaving as well as is possible within X-Plane's architecture. As far as I know, SMP is the only weather add-on that even attempts to represent individual storm cells with cumulonimbus and towering cumulus clouds, so it's sort of a bleeding edge thing still.

The current system just uses latitude and the month to estimate the season, and can't account for micro-climates such as England's. Keep mind 51 degrees latitude is the same as Canada and some pretty cold parts of Russia too. In the US it's even north of Maine, where it's still quite wintry.

We have some more performance improvements ready to go here, and some small bug fixes. The main thing we're working on is VR support; right now we're waiting for Laminar to look into some things on their end, as it seems as though X-Plane's SDK isn't behaving as it should in VR mode. But that's why VR is still in beta. Right now I'm calling it 4.7, but we haven't really talked about a release plan for it yet.

If you examine the seasons.txt file inside TerraMaxx's plugin folder, it will answer any questions you have about how seasons are chosen for a given location and time. If your simulated date in X-Plane is in April, you would have to be flying above 50 degrees North for TerraMaxx to consider it "Winter" in auto mode.

What date was being simulated in X-Plane? In April, the cutoff latitude for winter is defined to be 50 degrees North.Perhaps X-Plane was set up for a different time of year where the cutoff is further South. " considering there is no snow where I live it should not be deep winter. " Again bear in mind the weather data available to X-Plane tells us nothing about whether there is snow on the ground. We make no claims that what we represent will automatically match what you see out the window at all times. All we can do is make a best guess based on your location and the time of year. The temperature will affect just how "frozen" things looks when we do think there may be snow on the ground. You can easily change the season manually using TerraMaxx's configuration screen if you want to.

Thank you owine... I loaded up your METAR files at the location you specified, and nothing crashed - so I'm cautiously optimistic this won't happen again after our next release.

I think I remember seeing a report that it does not, but bear in mind VR is still in beta with Laminar and they are still working out the kinks involved with supporting third party add-ons with VR. We are actually working pretty closely with Laminar on VR integration with add-ons. I expect we'll get it working but it is all a work in progress still.

Sure, if you can provide your metar.rwx along with the location you were flying at when it crashed, I can use that to make sure the fix I wrote yesterday actually works. Thanks.

Yes, I think some unusual weather conditions triggered this. Presumably the issue has already passed. But, I'm working on making this part of the code more robust for our next release right now.

You're right, that does look like the same issue. Given that it seems to have happened around the same time, I think there were some unusual weather conditions being reported that found a case that triggers this crash. I'm looking into it to see if there's anything we can tighten up for our next release.

About the only explanation I can come up with is that something corrupted the memory that our internal clouds use, which led to a crash when we tried to sort them. Looking at your log, I think we were trying to process new weather data at the same time that your Flight Factor aircraft was trying to do something as well, so it's possible there was some sort of bad interaction there. You do have a large amount of third-party add-ons and scenery in the mix so it's hard to say what might be causing trouble. Has this crash ever happened to you before, or since? If it does start to become a problem, see if running without other third party aircraft or plugins makes a difference. Re-installing SMP 4.6 might not be a bad idea as well, in case you still have some older components of SMP 3 installed somehow. SMP 3 did have an issue that would explain this behavior more readily. The version SMP thinks it is can be seen in its configuration menu.

Hi, what version of SMP are you using? This does indeed look like our crash, but it looks like something I thought we fixed a long time ago.

Just to make sure we're barking up the right tree, it might be a good idea to open up your Custom Scenery/SeasonsXP/library.txt file and see if it is in fact corrupt. It should start with: A 800 LIBRARY If it doesn't, then that supports the corrupt download theory and would explain the error you're seeing.

Ah, I misunderstood. I see now there are some small and grass airfields that use .pol resources that we missed. I'll talk to John about how we want to deal with it.

TerraMaxx does work with default scenery out of the box. This thread is just for people modifying their custom add-on scenery to work with TerraMaxx.

In March, our cutoff for "winter" is at 45 degrees North. EDDL is above that latitude. The temperature only controls whether we display "mild winter" or "deep winter" textures. The temperature alone can't tell us if there is accumulated snow on the ground or not, so we just give it our best guess. We make no claims to emulate the current snowfall conditions at a given location and time; we just try to make a reasonable representation of the seasons given the information X-Plane has.

It does, but only for default aircraft that don't have special, upgraded sound effects in place from Laminar. For example, the F-4 and SR-71 will be affected by SoundMaxx in XP11, but not the MD80 or 737.

It improves most default aircraft in XP 10, but in XP 11 Laminar improved the sounds on many of the default aircraft including the MD80. So we opted to leave the new default aircraft sounds in place in XP11 where they exist. SoundMaxx still provides ambient sound effects in XP11, in addition to improved sounds for default aircraft that don't have their own special, unique sound effects within XP11 (which is most of them, but not the MD80.)

It uses METAR reports from surrounding airports in this case. I'm guessing one of them are not reporting completely overcast conditions and so you're seeing some breaks in the clouds.

Try changing the simulated date to February. March is just past the point where Colorado's latitude is considered "winter." You can also force winter via TerraMaxx's settings.

I'm afraid this is looking like a hardware issue, if it's those corrupt, speckled textures you're seeing that remains the problem. Do you have all of the latest updates applied to your Mac? The last hope I'd have would be if it's a video driver issue that has since been fixed by Apple.

Thanks for the log. A few things of note in there: - Seems I guessed right that you're on a Mac. We have seen issues like this on specific Mac models that seem to derive from a video driver error or hardware error of some sort, and it looks like you may have one of them. You can try un-installing SkyMaxx Pro and re-installing the latest version; it helps sometimes. Or try *not* flying in HDR mode; that may also clear it up. - There is a low memory warning in your log file, although it looks like you have an 8GB system so I'm not sure why that is. I doubt it's a real issue, but make sure you don't have other apps running in the background while flying. - You're running a "terrain radar" add-on that I haven't seen before. It's possible it's somehow corrupting the graphics state before we have a chance to draw. Disabling it may be worth a shot as a test.

Also, I do remember a couple of people seeing this problem on MacOS that were able to clear it up by selecting HDR mode in their X-Plane graphics settings. Something to try if that describes you. You might also want to post your log.txt here so we can see if it might be some other add-on corrupting things.