sundog

Right now the cloud visibility is determined by the cloud draw distance set by the user in SMP's configuration, and visibility information received from X-Plane - whichever is lower. So, the existing cloud draw distance control basically is a cloud visibility limiter already. Right now the cloud draw distance maxes out at 40 nm, and it would be nice to increase that limit. When we've tried doing that in the past however, it just results in a ton of tech support complaints from people with 512MB video cards who can't handle that many clouds. Not sure what the best solution would be, but I'm open to ideas.

You are either running out of VRAM, or running with another add-on known to corrupt X-Plane's plugin environment. Lately this seems to happen most often with users of X-FMC; if you have X-FMC installed, there is a beta version of it that solves the problem. If not, show us your log.txt so we can see what else it might be.

Hey Jose, I do get what you're saying. But you're really describing an entirely new product that's every bit as complicated as something like Active Sky Next for FSX for example. It sounds simple but it really isn't. First of all, NOAA weather data would need to be somehow interpolated between weather stations, and then translated into thousands of individual clouds surrounding the plane that keep themselves updated as the plane moves. That's the hard part. Beyond that, there is no way for any plugin to communicate high-resolution weather data like that back to X-Plane - so X-Plane's weather radar would no longer agree with the conditions being represented. Also, a lot of people complain that METAR's hourly updates aren't frequent enough, so a six hour update for NOAA would just create complaints from people who will settle for nothing less than a photographic match of what they see out their window right now. We'd probably need to blend METAR data into the NOAA data, and also interpolate the resulting data over time, to make people happy. I'm not saying it can't be done, just that the level of effort is similar to that behind Skymaxx Pro itself. If it happens, it will probably be in the form of a new weather engine product that interfaces with SkyMaxx Pro if it's available for realistic visual depiction of the weather.

Apart from bribing someone at Laminar to extend their weather data API... no. We just do what we can with the data we're given.

Right. Weather radar data doesn't get to SkyMaxx Pro, so the weather conditions you see are uniform and based on the weather at the plane's current location only. As the plane flies into different conditions, we blend the weather from one uniform state to another.

The weather conditions that X-Plane sends to SkyMaxx Pro are only based on the current location of your aircraft. So, if there are no clouds over your plane, SkyMaxx Pro is told to represent clear skies. If you fly into the clouds on your radar, you should see them appear. X-Plane has no means of representing weather systems in the distance to plugins, and I think that's what you're experiencing here. If I'm wrong, send us a log.txt after replicating the problem and it will tell us exactly what's going on.

I think X-Plane might use different anti-aliasing techniques depending on whether HDR is on or off, so it's possible that HDR off could actually use more VRAM if you have multi-sample anti-aliasing going on. Admittedly I am just speculating - I've never seen what you're seeing myself, but lack of video memory would explain it. I spent a little bit of time to see if SkyMaxx Pro could somehow deal with VRAM running out more gracefully. Unfortunately there doesn't seem to be a good way to handle this case, and it does seem more prevalent on Macs. See https://www.opengl.org/discussion_boards/showthread.php/183930-glTexImage2D-doesn%C2%92t-report-error At the end of the day, you just have to make sure your configuration isn't such that you're cutting it too close.

My only guess is that it has to do with the extreme resolution you are running at. Cloud shadows depend on us making a copy of your depth buffer, and at that resolution perhaps there wasn't enough VRAM left over to make that copy successfully. If you run at a more typical resolution like 1920x1080, does it work? If so, it's all about conserving VRAM until enough is left over for the cloud shadow effect. If you're running with HDR, custom scenery, and 5K resolution, I doubt much is left over.

Further research suggests that this OpenGL error comes from your NVidia drivers once GPU memory is exhausted. I see you have quite a bit of custom scenery and other add-ons installed, and I suspect Skymaxx Pro's clouds just pushes your system over the edge in some situations. Fundamentally you need to reduce your VRAM usage. You can do this by removing custom scenery, turning of HDR and/or anti-aliasing, running at a lower resolution, or turning down the cloud draw distance and cloud detail settings in the Skymaxx Pro configuration screen.

