Simconnect bugs at GPS WP NEXT ID and PLANE ALTITUDE,feet"

There is already one question about GPS WP NEXT ID that says one character is
cut but my experience says that are more than 1. At my WPF application I load
a PLN file with custom waypoints and simconnect is retrieving only seven
characters when the name of waypoint is more than this length (wp1000m instead
wp1000mm69 for instance). Another recent bug is the PLANE ALTITUDE, feet that
returns a value different from the one shown at the instruments. I say bug
because my application was working well and both values were similar what does
not happen anymore! Thanks

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

You need to adjust your indicated altitude for ambient pressure. If the
current ambient pressure is different from the QNH set in your instruments,
plane altitude and indicated altitude will not match.

Yes, I begin to understand that but at 3000 feet I thought that the difference
would be not of this magnitude (almost 500 feet) . So I must adjust from the
QNH that I must retrieve from ATC or other source. Thks

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”)?