sundog

Denco - have you tried the new SMP 3.3 release? Your issue sounds like you just have more add-ons installed and/or high rendering settings or resolution than even your very beefy system can handle, but SMP 3.3 uses fewer resources which may help.

0:00:00.322 E/NET: Download failed with http error: 404 for URL http://weather.noaa.gov/pub/data/observations/metar/cycles/22Z.TXT That error message is actually X-Plane itself being unable to download its own METAR data; it's not coming from SMP or RWC. X-Plane's own METAR download was broken by the same issue that affected RWC. You need to install X-Plane 10.50rc3 or newer in order to fix that.

SkyMaxx Pro doesn't actually set visibility on your terrain; all it does is draw clouds. X-Plane itself is responsible for visibility. Did you install the new X-Plane 10.50rc3 update? If not, X-Plane is unable to download METAR data of its own to work with, and that's probably the issue.

I'm confused about what you're seeing; if you could post some more specifics when you're at your computer it would be helpful. There is no "WX" folder. X-Plane downloads METAR.rwx into the directory you installed X-Plane into, alongside the X-Plane application. If you set Real Weather Connnector to "always", then it downloads MAXX_METAR.rwx into that same directory. And that's where Real Weather Connector looks for those files. Perhaps you're seeing METAR data that's being downloaded by some other add-on? What you might be missing is the X-Plane 10.50rc3 update, which fixes X-Plane's own download of METAR data.

Argh! I really thought SMP 3.3 would help with this. This issue is basically personal now. So I spent the whole day determined to track it down. We're dealing with an incoming tropical storm here in Florida right now, which has the benefit of providing lots of nasty weather for me to fly in and test with. Sure enough, at last I think I can reproduce what you're seeing - performance that suddenly tanks and is mysteriously fixed by adjusting the SMP configuration, however slightly. The issue seems to have to do with cloud backdrops - the ring of 2D textures that represents distant clouds near the horizon. SMP is getting into a state where it thinks these backdrops need to be recomputed every frame, and that's the problem. It requires a rather odd set of circumstances, but if you fly long enough with a large enough cloud draw area, you can get into this state. I believe I've fixed the underlying bug, and this fix will go out with our next update. While I was tracking this down, I also found that due to duplicate entries in the METAR data we're getting from NOAA/NWS, we were creating way more thunderstorms than we should. I've also fixed that, which will help performance further in stormy weather. Thanks for working with us on this, guys. I'm hopeful the next update will finally fix this. (Before you ask, no I don't know when that will be yet!)

Please post your log.txt so we can see what kind of system you're on. First thing I would do is make sure your video drivers are up to date, in any case.

Yes, that's exactly what this update is for. It gets METAR information in "always" mode from a different server, since NOAA shut down the one we (and X-Plane) had been using before. NOAA/NWS isn't going to stop providing METAR data, but they reserve the right to change the way in which they provide it, which is what happened.

I've heard that the NOAA URL fix will actually be distributed separately as part of an RWC update. Stay tuned. Meanwhile, X-Plane's 10.50rc3 release fixes their own URL, so RWC in "automatic" mode should start working again if you have 10.50rc3.

