MSFS20 AIFP 3.4.3.7 - Attention Region Settings Changes Win10 21H1

[JanMartinHamburg]

Changed my Region Settings back to "Germany" for different purposes some days ago. When setting it back to "English (USA)" for enabling BGL / MDL compiling today, latitude and longitude formats appeared without dot and also without comma in AIFP, resulting in compiling errors.

The displayed format in AIFP at DD.dddddd was for example :
NFFN
-177584901452065*
177441913336515*

I used Windows System Restore to get my previous Region Settings back, that worked, and also, AIFP displayed latitude and longitude formats correctly again.

When trying to repeat and reconstruct the problem by changing the Region to "Germany" and - after a Windows reboot - back to "USA" once again, latitude and longitude formats remained without dot and also without comma in AIFP. I could get the functionality back only by using Windows System Restore again.

It does not seem to affect GMAX / MCX aircraft and or scenery model export to MDL format, which also requires region "USA". Both these tools worked after changing to "Germany" and back to "USA" without any need to restore anything with Windows System Restore. It only affects AIFP for me.

Later - and despite - the problem popped up and I eventually solved it by deleting files:
Airport_Kill.dat
Airport_Temp.dat
AirportList.dat
AirportList.dat.bak

After restarting AIFP everything was fine again; but previous data in these files would be lost of course ...

 

[gadgets]

AIFP typically saves geographic positions in whatever format they are entered (".", ",", etc) and simply replaces the "," with a "." when computing. No one has ever reported the problem you are having to my recollection. But, you did mention MSFS in your title.

It's possible I missed something when I added compatibility for MSFS.

If you could give me a specific example of the error, I'll investigate.

 

[JanMartinHamburg]

Of course, there were error messages at compiling; translated to English, something like "unable to save traffic file / arythmetic operation caused an overflow" or so, nothing more, no crash of program; and yes, I only have MSFS on my system. Just found out, AIFP also compiles at comma settings - region "Germany" -, but have no idea whether the created BGL then is still a valid and working file. So, only solution is to delete the 4 files stated in my above post.

 

[gadgets]

None of that should happen.

"Arithmetic operation caused an overflow" is indicative of a different problem. Please post the flight-plan file set/traffic file that causes this error when you compile as well as telling me which options you have selected and any other relevant settings. Indeed, it might be helpful if you posted your whole AIFP folder as well.

 

[JanMartinHamburg]

Well; I've already wasted some hours with this issue, to make compiling work again. Did not change any settings in AIFP. Attaching the FP files ...

 

[gadgets]

I compiled without error for both US and German keyboards using AIFP as it comes "from the box". I also checked the geographic positions in AirportList.dat were in comma format when German language was selected and automatically changed back to period format when reverting to US. Perhaps you didn't close and restart AIFP after changing language/regional settings.

I'm happy to try to get to the "bottom of this". But, without being able to duplicate your condition, there's not much more I can do - and for that I need your input. However, I infer from your message you are now generally satisfied that you can manage as is. Your choice.

 

[JanMartinHamburg]

Perhaps you didn't close and restart AIFP after changing language/regional settings.

So, this would be a simple explanation, wouldn't it be? But it isn't, since I never change system settings with any open program.

I'm happy to try to get to the "bottom of this". But, without being able to duplicate your condition, there's not much more I can do - and for that I need your input.

Yes, you need to be able to replicate the problem. Maybe you would need a computer that is "native" German sold, or so, for that.

But, obviously, you checked the content of the *.DAT file; in case, AIFP ignores any dot or comma in the file when reading it out, and thus displays lat and long values without any dot or comma, though there are such commas or dots in the *.DAT file? I will try to check this in the next days when I have time.

 

[gadgets]

AIFP ignores any dot or comma in the file when reading it out, and thus displays lat and long values without any dot or comma, though there are such commas or dots in the *.DAT file?

You have a choice of display formats. All should display with a "." or ",". Under what circumstances does it not., please?

 

[JanMartinHamburg]

Hey Don,
I'm afraid, I've got something for you ...
Please take a look to the attached ZIP and the DatFile sets. In "DatFiles 03 Region USA After Change Back From DE" for example, there are both AirportList.dat and AirportList.dat.bak not displaying any comma or dot in the lat and long data when opened with Notepad++ on my system. AIFP was always closed when doing changes to regional settings.

 

[gadgets]

I have repeatedly tested switching from US to German language and, as far as I can see, the ","s and "."s are up[dated properly. However,I can see from the data you provided that at some point, the positions data in AirportList.dat has neither "." or ",".

I suspect this is some intermediate state but I can find nothing that would cause it,

What I still need is for you to tell me the exact sequence of operations, step by step. that will allow me to duplicate this situation.

 

[JanMartinHamburg]

- change region
- open AIFP
- open any FP (set of 3 txt files)
- click any airport
- see lat / long without comma or dot like

The displayed format in AIFP at DD.dddddd was for example :
NFFN
-177584901452065*
177441913336515*

 

[gadgets]

Found the problem. Turns out the VB.Net "Parse" function simply eliminates whatever decimal separator is in a numeric string if it doesn't match the one in the Current Culture. The reason I had difficulty finding it is that in AIFP's debug mode, AirportList.dat is regenerated on each startup. For users, for response reasons, the list is only regenerated if the base data has changed. Since the base data doesn't change when the region changes, the old data in AirportList.dat was re-used, with the separator being lost.

I'm working on a fix that detects a change in decimal separator and, if changed, AirportList.dat will be regenerated. Hopefully the fix will be available tomorrow. In the meantime. you'll have to manually delete AirportList.dat if you change region/language such that the decimal separator changes.

 

[JanMartinHamburg]

Glad, you could find the problem, Don; thanks much!

 

[gadgets]

Please confirm that the problem is fixed.

 

[JanMartinHamburg]

Hi Don,
sorry for the delay; family issues. I can confirm, that AIFP 3.4.3.8 works correctly, creating AirportList.dat with comma or dot, according to regional settings. Switching between different regions does not cause any problems. There is a new file named AIFP3.pdb ?

 

[gadgets]

Thanks for confirming.

The .pdb file is not necessary for users. It contains debugging data. It was included in error and can be deleted if you installed it.

I'll update the general release.