pilotjohn

Ok. I just tested, and not setting global mode (setting dynamics to 0, clearing weather, then setting GLOB METAR) works for winds aloft. I now have to re-test all the other stuff I generate (temp/visibilty/clouds).

Well winds aloft in global mode definitely don't work, no matter what I do. How can I use the FSUIPC facilities to set the weather mode to "Custom" so that individual stations can be set? There's GLOBAL mode, and I can clear weather which reverts to "Theme" mode (according to logs). But it seems "custom" needs to be used if I want to set all stations and use "GLOB" to propagate to unset stations.

If global turns out not to work... Would you be able to add facilities for evaluating the nearest or adding "virtual" stations? As it is I can't determine what the nearby stations are if I have to use station-based weather settings since I don't see any facility for that except <??> which sets weather for THE nearest station. Perhaps if a lat/long is given, FSUIPC should create a virtual station at that location using the ID given in the ICAO field and then set the provided weather for it. That way I could create a grid of stations. If I don't enter global mode and set GLOB weather will it set all stations to that weather? What is that mode called? Theme?

Thanks... I'll keep poking. Both write and read look good in terms of winds aloft, they show up correctly in the FSX weather GUI, and WeatherSet2, but I'm not getting the results in flight. I used the B offset to write some METARs directly (now that it works - thanks again for fixing that BTW) but it seems to have no affect either (wrote GLOB 000000Z 36010KT&D1000NG 27050KT&A3000NG 15/10&A0) which again looks good in FSX GUI but doesn't get simulated. If I view it in the GUI and click "OK" it starts to work. The same thing happens if I use WeatherSet2 to add a layer. It shows up but doesn't appear to be simulated. You said doing this on a per-station basis works?

Yes, definitely in global mode (FSUIPC logs show this, weather cleared) and clouds(at least what works)/visibility/temperature are set correctly. The logs above are the METAR sent and received, correct? Or is there additional logging available?

Yep... for the sample above I was getting 5-6 KTS at 18000 feet during the slew read-out. I'll finish up my weather generator as is, and see how it feels with the limitations FSX imposes.

The read-back shows the same as that which was written (e.g. base altitude not the top of the layer, is this correct?). I'll take your word for this since slewing through layers seems to not show the correct wind, although everything in WeatherSet2 and FSX GUI, and read-backs show the correct settings. Only the surface wind read-out seems correct, regardless of the number of layers I create and where in the layer I am trying to slew/un-slew to check wind. 1853479 &gt;NewSet: Surface wind: to alt=10000ft AMSL, dir=215T, vel=2.00, gust= 3.0, turb=0, shear=0, var=4.8 1853479 &gt;NewSet: Wind layer 1: to alt=20000ft AMSL, dir=236T, vel=26.0, gust= 1.0, turb=1, shear=1, var=2.9 1853479 &gt;NewSet: Wind layer 2: to alt=30000ft AMSL, dir=257T, vel=63.0, gust= 0.0, turb=0, shear=1, var=7.8 1853479 &gt;NewSet: Cloud[0]: type=8, from 6170ft to 25410ft (+/- 0ft), cover=2, turb=1, topshape=0 1853479 &gt;NewSet: Precip=0, base=0ft, rate=0, icing=0 1853479 &gt;NewSet: Cloud[1]: type=9, from 10690ft to 16710ft (+/- 0ft), cover=2 , turb=1, topshape=0 1853479 &gt;NewSet: Precip=0, base=0ft, rate=0, icing=0 1853479 &gt;NewSet: **** End of New Weather details for ICAO=GLOB 1853479 Setting Weather: "GLOB 141503Z 21502G05KT&amp;D3048NG 213V217 23626G27KT&amp;A 3048OM 25763KT&amp;A6096NM 34KM&amp;B-1&amp;D1 34KM&amp;B1&amp;D1015 42KM&amp;B1016&amp;D1016 49KM&amp;B2032&amp;D10 16 57KM&amp;B3048&amp;D1016 65KM&amp;B4064&amp;D1016 73KM&amp;B5080&amp;D1016 80KM&amp;B6096&amp;D1016 88KM&amp;B711 2&amp;D1016 96KM&amp;B8128&amp;D1016 2ST062&amp;ST192FOVN000N 2CU107&amp;CU060FOVN000N 16/08&amp;A0 09/M 06&amp;A3048 M16/M24&amp;A6096 M40/M53&amp;A9144 Q1029 " 1859875 WX Error: timed out, WX request type 5, Lat=41.0669, Lon=-74.5561, Alt =0.0m 1874882 Weather Read request (At Aircrft) to area 4: Lat=40.36, Lon=-74.56, Al t=115.3, Req=2 1874882 Weather Read request (Nr Station) to area 5: Lat=40.36, Lon=-73.63, Al t=0.0, Req=1 1874882 Weather Received (type 4 request, Interpolated): "GLOB&amp;A0 141503Z 2150 2G05KT&amp;D3048NG 213V217 23626G27KT&amp;A3048LM 25763KT&amp;A6096NM 34KM&amp;B-1&amp;D1 34KM&amp;B1&amp;D1 015 42KM&amp;B1016&amp;D1016 49KM&amp;B2032&amp;D1016 57KM&amp;B3048&amp;D1016 64KM&amp;B4064&amp;D1016 73KM&amp;B50 80&amp;D1016 80KM&amp;B6096&amp;D1016 88KM&amp;B7112&amp;D1016 96KM&amp;B8128&amp;D1016 2ST062&amp;ST019FLVN000N 2CU107&amp;CU006FLVN000N 16/08 09/-6&amp;A3048 -16/-24&amp;A6096 -40/-53&amp;A9144 Q1029 @@@ 10 0 9 236 26 | 200 -16 257 63 | " 1874882 WX Received in 0 mSecs, WX request type 4, Lat=40.3567, Lon=-74.5567, Alt=115.3m

