PMDG Flight Plan .rte file Update

@pucksnplanes20

Hello John,

Certainly your files can be uplinked with all the entries populated, just as a saved route via the FMC.

Whether Simbrief can export all the required procedure data ( heading to track, heading to intercept etc ) I could not say, certainly many planners of the past would not. You will find discussions on the topic going back to 2011 and prior.

Unless the data is an exact match for PMDG then it can cause issues which is why PMDG request utility publishers export the route segment only. This is published in the NGXu manual:

External route export programs:
Flight plan .rte files created with external flight planning programs or websites will have the runways, SIDs, STARs and approaches contained within them stripped when importing into the FMC, resulting in just the enroute portion being entered.
Routes saved with the FMC itself will still retain these items.
This was done because these programs in many cases insert nonsensical terminal procedure data that will either crash the FMC or cause general weirdness in the route. In addition, COROUTES do not contain runways and terminal procedures in real life because they often change with the prevailing winds and the day’s departure routing. The runways, SIDs, STARs and approaches are manually entered by the crew when assigned by ATC even if a COROUTE was used for the enroute portion of the flight.

737 pilots I have known have said they are required to enter SID/STAR via the FMC even with a route uplink.

Perhaps PMDG’s guidance will change should GFO materialize.

I certainly don’t think anyone is trying to ‘shoot you down’ as suggested by some here.

Regards
Steve

2 Likes

Bring it on, implement it asap

2 Likes

Is there an issue with at least getting the flight number added?

2 Likes

Great Idea John! Thanks for the suggestion. I hope it will be considered.

2 Likes

There has to be a workaround for this issue. This user Idea would greatly enhance my and many others Flight sim experience. PMDG aims to achieve the highest level of realism in every aspect, so I don’t understand why shoot down a user suggested idea so fast. Have you guys looked into this issue and see if there is anything you guys are able to do? The author of this Idea was able to demonstrate that nothing conflicts with this change. Its not one person you’re letting down, its 64+ people that would love to see this added. If you guys need any help ask the author of this idea, who was able to do it perfectly fine with no issues how he did it.

Please,

Connor
PMDG User

1 Like

@oal260 I totally understand where both of you are coming from (and normally I would agree with you), except this is a perfect of example of why the Simbrief and Navigraph merger was a match made in heaven. With all abundant and numerous resources that Navigraph has, this would be no problem for them to create a way to implement this new format for the .rte file. Flight number isn’t even a question (obviously they could do that in no time). The real question is SID and STAR. @Ian what do you think sir? Do you think implementing SID and STAR data into the .rte file would be possible from Navigraph’s perspective? All proper altitude and speed constraints would have to be accurate of course.

