I recommend that when operating in DWC (with Global Mode on) that you elect the option to Force Destination Weather Zone On so on approach RC sees the AI operating correctly stabilized for runway assignment. The ASE log shows that METARs sent to FS are interpolated to the locked option. However, it also shows that for those ASE users choosing to download real weather (not archived) ASE periodically gets that weather. When this occurs it appears that the destination weather even in the "locked" zone will change ...

I'm not sure why you note this only for DWC mode -- surely that can apply in any mode. ASE isn't going to stop its periodic updates in standard mode either. Nor would FSX's own weather or any other system set to do periodic updating. RegardsPete

We had some discussion about what weather was applied in the Force Destination Weather Zone lock to prevent global mode from exerting weather at aircraft location to the destination location. The idea was to verify if the predicted destination weather when using archived weather would be locked to the destination METAR. That was verified in this ASE log but for real-time updates it still is the destination METAR and not the weather around the aircraft 40 nm out. That is OK.I just wanted to emphasize that updated downloaded destination METARs could still affect AI (and correctly) for those who had complained about the difference in RC's approach runway assignment and why AI might have shifted on arrival in the destination pattern. This part would be true for other versions of AS in FS9 and FSX as well. It also emphasizes that using a recent archive download for the date and Z time of the flight would provide a more predictable pattern to address user questions on why the difference between ATIS at 40 nm out and what was found. In Bob's log just before that fifteen minute period (five minutes before touchdown estimated) where the download update took place the wind vector was 340 in the METAR imposed and 310 after that update. He also stated 310 matched the NWS TAF for destination at 310.Here's the first entry regarding the implementation of Force Destination Weather Zone:4:41:15 PM:0315 - Sent String: KACY 082121Z 17407KT 24 1/2SM FEW024 SCT036 SCT075OVC130 M01/M08 A2942 RMK ADVANCED INTERPOLATION RMK FORCED TO DESTINATIONHere's some extracts around the update time:5:12:55 PM:0548 - Populating weather stream with new data...5:12:55 PM:0550 - Parsing line items5:12:56 PM:0244 - Sent String: KJFK 082051Z 34009KT 10SM FEW036 BKN045 OVC130M01/M07 A2943 RMK AO2 SLP9665:12:56 PM:0487 - Sent Weather: KJFK5:13:00 PM:0356 - Sent String: KJFK 082051Z 34009KT 10SM FEW036 BKN045 OVC130M01/M07 A2943 RMK AO2 SLP9665:13:00 PM:0528 - Sent Weather: KJFK-------------------real world weather download update applied--------------(my entry)5:13:03 PM:0018 - Download complete5:13:03 PM:0021 - Downloading Met/Rep data from Secondary Server...5:13:03 PM:0304 - Sent FS Message: ASE new weather download completed...5:13:04 PM:0413 - Sent String: KJFK 082151Z 31011KT 8SM -SN FEW032 BKN045 OVC060M01/M08 A2945 RMK AO2 SNB485:13:04 PM:0468 - Sent String: KJFK5:13:07 PM:0767 - Met/Rep Download complete5:13:08 PM:0717 - Sent String: KJFK 082151Z 31011KT 8SM -SN FEW032 BKN045 OVC060M01/M08 A2945 RMK AO2 SNB48Here's the FS termination time:5:30:26 PM:0232 - FSX connection not establishedHe probably touched down at 5:20 PM so destination weather was locked (except for real-time updates of the destination METAR) for about thirty minutes. That should provide stability compared to having Global Weather at the aircraft location enroute forced on destination weather for the last thirty minutes of flight time.Bob's ASE log in this case (using real-time weather updates) fifteen minutes before arrival did show the destination METAR with a wind vector of 310 was what he got when he arrived. In his B763 that would correspond to about 40 nm out at least I estimate. The ATIS error he got was prior to the release of 4.651 and he'll be running another test probably Tuesday evening and report his results Wednesday evening. Others have already posted that RC has reported the weather correctly with 4.651 so I think we are OK now with the user deciding (as in all versions) if he wants by using real-time downloads of weather if he wants to permit those weather changes or have constant weather from 40 nm out or so by loading an archive. The problem introduced by Global Weather Mode (as required for DWC) seems to have a resolution now.FYI - My main interest was in determining the AI behavior which has first priority when RC looks to the destination for runway assignment at 40 nm out. The second was the ATIS weather report matching fairly closely the expected arrival conditions.

FYI - My main interest was in determining the AI behavior which has first priority when RC looks to the destination for runway assignment at 40 nm out. The second was the ATIS weather report matching fairly closely the expected arrival conditions.

