sundog

Your log does look like SkyMaxx Pro crashed due to unexpected METAR data. There was an incident a few days ago where NOAA was publishing data that crashed SMP for a couple of hours, so I wonder if you still had a copy of that in your X-Plane folder. Try deleting your METAR.rwx and/or MAXX_METAR.rwx files before starting, to ensure new data gets downloaded. Does that help? (We do have a patch to prevent this from re-occurring that we'll be distributing soon.) I just checked and SMP seems OK with the data that's being published currently.

I wonder if your position is what suddenly changed as opposed to the weather. If it happens again, please post your log.txt file so we can get some more info on what's going on.

I think the underlying issue was probably X-Plane suddenly switching to uniform weather, and we honored that. You can set RWC to "always on" to force it to always use METAR data no matter what.

We don't do anything that would affect X-Plane's internal settings for weather, so I think that issue with things suddenly changing to "uniform" for no reason may actually be a bug in X-Plane. You should probably report it as part of the beta process.

Plugins currently have no way of communicating cloud formations to X-Plane's internal weather map display. Both should be more or less similar as they should be based on the same METAR data, but they won't match up exactly as we interpret METAR in a different way. We've talked to Laminar about some longer-term solutions for this, but for now it's something we have to live with I'm afraid.

Our thunderstorms range from 5-7 km in height. Look at the cloud's size relative to the trees it is over, not relative to your plane in the foreground. They are small by cumulonimbus standards but not physically implausible. We need to keep them on the small side in order to guarantee acceptable performance.

I double checked, and the METAR data currently being published works fine with the SMP/RWC versions that are currently released. The issue was specific to earlier this morning.

Well, I found the culprit: CZFA 191300Z 29007KT 10SM BKN013 OVC030 12/10 A2991 RMK ST5SC3 VIS N-NE 5CLIMAT 18.6/11.4/3.0MM SLP142 DENSITY ALT 2500FT I don't know what the heck that is supposed to mean! But it's triggering a bug in the METAR parsing code we got from NOAA. It's probably crashing all sorts of systems that use that code library, which probably explains why this entry has already been changed in this hour's data Just in case it comes back, I am preparing a patch that fixes the underlying problem.

It does indeed look like unexpected METAR data. I'm looking into it. Hopefully the next hour's data will clear it up on its own.

Thanks for posting! I especially like the Mt. Hood shots.

To answer the earlier question, I'm on NVidia driver 365.19 here. But it's sounding increasingly like this is just something that really hard to make happen reliably (or quickly.) It probably depends a lot on the specific weather you're flying through, as well as your settings and what other add-ons you have. I know some people think I'm dodging the issue here, but I can assure you that SMP's memory management has been tested very extensively. I'm pretty sure we're not just leaking memory or resources over time or anything like that due to bad code. But, as you fly with RWC, we do keep a cache of cloud areas around so we can quickly swap them in as you fly into new weather. This cache grows over time, but does have an upper bound. This is how we avoid stutters as you fly into new weather. So, I think this upper bound may just be too high for some systems. It's not actually consuming all that much VRAM, but it might lead to memory fragmentation issues in the driver or something. I can get into this state myself if I crank up my cloud draw area all the way and fly through bad weather for a long enough time, but not with a cloud draw area of just 10,000. Short story - it's complicated. If this is happening to you, it probably means you need to reduce your cloud draw area setting - and an immediate workaround during flight is to tweak SMP's settings which causes it to clear its cloud cache and start over. Longer term, I suspect we will need to adjust our tradeoff between cache size and stutter prevention in future versions.

That's really strange; I don't see any changes between 3.2 and 3.2.1 that would explain this sort of behavior suddenly starting. Any chance you also changed your video driver around the same time? Regardless, I'll try again to get this to happen and see if it's something we can address somehow for the SMP 4 release. Right now my suspicion is that certain video drivers aren't properly disposing of our clouds' resources for some reason, or are leaving memory in an increasingly fragmented state over time, but there might be some workaround if so.

What version of SMP were you using previously, Muskoka?

For people experiencing this - have you all increased your cloud draw area setting significantly from default settings? Does resetting SMP to default settings make the issue go away? Like frontendrob, I can't get this to happen on my system (unless I crank up settings in general beyond what my system can handle) - I'm just trying to figure out what's common between people who do have the issue.

In all seriousness, I drove past about seven CB clouds the other day that looked just like this here in Florida. People have different expectations of what storms look like based on where they live, and what they've seen in other sims. That said I won't say there isn't room for improvement - there always is, and we're always working on it.

It still sounds like some sort of resource swapping; perhaps it's not VRAM but something else. Does the issue go away if you don't use HD Mesh and/or ultra high settings? If so, that points to a general resource management issue as opposed to an issue with SMP itself.

Seth, I wonder if the real hit there was getting close enough to the clouds for the landing light illumination effect to kick in. Perhaps your system is sensitive to the few extra shader instructions that happen in that case.

Like you said, the hit is fillrate. So if you're running at a really high resolution, or high anti-aliasing settings, that will exacerbate the impact. MSAA can really slow things down in particular.

Thanks for the ideas. I've actually done some tinkering with changing the visibility distance (for our clouds, at least) as a function of altitude, framerate, and some other ideas. Getting it so it's not noticeable when it happens is the hard part, but I think it's worth further exploration.

There is no log specifically for SMP; it writes data into the same log.txt file everything else writes into. You should find that file in the top level of whatever directory you installed X-Plane into.

You might try turning off cloud shadows and cloud/terrain blending, but apart from that there's nothing really challenging about the SMP settings you have. It should run just fine. If problems continue and you confirm it only happens with SMP on, please send us your log.txt after experiencing the trouble.

Have you fiddled with your video drivers at all on this system, or are they the standard Apple drivers? I'm afraid the only other times I've seen something like this reported, it turned out to be a hardware issue with the video card. But corrupt or incorrect video drivers could also explain it. You might also try reverting SkyMaxx Pro to default settings; perhaps some specific feature such as cloud shadows is triggering whatever the defect is.

We offer separate installers for Windows and MacOS. You'll have to go into your X-Aviation account and download the appropriate installers for your new operating system, and re-install. Thanks for being such a loyal customer, by the way!

The last thing in a log file does not mean that's what caused the crash, unless X-Plane clearly states the crash was caused by that plugin. I see you have HD mesh installed, so it's much more likely that your system just ran out of memory (VRAM or system RAM.) The SkyMaxx Pro configuration panel displays a measurement of how much you have available; if it's less than a few hundred MB, then you're in danger of running out of memory which can cause X-Plane to crash. In this case, you need to dial back your rendering options, custom scenery installations, and/or cloud draw area settings.

Quite honestly I don't have any experience with multi-PC setups. I think it probably doesn't matter, but I'd set the server to be the same as the clients just to be safe.