Now that being said, ever airline/company is different when it comes to ACARS and uplink functionality. In the USA, there are numerous B737 operators whose RTE REQUEST> functionality includes auto populating the filed ORIGIN, DEST, ROUTE, SID, STAR, and FLT NO. I know not all operators do this and thats ok (maybe Navigraph could keep the old .rte format as well and just include a new additional one. That way we get the best of both worlds and keep everyone happy - one .rte file with SID and STAR included for those who fly Southwest Airlines for instance and then one without SID and STAR for those who fly Ryanair for instance.

Also, in the USA, we don’t use the COROUTE function anymore. We only use REQUEST> LSK function, can’t speak for how things are done in Europe because I am completely unaware of European airline operations. That being said, COROUTE generally speaking is not used anymore over here in America.

Sorry I dont mean to beat a dead horse or anything. It’s just this is such a cool feature that the airplane is missing and there are many many people who look favorably at this concept being materialized. This would be a game changer for those who simulate flying US airlines who include SID, STAR, and FLT NO into the RTE REQUEST> LSK function.

Regards,
John

1 Like

Hi John,
I´m not @ian but I can also answer this - the general answer is: yes, but the “devil is in the details”, means. as soon as PMDG supports this feature officially. I hope you understand, that we can´t implement something which isn´t official supported from any 3rd party developer and currently, it isn´t …

We have no idea about possible side-effects and as you know the flightplans can be used in all different PMDG versions, in all sims. So, it´s not only a MSFS question - this is a general question and therefore we need a official “go” from PMDG. What we don´t want is a “finger point” to someone, in this case to PMDG. We trust these guys, we respect their development, their open communication and of course their knowledge about their study level products. The posting from Chris directly here in our forum show us, that this is not so trivial and needs time to discuss.

We have also started an internal discussion about this feature-request and of course, we will discuss this with PMDG too in the next couple of weeks. Possible we find a way in the future but it´s clear, that this way can only be gone together with PMDG.

In the hope all here understand these lines … we hear you and we see the votes
Cheers,
Richard

4 Likes

@NAVData Thank you for the response Richard. I understand.

If it is determined that this only works in FS2020, do you think it would be possible for Navigraph to differentiate between different PMDG route files available for download?

For instance, one could be for FSX and P3D, and FS2020 (NO SID and NO STAR included) and then another could be for FS2020 only (SID, STAR, and FLT NO included), as an example…

Lastly, if the above is not possible due to PMDG not giving their blessing, at a minimum can we at least request that FLT NO be included in the .rte file? At a bare minimum it would be great if Simbrief/Navigraph would implement that into the .rte file. I know its a simple request but at least that would be a nice compromise were Navigraph and PMDG to decide to not go forward with this feature implementation.

Thank you very much sir for everything you do for our Flight Simulator community!

All the best,
John

2 Likes

The FLT NO will be a nice cool stuff to have as starting point as don’t mass or create an internal error (I think) with any sim.
Thanks

Hi all,

Your interest in this feature has been noted, but there are significant challenges which make this impossible to add for the moment. @srcooke and @NAVDataOld made several good points in their posts above, I can add my thoughts as well:

If you download the original post’s .RTE file and open it in Notepad, you’ll see that every single detail of the SID/STAR lateral and vertical paths are included. Every vector leg, intercept heading, altitude restriction, and waypoint. There are multiple ways one could potentially encode these legs in the file and no doubt the PMDG FMC is expecting things to be done in a very specific way. The research, development, and testing that would need to go into SimBrief’s SID/STAR export to make sure that it always matches exactly what the PMDG FMC is expecting would be significant, and difficult to justify in this case.

In addition, SimBrief doesn’t currently store initial headings, vectors, or intercepts in its database. This would need to be added to the backend first, which would be a big job in itself.

Finally, and perhaps most importantly, is that PMDG has expressly requested that we don’t do this. While I can’t speak for them, I certainly understand PMDG’s position here. It doesn’t sound like their FMC has been programmed with this use-case in mind. What if SimBrief gets even one detail wrong when exporting the SID/STAR procedures? What happens when users are on a different AIRAC cycle in the sim vs SimBrief, or using an AIRAC from a different provider? How does the FMC react when the SID/STAR encoding isn’t exactly as expected, does it handle it gracefully? Does it immediately crash the sim? Does it appear to import fine at first, only to crash or veer wildly of course once you takeoff and hit “LNAV”? We basically have no idea, which is why it’s important for us to always follow the developer’s official guidelines.

Trying to work with the current SID/STAR format, which was clearly intended to only be written and imported by the FMC itself, would be difficult and probably end up creating a support nightmare for both sides. If it was a 15 minute (or even a 10 hour) job to add this, then maybe I’d be more inclined to just give it a shot and see. But as it stands, there is significant development time required, and we don’t even know if it will work reliably.

Maybe, but only if PMDG approves. There might be compatibility issues even in this case. It may not be compatible with older PMDG aircraft, which means at the very least it would need to be split off into a separate format. If I’m honest, it seems silly to add a separate format for such a small addition, and for all I know, this only works in conjunction with the SID/STAR encoding (part of an “extended” .rte format perhaps).

Have you tested adding only the flight number section to a SimBrief .rte export? If it works, can you upload the resulting file please?

Cheers, we appreciate the feedback as always.

Stepping back from the internal implementation aspects of this for a moment…

It seems the way this should work from a black box requirement level, and I am guessing this is how it works in real life as well, is for the SID and STAR names to be included in the uploaded data (i.e. .rte file), and the FMC then using its own navigational database to translate the names into strings of waypoints? I.e., same result as if we select the SID and STAR manually with the DEP/ARR page. Not having each waypoint and constraints and all that included in the .rte file for the FMC to interpret as the actual SID or STAR (which may or may not be identical to what is in its internal database).

But that still would have to be supported by PMDG before it can be supported by Navigraph.

Yes exactly, the current SID/STAR format is simply not intended to be exported by third-party programs. It’s too granular.

I suspect if PMDG does want to add support for this one day, they will take an approach similar to what you have suggested. But if/when/how they decide to do this is entirely up to them.

Best regards,

It would make more sense for the aircraft addon developers to import an ICAO format flightplan including SID/STAR such as FSL and Leonardo. These read the route from OFP.

This way there is no need for the third party developers to produce dozens of varying formats, increasing costs and leading to errors. Just as there should be a single sim arinc database format.

2 Likes

Why does the simbrief downloader then include two different export formats for the PMDG 737, one of which includes SID/STAR data?

When this version is imported into the FMC, the SID/STAR data is removed anyway, so what is the point of having that option?

Hi, I only see one PMDG flight plan (.rte) format (which doesn’t include SID/STARs). Can you send a screenshot of where you are seeing a second format?

Cheers,

Hello, completely my mistake, there is only 1 for PMDG, my brain is playing tricks on me and was thinking of the MSFS format, which has two options, one with SID/STAR. Nothing to see here, time to move on :slight_smile:

1 Like