sundog

Not sure I understand the issue here - the METAR calls for broken clouds at 1100, and you're just below them at 1000 unless I'm missing something. Can you provide more detail on what I'm looking at here, and if you tried any of the troubleshooting steps I suggested earlier?

I'd really need to have your entire METAR.rwx that was in use during this flight to say what's going on. From your log, I can tell that initially RWC received a totally empty Metar.rwx file from ASXP, which would result in no 3D clouds being displayed at all and only certain visibility effects showing up. That might explain what you're seeing. Did you try my suggestion of changing SMP's settings a little bit to force it to reload the weather? It might also be a discrepancy in how we define the "bottom" of a cloud layer; the first screenshot might be what I'd expect to see as you're just entering a cloud layer but you're not deep enough inside it yet to completely obscure your visibility. Hard to say exactly what's going on without that METAR file though.

It's not a known issue, assuming you have RWC set to "external injector" mode and "never change visible weather" is not on (which is what you want to ensure the scene matches what ASXP is sending in.) You might also want to try going into the SkyMaxx Pro configuration, change some setting slightly (like the cloud draw area,) and see if that causes new clouds to appear where you expect them to be. There can be a race condition where where ASXP sends in its weather data after SMP has already constructed the scene, and that's a way to force SMP to recreate everything. If you're still seeing this problem after trying that, we'd need to see any METAR-related files in your X-Plane directory, your log.txt, and the location your plane was at. I think ASXP deletes its METAR files when it shuts down though, so collecting the data we need is unfortunately tricky. It's possible you're seeing the effect of "scud", or the irregularities at the top and bottom of a cloud layer. Real clouds are not perfectly flat slabs; there is some distance between the bottoms of the bottom-most puffs that make up the cloud, and the point where you are 100% enveloped by it. 2,000 feet seems a bit much for that, though. There are also a few cases where we will override where an external injector says clouds should be because the data is not physically plausible. It could be one of those.

Not yet! It's only been 4 months since the last update, and my "day job" has been getting most of my attention during that time. We have a couple of minor fixes teed up so far, regarding cloud coverage and precipitation.

It sounds to me like memory fragmentation on your video card. You're probably running out of VRAM over time, which leads to this sort of behavior. The best solution is to turn down your "cloud area covered" setting, or other graphics settings within X-Plane, to ensure you stay within the bounds of your video card's memory.

Looks nice; thanks for posting!

Your metar.rwx file is completely empty; there is no weather information in it for SMP/RWC to work with. I think there might be some sort of setup issue with ASXP going on, or perhaps it emptied out the metar.rwx file before you copied it. Try copying the metar.rwx file during your flight for us, and we'll also need to know where you were flying. Might be a good idea to check that you can see weather with ASXP when SMP and RWC are disabled. Get ASXP working first, then introduce SMP/RWC.

Make sure "never change visible weather" is off in the RWC settings, and worst case you can try changing some setting inside of SMP, like "cloud area covered", a tiny bit just to force it to reload the clouds. It might be a timing issue where ASXP sent its data after SMP already set up the scene. If you're still not seeing the weather you expect, we'll need to know more details - where you are flying, and your log.txt and any metar files that are in your X-Plane folder at the time.

The current version bases its automatic season selection on rules based on latitude, longitude, date, and temperature. Since altitude is highly variable within a scene, and we can only load one "season" at a time, we don't use it directly - but there should be some correlation between altitude and temperature. TerraMaxx works by replacing X-Plane's built-in land textures, so if X-Plane has classified a mountain peak as being in a permanent snowfield, that will still be honored. We work with X-Plane's terrain classification instead of replacing it. We wouldn't represent winter in the jungle the same way as winter in the Alps, because the jungle would be at too low a latitude and too high a temperature for our "deep winter" season. Of course, TerraMaxx allows you to manually force whatever season you want, and we won't stop you if you choose to do that.

He tweaked some of the cloud puff textures in SkyMaxx Pro 4.6. We made further improvements to them ourselves between then and the current version (4.8).

@xZone you might want to refer to the SkyMaxx Pro manual; it details a ton of things you can customize to get the look you want. I'm attaching it for your convenience. The "fast" option is under Plugins / SKyMaxx Pro / Select Cumulus Textures. SMP_Doc.pdf

Our clouds are 3D objects that you can fly around and through. I think you're probably referencing the "volumetric clouds" that one of our competitors talks about a lot. Our clouds are volumetric too, they just use a different, more efficient rendering technique that allows us to include more detail when you're close to the cloud. SkyMaxx Pro has actually has the same "volumetric" technique being used by our competitor (GPU ray-casting) under the hood, and it's been there since version 1. But we haven't exposed it to users because we aren't satisfied with its look or performance. It's our view that today's GPU's just aren't up to the task yet, but we'll enable them as soon as they are. If you just don't want the cumulus clouds to look like they are made of textures, try selecting the "fast" option for cumulus clouds in the SkyMaxx Pro UI. This results in a more "volumetric" look.

