sundog

Tagging @Cameron

Ah, I see. For cumulus clouds (ie, "broken") we only pay attention to the base altitude of the layer, and allow our physical model of cloud growth to take care of the thickness of it. But we do model in some variation to the bases of the clouds as well - and the clouds themselves vary quite a bit in size and shape. So it's not really possible to position a cumulus cloud layer at a precise altitude and still have it look realistic. It's just the trade-offs we chose to make there. However I do suspect this may be worse with ASXP, because I believe they limit themselves to 3 layers. So if they really want multiple cumulus layers close together at similar altitudes, they don't have a way to convey that information to us. FSGRW, and RWC used alone with X-Plane's default weather system, can both represent unlimited numbers of layers and so this is less of an issue in those scenarios. Be forewarned you're likely to encounter a lot of tribalism around weather add-ons on the org. But if you learn anything useful there please let me know. I stay off the org for my own mental health!

Well, this is getting weird. I loaded up your metar.rwx, went to KVUO, and moved up - and the two layers are distinctly visible to me. They look pretty darn good if I may say so, even. Might be time to have a look at your log.txt and SMP and RWC settings.

Sounds like the sort of thing where you'll need to open a support ticket at http://www.x-aviation.com/catalog/contact_us.php - it may have to do with the specifics of your system and license.

Are you running with RWC in "always" mode perhaps? It would help to know your settings and how you're using real-world weather. A log.txt might help as well. The only known issue, however, is if you are running RWC in "always" mode - and we've already handed off a fix for that to X-Aviation.

Well that's odd - your METAR.rwx file is actually empty of any data at all! I think maybe ASXP wiped it out before you were able to grab a copy of it. However, I just now tried KPDX with ASXP and fortunately similar conditions still existed there. I think I might know what's going on. Do you have your overcast representation in SMP set to solid or broken procedural? If so, cumulus (broken) cloud layers that intersect the overcast layer are suppressed in SMP, because having these two different representations of cloud types overlapping each other looks weird. The issue isn't that the broken layer is low, it's that it's too close to the overcast layer. If you change your overcast representation to something else, like "Soft HD", you should see both layers appear. Although, they are close enough that they can be difficult to distinguish - but they are there. Our clouds tend to be larger and taller than default clouds, so visualizing distinct layers that are close together can be tricky at times. Anyhow, I hope you just had overcast set to a procedural setting and that's all it is.

If you can send me the metar.rwx file that's in place when you encounter this, and the location you were flying at, that should allow me to figure out what's going on.

Yes, it would work the same way in 4.8. I like the idea of a "force weather reload" button somewhere. I'll make a note of that for 4.9.

It would be ideal if we could download weather asynchronously ourselves instead of relying on Gizmo. The issues are technical; SkyMaxx Pro and Real Weather Connector are both written entirely in C++, and making them multi-threaded in a cross-platform way is a pretty risky and difficult thing to do. If we hear that updating Gizmo for this issue just isn't going to happen, then I guess we'll have to bite the bullet - but that's not what we've been told thusfar. For now however we have a stopgap solution in place, and although it results in a performance stutter, it's only once per hour (once 4.8.1 goes out - it's been handed off to X-Aviation already.) And for anyone reading this out of context, bear in mind this whole issue only applies to the small subset of users who must run Real Weather Connector in "Always" mode.

Glad you're enjoying it! FSGRW knows that SkyMaxx Pro and Real Weather Connector can represent basically an unlimited number of cloud layers at distinct locations and altitudes, and I do think they take advantage of that.

Argh, sorry to confuse everyone on this. The downloading I'm referring to is for the raw METAR data from NOAA. Normally, X-Plane 11's real world weather system downloads this on its own, and some weather add-ons inject their own METAR data files in place of X-Plane's. But, there are edge cases, for example XP10 or people who want to use weather add-ons that don't use METAR-based weather data and disable X-Plane 11's real world weather system. For these special situations, Real Weather Connector offers an option to download its own METAR data from NOAA and read from it, in exactly the same way we'd read the METAR data normally downloaded by XP11. In that edge case, which is what "always" mode in RWC does, what's supposed to happen is we send a request to Gizmo to download that data in the background, and notify us when it's ready so we can read it. This way, the weather download happens without causing a big pause in framerate. The problem is that NOAA changed their weather download server to use HTTPS instead of HTTP, which means Gizmo cannot download that data until it is updated to handle the HTTPS protocol. Since I don't know when that will happen, we implemented a "plan B" in SMP 4.8 that will go get that data itself if Gizmo fails to get it - but this comes at the cost of a performance stutter. This all ONLY happens in RWC's "always" mode. There's no point in using this instead of XP11's weather data though, because it's the same exact weather data. It's just there to deal with these somewhat unusual configurations some customers have. And we still want Gizmo to be altered, because it offers a way to download this data without causing a performance stutter in the process.

