SDK Q&A Stream Feedback

Working Title is on the MSFS team, so just speaking to what we’ve discussed together (MS, Asobo, and ourselves).

We are definitely looking at everyone’s feedback, and we super appreciate it all! I just want to be clear on what we can and cannot offer, and where things are headed.

-Matt | Working Title

Two questions:

  1. Are these only the third party developers recognized by Asobo, or does this include all third party developers, who may or may not be in communication with Asobo, that have expressed their opinion on the matter?
  2. In order to improve third party access to the SDK and to extend the number of developers (which i’m sure we can all agree is a good thing), shouldn’t an emphasis be placed on the developers that currently cannot bring their addons into the sim? Sure, the ones that are already in the game might want to continue the status quo, but is that the right thing to do if it means it locks out other developers? Wouldn’t a middle ground be more favourable?

As for security, I still don’t see how sandboxing improves anything, considering a user is infinitely more likely to run malicious code during addon installation than while the addon is ran by FS2020. But, then again, i’m a nobody so Asobo doesn’t need to explain themselves to me, I suppose. It wouldn’t even be an issue if it wasn’t limiting addon capability. And, again, @CptLucky8 has proposed solutions on how sandboxing can be maintained whilst enabling dll-like functionality, all the more reason why I personally think he should be brought into the discussion:

Thanks Matt.
If this is the Official word, then its good to hear it spelt out so clearly and with ambiguity.

So, unlike FSX, P3D & XP, we are not lightly to see support for the Trainer Garmin GPS system, as developed by RXP … so no point in expecting them unless there is some major change of direction by MS/ASOBO.

Time to accept that an move on … (probably to XP.)


I don’t think it’s the SDK or the sandboxing that is preventing those addons from coming to FS2020. Those make things complicated, for sure, but I think it’s the autopilot interactivity that’s the blocker, if i remember correctly.

No, of course not. A lot of this feedback is making it back up. We (WT) were a prime example. We are way outside the usual third party viewpoint. We were brought on specifically to build out some parts of the SDK and make them modernized and add our viewpoint to the mix. And this plays into your second point. As I mentioned, my goal is to democratize a lot of this with better tooling and APIs, but it is going to be evolutionary over the next year or two as there’s a lot of work to be done. And the new AnswerHub, which will be more open, will also enable better MSFS team to developer communication. There is definitely an awareness that better back and forth is needed, but doing so via the forums has become drinking the firehose, so to speak.

Sandboxing is industry standard these days; allowing processes like games that have fairly low level access to load arbitrary untrusted code is just not a good idea. Just look at the drubbing Cyberpunk took for their code load vulnerability. Consumers expect that third parties can’t load things that are unsafe. I understand that from a practical perspective that hasn’t been a problem yet (although there are a couple of historical FSX examples, they aren’t the rule), but regardless it’s important in 2021.

I agree that having some sanctioned, safe, and high performance communication solution would be a good thing. We’ve been discussing that in the context of how to move data between the JS side and the WASM side, for example. There are already some solutions getting data in and out: on the JS side you can run an external process (it doesn’t even have to be local, could be anywhere on the LAN or WAN/cloud) and communicate to JS via websockets, for example. On the WASM side you can use SimConnect client events to transmit data. The SimConnect client events solution is a bit limited, of course, but those are some options presently if you need to move data to external processes.

We are actively working on making the sim autopilot and associated vars much easier to work with and write to for overriding scenarios. I don’t know when those features will land yet, but it is something we are definitely tackling.

-Matt | Working Title


Speaking as someone who is presently working on producing “study level” Garmin instruments, I think the idea here is to develop high quality instruments that don’t require communication with the real Garmin trainers. Forwarding data in and out of the Garmin trainer itself is enormously limiting, as an architecture:

  • The trainer DB is hard to update (for some trainers not possible) and doesn’t sync with the sim nav data
  • The trainers themselves have a number of bugs and love to crash (NXi trainer, I’m looking at you)
  • Getting access to the trainers is difficult (or impossible, for some units) and sometimes the trainers are out of date compared to the actual plane installs or have wrong options
  • The performance of the trainers is not always very good compared to what can be achieved with good code in the sim