Cirrus clouds move with the camera by design (because they are too complex to tile smoothly, and large enough that their motion isn't usually that apparent.) Cumulus and stratus clouds however should move realistically relative to your motion. So, if you're seeing this with cirrus clouds, it's not a bug. But if it's with other clouds, I'd like to see a video of it.

OK, that doesn't sound so scary then. Actually I'd welcome the XML format, as it explicitly breaks out the cloud cover information we want instead of making us parse out the entire METAR string - as long as we have enough prior notice!

Is that January 2017 deadline documented or announced anywhere that you know of? It sounds a little ambiguous to whether the current text format we expect is going away or not.

jcomm, where did you get that info? I want to be sure we're on top of the details.

They'll be one and the same. We had 3.3 ready to go before the NWS/NOAA server issue arose.

Peter, be sure to try SkyMaxx Pro 3.3 once it's released as well. I think it might help people who are having this issue. No ETA on its release yet, but keep an eye on your email for an announcement.

> Is it possible to add an option to override whatever XP is telling you? Well, what you've got me thinking is whether we should always treat the visibility setting as a lower bound for the cloud visibility. That is, retrieve both values from X-Plane and use whichever one is higher. I think that's a good idea for SMP 4. > Also I assume you are doing some type of interpolation between METARs? SkyMaxx Pro doesn't do anything with METAR data directly, but if you also purchased Real Weather Connector, then we do. Cloud systems do tend to have distinct boundaries, so I lean away from blending the reports together and try to preserve those frontal boundaries. If you prefer your weather to be more uniform, you might consider using FSGRW together with SMP/RWC - we'll honor the weather data it outputs, which is more blended.

We base our cloud visibility on the sim/private/stats/skyc/fog/far_fog_cld dataref provided by X-Plane. (If it's not available, then we fall back to what the visibility slider says.) I don't know what algorithm Laminar uses for this value, but the reason we use it is because it gives us higher visibility distances at higher altitudes - even higher than what the visibility slider may indicate. Basically it tries to account for the fact that visibility improves with altitude, generally speaking. Beyond that, cloud draw distance is also limited by the size of the cloud draw area. At 40,000 square km, that works out to 100km distant at most. We will be raising this limit a bit in the upcoming SMP 3.3 update, though.

Yes, we're working on a patch. There's really no way to patch it yourself - just wait for us to release it please. Meanwhile keep RWC on "automatic" mode for now.

Egad, I thought this was just a temporary server problem - but NOAA/NWS really did shut down their METAR service for good. I've noticed X-Plane's built-in real weather system isn't successfully downloading updates either (at least for me,) so this isn't just affecting RWC. I'm sure there are plenty of real-world systems that depend on this data as well, which is a little bit terrifying. We're working on it... for now, you're best off keeping RWC in "automatic" mode so it can at least use the last data X-Plane itself successfully downloaded.

Try flying to a higher altitude, above the clouds. I think X-Plane is just limiting visibility due to the low altitude in that scene. You can see the clouds are getting faded off a bit there, which usually mean they are constrained by visibility instead of any limits that we are setting. I know your visibility slider is all the way up, but the way X-Plane computes cloud visibility distance is a bit more complex.

I wish I had a better answer for you, but this is a limitation of X-Plane's SDK that we can't do anything about yet. We have to pick a draw order between our clouds and things like rotor blades, and either choice results in issues like this - just different issues. Helicopter models that don't use transparency in the rotor blades won't have this issue, although I believe most do.

I'm pretty sure the community would be at my door with torches and pitchforks if god rays were active all the time - the FPS hit is noticeable. Introducing a config switch for that in a future version might not be a bad idea, though.

"God rays" are only computed when the sun is in view. So when you rotate the camera like this to put the sun out of view, the god rays go away with the sun. While it's in view, the intensity of the rays depend on the position of the clouds relative to the sun.

Jeff, that last log you sent crashed due to unexpected METAR data. The situation only lasted for an hour, so you should be OK now. We do have a code fix awaiting distribution for the underlying issue.

That means NOAA's servers are down. Nothing we can do about that! Delete the file, and try again in a bit.

It's simply that our interpolation of METAR data across various stations doesn't necessarily match up with X-Plane's default weather system. As a result, what you see in X-Plane's weather map may be slightly different than what SMP/RWC represents. And due to time delays in the data, neither ours nor X-Plane's weather representation necessarily matches what's out the window exactly. In this example, you're close to the edge of a cloud bank, and we apparently have you beyond that edge while X-Plane's weather map does not. Meanwhile, wind had probably moved the clouds over the location in the real world as there is around a one hour delay in weather data. We've talked to Laminar about having tighter integration between X-Plane's weather map and what our weather data is telling us in future releases, and have already written some code to support this once it's possible.