sundog

The config file is not intended to be modified by end users; these settings interact with each other in complex ways, and often have side effects that only occur in specific conditions. No documentation is available, or even exists, for these settings. You tracked down my email address to ask these same questions, so I'll leave our further conversations on the matter in our private discussion there.

The problem is where do you define the "base level" of the clouds? Clouds are wispy; does the "base" start at the lowest point where any wisps might extend to, or does the "base" start where the cloud is entirely filled with water vapor? That's the only uncertainty we're talking about here. I would also argue that in real life, the clouds in a layer are not all at the exact same base altitude. They vary a bit. You can specify an altitude at a given point, say over an airfield, but the larger layer of clouds isn't a perfect slab. Basically we're trying to provide an even more realistic experience than what the METAR reports can reflect, while still respecting the data in the METAR.

Yes, it will be a free update.

While looking into some reported issues with cloud altitudes being off in certain situations, I also stumbled across a bug that might explain what you were seeing there. I've fixed it for SkyMaxx Pro 4.8 which is in the works.

OK, so I've been digging into our logic of how cloud altitudes are determined all morning here. While we're not interpreting the tops as bottoms or vice versa, there are a few special cases that can result in the adjustment for "scud" or the size of the bottom row of puffs to be larger than it probably should be. I think you're hitting one of these cases. We'll refine how this works in SMP version 4.8, which we're working on now. I'm also going to remove those log messages as they just generate confusion; we still need to adjust our internal idea of where clouds are to match X-Plane's definitions, to match X-Plane's coordinate system, and to avoid various anomalies, and so the altitudes we use internally will always be different from what you set in the X-Plane UI. That doesn't mean they are inaccurate, however. These issues are all specific to when you're running Real Weather Connector in "never" mode. Hopefully a new Gizmo release will come out shortly to fix the weather download issue that prevents you from running in "always" mode. ("automatic" and "external injector" modes both should work fine.)

I guess I don't understand the data you're showing me. What is that "nube B2" display in the upper right corner? Where does that come from? I don't think I've ever seen that. In the first picture, I see that we created a cloud layer at 1487 meters, and then another one at 2432 meters (based on how SMP positions clouds). This is pretty close to the "nube B1" and "nube B2" values you're showing there. I'd encourage you to actually fly up there and see where the clouds really are; the data we write in the log is only for internal debugging purposes, and is not intended to give you a complete picture of where all of the clouds in SMP are.

In this case, it looks like things are actually working properly. In your final image, I see that you have a dataref placing a cloud layer at 1791 MSL, and our log shows us placing one at 1591 MSL. The 200 meter discrepancy in what is reported is intentional; it's to account for the size of the individual puffs that make up our clouds, and ensure that the base altitude where you're truly "inside" the cloud and not just within its edges matches up. Basically there is a 200 meter difference (this number can vary based on your settings) in how SMP and X-Plane define cloud layer altitudes, and we're just correcting for that. I think something else was going on in your original image, though. This effect wouldn't account for a difference in thousands of feet from what you expected. Also I'm curious why you're running RWC in "never" mode... you're basically disabling it entirely.

Your log shows that SkyMaxx Pro was explicitly told to create a cloud layer at around 6500 feet. So, the error seems to be in wherever that data came from. What are your settings on Real Weather Connector, and do you have X-Plane's weather settings configured to use real weather? It kind of looks like something is misconfigured there, or the METAR data being used by X-Plane is different from the METAR data you're looking at.

Do you still have your log.txt available from this flight? We'd really need to see that to understand the details of what's going on here.

OK - be sure to capture your log.txt as well if you encounter it again, as it well tell us what cloud type and altitude SMP was using. That might be important info for us.

Well, it's not true that "it doesn't do anything" - there's just a bug that affects overcast clouds in certain cases under X-Plane 10. But I understand that it's a show-stopper for how you're using it. I can't make any promises as to when this fix will be released. It needs to be tested, packaged up, and distributed by X-Aviation, all of which is outside of our control. We're also hoping to squeeze a few new features in with it over the next week before we take it to that stage.

Just to close this out - I've spent the morning testing things in XP10. It turns out that some changes we made for VR support in SkyMaxx Pro 4.7 had the side effect of breaking the in-cloud fog effects in X-Plane 10, if you selected "solid stratiform" or "broken stratiform" for the overcast representation. I've fixed that for our next release. I think that's what you were seeing. Separately, there were some adjustments happening to "overcast cumulus" cloud layer types if you had the cloud/terrain blending control set higher than zero that may have been affecting you when using other clouds types. I've also fixed that.

Some of those shots look pretty nice I agree that the bug I found likely isn't the issue you're seeing. There is probably an edge case where clouds of a specific type at a specific AGL altitude don't blend as well as they should with the ground. If you do encounter it again, please see if adjusting the cloud/terrain blend setting makes any difference at all in its appearance. If you set it to zero, does it look even worse? If so, we may just have to increase how far up that slider goes.

OK... so I think what's happening is that when you were at the ground, you did see the bottom of the cloud layer at 800 feet. When you flew through it, that was the flash you reported. So at this point, you're inside the cloud - and I think the issue is that the ground isn't fogged out as it should be, due to you being inside the cloud. I'm not really sure why that's happening; I suspect it must be some bug specific to X-Plane 10, as I'm pretty sure that works in X-Plane 11. We'll investigate it as we prepare our next release, but to answer your immediate question, no I don't have a fix for that. I'd suggest experimenting with our other options for overcast representation in the meantime - or consider upgrading to X-Plane 11, which is better supported at this point.

