FYI <WorldPosition> inside the <ICAO> tag is (presumably) a typo.
Also the EFB “Load PLN” “Send to ATC” capability as of SU3 seems broken, at least for User waypoints e.g. the attached “EFB format” PLN file with 9 waypoints results in the GET_FLIGHTPLAN return containing only 4 of those (1,2,8,9)
To be frank, I think any fix for a clean PLN file load at this stage will be too late for us, we have an alternative external API and need to move on to more value-add content in the sim.
thanks - not sure if it’s the same bug, my understanding was the bug previously reported was certainly planned for fix in SU3.
If the SDK EFB PLN example included “User” waypoints (i.e. points with a name, lat/long and perhaps elevation - those were very common with VFR flights previously from Little NavMap). then we could cut-and-paste that SDK example into the EFB as a base-case for working PLN support / error reporting.
This probably seems like a small part of MSFS, but for multiplayer VFR flying the sharing of flightplans between players is absolutely fundamental.
This indeed was fixed for SU3. Idents are now preserved throughout and PLN files don’t cause ident deletions any longer.
Your plan file is perfectly OK. Loading the PLN file and then using the EFB Send To ATC function (to get it to the old GET_FLIGHTPLAN call) I have found the following issues when the legacy/mission plan builder gets ahold of the plan:
When the flight plan is set to VFR, the plan builder totally ignores all enroute waypoints
When attempting to work around this by setting IFR in the PLN, the plan builder will make a visual departure and arrival even if the plan explicitly has None for the visual pattern type
After those issues, it still attempts to merge a few enroute waypoints for reasons I’m not sure of at the moment
I’m not totally sure of the reasons for the aforementioned behaviors, perhaps our colleagues will have some more ideas as it within their area. That being said, would it be possible for you to use “GET_EFB_ROUTE” from JS_LISTENER_PLANNEDROUTE instead? During the SU2 timeframe it was updated to include the requested items that I recall you felt were important to have, namely the waypoint ID (name in the API) and the waypoint altitude.
That would skip all these extra conversion roundtrips that have to go through legacy code back to the old flight plan system. Here’s what I get, for example, when loading your PLN file and using that API:
thanks - I’ve tested the PLN load with the GET_EFB_ROUTE and indeed all the waypoints appear via that API. 2020/2024 compatibility is still pretty key for us as we still have the vast majority of glider flying in 2020 so I’ll extend my common html/js codebase to call GET_FLIGHTPLAN / GET_EFB_ROUTE / the external API in that order.
