JarangMandi

I'm not trying to prove anything - just to understand FS weather and its interaction through the NWI to FSUIPC. I'm starting to develop software against FS9 later than most, and the searches I ran through this forum didn't turn up any answers, although that might have been down to the search terms I was using. That information answers the question I was asking. You're right - I didn't check the winds aloft in FS9 by actually going there and I apologise for not doing this before posting. Should I expect to see "GLOB" in the data that WeatherSet2 displays after doing this? I don't - and I've noticed the same behaviour when trying to read weather for "GLOB" from code; I always get a zeroed string in chICAO instead - which I understand to mean the weather at the aircraft location. The information regarding version number was drawn from the FSUIPC dialog - the date in that dialog is July 16th. This doesn't match the version of the file that appears in the file properties when examined through Windows Explorer which is indeed 3.82. I've checked that it's this file that's being used by removing it from the "modules" directory.

Pete, You're going to start dreading my posts soon, but... I'm seeing a few problems with reading wind direction through the NWI with FS9 using FSUIPC 3.817. I've seen it manifest itself in all sorts of ways, and can't find a pattern to it, but the following steps will (should) reproduce it. 1. Fire up WeatherSet2 2. Fire up FS2004 3. Choose "Select a Flight" and choose the "Default Flight". For me this is still the default start at KSEA. 4. Select "Fly Now". 5. Enable FSUIPC Weather Logging. 6. Select weather theme "Clear Skies" from "World... Weather" dialog 7. Weatherset2 shows a single wind layer, speed and direction 0,0. 8. In FS9, select "user defined weather" from "World... Weather..." dialog, and then "advanced weather" 9. On the wind tab, insert a new wind layer, 25000ft, 120kts, 270 deg. 10. OK all the way out... 11. Weatherset2 shows two wind layers - layer 0 is unchanged; layer 1 is at 25000ft, 120kts BUT 090 deg. The relevant lines from the log file read as follows... 483946 >Change: FS98 Pressure=0.0 mb 483946 >Change: FS98 Vis: range=0sm, (raw value=0) 483946 >Change: FS98 Dewpoint Control: 0.0C 483946 >Change: FS98 Precip Control: None, Intensity=0 483946 >Change: surface wind: to alt=2000ft AGL, dir=360T, vel=0.0, gust=0.0, turb=0, shear=0, var=0.0, Flags=0, AMSL=2380ft 483946 >Change: wind layer 0: to alt=25000ft AMSL, dir=90T, vel=120.0, gust=0.0, turb=0, shear=0, var=0.0 483946 >Change: Visibility[0]: range=60.0sm (96560m), from=0ft, to=15000ft 483946 Results: Visibility[0]: range=60.0sm (96561m), from=0ft, to=15000ft 483946 Results: FS98 Wind0: ground (430ft) to 1950ft AGL, dir 359M, vel 0, gust 0, turb 0 483946 Results: FS98 Wind1: 2380ft to 25000ft AMSL, dir=89T, vel 120, gust 0, turb 0 I have taken a look at the raw data as reported with offset reads are logged and reads are executed from from offsets 0xC000 and 0xCC00, and the wind direction reported in there does match the value in the log (089deg) - but obviously not the value that was set (270deg). I've also tried with different direction values... an entry of 315 degrees comes back as 045, and an entry of 225 degrees comes back as 135 deg. My first impression was that it might be an overflow, but when I started changing the direction of the lower layer that didn't seem to hold true any more. When the direction on the lower layer is changed, all kinds of weird stuff happens! I've not had the opportunity to try this on FSX yet as I'm working away from home and they won't give me a laptop that will run it! I'd be surprised if the problem was the same though as I understand that the underlying mechanisms are now totally different. Do you see the same things happening? Thanks (again) in advance, Andy

Got it Pete, and it appears to have resolved the inconsistency between the FS9 and FSX interface. Thanks!