Pete, I think there's a bug in how you translate the NWI winds aloft structure to the extended METAR syntax. See below: 1233328 &gt;NewSet: Surface wind: to alt=3330ft AMSL, dir=42T, vel=8.00, gust=1. 0, turb=0, shear=1, var=4.2 1233328 &gt;NewSet: Wind layer 1: to alt=6670ft AMSL, dir=43T, vel=15.0, gust=1. 0, turb=1, shear=1, var=2.8 1233328 &gt;NewSet: Wind layer 2: to alt=10000ft AMSL, dir=44T, vel=23.0, gust=1 .0, turb=2, shear=0, var=5.1 1233328 &gt;NewSet: Wind layer 3: to alt=13330ft AMSL, dir=45T, vel=30.0, gust=0 .0, turb=1, shear=0, var=4.8 1233328 &gt;NewSet: Wind layer 4: to alt=16670ft AMSL, dir=47T, vel=36.0, gust=0 .0, turb=1, shear=1, var=0.6 1233328 &gt;NewSet: Wind layer 5: to alt=20000ft AMSL, dir=48T, vel=41.0, gust=0 .0, turb=1, shear=1, var=3.4 1233328 &gt;NewSet: Wind layer 6: to alt=23330ft AMSL, dir=49T, vel=41.0, gust=0 .0, turb=1, shear=1, var=0.7 1233328 &gt;NewSet: Wind layer 7: to alt=26670ft AMSL, dir=50T, vel=49.0, gust=0 .0, turb=0, shear=0, var=4.1 1233328 &gt;NewSet: Wind layer 8: to alt=30000ft AMSL, dir=52T, vel=54.0, gust=0 .0, turb=2, shear=1, var=8.7 1233328 &gt;NewSet: Cloud[0]: type=9, from 3420ft to 5574ft (+/- 0ft), cover=1, turb=2, topshape=0 1233328 &gt;NewSet: Precip=0, base=0ft, rate=0, icing=0 1233328 &gt;NewSet: Cloud[1]: type=9, from 6780ft to 10476ft (+/- 0ft), cover=1, turb=2, topshape=0 1233328 &gt;NewSet: Precip=0, base=0ft, rate=0, icing=0 1233328 &gt;NewSet: Cloud[2]: type=9, from 12960ft to 17700ft (+/- 0ft), cover=1 , turb=2, topshape=0 1233328 &gt;NewSet: Precip=0, base=0ft, rate=0, icing=0 1233328 &gt;NewSet: **** End of New Weather details for ICAO=GLOB 1233328 Setting Weather: "GLOB 141541Z 04208G09KT&amp;D1016NM 039V044 04315G16KT&amp;A 1016OM 04423G24KT&amp;A2032LG 04530KT&amp;A3048OG 04736KT&amp;A4064OM 04841KT&amp;A5080OM 04941K T&amp;A6096OM 05049KT&amp;A7112NG 05254KT&amp;A8128LM 32KM&amp;B-1&amp;D1 32KM&amp;B1&amp;D1015 38KM&amp;B1016&amp;D 1016 43KM&amp;B2032&amp;D1016 48KM&amp;B3048&amp;D1016 54KM&amp;B4064&amp;D1016 59KM&amp;B5080&amp;D1016 64KM&amp;B6 096&amp;D1016 70KM&amp;B7112&amp;D1016 75KM&amp;B8128&amp;D1016 1CU034&amp;CU022FLVN000N 1CU068&amp;CU037FLV N000N 1CU130&amp;CU047FLVN000N 25/16&amp;A0 05/M09&amp;A3048 M17/M26&amp;A6096 M19/M32&amp;A9144 Q10 25 " The sections after the surface wind should contain the actual UpperAlt value for the winds aloft, but it looks like you're subtracting the surface wind depth from each (the first one should be 2032, and last one should be 9144, but they are all less by the depth of the surface layer). "The altitude of a WINDS ALOFT section specifies the top of the layer in which the given wind data is to apply. The bottom of the layer will be determined by the top of any lower layer, either another WINDS ALOFT entry, or the SURFACE WINDS entry." This is visible in FSX weather interface, as the first aloft layer is nearly on top of the surface layer. Can you fix this? Also, I'm not sure if the SimConnect METAR documentation is in the correct order, but if it is, the surface wind variation should come after the winds aloft section, not after the surface winds. (http://msdn.microsof...y/cc526983.aspx) Regards, John

