This discussion has come up before, but I noticed something I have not seen before. On a flight today KTPA to KMEM at 36000 feet, with ASE build 586 I ran into CB's that were at and above my flight level. I thought in previous post there were limitations of the FSX weather engine that prevented CB's from being depicted above FL240.Did the new build of ASE (build 586), overcome this limitation? The clouds were depicted perfect for the enroute weather. I don't recall any mention from HiFI Simulations that CB's were now depicted, did I miss this? In any case it made my flight very real.Now if HiFi Simulations can fix the DWC's inability to properly report destination surface weather via Radar Contact, all will be good in FSX world. BTW, my haze layer is completely gone and views of the ground at altitude is just great.BobDTW

That would be WONDERFUL!!! to see towering CBs enroute. This would make sense for asking deviation due to weather... otherwise flying with ASE in summer thundery weather is pointless :(

Hi All,No, nothing has changed in the cloud layer performance.No, nothing is going to change or be fixed with DWC in the near future, because DWC is doing what is set out to do. Please ask the RC folks to read the data directly from ASE instead of from FSX for RC5 and this would be fixed!

Jim, something has changed, maybe snapshot, but I got CB's again today above my flight level of 350. As far as the "RC Folks", that would be me and the team and we will discuss it.Bob

Hi,A snapsot is just textures. IDK maybe something got programmed differently and nobody realizes it at our end.Each AS version has a file that does contain the current data and has the same format from version to version. If RC5 could read that file, then things would be good. This is the same way that FS Build has been able to access winds data for all these years.

As I said in another post, the RC team will have a discussion, and boy did we ever. Jim you will be getting a note along with Damian about some work that Pete Dawson has done with FSUIPC that could fix this issue quickly, without ASE or RC having to do anything. The technical part of this is what Pete will be contacting HiFI about.What ever is giving me the great depictions in ASE, I am not complaining.Bob

Hi Bob,Thank you for taking the lead on this and working with your team so closely.

that would ROCK my flights!!! forever :)

Jim this is just part of a discussion we had over the weekend, that I thought you my find enlightening on what Pete Dowson could do to rectify this DWC issue and destination weather. Let me know what you think and please pass this note on to Damian also. :( For FSX I've recently added facilities in FSUIPC4 for assigning buttons etc to "custom controls" which SimConnect allows its clients to add. So far, as far as I know, only one product is using these, but still ... On similar lines there are facilities in SimConnect for any client to see other client's "user data", provided it is created by the owning client with a known name. This is how the recent Squawkbox 4 Transponder mode controls were added. If ASE were to "publish" weather for nearby, or requested, Wx stations via SimConnect client data I could certainly provide a mapping into those via FSUIPC offsets. I'm not sure why you view Jim's suggestion with "horror". I remember the arrangement we had with RCV3 and FS2000 (or was it FS2002? Or FS98?) when FS weather was always Global in any case, and FSMeteo fed in the destination weather at specific offsets for RC to use. The proposal for ASE would be on very (very!) similar lines. I'm sure I've explained this before. But here goes ... The only reason for this is to work around the terrible bugs in FS''s weather engine which cause ridiculously reversing winds, uncontrollable multiplication of wind and temperature layers, loss of control over visibility, and stupid fluctuations in the pressure. All of these bugs were also present in FS9, but in FS9 I managed, for FSUIPC, to dig deep into the FS code and work out ways to defeat them -- by smoothing. This still doesn't give you the exactly correct weather, as stated in the METARs, but at least stops it being so erratically changeable. In FSX I do manage to overcome it to a certain extend, but nowhere near to the level I did in FS9. I was simply defeated by the terribly increased complexity in the FS code, and of course my withering grey cells. Since the problems are 100% caused by bugs in the way FS interpolates the weather between different weather stations, you should see that by using the (new to FSX) global weather option, where all the weather everywhere is the same and exactly how you set it, ASE can get over all these nasties. The original reason Microsoft provided the FSX global weather option was in response to requests by myself and Damian for a way of very tightly and reproducibly controlling weather so that flight training scenarios could be set up and repeated. The ASE implemented option is, if you like, a "misuse" of this, but provided, optionally in ASE, as a way of avoiding the bugs. There's a lot that's good with ASE without that option -- and that option is off by default in any case. As you know from when you fly here with me, the result of not using it isn't usually bad. Maybe some of those QNH changes on approach are due to the fluctuations, but I don't know and haven't tied those down yet. I think folks experiencing the worst of the bugs are flying in places where there are lots of Wx stations which also might be reporting weather at different times and so making possible conflicts so much worse. Here in Europe we tend to be lucky, usually, with consistent METARs.Bob

Hi Bob,Not being a programmer at all, but understanding a little bit about how ASE operates, I don't think that would work. Pete/Damian would know for sure.The reason I think it wouldn't work is because when DWC is On, the data we send to FSX is already in "global mode" so the "user" data is already global. This looks to be different than when FS was setting the global weather. Or maybe it is SimConnect creating the global situation!If this is the case, then the raw data is still available in one .txt file, which can be decoded.As I said before, Pete and Damian would know the best, and the best ways to move forward.