Odd then. I had a flight from EGCC to EIDW. The winds in both places were from the North East. RC's ATIS reported the weather at EIDW correctly when i asked for it at about 70 nm out, and stated runway 10 in use, which I expected. I was given the 40 nm crossing restriction as FL120 as also expected. All good so far. But then after 40 nm, approach gave me vectors for runway 28 and got me landing on that runway with a 15 knot NE tailwind (the tail component being within limits for a 738 I let that be). Luckily none of the AI happened to be taking off, but when I taxied off the runway I was met by a queue of AI proceeding to takeoff on Runway 10, as they should have been given the wind.To my knowledge neither the winds nor the AI changed, everything was correct for Runway 10 all the way. And the winds throughout the route were N, NE or E, never W.I don't know why RC did this, but as I was intent on testing other things (looking for that delay folks were complaining about) I didn't follow it up.Next time, though, I certainly will.BTW I am still getting RC telling me the QNH long after landing. Weird.RegardsPete

RC's ATIS reported the weather at EIDW correctly when i asked for it at about 70 nm out, and stated runway 10 in use, which I expected.But then after 40 nm, approach gave me vectors for runway 28 and got me landing on that runway with a 15 knot NE tailwind (the tail component being within limits for a 738 I let that be). Luckily none of the AI happened to be taking off, but when I taxied off the runway I was met by a queue of AI proceeding to takeoff on Runway 10, as they should have been given the wind.

I have had this exact same thing happen to me twice now. I'd assumed it was to do with UT2 traffic injection not having any AI at the airport but according to what ronzie has stated that can't be the case. Something very odd happening.Steve

Be sure UT2 is set to spawn AI at more than 40 nm out from your aircraft location.It also would be a good check to use a downloaded weather archive as opposed to real-time weather download. Just download the Z time for your FS time of departure. This would test the other assumption about with Forcing Destination Weather Zone on updates within the 40 nm radius of the airport are not occurring in the locked zone. This does not help if there is an AI spotting issue but who knows?

I have had this exact same thing happen to me twice now. I'd assumed it was to do with UT2 traffic injection not having any AI at the airport but according to what ronzie has stated that can't be the case. Something very odd happening.Steve

Hi all,I just had my first flight in a few days and I was sure to use the latest 4.651 and 6.839 versions. I had ASE, Topcat, RC, and FSFK all running all my wide-client and I did a flight from FSDT's new KTPA to ImagineSim's KATL using the new Level-D 763 Winglet, Delta Airlines livery. FS2Crew Voice Edition, and a FS Passengers session. With the new GEX textures, REX clouds, and RC running so smoothly now, it was one of the best flights I've had in a long, long time - simply stunning. I got a 100% score and "Good" landing rating in FSFK, a "Congratulations" in RC, and a "Perfect Flight" with very satisfied passengers in FS Passengers. I'm not sure I'm following all the new ATIS arrival discussions in this thread but I wanted to report that I checked the ATIS arrival in this flight at 70nm DME from ATL, and Otto checked them again at 40nm. Both times they were 325/12, and that is exactly what I experiencd on arrival, with an approach from the far-side and final into 27L. The metar listed in both the ASE Briefing screen and the ASE Report screen, had KATL 32012G18.I had the same FSIUPC and ASE settings for this flight as I had in my OP at the top of this thread, including live GMT weather checked. FWIW, I run a large custom built AI collection and they were all landing in the correct direction. It was really cool peforming the ILS approach with other Delta aircraft parallel, right next to me on both sides, performing their own final approach and landing - just like I"ve seen on many occasions in real life. :( I wish I could contribute a more detailed analysis of any wind issues, but I just didn't experience any on this particular flight.

Be sure UT2 is set to spawn AI at more than 40 nm out from your aircraft location.