Did you mean you tested with Ortho and HD mesh disabled, and it still crashed? My point is you need to reduce your overall memory usage somehow, and that should help. 6.4GB actually doesn't leave much left over; problems will start to arise before you actually hit 8GB. It is true that the larger the cloud draw area setting you have in SMP, the more memory it will consume as well.

I'm afraid I don't really know how XPGFS in particular works. "Always" mode is intended for weather add-ons that update weather via X-Plane datarefs, which are limited to 3 layers of uniform weather surrounding the plane. "Automatic" mode in this case would work, but in order to get localized, complex, many-layered weather with RWC and SMP, you'd want to use "Always" mode to tell us to always download our own, detailed real-world data instead of depending on the add-on or X-Plane's default weather to do so. If you are using XP11 and its built-in real world weather system, yes "automatic" would be the right setting. If the Gizmo issue is fixed, you won't need to change any settings once you've found the one appropriate for your setup. What we're doing is checking to see if Gizmo failed, and if so, we do it ourselves instead. From your standpoint you shouldn't care which plugin ended up doing it.

Just to clarify - in our forthcoming 4.8.1 release I'm issuing a fix so that new weather is only downloaded once per hour when "always" mode is on, and Gizmo is not getting it for us successfully. This should at least reduce the stutters to once per hour while we wait for that fix, if you must run with "always" enabled.

I haven't run any performance test between FSGRW and ASXP, so I'll have to defer to others to comment on that. FSGRW does have a tighter intergation with RWC and SMP however. They also communicate via the METAR data, but they include extra information for us in their METAR that we know how to interpret in order to display specific cloud types that aren't part of X-Plane's default choices.

You'll have to open a ticket with X-Aviation to see if the 4.7.3 installer is still availble. But if you are also using Real Weather Connector and have it set to "Always" mode, I think I know what might be causing this - and it should behave better in our forthcoming 4.8.1 release. Using any other mode than "always" would also clear it up. If that doesn't describe your setup, you're probably running out of memory and freezing while it all swaps. Removing custom scenery, add-ons, or reducing settings in X-Plane or SMP can help.

I reached the same conclusion. The option will be back in our 4.8.1 release (coming soon!)

OK, I did find a bug that could result in your cloud choices getting reverted after using the main SMP configuration screen. Thanks for reporting that. We'll put together a 4.8.1 bug-fix release soon. At a minimum it will fix this, and bring back the missing "force cirrus" option in the UI.

The only thing we know of that can cause SkyMaxx Pro to crash is running out of memory (or something corrupting the memory we use.) So if SkyMaxx Pro is crashing, that's my primary suspect. HD mesh consumes a LOT of memory, and you could be running low even on a 32GB system.

Based on this info in this second log, the issue isn't FSGRW or METAR related after all. My guess is that you're running out of memory. Can you try temporarily removing HD mesh and other custom scenery to see if that helps?

We did test SMP 4.8 on an X-Plane 10 build and it did load up successfully. To answer your question, X-Aviation is responsible for the installer, not us. We don't even have the installer here. Please be patient - X-Aviation support will have to help you through this.

SMP 4.8 just contains a backup means to download weather data if Gizmo fails to download it for us, when you have RWC in "always" mode. It does create a stutter I'm afraid, since we aren't using an external plugin (Gizmo) to download it in the background. We do still need HTTPS support in Gizmo to get "always" mode working the way it used to. But that's in X-Aviation's hands. If you are using RWC in any mode other than "Always" however, things should be working as they always have.

The short answer is I think you won't have any trouble activating two copies on the same PC, but I don't know the details of the X-Aviation licensing system. I'll tag @Cameron (who does) to confirm.

It looks like perhaps something unexpected was in your FSGRW weather data. If you still have the fsgrwsmp.rwx file that was in place when the crash occurred, I'll need it as well in order to figure out what happened. This sort of thing usually clears itself up once new weather data is downloaded, but we definitely want to figure out what caused this if we can.

Thanks for the report! I hate to be a pest, but do you recall the specific steps you took? I just tried changing the cumulus representation, closing that window, opening "configure clouds," changing the draw area, and then closing that window and re-opening the cumulus one. It looked like the new setting was preserved. I don't doubt you found a bug, but I'm having trouble figuring out the sequence of events that might lead to a problem.