Cool ... that is certainly encouraging. I had no idea that anything like this had actually made it into the SDK.I must add that I'm a bit puzzled by your implementation. :)- David Sandberg

Looks like you have a few good links here. Below is another...http://www.landings.com/evird.acgi$pass*47...av_weather.html

Puzzled?! Oh come now, it's perfectly obvious... :-lolHere's what my code does (in english):First choose an arbitrary initial wind heading.Now for each wind layer, change the direction of the wind heading randomly by anthing from 10 degrees up to 180 degrees. The da[] table provides a simple probability table--there is more likelihood of changing only +/-10 to 20 degrees that there is to change 90 or 270 degrees.For each wind layer, choose an initial wind speed in the range of 0 to 30 knots. Then, arbitrarily add a whole bunch of wind just to make things interesting. The conditional makes it more likely that there is higher wind at higher altitudes.Finally, add an arbitrary amount of gust and arbitrarily make the winds variable. It works and makes for some very entertaining wind patterns! :-)Cheers, Tony

It was the odd sequencing of the values in the delta array that had me scratching my head, but now I can see why you would have chosen to order them in that way. Personally I tend to do ramped calculations like that with pure math, in order so there is some chance of any and all direction changes ... like 40 degrees, for example, a direction change with altitude that can never occur with this code.Edit: another thing just occurred to me ... is there some reason why you didn't allow any possibility of the wind direction not changing at all with a given bump in altitude? Maybe put a couple of zero elements at the tail end of delta?- David Sandberg

Hi David,I know you're not being overly critical, but let me just say that I banged this code out in about 20 minutes--start to finish. I had given some thought to what I would do to test the API function and this is what I came up with. Anything more realistic would have taken me a bit more time. Besides, what we really want is to use the real data. So, my code is just a proof point and nothing more. :-)Cheers, Tony

That's fair ... sorry to have been nit-picking. If anything, I hope you'll take my suggestions as a compliment, since in 20 minutes work you seem to have come rather close to as good a randomized winds aloft function as anyone could ask for.- David Sandberg[br][br]

Now, as to how to read FDsWhat does FD stand for anyway?Lastly - Also I want to point out that InfoMETAR isn't doing a thing at this point ... it is out of the picture once you've saved METARs to disk for use in Fly! What Fly! does with them at that point is beyond my control. The whole point of InfoMETAR is to tweak the METARs before Fly! sees them, in such a way that Fly! is more likely to produce accurate results with them.But, the file you load must have different wind speeds & directions at different stages of the flight - no? I mean, in any given flight, you are likely to cross several Metar stations, each with different surface wind directions & speeds, so therefore, even though the file is already pre-loaded at the outset of the flight - don't the wind speeds & directions get changed & updated to reflect the current station your are passing. These varying numbers were loaded as part of the original file. So if I change the winds aloft, won't these numbers be overridden or reverted back to reflect whatever was in the original file when I pass each succesive station? In short, even though the file is loaded only once & it is in place for the entire route as a static file, each station has its own numbers & weather elements (that's why you can go from clear skies to precipitation for example). So, if I change the winds, won't they change back to the "real numbers" encoded in the loaded pre-existing file once I pass each new station? Hope I am making sense. :-)Thanks. Chris

Chris,The METAR file produced by InfoMETAR and thereafter loaded by Fly! contains surface observations only, including surface winds. Again, the important word is surface. Internally in Fly! the data structures that contain surface data (including winds) appear to be entirely distinct from the one containing winds aloft layers. Fly! continuously and dynamically interpolates between all loaded surface observations to produce weather conditions, but presumably surface winds extend to all altitudes only if no winds aloft are specified. Winds aloft information is global in nature and not interpolated. I'm fairly certain there is no interaction between surface observations and winds aloft settings, or at least the sort of interaction you are evidently concerned about.In short, I don't expect this to be a problem.I have no idea what FD stands for, and was surprised to find that it wasn't specified as anything other than "Winds and Temperatures Aloft Forecasts (FDs)" even in any of the weather and/or aeronautical volumes I have here. Maybe someone else here can chime in with the answer if they know?- David Sandberg