Pete, Just to make sure... I'm assuming that the changes you made in the 4311 file have made it into the latest beta - which at present stands at 4322 if I'm understanding things correctly. I just don't recognise the changes in the text description that accompanies the 4322 file. Also, I think I've come across a problem where there's a difference between the way that precipitation intensity is returned from FS9 and FSX versions of FSUIPC. FS9 appears to return a number between 0 and 5 - with 0 for "no precipitation" in conjunction with the same setting in precipitation type, whereas FSX seems to return a number between 0 and 4 - with 0 for "very light". I'm not 100% sure of this yet and plan to investigate further this week, but is it something you can take a quick look at? Thanks, Andy

Pete, I've just spotted when you made those posts... don't you ever sleep?! The level of support you provide is second to none. Thank you. I've tried the new version that you posted the link to, and it all seems to work fine for me with no apparent side effects other than being able to set the weather much more quickly now. The logs are reporting that the clear weather command is being actioned on receipt too so all seems well. Thanks again, Andy

Thanks Pete, I'll try it out when I get home from the day job. Andy

Thanks (again) for the quick reply Pete. Yes - clear weather! In fact, depending on how long it takes to process the "clear weather" command, I'm seeing the commanded weather, albeit fleetingly. The FSUIPC log snippet below seems to support this - although you're obviously in a much better position to interpret it than I. 455766 NW_DYNAMICS command, setting weather dynamics = 0 455922 NW_CLEAR weather command received 457078 Weather Read request (At Aircrft) to area 4: Lat=47.44, Lon=-122.31, Alt=133.1, Req=2 457094 Weather Received (type 4 request, Interpolated): "????&A0 071952Z 24805G06KT&D1000NG 16KM&B-318&D3500 8ST012&ST000FLMR000N 6CU027&CU000FMLR000N 5CI299&CI000FNVN000N 11/10 Q1009 " 457094 WX Received in 16 mSecs, WX request type 4, Lat=47.4382, Lon=-122.3112, Alt=133.1m 458000 NW_SETEXACT weather command received, ICAO=GLOB 458000 >NewSet: **** New Weather being set: ICAO=GLOB (Dyn=0) 458000 >NewSet: Pressure=1013.0, Drift=0.0 458000 >NewSet: Visibility[0]: range=62.5sm (100584m), from=-1040ft, to=8960ft 458000 >NewSet: Temperature[0]: alt=430ft, Day=14 C, NightVar=0 C, DewPt=4 C 458000 >NewSet: Surface wind: to alt=6990ft AMSL, dir=0T, vel=0.00, gust=0.0, turb=0, shear=0, var=0.0 458000 >NewSet: Wind layer 1: to alt=20115ft AMSL, dir=270T, vel=20.0, gust=0.0, turb=0, shear=0, var=0.0 458000 >NewSet: Wind layer 2: to alt=23114ft AMSL, dir=270T, vel=25.0, gust=0.0, turb=0, shear=0, var=0.0 458000 >NewSet: Cloud[0]: type=9, from 6000ft to 0ft (+/- 0ft), cover=2, turb=0, topshape=0 458000 >NewSet: Precip=0, base=0ft, rate=2, icing=0 458000 >NewSet: Cloud[1]: type=1, from 39700ft to 0ft (+/- 0ft), cover=6, turb=0, topshape=0 458000 >NewSet: Precip=0, base=0ft, rate=2, icing=0 458000 >NewSet: **** End of New Weather details for ICAO=GLOB 458000 Setting Weather: "GLOB 071952Z 00000KT&D2131NG 27020KT&A2131NG 27025KT&A6131NG 101KM&B-318&D3048 2CU060&CU-59FNMN000N 6CI397&CI-396FNMN000N 14/04&A131 Q1013 " 458219 NW_SETEXACT weather command received, ICAO=KSEA 458219 >NewSet: **** New Weather being set: ICAO=KSEA (Dyn=0) 458219 >NewSet: Pressure=1009.0, Drift=0.0 458219 >NewSet: Visibility[0]: range=10.0sm (16093m), from=-1040ft, to=10440ft 458219 >NewSet: Temperature[0]: alt=430ft, Day=12 C, NightVar=0 C, DewPt=11 C 458219 >NewSet: Temperature[1]: alt=3710ft, Day=7 C, NightVar=0 C, DewPt=5 C 458219 >NewSet: Surface wind: to alt=3710ft AMSL, dir=248T, vel=5.00, gust=1.0, turb=0, shear=0, var=0.0 458219 >NewSet: Wind layer 1: to alt=6710ft AMSL, dir=135T, vel=20.0, gust=0.0, turb=0, shear=0, var=0.0 458219 >NewSet: Cloud[0]: type=8, from 1200ft to 0ft (+/- 0ft), cover=8, turb=0, topshape=0 458219 >NewSet: Precip=1, base=0ft, rate=2, icing=0 458219 >NewSet: Cloud[1]: type=9, from 2700ft to 0ft (+/- 0ft), cover=6, turb=0, topshape=0 458219 >NewSet: Precip=1, base=0ft, rate=1, icing=0 458219 >NewSet: Cloud[2]: type=1, from 29900ft to 0ft (+/- 0ft), cover=5, turb=0, topshape=0 458219 >NewSet: Precip=0, base=0ft, rate=0, icing=0 458219 >NewSet: **** End of New Weather details for ICAO=KSEA 458219 Setting Weather: "KSEA 071952Z 24805G06KT&D1000NG 13520KT&A1000NG 16KM&B-449&D3500 8ST008&ST-11FNMR000N 6CU023&CU-26FNLR000N 5CI295&CI-298FNVN000N 12/11&A0 07/05&A1000 Q1009 " 459391 Weather Read request (Nr Station) to area 5: Lat=47.44, Lon=-122.31, Alt=0.0, Req=1 459391 Weather Received (type 5 request, Nearest): "KSEA&A131 071952Z 24805G06KT&D1000NG 13520KT&A1000NG 16KM&B-449&D3500 8ST008&ST000FLMR000N 6CU023&CU000FMLR000N 5CI295&CI000FNVN000N 12/11 07/05&A1000 Q1009 @@@ 37 7 135 20 | " 459391 WX Received in 0 mSecs, WX request type 5, Lat=47.4382, Lon=-122.3112, Alt=0.0m 459391 NWI weather clear actioned My interpretation of this is that the NW_CLEAR command issued at timestamp 455922 completes at timestamp 459391; when it is actually issued to FSX is unclear from this. In the meantime, I've waited for the timestamp at 0xC824 to change per the SDK, and issued a set for "GLOB" and "KSEA" weather stations which appear to be being sent to FSX at timestamps 458000 and 458219 respectively. The unfortunate effect of the NWI weather clear being actioned at 459391 is that it wipes out the effects of those two writes. The corresponding section of the SimConnect log reads as follows... > 456.50588 [65, 2566]WeatherSetDynamicUpdateRate:dwRate=1 > 456.64784 [65, 2567]RequestSystemState:RequestID=1, szState="Sim" > 457.81453 [65, 2568]WeatherRequestInterpolatedObservation:RequestID=-1073741785, lat=47.438221, lon=-122.311234, alt=133.113525 > 458.73672 [65, 2569]WeatherSetObservation:Seconds=0, szMETAR="GLOB 071952Z 00000KT&D2131NG 27020KT&A2131NG 27025KT&A6131NG 101KM&B-318&D3048 2CU060&CU-59FNMN000N 6CI397&CI-396FNMN000N 14/04&A131 Q1013 " > 458.94958 [65, 2570]WeatherSetObservation:Seconds=0, szMETAR="KSEA 071952Z 24805G06KT&D1000NG 13520KT&A1000NG 16KM&B-449&D3500 8ST008&ST-11FNMR000N 6CU023&CU-26FNLR000N 5CI295&CI-298FNVN000N 12/11&A0 07/05&A1000 Q1009 " > 459.21395 [65, 2571]RequestSystemState:RequestID=1, szState="Sim" > 460.12344 [65, 2572]WeatherRequestObservationAtNearestStation:RequestID=-805306328, lat=47.438221, lon=-122.311234 > 460.12697 [65, 2573]WeatherSetModeTheme:szThemeName="" > 460.16783 [65, 2574]WeatherSetModeCustom: This would appear to suggest that the clear weather theme is being commanded after the weather has been set. Is my interpretation correct? It will be, yes - distributed to members of the Bristol Flight Simulator Group. I'll e-mail you offline about this. Regards Andy

