sorry to lengthen this thread, which I know is just a maybe, but as a bit of help that you can discard guilt-free, here's a Trail* and IGC version of the same file:

Title=Mooney Bravo
Type=Mooney
Model=M20T
ID=SAM292
Airline=
Flight=
Plan= (LSZL-LSZA)
22:04:39,46.1647588519841,8.8744292285602,654,4,77,0
22:04:43,46.1647683258938,8.87449371225494,654,4,77,7
22:04:47,46.1648161050525,8.87481566413328,654,4,78,19
22:04:52,46.1649215326648,8.87564770623158,654,4,78,38
22:04:56,46.1650844753151,8.87682091818211,654,4,77,53
22:05:01,46.1653765777504,8.87882923037018,654,4,78,71
22:05:05,46.1656745462594,8.88099208055504,665,15,77,83
22:05:09,46.1660578493582,8.88353193080254,724,74,75,84
22:05:14,46.1664511673058,8.88585004283501,824,175,75,79
22:05:18,46.1667461845265,8.88781312560532,903,256,77,80
22:05:23,46.1671382773668,8.89046926141607,997,353,75,79
22:05:27,46.1675024116139,8.89271586411786,1006,360,76,92
22:05:32,46.1679117119701,8.89581546911534,1027,378,79,102
22:05:36,46.1682079243516,8.89902799149374,1022,370,82,114
22:05:40,46.1684001410901,8.90214337755123,1026,375,85,123

And IGC:

AXXX Plan-G v2.05 (build 432)
HFDTE250311
HFFXA035
HFPLTPILOTINCHARGE: pilot SAM292
HFCM2CREW2: not recorded
HFGTYGLIDERTYPE:Mooney M20T
HFGIDGLIDERID:SAM292
HFDTM100GPSDATUM: WGS-1984
HFRFWFIRMWAREVERSION: 2.05 (build 432)
HFRHWHARDWAREVERSION: 2011
HFFTYFRTYPE: Plan-G by Tim Arnot
HFGPSGPS:Microsoft Flight Simulator
HFPRSPRESSALTSENSOR: Microsoft Flight Simulator
HFCIDCOMPETITIONID:SAM292
HFCCLCOMPETITIONCLASS:
I043638FXA3943TEN4446HDT4750GSP
L PLAN-G Plan (LSZL-LSZA)
B2204394609886N00852466EA0019900199027000010770000
B2204434609886N00852470EA0019900199027000010770013
B2204474609889N00852489EA0019900199027000010780035
B2204524609895N00852539EA0019900199027000010780070
B2204564609905N00852609EA0019900199027000010770098
B2205014609923N00852730EA0019900199027000010780131
B2205054609940N00852860EA0020200202027000050770154
B2205094609963N00853012EA0022000220027000230750156
B2205144609987N00853151EA0025100251027000530750146
B2205184610005N00853269EA0027500275027000780770148
B2205234610028N00853428EA0030300303027001070750146
B2205274610050N00853563EA0030600306027001100760170
B2205324610075N00853749EA0031200312027001150790189
B2205364610092N00853942EA0031100311027001130820211
B2205404610104N00854129EA0031200312027001140850228

i.e. if you *wrote* an IGC file it would look something like above, and if you *read* an IGC file it would be similar except the 'B' records would be unlikely to have AGL,heading,groundspeed. If you got fancy you'd find the IGC file can actually contain the waypoints of the flightplan (sim_logger for FSX actually stores the flightplan as well as the trackpoints). As with everything IGC, it is trivial to skip e.g. flightplan records in the IGC if you want to ignore them. The *units* of IGC 'B' record fields are specified (meters, kph) as well as the format of lat long  - so these were translated by me from your Trail* format (feet, knots) also.

There *will* be other records in any IGC file you read, i.e. the logger may store wheel-up events or something, but the simple trick is the first couple of letters of every line tells you the record type so *only* read records you're looking for (i.e. mostly B) and skip anything else.

thanks Tim - kind of you to consider it.

If you use the IGC file format, you'll find all the existing plan-g trail record fields can be shoehorned into the existing IGC tracklog 'B' record one-for-one. The subtlety will be the IGC default B record is time,lat,long,alt and I assume you'd want to add speed, heading and height AGL - the IGC format has a method of defining appended additional fields via a header 'I' record, where you'd append 'GSP' for 'groundspeed',  'HDT' for 'heading true', and probably repurpose 'TEN' (total energy altitude) for your use as alt AGL.  The file spec is here http://carrier.csi.cam.ac.uk/forsterlewis/soaring/igc_file_format/index.html

Great software - thanks.

Some of us create flight 'trails' both within and without Plan-G. It'd be nice to use Plan-G to display them. There are two slight issues: (1) Plan-G uses a 'folder' icon on the Trail Analysis side menu to load a trail, which is honestly IMHO a very strange place to have it (vs. the File Load menu) unless you totally get how Plan-G trails are 'different' from trails you load in any other similar program and (2) the trail format being unique to Plan-G obviously limits the utility of that function.

re (2) I could program gpsbabel to recognise yet another 'trail' format, but it's a shame that's necessary and no-one else seems to have done it, and we'd still need to circulate around that converter style for anyone to use it. There are quite a few other formats that are almost identical to Plan-G trail files (my suggestion would be IGC, as that's the only aviation-related standard of any heritage).

thanks again -- B21

Msoft switched from ascii to Unicode for the flightplan with FSX (but not the other FSX text files...) It seems like the Plan-G FSX flightplan isn't being written quite correctly as a Unicode file...

I've attached a simple Plan-G plan to show the issue - simplest test is to open it in Wordpad and you see the 'degree symbols' display incorrectly in fields such as DepartureLLA. I was able to use a text editor (the excellent freeware Crimson Editor) to load the file and then save it as Unicode, which worked fine.

FSX *will* read the Plan-G flightplan ok, so its input routine is ignoring the text between the degrees and minutes (where the degree symbol appears), so this isn't an issue for most of your users. I am reading flightplans into my FSX module sim_logger (an IGC-format secure logging utility) and hit a glitch reading Plan-G flightplans, although I was reading FSX flightplans without a problem so I took a deeper look. I've implemented a workaround in sim_logger (mentioned below) but thought you should be aware.

(In VC++) I open the flightplan file for a unicode read:
fopen_s(&f, filepath, "r, ccs=UNICODE")
then loop reading in lines with
fgetws(in_buf, MAXBUF, f)

Given an LLA string such as
<DepartureLLA>N50° 55' 32.08",W0° 28' 12.51",+000107.30</DepartureLLA>
I use sscanf with the format string including the degree symbol
"%c %d° %d' %f\", %c %d° %d' %f"
(FYI I ignore the altitude element on the end)

This works for FSX but for Plan-G it fails to parse the record due to the 'degree symbol' issue.  My workaround is to modify the sscanf format string
"%c %d %*s %d' %f\", %c %d° %d' %f"
i.e. there is  %*s (ignore multiple non-whitespace chars) where the degree symbol used to be.

My guess  is when you open the file for writing, you're not using the 'open unicode text file for writing' call in whatever language you're using so it's ending up as ascii with a double-byte degree symbol (just a guess).

Not a problem for the vast majority of users I'm sure, as FSX loads these flightplans fine.

B21