sundog

I'd be curious to see your log.txt file after this happens. It might shed some light on whether the crash is happening while SkyMaxx Pro is destroying its clouds, or while X-Plane is creating its own.

When did you email support? It can take around 3 days for them to get to you when things are busy (and they are, with IXEG going on.) Make sure not to email them twice for the same ticket - the system puts you at the back of the queue when you do that.

They actually do have the ability to do this, but we kept listening to complaints about the clouds being too dark and ended up brightening them to the point where this effect was lost. The upcoming 3.2 update will dial this back down a bit. Just to manage expectations though, we're a long way from being able to do photo-quality representation of clouds in real time! This darkening only works at the resolution of the individual puffs that make up our clouds. I actually have code that can do this lighting on a per-pixel basis, but it won't even run on a top of the line PC on anything but a very small area of clouds. When hardware catches up though, we'll be ready!

Let me restate my original advice: There were no changes between 3.1 and 3.1.2 that change behavior at shutdown.

That's right; RWC is downloading its own copies of the METAR data in "always" mode. It's sort of a fail-safe mode for setups like yours where the "stock" METAR data isn't getting where it needs to be for whatever reason.

> The METAR.rwx files on both Visual PC's are not updated Well, that would be the problem. Try setting RWC to "always" on your client PC's.

The upcoming SkyMaxx Pro 3.2 update will have an option to only apply updated weather to areas you haven't yet flown into, so it should be seamless when weather is updated. I'm not really a fan of smoothing out the weather like you're describing; you'd never see crisp frontal boundaries then. I believe FSGRW does this though - they fabricate METAR stations for the purpose of blending weather between them. If you're using RWC in "automatic" mode with FSGRW, then you'll get the behavior you want.

Nothing's going to be resolved in a future version of SMP; you're the only person who has reported this problem to my knowledge, so there's nothing we can even investigate on our end. We have thousands of customers using 3.1.2 without any sort of crash on shutdown. Whatever is going on seems unique to your system. You'll have to try my suggestions if you want to resolve this.

Yes, I forgot to mention you also need the Gizmo plugin in order for SMP to work. There's nothing in either of those logs that suggest any sort of problem we can solve, though. Try removing all plugins except SMP and Gizmo, and also any third-party aircraft. Does it still happen? First I've heard of this happening to anyone. Are you overclocking anything? If so try disabling that. Also a fresh install of X-Plane from disks or Steam may be in order. One other thought is to install the Visual Studio 2010 x64 runtimes; something could be wrong with that on your system. You can get it at https://www.microsoft.com/en-us/download/details.aspx?id=13523

Please post your log.txt file after experiencing this (with other plugins removed) so we can see what's going on with your setup.

Sounds like you might want to invest in the FSGRW weather engine add-on. It has a "static weather download" option that would fulfill your first question, and the ability to load historical weather for your second. RWC will read the METAR data provided by FSGRW and display the clouds accordingly.

I've coded it up as an option that's on by default, so you can choose to have it work either way. It's clear there's no "right answer" to how this should behave.

If you fly a lower, slower aircraft you might not want to have to fly 100km in order to pick up updated weather conditions. There's also people who fly little circuits that would never go far enough. I threw up a question on Facebook about this though, and so far pretty much everyone agrees with you! I think I will make that change. Keep in mind new weather conditions for the world currently only come in once an hour, so we're not talking about something that happens often here anyhow.

Well, I'd like to hear other peoples' opinions on this. Earlier today we heard from someone who actually wanted the weather to update more frequently - say every 10 minutes, in order to have the most up-to-the-minute conditions possible. If we only updated weather on new areas you're flying into, you might have to fly 100km or so before seeing the updated conditions around you. Seems like one of those things where you are going to make some customers unhappy no matter what. One thing SMP 3.2 will do is check to see if a newly dropped METAR file actually changed anything or not - and if not, it won't do anything with it.

We do have specific clouds for cumulonimbus "anvil" clouds as well as towering cumulus. If the METAR includes "CB" or "TCU" we honor it. As summer approaches they'll become easier to find For now, check a national weather map to find stormy areas and you're likely to find them there.

RWC does not touch X-Plane's visibility settings; it leaves it to do what it would have done without RWC based on its own interpretation of METAR or what external add-ons are telling it. RWC only concerns itself with the placement of clouds. As for how X-Plane interprets CAVOK or 9999 - only the wizards at Laminar know for sure! If I were them, I'd set the visibility as far as I could while still obscuring the edges of the terrain tiles that are loaded.

There's no way that I'm aware of for a plugin to tell X-Plane "download weather now." But if RWC is in "always" mode, we download it ourselves - and we could do it more frequently if we wanted to. Thing is, if new weather conditions come in for the location you're at right now, then we need to change our representation of the weather - and many users find that distracting. It's one of those things where you can't make everyone happy. Some people want it to update more often, others want it to never update once you've started flying. Exposing the download frequency as a configuration option's an idea, though.

I don't use Real Terra Haze myself, so I'll have to rely on others to answer most of your questions. But I can tell you the Skymaxx Pro and Real Weather Connector generally don't mess with whatever RTH + X-Plane would have done with visibility without us; for the most part, we just let X-Plane do its thing with visibility. The one exception is if you're flying into a stratiform cloud. Apart from that, SMP and RWC don't enter the picture at all with visibility effects.

Never heard of that one before! Please post your log.txt after experiencing this so we can have a look. It's almost certainly a conflict with some other plugin.

Your SMP settings don't look particularly challenging, and you have a fair amount of memory available - so I'm not convinced SMP is the culprit here. However, I see you messed with the minimum and maximum cloud size settings. I would recommend setting those back to default, as they can influence how many clouds are created. Also, solid stratiform will perform better than sparse particles. But again, I'd be really surprised if SMP is the root cause given your very modest settings and your system configuration. I'd recommend temporarily removing your plugins and custom scenery, and start adding them back in until you find what's causing the problem. A GTX970 shouldn't even break a sweat with your SMP settings.

Yes. Well, safe in the sense that it won't interfere with SMP in any way.

Not much to go on there. If this just started after installing SMP, try re-installing it; perhaps something went wrong during installation. If not, there's nothing in your log that implies SMP is what caused your crash really. I would start removing plugins until you find the culprit - you have quite a few.

SMP does not interact with your scenery in any way; there's nothing we can possibly "fix". The issue is that plugins associated with some scenery, or improperly installed scenery, can result in memory corruption that can cause any other plugin to crash. Just because a plugin was the last thing to write to the log does not mean it is the root cause of the problem. Another scenario would be having so much custom scenery installed that your system has no memory left over for SMP to work with. Again, nothing we can do there, except recommend that you load less stuff to free up some memory. Put another way - if some other plugin corrupts memory which leads to crash later on, there is nothing we can do about it. The other plugin needs to be fixed, not ours. If the crash actually happened while SkyMaxx Pro was executing its own code, the log would indicate that the crash occurred in the SkyMaxx Pro plugin.

My intuition says it was related to your scenery. The FF 767 is a popular aircraft, and if it had a bug of this magnitude we probably would've heard about it earlier. Yes, a problem like this can cause a crash regardless of weather conditions. I would just keep on flying without that KSAN scenery and with your 767. If crashes start again, use a different plane - and if that doesn't clear it up, post back here and we'll continue to help.

We actually do disable the effect if landing lights are off. If you are seeing this on a specific third-party aircraft, you should contact the aircraft's developer - they are not properly setting the sim/cockpit/electrical/landing_lights_on dataref in response to their plane's landing lights switch.