How may I introduce GPS coordinates as a waypoint in Prepar3D?

[SteveW 1,792]

Yes the problem with other than US English the edit boxes show a zero and cannot be used. The PC must be set to US English number formats to use the Edit Waypoint function.

[wipeout01 0]

Gracias, wipeout01

 

Gracias a ti amigo

Yes the problem with other than US English the edit boxes show a zero and cannot be used. The PC must be set to US English number formats to use the Edit Waypoint function.

 

No. World exist outside the United States and the United Kingdom, and of course normal users won't set their regional settings to the US settings in Windows, everytime they run the simulator. No that would be a very painful job to do, all the time, also unrealistic since a practical point of view. People install Windows, set the settings to the regional settings of their countries and the software adapt itself to the settings.

 

As I said, Lockheed Martin 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... ???

 

Since a programmer point of view (and I am also a computer programmer) solving this issue requieres just 1 or 2 lines of code. Perhaps, even less. It's a minor issue to solve since a programmer's point of view, and could give many headaches to many users.

The result is this conundrum. See the map.

 

[hesynergy 67]

In my best Emily Litella imitation.....

 

 

"NEVERMIND!"

[WarpD 824]

wipeout01... doesn't really matter what you think. L-M has stated they will only support US locale settings... it is what it is.

[wipeout01 0]

WarpD the problem is you don't read the thread in full, then you are posting messages that have no sense. To understand this bug, you need watch the video in full and read the messages in full, describing the bug.

I will summarize this. Please, pay attention and read well.

 

Seems to be you did not understood the error.

 

FIRST THING, YOU HAVE THE WATCH THE VIDEO IN FULL.

 

Then, please read this.

 

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 (it use the locale settings).

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. If you introduce coordinates using the point, US Standard with a computer in Spain, you drive crazy to Prepar3D and get weird results in the map.

When showing results use a point (US Standard), when inputting results, need a comma (locale settings, Spain).

This evidently confuse the users and consequently it's a clear bug.

 

If Prepar3D use always the US Standard, it need to show the results with a point as a decimal separator, and also using a point when inputting the coordinates, AND NOT using the locale settings from Spain.

 

I can't explain this more easy. Please, read the post in full.

 

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

[WarpD 824]

Yeah... set your locale to US English like L-M says it needs to be... no bug. Doesn't get any easier than that.

[Lorby_SI 2,038]

Yeah... set your locale to US English like L-M says it needs to be... no bug. Doesn't get any easier than that.

 

I can't find this in the list of System Requirements on the Prepar3D site. Should IMHO be in there if it is a prerequisite.

[wipeout01 0]

Well WarpD I guess you want finish with the last message in the thread and you want "to be right", at any cost. In urban dictionary usage, I'd say this is "trolling". Never understood why trolls act this way, but it's the same. If you want to be the only one thinking this is not a bug, fine. For me it's perfect.

 

For me it's the same, however I consider necessary explaining why this is a bug. Not you, I know it will be completely impossible to have a reasoning with you, so I explain this to all the users (except you, of course)

 

The reply to you is: YOU ARE RIGHT. Okay? So we save time.

 

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. It show results with a point, it must accept results with a point too. As simple as that. End of the question. Finish. Kaput.

 

Softwares are intended for human beings and not to confuse the users. That's not an opinion, that's real.

 

The problem is: P3D is showing coordinates using a point as decimal separator, and then, when inputting the results, it ask for a comma (other different decimal separator).

 

So, it shows a point as decimal separator, and then, when you enter a value, it expect a comma as decimal separator.

 

Any people with a bit of "normal common sense" can see something is wrong here.

 

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.

In this way, a computer program can work everywhere assuring always the results you input, will always works fine and be corrected properly. That would be a kind of autocorrection, like the one you find in Google when searching.

 

The problem here, is, many people doing these changes in Windows, accept this, as it is, because it is. End of the question.

No. To change a bulb you don't need to learn how to be a monkey and jump over the room until you finally get the bulb on the roof.

To change a bulb you only need a staircase. As simple as that.

 

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 can work with that result. 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.

 

When a computer program is correctly developed, the first thing it will do, is asking the system the locale settings and adapting itself to the locale settings for basic input / output operations.

 

However, if that involve to change a lot of code, that it doesn't, there are other solutions, like getting the results into a temporary variable of the string type, and then, reading character per character to find decimals separators and correct them on the fly in other temporary variable, until you finally provide to the code the right value.

 

In other words, that you can correct this kind of silly errors very easily.

 

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. I am a programmer, and I know what I am talking about.

 

And if someone is telling this is not a bug, it's simply a lie. Perhaps for trolling, popularity reasons or who knows, everything else.

[WarpD 824]

Well... I'm certainly not a programmer so...

[wipeout01 0]

As I programmer I am, I know this is a bug. Cheers

[vc10man 732]

Can this now be brought to a conclusion, moderators?

[hesynergy 67]

+1 we all understand your frustration...but face the fact that things are not likely to change....you have heard the real solutions, and band aids to the problem...anything more is an ego trip through he said, she said they said...

 

 

Submit your cause to LM, and deal with the answers you have been, given including by those of us who never understood your plight in the first place.

 

Chas