Pete, Following on from this thread, development is well under way and I'm (almost) happily writing weather to both FS9 and FSX from the same program. Something I've come across where the behaviour in FS9 and FSX appears to be quite different though is the behaviour in response to a "CLEAR WEATHER" command. The SDK suggests leaving a "a little delay afterwards" and whilst FS9 always seems happy with a 2 second delay (I've not tried shorter) the behaviour I'm seeing in FSX by examining the FSUIPC weather logs suggests that the time taken to complete the command (on my system at least) is on average around 1.5 seconds but has been seen to reach in excess of 4 seconds with the result the desired weather that has been set at specific stations in the meantime is being overwritten. Do you know of a hard and fast rule that says how long I should wait? Is there something in the FSUIPC interface that says that processing of a clear weather command has completed (as opposed to having been written to FS as indicated by offset 0xC824)? As an aside, to be able to distribute this program (when it's complete), is the process still to e-mail you for a code so that it will work with unregistered versions of FSUIPC? Thanks, Andy

Plenty of food for thought there Pete. It's an assumption I'm making through observation... Weather is set on the server through the UI (either a dialog or a web page depending on how you want to access it) and sent either on demand or at regular intervals to all connected FS clients. There's no other connection to the server than the FS MP session. When I get a few moments, I'll put a network monitor on there and see if I can spot anything obvious. So by setting an appropriate temperature at the tropopause (-56 at 11000m for sake of argument) as well as the surface temperature, FS will give me the gradient? All I need to do now is convince the author to put this into his program! Again, many thanks for the rapid and comprehensive response. Andy

Thanks for the prompt reply Pete... I don't know if you've ever looked at FSHost - I suspect it doesn't use FSUIPC - but it's essentially an FS2002/4 multiplayer server that doesn't require a flight sim installation, and which allows FS2002/4 and (with a SimConnect based interface program) FSX pilots to fly together in that multiplayer environment. It should either be setting a series of temperature layers (perfectly possible in the extended METAR format supported by SimConnect, or, possibly easy, send a fresh Global setting as the aircraft climbs or descends. Same goes for winds of course. The weather feature of FSHost only allows a single temperature layer to be defined. Whilst this gets translated correctly in FS9 (presumably through the native MP interface) the way the FSX interface translates this is through setting the FSX weather mode to "Global" (unavailable through the UI according to the SDK) through SimConnect, and then through issuing a METAR string for the "GLOB" (global) weather station. A side effect of this appears to be that which I've noted in respect of ambient temperature - although pressure seems to decrease with altitude. I knocked something together to deliver an identical METAR but use the "Custom" weather mode, and (although it can take a while to propogate) everything appears to work as expected. Surely as you fly to different weather areas it obtains and supplies a fresh METAR? Unfortunately not... weather is set globally only. The weather doesn't (nor do I want it to) change in real time, but it would be nice to be able to have different conditions at departure, en route and arrival. As I'm not too worried about changing weather (at least not in the first place), it looks like the solution might be to clear the weather, to issue an "en route" (global) METAR, and then specific METARs for departure and arrival. Does that sound like it might fly (pun intended :) )? Thanks again for the prompt reply. Andy

I'm a bit new to this, so apologies if these questions are phrased incorrectly, or don't quite sit with general understanding. I'm a member of a group of private individuals who congregate on a weekly basis and engage in online flying using FSHost. Problem is, I've come across some problems whereby the weather doesn't work for FSX (the FSHost client for FSX uses SimConnect, and sets "Global" mode before it sends the METAR for "GLOB" across, and FSX appears to interpret that by setting and maintaining the ambient temperature around the aircraft to the temperature supplied in the METAR no matter what the altitude). The other well documented feature of FSHost is that only global weather can be set; there's no scope to take off in snow and arrive in sunshine! My intention is therefore to provide the group with a (free) utility for that works for both FS9 and FSX that allows us to manage weather at different locations, perhaps providing "global" weather between them. I've already played with the weather interface provided by SimConnect with some success, whilst that works for FSX, it's obviously not a solution for FS9. The hopefully simple question after all this background is, "Can the same FSUIPC weather interface be used to control the weather for both FS9 and FSX, and provide (within reason) identical weather for each?"