sundog

That number's clearly not correct, but it's what MacOS is giving us as the "vramFreeBytes" value in its "PerformanceStatistics" dictionary (divided by 1024 to give us MB). Apart from that however, your framerate looks good and I don't see any indication of other problems - so I wouldn't worry about it too much.

I think this was discussed in more detail in another thread, but to summarize - it's a known issue that can happen if you have a large cloud draw area setting in SMP and change the time of day during a flight. It should be fixed in SMP version 4. It will still take a few seconds for distant clouds to re-light in response to a time of day change, but they shouldn't get "stuck" like they can now.

In this case you should have RWC and SMP installed on both PC's, and I would recommend setting RWC to "always" mode. What's critical is that both PC's have the exact same settings for SMP; you may want to copy the resources/plugins/silverlining/settings.dat file from one PC and copy it to the other to be sure.

The log doesn't show that SMP caused the crash. You've got a lot of custom scenery - looks like some w2xp and HD Mesh stuff along with others. You're also using XSB/VATSIM, XACARS, and a third-party aircraft. All you can really do is remove all custom scenery and add-ons, confirm things work again, and then start adding stuff back in until you can isolate what's causing the issue.

Well, I'm glad it's holding up. The way Macs manage memory is, shall we say, complicated. I don't think what you're seeing with reported memory usage is necessarily unusual. Focus on finding settings that work reliably, and avoid running other apps at the same time, as you're doing.

But - no crash under medium settings? If it seems stable, then we have something to work from at least - and it would seem that your system was just overtaxed somehow. Memory usage is only part of the picture. From there, you can try turning up specific rendering settings. Not sure what kind of flickering you're seeing, but maybe you need a higher AA setting for that.

Try the "medium" preset. That shouldn't be too demanding.

Don't forget to try lower rendering settings too.

SMP4 features a new "HD puffs" overcast setting that is much faster than sparse or dense particles. With it, you should be able to draw clouds out farther than before with the same or even better performance. Glad to hear our latest updates got you moving in the right direction!

Well, it's never a bad idea to start from a clean X-Plane installation and re-install the add-ons you care about when strange stuff starts happening. I'm not sure what sort of weird things having two copies of Gizmo installed might cause, or how you got into that state. But that would be a sure way to clear it up. Since you're on El Capitan, you shouldn't need the latest Gizmo beta version or anything like that. Since you can replicate this reliably, I think it's also good to experiment with flying with a different aircraft, and with lower rendering settings, and see if that helps. Your latest log doesn't even indicate a crash which is just more oddness.

I looked back at your earlier crash report, and it actually crashed in a very similar manner - after this line in the log: SkyMaxx Pro: Coordinate system changed; repositioning cloud layers. This indicates that the METAR data parsed OK, but something seems to have gone wrong while SMP was moving the clouds to account for your plane crossing a tile boundary within X-Plane. Thing is, I can't explain how that could cause a crash. I've been staring at the code all morning and there's just nothing there. Plus, you're the only person experiencing this issue as far as I can tell. I've never had a crash like this myself, nor seen any other similar reports. The only explanations I can come up with are: - You're still running out of memory; your video memory is pretty tight in your screenshot above, and unfortunately there's not much you can do to expand that on a Mac. You may need to reduce your cloud draw area further, or use a less demanding aircraft than the 777, or reduce your rendering settings in X-Plane to "medium" or so. - Some other plugin is corrupting the memory that SkyMaxx Pro is using. But as far as I can see, all you're running is the latest version of the 777. That's a fairly popular aircraft, and I don't see any other crash reports related to it here or in the 777's own support forums. - Something's wrong with your operating system. SkyMaxx Pro does a lot with the "C++ standard library" provided by the operating system at the point where you're getting a crash. Did this just start happening after an OS upgrade, or after installing some other software? - There is a physical problem with your memory causing data to be corrupt. But I would think that would manifest itself in other ways and not just by making SMP crash at this point. Sorry I can't be more helpful at this point; without the ability to reproduce the problem and not seeing anything while inspecting the code, I can only speculate as to what's going on. My practical advice would be to start flying from a point in your flight path just prior to where it crashed; what you're seeing should be triggered by crossing specific locations. If you can get it to crash consistently, start experimenting. Does lowering your cloud draw area allow you to get past that point? Does using a default aircraft get you past that point? Does lowering your rendering settings help? That way we can narrow down the cause. I hope you're willing to work with us on this; I definitely want to understand what's happening on your system and fix it.

It sounds like you're describing dynamically generated imposters. They are an optimization for drawing distant clouds into 2D textures. FSX does the same trick. If you reduce your cloud draw area setting, they should go away. The appearance of them will also be improved in Skymaxx Pro 4.

