I've opened this thread for the LM team responsible to develop Prepar3D.
In this video I am showing an error in which P3D v3.1 is showing incorrectly the coordinates in computers abroad the United States and separating decimals with a comma and not with a point.
The problem is the P3D confuse the users, because it shows the coordinates separating the decimals with a point. But, when you introduce coordinates separating the decimals with a point and you are abroad the US, P3D get's absolutely crazy and get strange red lines crossing the earth :D
You will see that in the video.
The solution is simple.
P3D must show the coordinates using the locale settings of the computer and not a point always, which is the US standard.
When P3D input coordinates, it doesn't accept the US Standard, it use the locale settings from the computer, however, when it shows the coordinates, it always use the US settings, so this confuse the users when introducing coordinates.
PLEASE, SEE THE VIDEO DEMONSTRATION OF THE BUG HERE (IN ENGLISH):
https://youtu.be/Xv09VfjWioQ
I also discover other bug, when creating waypoints. The red line cannot create a waypoint when we click over it, if we have a high zoom rate.
By the way, hope my english spelling be okay for you?
Cheers
Bug discovered in P3D v3.1 (locale settings and inputting coordinates)
Re: Bug discovered in P3D v3.1 (locale settings and inputting coordinates)
You have two options to solve this bug.
1. Use the regional settings from the computer Prepar3D it's installed to show the coordinates and also to input the coordinates. In other words, if Prepar3D it's installed in Spain, you must show the coordinates with a comma to separate decimals. Also when inputting coordinates, you must accept you separate decimals with a comma.
OR...
2. Use always the US locale settings, displaying a point to separate decimals and accepting you input coordinates with a point when separating decimals.
What you cannnot do is: Using the US locale settings to display the coordinates and using the system regional locale settings to input the coordinates. It display the decimals separated by a point, when you introduce the decimals it expect a comma... ???
The result is this conundrum. See the map.
PLEASE, SEE THE VIDEO DEMONSTRATION OF THE BUG HERE (IN ENGLISH):
https://youtu.be/Xv09VfjWioQ
1. Use the regional settings from the computer Prepar3D it's installed to show the coordinates and also to input the coordinates. In other words, if Prepar3D it's installed in Spain, you must show the coordinates with a comma to separate decimals. Also when inputting coordinates, you must accept you separate decimals with a comma.
OR...
2. Use always the US locale settings, displaying a point to separate decimals and accepting you input coordinates with a point when separating decimals.
What you cannnot do is: Using the US locale settings to display the coordinates and using the system regional locale settings to input the coordinates. It display the decimals separated by a point, when you introduce the decimals it expect a comma... ???
The result is this conundrum. See the map.
PLEASE, SEE THE VIDEO DEMONSTRATION OF THE BUG HERE (IN ENGLISH):
https://youtu.be/Xv09VfjWioQ
Re: Bug discovered in P3D v3.1 (locale settings and inputting coordinates)
I use the regional settings for use the decimal point instead of the comma and the same manipulation as your works perfectly in France.
Re: Bug discovered in P3D v3.1 (locale settings and inputting coordinates)
I created the same flight plan as your and everything is OK in P3D.
I also copied the coordinates since GoogleEarth. The problem comes maybe from your version of GooglEarth.
I also copied the coordinates since GoogleEarth. The problem comes maybe from your version of GooglEarth.
Re: Bug discovered in P3D v3.1 (locale settings and inputting coordinates)
No, the problem don't come from other software.
Seems to be you did not understood the error.
FIRST THING, YOU HAVE THE WATCH THE VIDEO IN FULL.
I will explain this easy.
In computers from Spain:
- Prepar3D show the coordinates with a "point" decimal separator (US Standard)
- When you introduce coordinates, Prepar3D don't accept the "point" as a decimal separator (US Standard), instead, Prepar3D need a comma as a decimal separator.
CONCLUSION: In computers from Spain, Spanish, Prepar3D is showing decimals separators with a point (US Standard) and when inputting coordinates to it, Prepar3D don't use the point as a decimal separator, it need the locale settings in this case a comma.
When showing results use a point, when inputting results, need a comma.
This evidently confuse the users and consequently it's a clear bug.
If Prepar3D show the results using a point (US Standard) it must use also a point (US Standard) when inputting results to it, and not a comma.
Cheers
Seems to be you did not understood the error.
FIRST THING, YOU HAVE THE WATCH THE VIDEO IN FULL.
I will explain this easy.
In computers from Spain:
- Prepar3D show the coordinates with a "point" decimal separator (US Standard)
- When you introduce coordinates, Prepar3D don't accept the "point" as a decimal separator (US Standard), instead, Prepar3D need a comma as a decimal separator.
CONCLUSION: In computers from Spain, Spanish, Prepar3D is showing decimals separators with a point (US Standard) and when inputting coordinates to it, Prepar3D don't use the point as a decimal separator, it need the locale settings in this case a comma.
When showing results use a point, when inputting results, need a comma.
This evidently confuse the users and consequently it's a clear bug.
If Prepar3D show the results using a point (US Standard) it must use also a point (US Standard) when inputting results to it, and not a comma.
Cheers
Re: Bug discovered in P3D v3.1 (locale settings and inputting coordinates)
The French version of Windows gives the comma as the decimal separator.
To pass in the US standard it is necessary to change this "," in "." in the regional parameters, what I'm doing for years.
This makes, everything works perfectly in P3D and others.
As I said it higher, I redid your flight plan such as described in the video, my copy/write is perfectly accepted by P3D.
Your problem is not thus, in my opinion, a bug of P3D.
To pass in the US standard it is necessary to change this "," in "." in the regional parameters, what I'm doing for years.
This makes, everything works perfectly in P3D and others.
As I said it higher, I redid your flight plan such as described in the video, my copy/write is perfectly accepted by P3D.
Your problem is not thus, in my opinion, a bug of P3D.
Re: Bug discovered in P3D v3.1 (locale settings and inputting coordinates)
Maybe it would it be possible, for LM, in future releases of P3D, to compile P3D with Localization forced to USA within P3d ?
Re: Bug discovered in P3D v3.1 (locale settings and inputting coordinates)
One thing is changing the regional parameters and other different thing is a software, let's say P3D or let's say other software confuse the user.
If the software present a number using a point as a decimal separator, then, when you input results to that software it must accept a point as a decimal separator, and not the locale settings.
The problem is: P3D is showing coordinates using a point as decimal separator, and then, when inputting the results, it ask for a comma.
That is a bug.
Why?
Because when you create a computer program and you input a value, you can load that value in a temporary variable of the string type, and then, analyze character per character. With this information, you can locate decimal separators and correct them on the fly, changing a comma for a point or viceversa if necessary.
The problem here, is, many people doing these changes in Windows, accept this, as it is, because it is. End of the question.
Well, I am a computer programmer also, so I know very well when you input a result, it goes to a variable, and then you get that result. As a computer programmer I am, I know this is a bug (not all people have this knowledge) and also I know when you input a value, you can analyze the result character by character, also knowing what kind of decimal separator is being used, and correct it on-the-fly, to avoid this kind of problems.
Probably normal users don't accept this as a bug, because they simply think, this is the only way to make Prepar3D work, changing all the time the regional settings... but, no... I am sorry. This is clearly a bug.
If the software present a number using a point as a decimal separator, then, when you input results to that software it must accept a point as a decimal separator, and not the locale settings.
The problem is: P3D is showing coordinates using a point as decimal separator, and then, when inputting the results, it ask for a comma.
That is a bug.
Why?
Because when you create a computer program and you input a value, you can load that value in a temporary variable of the string type, and then, analyze character per character. With this information, you can locate decimal separators and correct them on the fly, changing a comma for a point or viceversa if necessary.
The problem here, is, many people doing these changes in Windows, accept this, as it is, because it is. End of the question.
Well, I am a computer programmer also, so I know very well when you input a result, it goes to a variable, and then you get that result. As a computer programmer I am, I know this is a bug (not all people have this knowledge) and also I know when you input a value, you can analyze the result character by character, also knowing what kind of decimal separator is being used, and correct it on-the-fly, to avoid this kind of problems.
Probably normal users don't accept this as a bug, because they simply think, this is the only way to make Prepar3D work, changing all the time the regional settings... but, no... I am sorry. This is clearly a bug.