I'm still pretty sure you're running out of rain particles. Our next release will fix that.

Well, I suspect you hit some sort of edge case where FSGRW may have been sending in even heavier precipitation than X-Plane's "severe" setting. But I'm glad it's cleared up for you, whatever the cause. You do need RWC if you want to use SkyMaxx Pro with real-world weather with good results. FSGRW just changes the source of the weather data from X-Plane itself to FSGRW. RWC serves as the "glue" between real world weather - wherever it's coming from - and SkyMaxx Pro.

OK, I think I see what might be happening. Basically we are running out of rain particles because you've set the precipitation intensity all the way up. Obviously that shouldn't happen; the reason is that we lowered the max number of rain particles for SMP in the name of performance, and this was an unintended side effect. We'll fix it for our next release, but for now set our precipitation mode to "default" if you'll be flying in extreme conditions like this. Thanks for reporting this.

That's odd; it worked the last time I checked. I'll have to look into it. Meanwhile, set the rain setting to "default" and it should behave as you expect.

Hm. I'm not the author of Gizmo and don't really have a way to debug this, so I'll have to tag @Cameron and @Ben Russell to take a look at this one. If you haven't already filed a support ticket with X-Aviation on this, please do so.

Might want to post this on the developer's support forum: https://www.tapatalk.com/groups/fsgrw/index.php Offhand though, it looks like there is a space after "data" in the path it's displaying. That seems odd, and might explain why it can't find where your configuration file is. I don't remember if you need to enter the path to the X-Plane data directory as part of setting up FSGRW, but if so, I'd remove the extra space after that path.

I see you also changed the setting for "Sync precipitation with Real Weather Connector." This has the effect of only drawing rain when you are directly underneath an individual rain cloud. So, it may be that your plane is underneath a gap in the clouds, and that's the setting that actually affected things.

Feedback noted folks.

Real Weather Connector "connects" SkyMaxxPro to some source of localized METAR data, allowing it to represent localized weather, cloud fronts you can fly into and out of, etc. RWC can use X-Plane's built-in real world weather system for that purpose, and it will work fine. Or, you can use a third party weather system replacement, such as FSGRW or ASXP instead, and configure RWC to use it as its weather source. In short - for accurate real-world weather representation with localized effects, you need RWC with SMP. If you also want to replace X-Plane's built in weather system with ASXP, then RWC supports that as well. When setting weather conditions manually, you are affecting all of the weather everywhere at once. Which is why transitioning between different settings in manual mode looks weird - it has to change all of the clouds around you immediately (which doesn't happen in nature), not just new weather conditions that have arisen as you fly into them. Hope that makes sense.

To my knowledge older versions are not available. But generally speaking, we add features more so than removing them. It's probably possible to recreate whatever you saw with 4.5 by configuring 4.8. The differences you see probably have more to do with configuration settings than with the version. I'd recommend reading through the SMP manual if you haven't already, so you can get a sense of which config settings will produce the effects you want. Using the Real Weather Connector add-on also makes a big difference in how real-world weather is depicted with SMP. If the videos you saw were using RWC and you don't have that, it would also explain some differences.

I cracked open the code just to check for myself what exactly is going on. If you're not using RWC, X-Plane sends in a coverage value for the cloud layer that ranges from 1-6. We convert that to a percentage and honor it as best we can. But sometimes, X-Plane doesn't send a coverage value, and in that case we default to 40% for "scattered" cloud layers, which I think is presented as "few" in the X-Plane UI. I don't know what drives that coverage value through the API in X-Plane, but the unknown details of that is probably what explains the difference in what you're both seeing. My guess is that FlyAgi's setup is sending in a specific coverage value for the layer to us for some reason, while Prosco's is not. So... I'm going to lower our internal fallback value of 40% to 30%, as I do think that's more appropriate for "few". I don't think this warrants a new release of SMP in itself, but it will go out with our next update.

If it's happening with SMP disabled, then I don't think it's us. More likely it's an X-Plane issue, or something related to your other add-ons. I see in your log something about a "WhiteoutInClouds" script and a "FourSeasons" script, both of which might be trying to redraw the terrain and causing this somehow. It's possible the issue has to do with your custom scenery as well. Probably best to just disable everything as a test to see if that fixes it. If so, start enabling things until you identify the culprit.

If people didn't turn up every slider they see and then complain about performance to everyone they can, I'd agree! A "cloud density" slider would affect performance a lot, which is why I'm hesitating to add one.