Just wanted to add that B647, combined with the changes you made on the server end, has really done the trick. Upper winds over Europe, and elsewhere, now appear to perfectly match current real-world upper air charts in every regard. This is the best winds aloft performance I've ever seen in ASE. Great job guys!Jim Barrett

Hi,B647 seems to work for the winds aloft. I flew from BIRK to CYYZ and everything was fine. If your programmers could now do a similar miracle for the data files for non-US users, we would be able to use this now correct wind info for FSBUILD again.RgdsReinhard

Hi,B647 seems to work for the winds aloft. I flew from BIRK to CYYZ and everything was fine. If your programmers could now do a similar miracle for the data files for non-US users, we would be able to use this now correct wind info for FSBUILD again.RgdsReinhard

You are right about this. We as users expect everything to always work as it should and easily blame what seems to be the most obvious reason for our problem. However, consider the following scenario:You have a program that has a Server part ("S") and a client part ("C"). C downloads periodically some piece of data (I'll name it "DT") from S and they both work in harmony. DT may be in a proprietary format (no one should complain). S happens to be on a server in the US and bring down data that have the US -locale. S doesn't know in what country C is (all the server programs are and should be client agnostic for performance reasons). C decodes the downloaded data correctly and C is a time critical applicaiton.Now, let's consider a third application ("X) that claims to support and decodes DT for some functionality. X runs on the client machine and it is not time critical (at least not at the level C is). X may run on a machine with a different locale than S and in that case it cannot decode correctly DT. That's the situation we have here. Possible solutions:1) X changes a line or two of code to decode DT correctly, by knowing that DT has a US locale. In dotNet it's as simple as using NumberFormatInfo.InvariantInfo.NumberDecimalSeparator instead of NumberFormatInfo.CurrentInfo.NumberDecimalSeparator 2) Change C, so that when DT gets downloaded, it reformats it to use the local format AND change the parsing code to accomodate the changes. That means 2 changes are needed for a time critical application such as C, that this way MAY slow down.What do you think is the better solution?Afterall, FSbuild claims to support AS weather, not the other way around.Regards, Kostas

Kostast,Thanks for your input. The only thing is, that Hifi Sim has changed the format for non-US users, which wasn't the same in the past. So they simply should write the old format for all users again - as they did with ASV6.5. That's so simple - but ignored until now.RgdsReinhard