Formatting error in Flight Plans since SU#5?

 AceXML Document   
    †eg" to Daytona Beach Intl >  
    N28° 17' 23.30",W81° 26' 13.50",+000078.50     
    N29° 10' 47.67",W81° 3' 28.95",+000031.16
    †eg" to Daytona Beach Intl   
    Kissimmee Gateway  
    Daytona Beach Intl

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,

@sylvain Does your “like” mean that you also see this as a Bug, and that it
might get onto a “to be fixed” list ?

A little more detail.

AceXML Document aSaeCu to Kissimmee Gateway Departure name wrong VFR
3400.000 KISM N28° 17’ 23.30",W81° 26’ 13.50",+000078.50 KISM N28° 17’
23.30",W81° 26’ 13.50",+000078.50 aSaeCu to Kissimmee Gateway Departure
name wrong
24 Kissimmee Gateway Kissimmee Gateway 11 282174 ****

€nc@u to Kokhedsfältet Airstrip VFR 9500.000 BIHV N65° 16’ 8.01",W20° 50’
53.47",+000155.76 ESAB N66° 9’ 0.79",E21° 2’ 7.56",+000220.56 €nc@u to
Kokhedsfältet Airstrip NOT OK, Departure wrong 36 Krókstaðarmelar
Airport OK Kokhedsfältet Airstrip OK 11 282174

Kokhedsfältet Airstrip = “Kokhedsf a… ltet Airstrip” (a with 2 dots above
it ) = OK UFT-8 Encoding but why has Kissimmee Gateway been coded as
a SaeCu because it does not contans any foreign characters ?
To Reproduce, make a FP in World Map KISM to KISM

A Flight lan made in Little Nav Map has correctly displaying foreign
characters BIHV to ESAB IFR Direct 11000 BIHV N65° 15’ 47.63",W20° 50’
45.22",+000156.00 ESAB N66° 9’ 0.80",E21° 2’ 7.57",+000221.00 BIHV, ESAB 36
Krókstaðarmelar Airport Kokhedsfältet Airstrip Note: LNM uses ICAO codes in
Title MSFS uses Full Names But this is not about LNM – its about MSFS
generated FPs from World Map

A further Comparison between MSFS & Little Nav map. Not saying LNM is the
correct Standard, but clearly showing that the MSFS has “issues” Note: SDK
states that should be ICAO Codes LNM does this correctly MSFS uses the full
airport names MSFS is missing the Departure Airport in the (major BUG ) MSFS
and are some strange formatting, while LNM is displaying the names correctly,
with their foreign character set

So what does this matter – is it really that important ? YES (1) It seems
to be a degradation in SU#5 (2) It creates an issue with any GPS system trying
to read these flight plans (3) The MSFS FP is not following the SDK (
Title should be ICAO codes) and Departure should be in the Title

I am not the only one questioning this formatting, ie These are not
[character] escape codes, if you have noticed. [ 4:18 PM ] So while it is
acceptable to just smash in some char escape codes for characters with
diacritics regardless of what encoding is actually used, their new approach is
literally a terrible one: 1) declare UTF-8 2) slam in escaped octets (bytes if
it is easier to understand) inside the XML [to reiterate, these are NOT
escaped characters; these are bytes (binary data) inside XML] 3) when parsing
the xml, parse out all the bytes of the name/description elements ( instead
of just using XML text parsing
) 4) decode those bytes using UTF-8 and get
the final text for those elements so in the end you get a truly brain-damaged
approach which is, no matter how you look at it, WRONG and NEEDS to be

I’m checking with the devs in charge of this.

Thanks … The Little Nav Map develeloper is probably also interested in this,
as his App exports and imports MSFS compatible Flight Plans

Geoff, Given you’re saying this

AceXML Document

aSaeCu to Kissimmee Gateway **Departure name wrong** 

And you’re saying it’s wrong, could you write out what you’re expecting is the
“right” Departure Name? I couldn’t find what you think is the correct wording
in your description, or explanation why you think it’s wrong. I’m not saying
you’re incorrect in your description, I’m just wondering what the right text
would be.

Hello. We identified and fixed the bug. The problem was with the way these
strings were written by the game (bad encoding). About the content, AFAIK the
doc does not state that it must contain ICAO codes. It’s more of a common
practice. Does LNM relies on Title containing ICAO to ICAO format ? Regards,

Thanks Sylvain. Good to know the cause has been identified and fixed,
Hopefully, that fix will be in the next update I believe LNM created the .pln
with the ICAO codes in both & The issue with LNM was in reading those
inserted non UDF-8 hex code escape sequences when trying to have LNM (or a
MSFS) read those oddly encoded .pln files, and of course the instances where
theh Departure airport was sometimes completely missing in and/or Thanks

Sylvain, As well as the Encoding issue, did you also catch the Missing
Departure Airport name ? Just making sure I correctly conveyed both the Bugs


We think it’s a side effect from this corrupted substring starting with a
string termination char. Is it happening 100% of the time when starting from
Kennedy Intl?

Maybe, lets assume it was caused by the incorrect string terminator character,
which has now been fixed. I’ll do some further tests - because: I think I
saved this .pln file during flight, and the save options were initially just
for .flt I forced the issue and forced it (it would seem) to save as a .pln,
but in forcing it to save as a .pln, it might have caused the missing
departure airport. This actually bring up another question. Why, when in World
Map, is there the option to save/load both .pln & .flt files, but after
starting flying, and then ESC, the save option only gives the selection to
save as a .flt ?