No, we don't do live support with TeamViewer. According to the log - which I know you don't care about, but it tells us exactly what SMP is doing under the hood - the stratus layer was positioned at 84.3 meters AGL. It looks like you're flying out of KRME, which is at an elevation of 154 meters. If I add those together I get 238 meters, which is 780 feet. Pretty close, considering local variations in elevation and such. The "scud" we simulate is within +- 150 meters of the cloud. None of that would explain you seeing a stratus layer with a bottom at 5,000 feet. According to the log, that just isn't happening. It might be helpful to see a screenshot showing this cloud layer you're seeing. It's possible it's some effect happening outside of SMP or something.

Bear in mind we model "scud", which is random variation in the tops and bottoms of cloud layers. Clouds are not perfectly flat in reality, and we try to reflect that. Your log indicates that we positioned a stratus cloud layer with a base altitude of 84.3 meters, which is 276 feet. I'm guessing this is some sort of AGL / MSL confusion.

I'll assume your setting is "HD Cloud Puffs" and you're using SkyMaxx Pro 4.7.1 (if it's really 1.4.7, that's the problem!) The current version of SkyMaxx Pro is 4.7.3, by the way. If you just obtained SkyMaxx Pro, I'm not sure how you ended up with 4.7.1. If you can reproduce this, it would be really helpful to get a copy of your log.txt file after finishing the flight. There are certain edge cases where SMP will force the altitude of a cloud layer to something different in order to avoid some sort of visual anomaly, and you may have hit one of those. You might also experiment with other overcast settings; "solid stratiform" might give you something closer to what you expect. As for seeing runway lights through clouds, I believe that's an X-Plane bug that was fixed in X-Plane 11.

We treat thunderheads (cumulonimbus) separately from towering cumulus, and have different representations for each. I think it's the towering cumulus that tend to be tall and skinny in our representation, and those are the ones that we're going to suppress above 40 degrees North (unless an external injector such as FSGRW explicitly tells us to use them.) When SMP creates a thunderstorm, it uses a mix of these two cloud types. Cumulonimbus have the broader / darker appearance you're referring to, and those will continue to appear at all latitudes if a thunderstorm is present.

It looks to me as though you're seeing the intersection of cloud puffs with the ground. Since each puff is really a 2D picture facing you (for the particular cloud type you're showing in your picture), it creates a straight line where it intersects with the ground. The "blend softness" control is intended to fade out the clouds as they approach the terrain, so you don't see that. I just scoured our code trying to find a case where this wouldn't work as it should, and I did find one. If you're in a scene that only has ground fog present and no cumulus clouds, and you are using RWC, then it looks like this effect might not be triggered as it should. It's a bit of an edge case that should only happen under these very specific conditions. I've fixed that for our next release, but in the meantime it might help to increase your cloud area covered setting if you can, which would increase the likelihood of other clouds being present in the scene.

Yes, I think they are mostly a tropical or sub-tropical thing. They're not unusual at all here in central Florida, but we get enough complaints from people in more northern latitudes that we probably should suppress them if you're flying above 40 degrees latitude or so.

I think increasing the "cloud / terrain blend softness" setting in SMP should help with that. I haven't heard any update on the RWC / Gizmo issue. Meanwhile, you might want to consider updating to the latest version of X-Plane 11, which will allow you to use RWC in "automatic" mode and regain the more detailed cloud representations RWC can give you.

Honestly at a loss - the only other thing I'd try is reducing your graphics settings to disable HDR for example. Your video memory does look pretty tight based on what's shown in your SMP settings. Beyond that, it might be time for a clean re-install of X-Plane and the add-ons you care the most about.

Flickering? Can't say I've seen other reports of that. If it's the whole sky, you might try changing the sky in SMP from Hosek-Wilkie to default or some other setting of your preference. Could be there is something in our sky shaders that your OpenGL drivers on your system doesn't like for some reason. I'd also try reducing the "cloud area covered" setting to see if it's just a matter of running low on VRAM due to too many clouds being present in the scene. The only Mac-specific errors in SMP I'm aware of involve very rare hardware failures of GPU's on certain models.

Ah... looking at the code, we do base the AGL altitude used for the effect on the plane's position and not the camera's. Getting the camera's AGL is an expensive thing to do performance-wise (you have to convert the camera coordinates to world coordinates, do a terrain probe to figure out where the ground is, and subtract the two), so I think that's a compromise I made intentionally. I'll try and find some clever way around it though.

I haven't heard of any similar reports from VR users. It's possible that there was something unusual in the METAR at the time you encountered this that caused an issue; it might work if you try it again with new weather conditions. I'd also try deleting the settings.dat file from your plugins/SilverLining directory to revert to standard settings (I think you did that, but just making sure). If you had RWC in "always" mode, that's known to not work until a Gizmo update comes out to address the move to HTTPS by NOAA for its weather data. Deleting the settings file will revert it to "automatic" mode which might clear it up. Deleting any METAR files in your X-Plane directory might also be a good idea, in case the issue is a bad METAR file. As you're using FSGRW, that would include the "fsgrwsmp.rwx" file in addition to METAR.rwx (make sure you put RWC back in FSGRW mode when you get it running again) I'm also not aware of any conflicts with X-Vision or librain; SMP only uses its own textures and does not depend on X-Plane's, so if some other plugin is messing around with X-Plane's own resources, we shouldn't be affected. That said it's always a good idea to strip out all plugins and addons when beginning your troubleshooting, as they can interact in complex ways. You said this started happening recently; was it associated with your initial installation of SMP? Did any other software change or was added when the trouble began?