Are you really just on here to promote your own competing cloud package? That's pretty low if so. Regardless, REX does a lot more than just clouds, so it makes sense for them to have an option for it. SkyMaxx Pro is all about clouds, so not so much there. SkyMaxx Pro does have a cloud draw distance control in its configuration dialog, that allows you to push out the cloud distances if you have the GPU memory to handle it.

Huh? Clouds are kind of the whole point of SkyMaxx Pro. We won't be adding an option to disable clouds in a product that bills itself as a cloud replacement. You can always un-install it, or disable the "SilverLining" plugin from the plugin admin menu. I guess SkyMaxx Pro's clouds look more like FSX's default clouds than X-Plane's, but they're not really all that similar. FSX must have done something horrible to you if you don't want to be reminded of it that badly!

OK folks, I've halved the frequency of lightning strikes, and made the bolts themselves a bit thinner, in beta 4 of SkyMaxx Pro 2.1.1. This has been handed off to our beta testers, and we hope to release within the next few weeks. jiggyb2 - make sure you're using SkyMaxx Pro 2.1 if you aren't already; those weird "lone thunderheads" shouldn't happen so much in that version. Thanks for your feedback!

Well, the earlier dump you sent implicates the crash came from a plugin associated with the aircraft you are using. I think you're just running out of resources on your system, and Skymaxx Pro pushed you over the edge. Between your custom scenery, aircraft, and SMP, it's just too much. You could configure SkyMaxx Pro to use fewer resources by lowering the cloud draw distance and cloud detail settings, which might enable you to use it even with your system otherwise loaded up. Otherwise, something will probably have to go, and you'll have to choose what.