This is a Lua script that provides all sorts of failure scenarios. It can be auto-loaded at start so you don't have to set up failures every time. It can be configured for many different behaviors and probabilities. I have it running all the time, so I always have to be vigilant to make sure I didn't forget things. Flying the simulator can degrade your real-life skills because there are no consequences for being lax. This can alleviate some of those tendencies. You can also assign buttons/keys to show the current failures (if you can't figure out what went wrong) and to reset them. Rename to .lua and follow instructions at the top. RandomFailure.txt

If you turn on "Filter" on the throttle axis, you won't have the hang in REV problem. You can also increase the threshold where the auto-forward toggles.

Now, I'm motivated... maybe a free copy of WideFS so I can run BlackBox on a client machine.

Do I get a prize when I report the 10th bug? :)

Very odd... key presses work for the Lua, but [Auto] does not. I changed script ordering, still nothing. In an act of desperation, I renamed it from SetFuel to FuelManager, and it worked. Can I not use "Set" in the filename for [Auto] - as shown above?

I'll try that... 4.745. can I do an Auto on any aircraft change (I understand the reload limitation) like Auto.*? Regardless, I'm just running a simple script to reload fuel tanks to 50+/-5% and for some reason that doesn't seem to happen when I first load a flight even though the Auto section is: [Auto] 1=Lua ConstantFailure 2=Lua ThrottleManager 3=Lua SetFuel

Is there some logging option I can enable to log [Auto] script parsing/starting? I have some [Auto] scripts that work. I added a new one and it doesn't seem to load on aircraft switches. It runs if I assign it to a key press, added ipc.log() to it, but won't start on [Auto].

Yes, that's how I was using it for my reverse throttles, and they were working correctly. Here are the results in -16k..16k, showing the value for those extremes at 0x3330: 1. assigned in FSUIPC direct to calibration, but uncalibrated 0..16384 2. ditto calibrated, not NRZ 6144..16384 3. ditto calibrated, NRZ (but i think this is the case you are using?) 8192..16384 4. assigned in FSUIPC to FS control "AXIS THROTTLE1 SET", but uncalibrated 0..16384 5. ditto , calibrated, not NRZ 6144..16384 6. ditto , calibrated, NRZ 8192..16384 I unchecked Exclude/nSet (otherwise it would nothing) 7. assigned in FSUIPC to FS control "THROTTLE1 SET", but uncalibrated 0..16384 8. ditto , calibrated, not NRZ 6144..16384 9. ditto , calibrated, NRZ 8192..16384 10. assigned in FS, uncalibrated 0..16384 11. ditto , calibrated, not NRZ 6144..16384 12. ditto , calibrated, NRZ 8192..16384 Looks like all the calibrated ones are incorrect. And, as I said before, the Joystick Calbiration GUI "OUT" value shows the correct value, not the incorrect one written to 0x3330.

I'm not sure why these were wrong before, they made sense before as they matched up with what the GUI was showing for out, and what you would expect the correlation to be between the raw joystick input and potential output to the simulator. On a joystick with a raw range of -16384 to 16384, direct to calibration and NRZ, it would set this value to 0 when the joystick was -16384, and to 16384 when the joystick was 16384. Now it's setting this value to 8192 when the joystick is is -16384 even though the GUI output is showing the correct value of 0. Mapping -16..16k to 0..16k with NRZ seems like the right move (that seems like "post calibration" to me), but that's not what it's doing anymore.