Looks like you do indeed have the newer SASL installed now. FYI "Silverlining" is part of SkyMaxx Pro.

You're using a really old version of the SASL plugin that is known to cause problems with SkyMaxx Pro and other plugins. That's my prime suspect. See if an update is available for the aircraft you're using. You're also almost out of memory on your Mac (despite having 16GB!), which could also lead to crashes. Custom scenery is usually the biggest memory hog; you might try removing it as a test. If you turned up SMP's cloud draw area setting, turning it back down might help conserve a bit more memory as well.

On my PC, the FPS cost of going from low to high rendering settings with SMP4 disabled is more than the cost of rendering multiple overcast layers to the horizon with SMP4. Showing a framerate under "common use" is showing the FPS impact of the rendering settings, aircraft, etc. much more than the FPS impact of SMP4. Everyone has different aircraft, scenery, settings, and hardware, so that really wouldn't be useful. What I'm offering is a baseline. I'm *not* saying "you will get 70 FPS with SMP4 under worst case weather conditions with SMP's settings maxed out." Just that it is achievable. Everyone's setup is different and it's impossible to make claims like that.

Please start a new thread in the support forum if it persists.

That's funny, because SMP's clouds used to do that - and then people complained about it, so we turned that effect off. Really, people were freaking out on us insisting that clouds always appear white no matter what (even though I know that's not true.) You've given me the courage to re-enable that effect, but perhaps just more subtle than it used to be. Thanks for the feedback.

Denco, I'm not sure but I think the stutters you're describing are a side effect of the NOAA plugin updating your METAR data too often. SMP4 will change how RWC interacts with things like NOAA in a way that should reduce this.

I've seen a lot of people asking for proof of SMP4's framerate with the cloud draw distance cranked all the way up. Mind you, I don't have John's artistic touch, but here are a couple of shots of what's pretty much a worst case scenario - with the framerate display on. Blow 'em up and see for yourself. This is over the Chicago area right now, where there are multiple large, dense cloud layers of different types being fed in from Real Weather Connector. Remember your mileage will vary. Skymaxx Pro usually isn't your performance bottleneck; scenery, your rendering settings, and other addons often are.

I don't use NOAA myself so I'm not real sure how it works. I can tell you that RWC in "always" mode will periodically check to see if either METAR.rwx or MAXX_METAR.rwx has been updated, and use the newer of the two if so. As crisk73 said, going back to NOAA 2.3 and deleting both of those files should get you back in business.

I think when you reverted back to 2.3, you still had a newer file modification date on METAR.rwx than was on MAXX_METAR.rwx, and so we kept using the most recent METAR.rwx that 2.4 had placed there.

Apparently the new NOAA 2.4 release updates the METAR.rwx file every minute, and that seems to be the source of this problem. Real Weather Connector is seeing that METAR.rwx is being refreshed more often than its own MAXX_METAR.rwx file, and so it is loading weather from METAR.rwx instead. Which apparently contains very little information (perhaps we're reading it while NOAA is still constructing it?). Even when RWC is in "always" mode, it will use whichever file is updated more recently (METAR.rwx or MAXX_METAR.rwx) for its weather source. Both of your logs say the same thing - METAR.rwx is getting replaced while NOAA is running and so RWC is using it as the newer source of data. What I can do on my end is to always use our own MAXX_METAR.rwx data even if METAR.rwx is newer when "always" mode is set in RWC, as part of the upcoming Skymaxx Pro 4 release. But I'd recommend going back to NOAA 2.3 for now. If the author of the NOAA plugin reads this, it would be a good idea to make the refresh frequency of METAR.rwx configurable if it isn't already, and to make sure it is updated in an atomic manner (for example, writing it out to a temporary file and then renaming it when it's ready.)

Could you also post your log.txt after experiencing this (together with the maxx_metar.rwx you had at the time?) There's nothing unusual about that METAR report so I think something more complex is going on.

At your cloud area setting, I don't think fast vs. crisp on the cloud puff type will make much of a difference. If you prefer the look of "crisp", go for it. What will make the most difference is increasing your cloud area covered setting, but as you noted you're pretty tight on memory already. Still, see how far you can increase it while in cloudy conditions while maintaining acceptable performance.

I didn't notice this happening on our own Sierra system, but I'll double check. It's either something specific to your hardware and OS, or you really are out of VRAM. **Update*** Just tested the current SMP4 build on a recent iMac running Sierra with a ATI video card, and the VRAM measurement does seem to be working fine. We'll keep an eye out for this during beta testing, however.