Yes, there is a way to change this - but rather than tell you how to hack our configuration file (that would open up a Pandora's box of support problems), there is an upcoming update that I could slip a change into quite easily. First though, I'd like to hear from others. As you said it's a matter of personal taste; real thunderstorms vary widely on their lightning frequency, and if it's too infrequent you'll rarely see it.

Your log tells us that the crash happened within the core of X-Plane itself and not from SkyMaxx Pro, but it happened shortly after a large number of clouds were created after entering a storm. "Error code 9" is coming from your NVidia drivers. Only NVidia knows what it means exactly, and there is no online documentation that I can find - only lots of people encountering it with various applications (usually Minecraft) and trying to figure out what it means. My best guess is that it is an indication of running out of video memory. So, to prevent this from happening, you need to configure X-Plane to use less GPU memory. Some ideas would be to remove custom scenery, or reduce the cloud draw distance and/or cloud detail settings in the SkyMaxx Pro configuration. Turning off HDR could also help, if you have it on. Multi-sample anti aliasing can also be a memory hog.

Based on the info you sent, the crash didn't come from SkyMaxx Pro. But like John said, we'd need to see your log.txt following the crash to tell more.

Update: I had some communication with the X-FMC developer on that... other forum. Sounds like he agrees that the upcoming beta version of X-FMC may work around what you are seeing; I think they just don't have a Mac version available of it yet for you, but they will soon. I would like to clarify that our best hypothesis is that X-FMC is triggering these crashes, but it's not really X-FMC's fault from the sounds of it. Rather a new API introduced in X-Plane 10.30 that X-FMC uses seems to cause trouble, and their new beta version just avoids using it.

Jose, the crash triggered by X-FMC is well understood by its developers, and I've only seen this sort of error reported by users who are using X-FMC. It is a bug that exists in X-Plane that is triggered by X-FMC, as I understand it. There is absolutely nothing I can do about it within SkyMaxx Pro as I have no control over the X-FMC or X-Plane code that causes it. We have to wait for an X-FMC update, or an X-Plane update, to fix this. X-FMC is leading to a state where X-Plane's environment that add-ons run wiithin becomes corrupt, and there's no code I can write that will let SkyMaxx Pro run reliably within a corrupt plugin environment. You are however correct that the "add in addons until it breaks" diagnostic method isn't always useful when it's an issue that only happens sporadically, like this one.

Yeah, we really need to see a log.txt following this. Just because X-Plane crashes while SkyMaxx Pro is installed doesn't mean it's something SkyMaxx Pro did. The log might tell us more.

SkyMaxx Pro does not parse METAR data; that is done before weather condition information gets to us. So I think the result might vary depending on whether you are using real-world weather in X-Plane, XSB, EFASS, or something else. If you want to help beta test the stratus improvements in SMP 2.1.1, Jaggo82, PM me.

For what it's worth - two other users I've been working with on a similar problem today isolated the problem to the X-FMC plugin. It has known issues with 10.30+. After disabling X-FMC the crashes went away for them. For others - unless your log.txt ends with "This application has crashed because of the plugin: SilverLining", your crash probably isn't caused by Skymaxx Pro. Start by disabling X-FMC if you are using it. Otherwise, you need to disable your other add-ons, verify that gets you back to a stable state, and then start adding them back in until you find the culprit.

I suspect the underlying problem still exists, but your new rendering settings have just rearranged memory in such a way that SkyMaxx Pro is no longer the thing getting stomped on. If problems come back I would recommend checking for updates to all aircraft and plugins that you are using.

Each of your logs ends with: --=={This application has crashed because of the plugin: [XPLM_PLUGIN_XPLANE]} This tells us that the crash didn't happen within SkyMaxx Pro itself, but some plugin corrupted the environment that all plugins run within. Since SkyMaxx Pro uses X-Plane's resources at a low level all the time, it's especially vulnerable to other plugins that corrupt memory. Your plugin directory seems more than a little messed up. See these lines in your log.txt: C:\Users/Fleming/Desktop/X-Plane 10.31/Resources/plugins/M2000.xpl : Error Code = 193 : %1 ¤£¬O¥¿½Tªº Win32 À³¥Îµ{¦¡ ¡CFailed: C:\Users/Fleming/Desktop/X-Plane 10.31/Resources/plugins/M2000.xpl. (This file is missing, not a DLL or could not be loaded due to another missing DLL.) C:\Users/Fleming/Desktop/X-Plane 10.31/Resources/plugins/XFMC_win.xpl : Error Code = 193 : %1 ¤£¬O¥¿½Tªº Win32 À³¥Îµ{¦¡ ¡CFailed: C:\Users/Fleming/Desktop/X-Plane 10.31/Resources/plugins/XFMC_win.xpl. (This file is missing, not a DLL or could not be loaded due to another missing DLL.) C:\Users/Fleming/Desktop/X-Plane 10.31/Resources/plugins/win.xpl : Error Code = 193 : %1 ¤£¬O¥¿½Tªº Win32 À³¥Îµ{¦¡ ¡CFailed: C:\Users/Fleming/Desktop/X-Plane 10.31/Resources/plugins/win.xpl. (This file is missing, not a DLL or could not be loaded due to another missing DLL.) C:\Users/Fleming/Desktop/X-Plane 10.31/Resources/plugins/32/win.xpl : Error Code = 193 : %1 ¤£¬O¥¿½Tªº Win32 À³¥Îµ{¦¡ ¡C My advice would be to start with a clean installation of X-Plane, install SkyMaxx Pro using its installer, and see if problems persist. If not, add in aircraft until you find the one that's introducing a plugin that's causing trouble, and see if an update for that aircraft is available. Older versions of SASL and XFMC in particular are known to cause odd problems like this (as are older versions of XSB). Also, a quick Google search turns up many reports of odd crashes like this with some of the aircraft you are using.

It sounds like SkyMaxx Pro can't write to its settings file for some reason. Is there a settings.dat file in your Resources\plugins\SilverLining directory? If not, perhaps this directory is somehow write-protected or in a system-owned location. If it does exist, try deleting this file - perhaps it got corrupted somehow. That's just an educated guess, as I've never seen that happen before. If that doesn't help, send along your log.txt and it might tell us something.

It seems there has been something of an uprising lately about IFR / low-visibility approaches in SkyMaxx Pro! While I can't bring back the "gray wall of death," I can introduce an alternate approach for simulating ground fog. Here's a sneak peek: This is from the forthcoming SkyMaxx Pro 2.1.1 release, which we're hoping to release post-holidays. To get this effect, you'll need to set the "overcast quality" setting in SkyMaxx Pro to medium or high, then place a stratus cloud at ground level. SkyMaxx Pro 2.1.1 will treat stratus clouds special - it will permit them to be at ground level, and use a technique called "soft particles" to blend them smoothly into the terrain. Version 2.1.1 will also resolve some issues about lights, propellers, rain, etc. showing through the clouds at times. Stay tuned.