Good suggestion! I'll check that here too!However, even if they weren't spawned early enough for that airport for RC to determine the runway by AI usage, it should have done so by wind direction, and that was certainly unchanged (except for some "variance" (240V300), which it wouldn't have noted), and pretty much the same all the way from EGCC to EIDW.I had exactly the same on the return journey, EIDW to EGCC, ATIS saying one this, Approach giving me the opposite, but this time I disregarded approach and landed against the wind and with the AI. Much safer! ;-)I'll extend the UT2 spawning distance in any case, and enable some wind and AI runway logging in FSUIPC, as well as the RC logging.RegardsPete

Hi, Pete:Don't know how to do it but apparently there is a logging facility in ASE as well. You might want it as a comparison cross-check of all the others looking for any updates in the last 50 nm.I also wonder if using a downloaded archive has any bearing vs. real-time updating every thirty minutes. Can you tell if ASE locks out external reads by other applications if just occurs during freshening FS weather?

Don't know how to do it but apparently there is a logging facility in ASE as well.

I think it's just the copy of the scrolling log it shows at the bottom of the main window, the first tab. I think it saves it automatically somewhere.

I also wonder if using a downloaded archive has any bearing vs. real-time updating every thirty minutes. Can you tell if ASE locks out external reads by other applications if just occurs during freshening FS weather?

I don't know at present. Obviously weather dynamics will still be there -- that's an FSX function, though you can slow them or speed them up via the ASE slider for it.However, I'm not sure any of what ASE or FSX is doing is relevant in my two odd cases -- I'm positive the simulated winds did not change significantly over any part of the journey. Everything was always set for takeoffs and landings via a specific runway yet somehow RC's Approach (only, not ATIS) gave me the opposite both times. So I'm going to do test flights with both reported surface winds logged as well as AI runway usage -- the things read by RC. Just four offsets will do the job so I'm using the Monitoring facilities.I'll report back when I've managed to reproduce the problem and analysed the result. Maybe it'll never happen again. ;-)Pete

Hi Peter,Ronzie and all of you other guys.Did a flight from KSAN to KDEN using FSX,ASE with DWC on and had a similar happening to Peter with his Dublin flight.RC gave me winds as 330/15,landing and departing 35.This was at the 50 mile marker.I was then vectored by tower to a landing on 8.yet all of the AI planes departed from 35.The tower on final was reporting winds as calm.ASE reports winds as 330/15 when i checked.I do not think that it was a one off Peter as others are seeing this erratic behaviour.Norman Bowman PS I am doing a European flight this evening and will fly it using last evenings set up.I will report what happens!

Just a suggestion regarding approach AI and winds for RC (I'm sure many of you already know this) - make sure you have the TCASRange= variable in the FSUIPC.ini file set to 80nm or more (0 disables any restriction). I have mine currently set to 80nm. Also make sure the TCASID= (I think) string is set to "Flight'. RC needs these set correctly to look forward into the AI picture for correct arrival analysis.

Just a suggestion regarding approach AI and winds for RC (I'm sure many of you already know this) - make sure you have the TCASRange= variable in the FSUIPC.ini file set to 80nm or more (0 disables any restriction). I have mine currently set to 80nm. Also make sure the TCASID= (I think) string is set to "Flight'. RC needs these set correctly to look forward into the AI picture for correct arrival analysis.

I think 80nm is effectively the max, so its the same really as disabling the restriction.In these odd cases we seem to be getting, the ATIS is being checked further out than the point where the Approach vectors are given, yet the ATIS is correct in selecting the runway according to the AI use on arrival, whilst Approach gets it wrong and vectors opposing the AI. THAT is the puzzling part. I could understand it much better if it were the other way around -- late spawning of AI traffic, or low TCAS range, both could do that. But I don't see how they can do the reverse!RegardsPete

Hi All,Found time this afternoon to do a EGLL - LKPR flight with Level D 767 ,ASE on DWC and Peters latest version which is 4.651 and winds reported in the correct manner all the way down to approach.Norman Bowman

Found time this afternoon to do a EGLL - LKPR flight with Level D 767 ,ASE on DWC and Peters latest version which is 4.651 and winds reported in the correct manner all the way down to approach.

Yes. Here too, EGCC to EIDW again. Of course my flight today was good -- bound to be, because I'd enabled extra logging to find out what's going on.I'll leave the logging in for now so I can work out what's happening if it does go funny again. The only thing I did change before this flight was the UT2 spawning distance (to its max) and reducing the ASE dynamic change rate from 50% to 10%.I'm now guessing that RC uses the winds, not AI, to forecast the runway in use in the ATIS message, and the AI runway usage for Approach. This might just explain the disagreement if the traffic wasn't being set at the time approach did its computations -- but then I would have thought it would agree with ATIS due to the winds.RegardsPete

RC 4.3 when assigning approach runway looks at AI first (TCAS table) and if no AI are located with a landing runway assigned uses winds, etc. If runways have ILS or LOC at one end, that gets priority (where no AI are present) pending an acceptable head wind component.That's what supposed to happen to my knowledge. JD would have to verify this.Have you looked at the RC log TCAS table to see what RC is getting at about forty nm out?The other question is why is ASE DWC affecting this so much. There rarely are conflicts with FSX and FS9 works fine.