question

Hello @novreis

GPS waypoint id simvars are limited to 7 characters.
Not sure why the PLN format allows more than that, this will be reviewed internally.

Your instruments will show INDICATED ALTITUDE, not PLANE ALTITUDE and those 2 can be different. This is the expected behavior.

Regards,
Sylvain

Hi Sylvain, thks for your quick answer. Understood the first point but as you say you need to review the code because the PLN file is loaded and work well.

About the second point I am surprised because my WPF application was giving before the same numbers and now there is a discrepance of about 300 feet when the Indicated Altitude is 3000 feet.

I get 25xx at Plane Altitude. As I did not change my variables at my code I cannot understand why! Perhaps because I am flying at Alaska? I will try. at other places. Thks anyway

The devsupport auto-email just decided I might be interested in this question...

So I'll take this opportunity to comment on Sylvain's "GPS waypoint id simvars are limited to 7 characters. Not sure why the PLN format allows more than that, this will be reviewed internally.":

My comment:

The MSFS support for flightplans is already challenging, with the data in the PLN file not being treated as the definitive source but layers of MSFS (presumably ex FSX) code mangling the data as it proceeds through the system. The current API's are circa 2003 if not before with the html/js code seeming to be a shim on top of that. You can see Asobo nav instruments loading the flight plan with Coherent.call("GET_FLIGHTPLAN") and then using hardcoded logic relying on knowing the names of additional inserted non-PLN waypoints such as "if (waypoint_name=="TIMEDCNT") then {skip that inserted waypoint}"

My advice FWIW:

(i) don't recommend retrospectively introducing further restrictions on what can be read from a PLN file, e.g. truncating waypoint names. It's already problematic that waypoint elevations in the PLN file get overwritten by MSFS before being passed to the gauges. It's understandable that some old API's may only show a subset of the data in the PLN file but that is not a good reason to limit newer API's.

(ii) recommend a new 2020's API which would return modern data structures which could include (if really necessary, and appropriately flagged) the added waypoints (like TIMEDCNT) as now but all the data in the original file would still be accessible (like lat longs, elevations, names) rather than being modified/overwritten by obscure layers of MSFS code. The autopilot code and the PLN code really should be layered and separate, rather than the original flightplan being modified to get the autopilot to function correctly.

(iii) possibly the simplest solution would be an additional html/js API call that returns the original PLN XML as either a string or an XML doc, without mangling/discarding anything that was originally in that file. Coherent.Call("GET_PLN")?