If folks want to make really awesome GPS units without compromises, I would definitely recommend avoiding the external trainer approach. But that’s just my opinion, of course, folks are always totally free to disagree.

-Matt | Working Title

Whilst i would agree that the best possible solution is to have a fully featured, 1:1 Garmin clone built with native sim code, I don’t think that’s enough reason to limit the access other developers have to the sim. After all, who can compete with you right now when it comes to marketing a G1000? You have privileged access to not only the sim internals, but you can change the course of the SDK. With great power comes great responsibility :slight_smile:

Further more, just because some other addon built using some other methodology might have shortcomings, is that reason enough to block it? The WT G1000 currently has all sorts of shortcomings, including a hard to update database, and that it doesn’t completely sync with the sim nav data, and there are a number of bugs due to the limited implementation, and a lot of people report a significant performance impact when using a glass cockpit as opposed to steam dials. But no one said you should give up on it. We all encouraged you to keep working on it to make it better and to weed out those issues. And that is also why we all are happy that you joined Asobo, in order to produce a better G1000. But now you’re using those shortcomings to cast other developers in a negative light. That’s hardly fair. Why not think about the situation you were in before joining Asobo? With an incomplete simulation, with a wall set in front of you, blocking you from fixing some issues. Shouldn’t other developers be given at least a tenth the opportunity you got? I don’t see how this would not be beneficial for all parties involved. Because, after all, I don’t believe that this is some petty attempt at monopolizing the Garmin implementation market. I think we’re all better than that, i hope.

Again, this isn’t necessarily about you fully embracing @CptLucky8 and declaring him your beloved leader. No. This is about him being given a chance to make his argument in an official setting, with the Asobo devs, rather than on this forum with the rest of us average mortals.

Either way, i said my piece, and i won’t continue with this further, unless you have any questions for me personally. I just hope that in the same way you guys were given a massive opportunity, a very good decision made by Asobo that I appreciate, maybe more developers can be brought to the table to at least offer their opinion, especially when they have proven themselves as knowledgeable as @CptLucky8.


I think this is hardly warranted. To be super fair, our position was always that the sim was already capable of doing most of what you needed to make study level instruments, and we were able to work extremely well to show that was the case with the CJ4. Our opportunity was created because we wholly embraced the new way of working, which does, unfortunately, include a sandboxed environment. I agree with you that our G1000 is not finished (although it does use the native flight plan and AP, so it actually does sync up with the sim nav data and has no database of its own), but we’re also going to be using our learnings while building the next big version as takeaways for how to make a framework that leads people into the “pit of success” as I call it, where it is clear how to get great performance and work quickly.

I’m a huge fan of Jean-Luc, I’ve owned a number of RXP products over the years, it’s all really really great stuff! Me pointing out those architectural limitations isn’t an attempt to downplay the high quality that he has produced. Just pointing out that there are indeed other avenues for creating 1:1 recreations of those instruments that don’t involve those same architectural limitations, which may be worth considering and pursuing. Yes, the accuracy of the awesome RXP trainer based products is amazing, as are the technical achievements, but just because that specific way of working is not possible doesn’t mean that the same fidelity is not achievable via other means. And we’re happy to speak directly to Jean-Luc about his use cases so he can get his goals reached in ways that don’t require direct hardware or native code access.

My job with the MSFS team is absolutely to open the most doors possible for making development modern, easy, and streamlined with the fewest pitfalls. But part of that modernization is definitely a team focus on security, and so sometimes there are just going to have to be other ways of solutioning. That’s not me purposefully putting up walls to box out “competitors”, that’s just a reality of modern game addon design that we all have to deal with, myself included.

As an aside, you don’t have to speak with me long to hear me rue the lack of information sharing and high level of boxing out that is the standard in the FS third party community. My goal is to slowly erase those knowledge gaps and even the playing field for everyone, so that everyone from the two decades old study level gurus to the first time devs have the same opportunity to make something great for simmers. Yes, there will sometimes be non-negotiable limitations, but the goal is to make it possible to still achieve super awesome things even given those, for everybody and everyone.

-Matt | Working Title


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.