Hello
Once again, a fancy and strange problem was reported to me:
A customer can create and compile Discovery Flights without any error message.
But: The coordinates in all “WorldPosition” elements are generated into the SPB as <WorldPosition>N0° 0' 0.00",E0° 0' 0.00",+000022.96</WorldPosition>. The elevation is the same as the original from the xml.
When I create the identical project on my computer, the SPB is correct. We have now spent several days checking and adjusting the settings with no success.
The machine of the user who compiles it to Lat/Lon 0.0/0.0:
is located in China
Windows settings and main language are Chinese.
it happens regardless of the language settings of MSFS: zh-CN or en-US
Thousand seperator is “,”, decimal sep is “.”
It doesn’t matter if it is connected via VPN to European, American or other servers.
Build via DevMode or fspackage-tool create the same problem.
it happens regardless of where the discovery flight should take place.
the user has two copy of MSFS, one is ms appstore china zone, another is steam us zone, both of them do not work.
English language pack is installed
For completeness: my machine is in DE, it works with US or DE/FR number formats, German or English as Windows and/or MSFS language, DevMode and fspackag-tool, …
@JoshFeng tested and yes, the issue also appears in Landing Challenges and Bush Trips.
See in lc-china-issue.spb the RectangleArea with InstanceId=“{2F687FC9-795A-4125-96D8-01AF38FE8ABF}” for the Landing Challenge and the RectangleArea InstanceId=“{ABE2B8E3-74E6-480E-8D77-E5DBEB66A050}” in the bush trip package bushtrip-china-issue_1.0.0. lc-china-issue_1.0.0.zip (2.0 MB) bushtrip-china-issue_1.0.0.zip (2.5 MB)
The issue happens with a clean community folder, too.
Hi,
we found a temporarily work around for the issue. While trying several things, the user detects, when saving a PLN from world map and reloading it, all locations are set to 0N, 0E, too.
Looking into the PLN, we saw, the degress-sign ° was replaced with a question mark.
Because of this finding, he set the language for “non-unicode-compatible applications” in control panel from chinese to english and the issue is solved. The PLN and the spb-compile bug.
Yes but the root problem is an issue with language support and has other side effects than just mission compilation.
If I understand you correctly, those players are unable to save/load a flight from the world map as the PLN will always be corrupt. This will be tracked at a larger scale if reported through Zendesk.
I’ll add it to our backlog as well.
Would you be able to let us know which value is returned by the Windows “GetACP” function on this machine?
FYI we should already handle issues with the degree sign for Korea, Japanese and Traditional Chinese codepages - however it looks like we don’t do the same thing for Simplified Chinese which may be used on the machine you are using.
In any case knowing the value returned by GetACP should help us fix the issue.
