Hi,There is a big difference in the wx_station_list.txt file (maybe only for non US users) compared to ASV6: In ASV6 you always used the comma "," as the list seperator and the decimal point "." as the decimal seperator. So the wx_station_list.txt under ASV6 looked like this:

AGGH,-9.421,160.052,9,9.1AGGL,-10.7,165.8,3,10.1AGGM,-8.32,157.262,2,8.4

With ASA you are dynamically downloading this list to the PC but this list make use of the local language settings for the coordinates but not for all values! So look at the difference for ASA:

AGGH,-9,417,160,050,0.0AGGL,-10,683,165,800,0.0AGGM,-8,317,157,267,0.0

As you are now providing the comma for list seperation AND for the decimal point (at least at the coordinates and maybe only for non US users), 3rd party products using this file (like FSBuild) cannot handle this format any longer. So please change back to the old format.RgdsReinhard

Hi,Let's see what we can do here.Here is my ASv6.5 selection:AGGH,-9.421,160.052,9,9.1AGGL,-10.7,165.8,3,10.1AGGM,-8.32,157.262,2,8.4ANAU,-0.55,166.915,6,9Here is my ASA selection:AGGH,-9.417,160.050,0.0AGGL,-10.683,165.800,0.0AGGM,-8.317,157.267,0.0ANYN,-0.550,166.917,0.0Now to my eyes these are both the same. Yes, I am using English(United States).With that chosen, my decimal separator is (.)and my list separator is (,) I believe. On that screen I can't tell the difference between a comma and decimal.What language settings are you using so I can try to duplicate this?Thanks,

Hi,I am using German(Austria) as my regional setting. My OS is Vista Home with the latest SP. I had it installed also on an old NB with WIN XP: Same result.My wish is, that you always use comma as seperator and and the point as decimal point. So the FSBuild integration will work in the same way as before.RgdsReinhard

Hi,We have not changed the format and many users are using FS Build successfully. I loaded that language and you need to make sure that the decimal symbol is the period(.) the digit grouping symbol is the comma(,) and the list separator is the comma(,).Can you please double check these for us?Thanks,

Jim,If I change the number format, then the output file has the old format and then FSBuild is able to use this file. If I use the standard regional settings of my location then FSBuild uses the data but finds totally wrong weather stations. You can check this by showing theses column in the navlog.BUT: The current implementation is only half of the truth. If you look in detail into my example, you will see, that for the last column you are NOT using the decimal point of the local language setting but always the point. And you are NOT using the list seperator from the local language setting, which is a semicolon in the German settings.So there are two possibilities: (1) You could force the old format by always using the US system regardless of any language setting. In that case all the addons relying on this file would work worldwide in the same way as before without any modification. And you have one format worldwide.(2) You are consequently using the regional settings for ALL elements in the file and force the addon suppliers to adopt their programs.For me the alternative 1 seems to be the better and simpler one. Of course you have not changed the format but you might use now another function to format the number for output, which takes the regional settings into account.RgdsReinhard

Hi,I asked Damian about this and both he and I believe that we are using the same formats for the weather snapshot file.Thanks,

Hi,But you are now producing a wx_station_list.txt file while in ASV6.5 you have a static one. Of course you produced this file once with your regional settings and therefore this never got a problem.With ASA you are producing this file out of the download data at every run. Again the following questions remain:Why don't you produce the same format for all columns?Why don't you use the regional settings for the list seperator?Or: Is it possible to force the US settings during output for all columns (like you do already for the lastone), so that the problem could be eliminated worldwide?It is not appropriate, that users should manipulate their regional settings, as this leads to a lot of problems with other software (e.g. electronic banking etc.).RgdsReinhard

For better readability I copy here my samples with a better font:ASV6.5

AGGH,-9.421,160.052,9,9.1AGGL,-10.7,165.8,3,10.1AGGM,-8.32,157.262,2,8.4

ASA

AGGH,-9,417,160,050,0.0AGGL,-10,683,165,800,0.0AGGM,-8,317,157,267,0.0

Look at the ASA sample: Only the last column has a point ?!? So there is a difference in formatting the numbers.RgdsReinhard

Hi,Any news for this topic? Will you fix it in the next build?RgdsReinhard

Hi,I am not sure as I have not seen the next build yet.

Jim,Have you found the problem in the meantime and will you publish a fix for this problem? Without converting back to the old format (in terms of the handling of decimal points) for international users, ASA cannot be integrated with FSBuild. From a technical point of view it doesn't look very complicated.This issue is one of the biggest blocking points for me at the moment to use a product, although I have paid for it. So I stayed with ASV6.5 and I have "stranded costs". To explain my procedure flow during flight planning here the steps I take:

• I download a snapshot of the current weather with ASV6.5 for FSBuild
• I plan my route including fuel calculation with the winds aloft using FSBuild
• I import the generated flight plan into ASV6.5 to get the route briefing

As I am able to integrate only with a single weather program and because ASA generates a different format (in the international version) which cannot be read by FSBuild, this flow is not possible at the moment with ASA. Hope you find a solution.RgdsReinhard

Hi,No, we have not found the problem and you are the only international user to report this issue and we also know the fix is to change the setting in Windows. We still believe that the formats are the same just as we did on June 15th.Thanks,

Hi,I am definitely not the only international user reporting this problem. If you look at the FSBuild forum, you will find other users having the same problem. Please look in detail in the samples I provided to you, that there is now a difference. This might arise from the fact, that the libraries you now use to produce formatted output show a different behaviour (e.g. taking the l

Hi,The raw data structures have not changed. How they are being shown on your system is beyond our control. The suggested fix has been made quite awhile back in this thread. At this time that is all I can suggest.

Hi,I am definitely not the only international user reporting this problem. If you look at the FSBuild forum, you will find other users having the same problem. Please look in detail in the samples I provided to you, that there is now a difference. This might arise from the fact, that the libraries you now use to produce formatted output show a different behaviour (e.g. taking the l