sundog

Make sure each PC has identical settings for SkyMaxx Pro to ensure the clouds line up properly. You may want to set things up the way you like on one PC, then copy the settings.dat file inside the SilverLining plugin folder to the others.

When SkyMaxx Pro starts up for the first time, it copies whatever is in the default XP sky colors (resources/bitmaps/skycolors) into its assets/plugins/silverlining/skycolors/default sky colors folder. if you select a sky color set via SkyMaxx Pro's UI, it just copies that set from the plugin's folder into the default folder. So, X-Plane always uses what's in the default XP sky colors folder. SkyMaxx Pro just provides a manager for what is in there.

Sounds like some odd issue with your filesystem, but you should probably contact orders@x-aviation.com if you haven't already - they can probably help you better than I on this one.

If you just want to sync the settings for SMP, these are stored in resources/plugins/SilverLining/settings.dat. As long as you have valid installations of the SilverLining and Gizmo plugins on both systems it should work fine, although you will be prompted to re-authenticate your license for SkyMaxx Pro on the new system. One caveat: if one system is Mac and the other PC, the settings.dat file won't be portable between the two.

Totally a guess, but does reducing your visibility setting help? It kind of looks like a depth buffer resolution problem to me, and pulling in the camera's far clipping distance can help with that.

If the act of restarting somehow restores an earlier copy of our settings.dat file, it's more likely some operating system thing or backup program doing it I would think. X-Plane and SkyMaxx wouldn't even be running then. I'm not really enough of a Mac expert to speculate on what's going on there.

John's right - if you have a crash SMP might not save its settings. Normally it does however. It's not a surprise at this point if you're encountering trouble on a Mac flying long-haul flights with overcast quality set to "low". My advice would be to set it to medium, quit X-Plane to make sure that new setting gets saved, and then leave it there.

Just to double check, your overcast quality was on "medium" for this flight?

Just to double check, your overcast quality was on "medium" for this flight?

Nano, that most recent crash was not caused by SkyMaxx Pro. Rather SASL got fingered for it in your logs, following what looks like a lost connection to a server. SilverLining (SkyMaxx's plugin name) doesn't show up at all in your crash log. Ben's probably right. I think setting overcast quality to something other than "low" did actually prevent SkyMaxx Pro from crashing in response to whatever odd conditions were going on, but there is a source of CTD's outside of SkyMaxx Pro going on here.

Thanks. Based on an analysis of the code, I think this error would only get triggered on MacOS when flying into overcast conditions with the overcast quality set to "low" - and even then it's a matter of chance as to whether it would happen. It seems like long-haul VATSIM flights are more likely to trigger it for some reason. My advice for MacOS users however is to avoid the "low" overcast quality setting until we issue an update to plug this rare problem.

I think a Chinese counterfeit iPhone is a much better analogy than a Fiat. The original release of this thing even copied Maxx-FX's theme names down to the letter. But like a counterfeit iPhone, it's not actually as sophisticated inside. Let's get this thread back on topic. No need to give this counterfeit any undeserved attention.

Nano, what is your "overcast quality" set to in SkyMaxx Pro's settings? We think this issue might be limited to using XSB on MacOS when running with overcast quality set to "low".

It could've hit you just as an overcast layer was about to be injected - I think this might be it still. It also explains why many other people reported that the 1.3.2 patch cleared this up - I bet they were running on medium or high. Look forward to hearing the results, and thanks for working with us on this.

vgmm009, can you please check what your overcast quality setting is at in the SMP configuration? Do you happen to remember if you were flying into overcast conditions when this happened? If it is set to "low", I suspect setting it to medium or high instead will clear this up.

We'll take a second look at the code your log is pointing at. There is no obvious cause for this happening in 1.3.2 so bear with us - especially given our inability to reproduce the error. (For others reading this thread thinking "OMG SkyMaxx is going to crash on me" - probably not. This issue only affects MacOS and has only been observed while flying for many hours in one sitting while using the XSquawkBox add-on - sometimes.)

We'll look into it for the next version... my best guess is that XSB is setting up cloud conditions we never anticipated under rare circumstances or something. Perhaps multiple cirrus layers at the same altitude or something like that. If anyone remembers what the cloud conditions looked like prior to encountering this it might be helpful.

This is exactly the issue 1.3.2 should have fixed, and seems to have fixed for others. Just to double check that something didn't go wrong during the update - can you check the version number displayed in the configuration dialog of SkyMaxx Pro for us?

We actually tried that at one point telamon. It ended up looking weird, especially when you suddenly flew through the (geometric) plane. As Cameron said, we're doing the best we can with the information X-Plane currently exposes to us. The "grey screen of death" approach isn't unreasonable for overcast clouds, but we don't know the altitudes at which that effect kicks in which limits our ability to work with it. I'm optimistic that future X-Plane updates will enable us to do even cooler stuff with overcast though.

On the low overcast setting you will just see a gray plane for the stratus cloud above you, which is what you are seeing. That one puffy cloud in the distance is probably a distant thunderstorm. For volumetric overcast clouds you will need to use the medium or high settings.

Still just speculation, but a good case that an electrical fire would cause a responsible pilot to do exactly what this flight apparently did - without involving conspiracies, aliens, meteors, etc. http://www.wired.com/autopia/2014/03/mh370-electrical-fire/ Interesting news from the Maldives there Michael - I just don't know when to believe the media on this anymore.

Yes please.

Love it! Thank you Wycliffe.

strider, are those two screenshots taken over the same location and same exact time and date? I just double checked our settings for this effect and they are identical between SMP 1.1 and 1.3. Your latitude / longitude, the phase and position of the moon, and the amount of twilight all play a role in cloud lighting just after sunset, and even minor changes in location or time can make a big difference. That's not to say there isn't further room for improvement. The real issue here is that we basically need to reverse-engineer X-Plane's lighting and ephemeris model in order to try and light our clouds consistently with X-Plane's sky. Sometimes X-Plane's model and ours differ by a few minutes, and that leads to small windows of mismatched lighting.

Creating cloud shadows from a plugin just isn't technically foreseeable now or in the near future from what we've been told. There are lots of other new features we're looking at however...