The METAR now updates correctly, thanks! But something broke in this version or somewhere between what I was running last. My throttle updates are incorrect. FSUIPC shows 0 being output at idle, but 0x3330 is updated with 8192 instead of 0 (direct to calibration, NRZ, filtering or not). This happens in both 4.743 and 4.744, but not the original install of 4.70 and certainly not what I was running last, which was 4.731.

Updated to 4.743, but the behavior is the same.

I turned on IPC write logging: ipc.writeSTR(0xB000, "GLOB 011907Z 00000KT&amp;D609NG 100KM&amp;B-1500&amp;D6072 8ST010&amp;ST500FNVN000N 4CU020&amp;CU010FNVN000N 15/05&amp;A0 Q1013") 12860317 WRITElua B000, 104 bytes: 47 4C 4F 42 20 30 31 31 39 30 37 5A 20 30 30 30 GLOB 011907Z 000 12860317 30 30 4B 54 26 44 36 30 39 4E 47 20 31 30 30 4B 00KT&amp;D609NG 100K 12860317 4D 26 42 2D 31 35 30 30 26 44 36 30 37 32 20 38 M&amp;B-1500&amp;D6072 8 12860317 53 54 30 31 30 26 53 54 35 30 30 46 4E 56 4E 30 ST010&amp;ST500FNVN0 12860317 30 30 4E 20 34 43 55 30 32 30 26 43 55 30 31 30 00N 4CU020&amp;CU010 12860317 46 4E 56 4E 30 30 30 4E 20 31 35 2F 30 35 26 41 FNVN000N 15/05&amp;A 12860317 30 20 51 31 30 31 33 00 0 Q1013. 12860317 Setting Metar: "" It logs blank regardless of what I try to write.

Ok, another question. I'm trying to write to B000 (instead of using the structs) but it's not working for me. I'm setting dynamics 0, global mode, and clearing via NWI, then write "GLOB ..." to 0xB000 via ipc.writeSTR(0xB000, "GLOB ...") but FSUIPC show only this: 5498536 NW_DYNAMICS command, setting weather dynamics = 0 5499457 NW_GLOBAL command, setting weather to global mode 5500377 NW_CLEAR weather command received 5500377 NWI weather clear actioned 5500377 External weather discarded 5500424 Weather Mode now = Theme 5500424 Weather Mode now = Global 5502187 Setting Metar: "" Any ideas? Writing to B000 seems to trigger that "Setting Metar" log message, but regardless of the string I send, it's shown as blank.

Is there no way to specify cloud height and/or tops? I notice the NWI has structure for it (UpperAlt), but logging shows no such data being sent since it's not part of the extended METAR. Also, I turned on logging and noticed that there are constant reads and writes for weather. I turned off all FSUIPC "weather" options and writes stopped (they were writes to nearby stations even though GLOB mode was active) but the reads continue. Is there anyway to tell what might be using FSUIPC to request the reads, or whether it's FSUIPC itself?

Yes, I'm in global mode. I placed FSX in global mode and write the weather for "GLOB" ID. The only way I seem to be able to "fix" visibility is if set NWI.Vis to -1 to 0 for altitude, and then use UpperVisibility layers from 1..whatever to set visibility. It seems only the NWI.Vis settings behave oddly.

Thanks... a few more questions. So far setting temperature layers works great, and so does setting visibilities with one problem. The NWI.Vis (the surface visibility) is set but then immediately starts to change on its own (visibly and viewed in WeatherSet2) to a higher value, about every 3-5 seconds or so, until it reaches the limit I set in FSUIPC. This happens even if I disable the limits in FSUIPC (and then it changes to 60). The upper level visibility layers I set appear to be untouched. This is regardless of whether I use NW_SET or NW_SETEXACT and ensure that dynamic is set to 0 prior to any of the changes. It also happens if I change he visibility with WeatherSet2. Any ideas?

I have some questions about NWI, specifically whether certain fields are used and their meaning by/for FSX: _NewWind.Variance: Is this +/- for variable wind? Is it used? _NewWind.SpeedFract: What is it used for? How? _NewCloud.Deviation: What is it? _NewTemp.DayNightVar: Is this an amount subtracted from Day temp when night falls? Dew point is unaffected? Will this simulated fog if T/D converge at night? Is it for FSX? It this used only for surface or all altitudes? Will clouds form when T/D converge at upper altitudes? _NewPress.Drift: What is this for? Your comments say "? Maybe" I'm planning on writing global weather generator (which seems to work, at least I can clear through Lua using vstruct), but if I chose to add location based variation, do you have any insights? If I write a different weather at 1 degree lat/long intervals, does FSX try to interpolate between them? For example, if I generate two MVFR conditions 60 NM apart and vis/clouds are different, what happens. Or, do I need to write weather only to ICAO locations?