Title & Descr seem to not be formatted correctly.
Confirmed not just me, others have same strange formatting in their FP since SU#5
(FP generated from MSFS World Map page).
Does not seem to upset MSFS itself, but play havoc with any GPS Mod that is trying to read these oddly formatted FPS. (ie PMS50’s Garmin GPSs)
This Format does not follow any documentation in the SDK , so I am assuming it is a Coding error / Bug,
I am having issues when making a flightplan after completing a flight and returning to the world map. While everything looks okay on the world map for the new flight, the gps display shows the previous flight’s route (or other issues) after startup for the new flight. It seems that a couple of flights in succession go okay and then things start going wrong. The only solution seems to be total shutdown of MSFS after a couple of flights. I have no gps mods.
Yes that is true.. but addons should also be able to handle it ! And also.. I wonder if this use of Unicode is legal in an XML file without the use of <DATA tags..
How to.
Open system settings > time & language > region.
Scroll down and click > additional data, time & regional settings.
In new window click Region > administrative tab > change system locale.
Check box - Beta: Use unicode UTF - 8 …
Indeed. That code. It should be in !! I don’t see it in the opening..
Anyway even when VS2019 does not translate these codes either, your display codebase should do that, I think TenPatrol is right, it should be enabled in the application to use Unicode UTF-8.. I see this in Visual Studio.. it does not mark or translate anything..
Of course, because it’s like looking at source code . I would be a problem if VS would markup just ordinairy ascii (ranged characters) which only combined can be parsed into an unicode (bytes) character because the escaping instructs as such. You could try to copy paste a smily into the Descr tag, just to see if the code editor supports unicode .
I would advice against this, this is now applied system wide. I would strongly suggest the app is able to handle unicode. I’m not saying it’s wrong, but could lead to undesired results in other apps which would cause to change it back again.
Also this would not solve the problem with “PMS50’s Garmin GPSs” if unicode is not supported by the app (as in literally applying a specific charset for parsing).
above the SimBase.Document tag, as this would tell a xml parser it may contain utf-8 characters, maybe that solves your problem.
Ok, to be 100% fair, like you already stated the xml definition tag is missing. It should be there in the export ;). so maybe the app is failing correctly because of missing tag it defaults back to whatever CP-1252 or even plain ascii for visual output and can not handle the “weird” bytes..
When I export a simple FP from MSFS, it does include the header
<?xml version="1.0" encoding="utf-8"?>
Perhaps the bug is an MSFS failure, in some circumstances, to not include the header.
I can see that if someone wishes to name waypoints in a language that requires unicode they should be allowed to do so, but still a correct XML header with the correct encoding specified should be in the FP.
(1) My BAD** – I did not include the whole of the FP file, and did not include the
<?xml version="1.0" encoding="utf-8"?>
(2) So you guys are saying that
<Title>†eg" to Daytona Beach Intl</Title>
is OK and that it will be decoded correctly as being utf-8 format.
(3) Ref
Solution.
How to.
Open system settings > time & language > region.
Scroll down and click > additional data, time & regional settings.
In new window click Region > administrative tab > change system locale.
Check box - Beta: Use unicode UTF - 8 …
Click OK and restart now.
That was not checked off in my Install of Windows 10.
Do I NEED to check it off, or should everything in MSFS and any addons work fine without that option being selected in the WIndows 10 OS.
(4) Why would MSFS decide to encode a USA spelt dep[arture airport with utf-8, as it does not include any special characters (and not the Destination Airport)
<Title>†eg" to Daytona Beach Intl</Title>
(5) Do other apps that deal with importing & exporting Flight Plans need to do anything new, if MSFS is starting to use foreign characters and encoding them with UTF - 8
And yes, I do not have much of a clue what I am talking about, but I hope others writing & coding this MSFS stuff, do !!
Well, the xml is completely valid, having the header is mandatory though.
It’s in fact correct the utf-8 characters got encoded in the exported file. It’s the correct way to do it. The application reading the xml should or decode back to the original characters, if it supports unicode. If it does not support unicode, you should see it exactly as in the xml. Except for the quote which is generic unless escaped/encoded characters are not supported at all. The you should see it exactly as un the xml.
To test this, you could replace the encoded part to normal characters so you get
<Title>Test to Daytona Beach Intl</Title>
and
<Descr>Test to Daytona Beach Intl</Descr>
to test if the app/plugin now correctly reads it. If not there is another issue.
If it does correctly read it is possibly parsing the unicode character but is unable to handle it internally or displaying it because the output does not support it.
I personally would not add a beta unicode language pack. Unicode support should come from an app itself as apps should not assume “exotic” packs to be present.
Looks like msfs is applying correct encoding, otherwise you would see something like those diamond shapes or question marks etc. Also depends on the file being utf-8 etc… Im expecting not. A missing header would indeed be something to be corrected to meet compliance and compatibility.
I dont know if waypoints allow characters beyond a-zA-Z0-9. Can’t say any usefull thing about that. But this example is simple title and description, One would expect with internationalisation in mind, It would a cept unicode there. But that’s an assumption from my side.
. I would be a problem if VS would markup just ordinairy ascii (ranged characters) which only combined can be parsed into an unicode (bytes) character because the escaping instructs as such. You could try to copy paste a smily into the Descr tag, just to see if the code editor supports unicode 
.