Offset 0130 and Mahogany Mtn. (1JY2)

[Jer029]

Peter,

I've encountered an unusual problem with FSUIPC offset 0130 for flight plan path and file name.  Things have been working fine until a user of my program encountered an error on FSX flight plan loading that included 1JY2 as the destination airport.

This appears to be one of the few (perhaps only) airport where the name ends with a period - Abbr. for Mountain as "Mtn.".  This creates an fsx- generated flight plan in the name of:

"VFR Sage Ranch to Mahogany Mtn..PLN".  Note that this  file name has two consecutive periods (one for the end of the file name and the other separating the file extension).

When I read the offset I get all nulls for the remaining 256 bytes after the first period (the second period and extension are ignored).

 

I'm not sure if this is what FSX does, what FSUIPC does, or how the .net library handles it, as I'm using Paul Henty's .net for FSUIPC.

The end result for me is that the flight plan file can't be found and produces an error.  I guess I could work-around this by checking for the valid extension and adding it if missing.

Not sure if I'm messing something up or if this just rarely appears ie. only with this airport and only when this airport is the destination airport.

Removing the one of the periods to create a standard file_name.ext format allows the entire name and extension into memory at 0130 and the flight plan is found correctly.

 

Any ideas?

 

Thanks, 

John

 

 

 

 

 

 

[Pete Dowson]

14 hours ago, Jer029 said:

"VFR Sage Ranch to Mahogany Mtn..PLN".  Note that this  file name has two consecutive periods (one for the end of the file name and the other separating the file extension).

When I read the offset I get all nulls for the remaining 256 bytes after the first period (the second period and extension are ignored).

Hmm. Strange. I'll check my processing of the Plan filename. But I know it does not normally remove the extension, so there's no need for it to search for a period.

The FSUIPC log file will show the Plan name as received direct from SimConnect. What does that show? If SimConnect does this, then all I could do is check for a .PLN ending and add this if it isn't there. This might be the only solution for FSX and FSX-SE (and probably P3Dv1-3) as those sims are unlikely to be fixed (and anyway, they'd probably say don't put periods into flight/plan names).

Of course the quick interim solution would be to save the flight or plan with a name without the period.  Is your program (sorry, I don't know what it is) generating the plan automatically?

I wonder if Flights with such names also suffer. 

Pete

 

 

 

 

[Jer029]

Thanks Pete!,

I wasn't aware that FSUIPC logged the flight plan from sim connect.    It appears then that FSX (sim connect) is the cause (and it's likely that Mahogany mountain (1JY2) is an airport naming error).  Here is the log results of Mahogany Mountain and then a standard flight plan that doesn't end in a period:

OG15-1JY2 (1JY2 as destination airport causes no extension)

 144375 C:\Users\john\OneDrive\Documents\Flight Simulator X Files\VFR Sage Ranch to Mahogany Mtn.

KMSP-KDLH (airport names not ending in period results in proper file extension '.PLN')

 269109 C:\Users\john\OneDrive\Documents\Flight Simulator X Files\VFR Duluth Intl to Minneapolis-St Paul Intl.PLN

My program is an ACARS program that gets flight plan location from offset 0130 and reads the flight plan and populates orig, dest, etc. based on the file information.

I could work around it, but I might just leave it alone since it's just one airport (I think), and it may not even be issue in other sims like p3d that might have corrected this airport name.

 

John

 

 

[Pete Dowson]

49 minutes ago, Jer029 said:

I wasn't aware that FSUIPC logged the flight plan from sim connect.

Well, yes ... but FSUIPC does first try to see if it can change it into a UNC path (one usable over the Network). If it can it will change the path part to suit. But if not (as in your examples), the Logged and 0130 offset version is exactly as received. Even it can match a shared folder, to create a UNC path, it doesn't touch the rest of the filename -- except to add an N to the end if the name ends in .PL. (I think this was because of some earlier bug in FS).

I can esily extend that fix by appending PLN or .PLN as necessary if there's no .PL either, including the period only if there isn't one.

I'll implement it here so it will be included in the next FSUIPC4 and FSUIPC5 update, whenever (I'd rather not release an update with only that change).

49 minutes ago, Jer029 said:

I could work around it, but I might just leave it alone since it's just one airport (I think), and it may not even be issue in other sims like p3d that might have corrected this airport name.

No, P3D3 and P3D4 have the same for 1JY2. I don't think they've changed any of the airport BGLs.

I'll report the bug to L-M. Maybe they'll fix it in a P3D4 update.

Pete