Agreed
The EFB is getting better, especially with SU2
It’s the FMC that’s the problem in 2024, it really doesn’t work without the EFB
3 Likes
@Bishop398 Hello, at the risk of going a little off topic here, some of what @KSFO787 states above also applies to the Max 8 in terms of disconnect between the EFB and the FMC where loading, W&B and CG calculations are concerned. While it is less broken in the Dreamliner compared to the Max 8, the Max is still a mess when one starts with a SimBrief import through the EFB as it is in 24 today.
To be more specific would take more time and effort than I have to offer during this beta, but please know that for both Boeings there are gaps that result in discrepancies between EFB and FMC that I have to fill with educated guesswork to make a safe flight. As to immersion, a clear path from SimBrief to FMC that does not introduce loading/CG errors would be a big step forward for both Boeing models in 24.
3 Likes
the real issue is that there is no PMDG level 787. with a decent 3rd party 787,. nobody would care what MS does or not does with their bird.
3 Likes
Ok thanks so sounds like you’re disappointed with the 787. My guess is it will be fixed up over time like the one in 2020 was. WT did a pretty excellent job with the g1000 etc after all. Sounds like others see it in the marketplace? I don’t.
The WT did a fantastic job on the avionics, it’s top notch. They even made the 2020 787 fun to fly with the integration of SimBrief. However, they are the one who also made it worse off in 2024 787.
I believe WT was not involved in development on the 2024 versions of the 78X and 748i. Asobo took those planes over. WT did the new 744, the 73M avionics, flight planner, and some other things I can’t remember.
The 2024 787 is a total disaster for me. Black screens everytime I face any runway to land, electric failure, engines shutdown … and crash!
The community is composed of more than folks who just use a single tool, and that also includes other developers who felt it unfair that one third-party’s product be effectively promoted through default features, as well as other pilots who didn’t understand why their tool of choice was not also supported in this highly customized way.
We didn’t build the EFB, only the flight planner app in the EFB, but I will say that the idea in general was to provide a common platform so that all developers could take advantage of the capabilities instead of favoring single third-parties. That has always been the mantra of flight simulator, to provide a platform for folks to create the exceptional tools that we know they can.
And, this approach has borne fruit quite quickly: there is already an EFB app for SimBrief. With the APIs available to send the flight plans to the avionics and APIs available to properly load aircraft, all the tools are available for any developer to do exactly what was only possible previously with a single third-party tool built into the plane itself.
I certainly understand the frustration with things changing a bit, and my intent here is not to not validate those who have it, I absolutely understand! 
But we certainly think having a level playing field for everyone is a much better starting point for 2024 and offers an environment where what was possible before is still possible, but that possibility is now available to anyone.
It is up to the tool developer how they want to send the plan to the aircraft. If they want, they can send only the enroute so that the pilot still selects the other information. Right now, from our flight planner app, we send the whole route, but other apps don’t have to take this approach if they don’t want to.
As we are not the owner of the sim load system nor the EFB app for it, I can’t say exactly what is going on here. It could be that SimBrief is not utilizing the API for loading the plane properly, it could be that there are bugs in the sim-side that result in a bad aircraft load, or it could be something else entirely.
I do know that the load system has been worked on a bunch for SU2, and we also now include a shortcut to load the plane based on the planner app planned load in that release using this API, so it should be possible to do without problems, but without more knowledge of the SimBrief app’s code or what specific issues are being encountered, it’s hard to say what is going on in this case.
We did do the 2024 78X.
6 Likes
I know that you and your team have no power over this, but I hope you have perspective that until/unless this EFB app is added to the Marketplace for Xbox users, this choice of moving things to the EFB has really kneecapped the already feature-deprived Xbox users of being able to import things directly (or direct-adjacent via the EFB app) into their aircraft.
(I’m aware Xbox users can do a similar process through the web Planner, but it just adds additional layers of complexity that don’t feel user-forward)
1 Like
It’s definitely something we strongly recognize, and we try and do our part to make it possible to work around these limitations in a tool agnostic way as best as we possibly can (i.e. via the web planner workaround as you mentioned).
We’re huge fans of the multiplatform story that is MSFS, and indeed a huge impetus for the web planner and platform APIs in general was to improve this story for more pilots, so in that vein we do genuinely hope that tools like these can land on these platforms in the future.
1 Like
I support the notion of allowing different tools. Instead of removing “SET FROM OFP”, you could have allowed other tools to leverage SET FROM OFP. Let other developers integrate into that system.
I don’t know what leveling the playing field means. There’s a certain immersion for the flightsim. To kill off features because some minority users (or worse, non pilots) are upset is just WRONG.
If you think about how real world pilots load routes into the FMC, it’s directly through the FMC. The way that it is being implemeneted now, if anyone even understand how it is implemented, is the EFB supposedly send the route to the FMC. The FMC magically having the routes appear when being sent from the EFB is so REALISTIC, WRONG AND BOGUS. Tell me which real world airlines do that!!
You had it ABSOLUTELY RIGHT before. Why destroyed it??
So IF level the playing field means make the game even more unrealistic, you have succeeded. I do NOT play 2024 787 because of the reasons I mentioned earlier in the thread.
SET FROM OFP is not something that appears in the real-world FMC, thus itself is not at all realistic. Pilots in the real world do not load the plane themselves, and they certainly don’t do it via the FMC. Developers now can use the APIs to load the plane from their own tools, and since SET FROM OFP was not realistic to begin with, we of course didn’t see a particular problem with having that be able managed on the tool end instead of the aircraft end if it enables more developers and tool writers to be able to do so.
While, again, we recognize the frustration with having a feature changed, the pilot interaction with the ROUTE REQUEST feature is effectively two button clicks and an extremely small part of the pre-flight setup. In our view, the ability for any developer or tool to be able to get flight plans into the aircraft overshadows these two LSK presses across the course of a complete flight, although we respect that different pilots will have different opinions on which features contribute most strongly to their own personal immersive experience.
If it becomes possible down the road to implement this for all developers/tools (i.e. not just SimBrief) using ROUTE REQUEST, then we will re-add that, but at this time it is not presently possible.
1 Like
Let’s try this one more time. I know you won’t change your mind. I hope you revert back to listening to the community.
This SET FROM OFP allows for a closer emulation of dispatch sending flight plans to the system. Pilots would go into the FMC, click on plans from dispatch to load the routes. In this scenario, it provides the closer simulation on what an airline pilots would do.
In WT’s NEW implementation, it is a further immersion disconnect. Coupled with the W&Bs, it makes it frustrating to use.
You kept arguing equity for all tools. Which other flight planning tool are you trying to provide a level playing field to? Who is complaining about NOT having the access? Is it a real issue or this is simply an idealistic philosophical argument to justify what you have done?
1 Like
SET FROM OFP only loads the plane with the appropriate weight and balance, so we must be speaking of different things. It isn’t related to requesting a route.
We have had a number of users, modders, and developers over the years ask how to synchronize their flight plans directly to avionics in a platform agnostic and avionics agnostic way. Examples of such tools are LittleNavMap, SimToolKit Pro, Avlasoft EFB, AviaPlanner, and others.
It was also of interest to Navigraph themselves, as it removes the necessity for them to write plugins for each avionics system into the sim and provides a standard interface via which any avionics system can receive a flight plan. As such it benefits both them as developers and us all as users of the sim as it removes engineering, time, and resource impediments to getting SimBrief to synchronize routes with aircraft, since it becomes a much more automatically supported feature just by virtue of being a standard part of the sim API now.
It also makes it easier on aircraft developers, as they only need to support the standard API and then SimBrief via its EFB app will automatically be able to send routes to it; they don’t need to spend engineering resources making special case code.
Hopefully that helps clarify, and if not, well, I think we’ll have to just, cordially and respectfully, agree to disagree.
think main issue is that the EFB requires to PUSH the flight plan into the FMS, which is not realistic. (of course loding an aircraft works different in real word, so in the sim this has to be solved somehow)
folks want to PULL the flightplan instead from the aircraft fms. so at the end we have to prepare the EFB, so be it, at the end if all issues are ironed out its a good thing.
but let us do the route request as before.
This is precisely the pain point in both 2024 Boeings, Dreamliner and Max as compared to the Dreamliner in 2020 where loading, weight & balance works as expected. In 2024, loading, weight & balance (and CG calculation in the Max) don’t work as expected and/or are defective in some respect. While not WT, who owns that code and how to go about getting that situation addressed and sorted out? Could be somebody’s work in progress but the Max is broken and the 787 could improve here?
1 Like
Please see this previous answer regarding that:
The EFB is owned by Asobo (aside from the flight planner app only). Posting your feedback here and on the beta forums (if you’re in the beta) in the form of a reproducable and detailed bug report is the best way to let the team know there are still issues to be addressed.
2 Likes
I raised a ticket with support, to ask them to fix my lack of access to the 2024 787 (as a 2020 PD owner), and this is what they said
Thank you for contacting Microsoft Flight Simulator Support today.
There is no difference between the 787 versions between MSFS2020 and MSFS2024. We checked your account and we can see the content correctly in your inventory.
So apparently, they’re exactly the same, and that’s why I haven’t got the 2024 version. I’m confused 
Well that’s really upsetting because there 100% is a difference between the two. I hope this gets seen by a Community Manager and escalated - it wouldn’t be the first time Zendesk is objectively wrong in their response, unfortunately.
2 Likes
Ok thanks for confirming, I really couldn’t match what people have written here and other places with what they told me. I’ve reopened the ticket and asked them to look at it again.