SDK Q&A Stream Feedback

Scale of 1 to 10, 10 being excellent, how did you feel about the quality of Questions Asked?
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10

0 voters

How often would you like to see a live SDK Q&A Stream?
  • Once a quarter
  • Once a month
  • Every other month

0 voters

Thanks for those who participated - our SDK team is really excited to kick off these streams and are certainly interested in what everyone’s feedback is on this type of content to help out the creator community. If you have ideas or suggestions about these future streams, feel free to reply here. Thank you so much.

Here is the Twitch VOD:


Thank you again for a great Q&A! It is great you’re also letting us discovering new team members!

My initial feedback:

There was a lot of great new information for 3rd party devs and this is appreciated. On top of my mind:

  • New people in the team
  • New Q&A platform (around May 3rd)
  • New “performance measuring” tools (mem profiler)
  • New JS dev tool (Coherent debugger)

There was also a certain number of set backs:

  • No SimConnect on Xbox
  • The justifications for sandboxing add-ons
  • They don’t want we override the flight model

There was also some hints about DX12:

  • “DX12 won’t change anything for the Xbox and later on for the PC”, which I read as: "we’ll get DX12 on the PC version after the Xbox release, not at the same time, not prior either.

There were some topics which weren’t specifically covered:

  • Gauges and system SDK evolution and direction.

And maybe a misunderstanding (I might have misunderstood):

  • When Eric was talking about the enhancements to come in the SDK, there was a chat question about “roadmap” and the answer IIRC was about “feedback snapshot”. However I believe the purpose of the question was not about the simulator roadmap but the SDK roadmap, i.e. when will such feature be added, what other features will be added and when, what is the direction the SDK team is leading the SDK toward, etc…

About “the justification for sandboxing add-ons” when asked for DLLs

Eric was saying what sandboxing is good for:

  • DLLs can carry unsafe code and they can’t have unsafe code in add-ons in the Market Place. Sandboxing is good for having safe add-ons in the Microsoft store.

  • Sandboxing is also a good way to port legacy addons in C++

I agree with the first one:

Sandboxing is ensuring you can only have safe code in the market place.

Nevertheless, what about add-ons which are not sold on the market place and why not opening up the SDK and offering DLL and low level support/access to the simulator for these addons then? (IIRC this was already requested as early as when the alpha started and was probably among the first questions from 3rd party vendors)

As for the 2nd one:

It seems to me they might have had “some” input from “some” 3rd party vendors they are closely working with in order to get this “overall” picture of what it is 3rd party vendors are doing in C++ with their “legacy” gauges.
I’ve been working exclusively in this industry for the last 20 years and the truth is radically different to me.

This is why I’d like to share this feedback so that it might help Asobo getting a clearer picture that 3rd party vendors are not just like this, and they are not all just doing simple XML gauges or EFIS screens in GDI+.

In effect, I don’t know what C++ gauges and modules Eric is referring to, but to me I don’t see how sandboxing is a good way to port legacy addons:

  • All C++ coded add-ons I know of (and I’m not talking about Reality XP own products) are in one way or another accessing the simulator in a low level which is no longer possible today with sandboxing.

  • Many of them are using 3rd party libs (other DLLs or .lib) they can’t use anymore.

  • Some of them need to also access other files on the computer and data sources (navdata, online services, etc…)

  • Sanboxing is further reducing performance for some of the most cleverly coded C++ gauges and modules. For example we do care about cache line size and do optimize our memory accesses, lock free and wait free programing, optimizations we can get with poisoned pointers, and many more low level C++ stuff no longer possible with WASM.

  • Sandboxing is also preventing clever use of SSE optimizations (not the auto-vectorized code by the compiler, but the hand-crafted SSE2/3/4 and AVX code we’re also implementing).

  • The WASM sandbox and the SimConnect conduit are not offering any latency guarantees, whereas our own IPC based lock-free/wait-free MPMC queues are offering these, and on top of that are running nearly at the same speed as a memcpy (this is why you get nearly no latency on the Reality XP GTN when touching the screen).

The above is just scratching the surface of why sandboxing is good for the market place, no doubt about this, but certainly not as good for 3rd party vendors in general, but only if you’re coding gauge and system in C++ like you’d do with any high level language or JS, without exploiting the benefit of C++ to-the-metal optimization opportunities.

Nevertheless, sandboxing the code running in the simulator wouldn’t be as much a problem if only there would be low level mechanisms to ensure fast inter-process communication (aka shared-mem based IPC) and additional socket based communications mechanisms (the latter not in lieu of, but complementary to the former). But even this seems to be totally ignored (IPC) and not planned (sockets).

I remain available and open to discuss any of this directly with Eric and Alyzée of course, and I’m French so there shouldn’t be any language barrier either.

PS: I’d be pleased to share with them any relevant source code as well, which will certainly also help them having a first-hand experience on some of the most advanced gauges available ( some of the most advanced from a gauge sdk standpoint, and not just from a simulation or Garmin standpoint: ).


There was 1 question about the profiler from the same user who has posted this question for the Dev Q&A.

The memory profiler tool that was discussed is great and if I understand correctly, it was designed mostly, if not solely, because they expect too many add-ons won’t be able to fit in the limited Xbox memory space and 3rd party vendors could be needing a tool to assessing the amount of RAM their add-on is using.

I’ve no doubt this is helpful (like we say in French: “c’est mieux que rien”), but can you please pass the following information to Eric, because I believe this is what the poster was asking for instead:

I did enjoy the stream, as always, but I do think it would benefit from a different format from the other streams. There seemed to be a lot of picking through questions during the stream, which is fine for some of the time, but I’d like to see a quickfire round, with each participant given 10-20 questions prior to the stream (given that questions were requested here on the forum) which they give brief answers without discussion. That wey we’d get a lot more info in a shorter time.


For a first SDK-focused stream it was very good and very informative. Thank you Jorg, Alyzee, Eric and Jayne for hosting it. Please give it a chance and see how it progresses.

I’m not a developer and I certainly don’t claim to be a computer security expert. That said, I believe Microsoft want to really, really want to make sure that no add-on can maliciously or inadvertently affect other systems. This is because an add-on running on an individual’s PC will also potentially have access to the wider Azure system, and a later date to Microsoft’s Xbox systems. What a tempting target!

I’m sure that Microsoft has already run a detailed risk assessment and that the use of WASM is one of the mitigations recommended to reduce the risk that they perceive.

1 Like


I believe you’re raising valid questions but the truth of the matter is that it is unrelated. If you’re not a developer, I fear you might feel what I just wrote is condescending, but it is not, and I’ll try to explain.

To get started, all simulators in existence, and many games, are allowing modding via DLLs running in the same process space. This was never a security concern and in practice, in the Flight Simulation world specifically, this has never been a security problem at all. 3rd party vendors, both professionals for which this is their sole job and revenue like Reality XP, or for which this is a part-time job, and freeware authors alike, are all making their best to delivering bug free and safe add-ons for their users.

But even if there is a rogue vendor wanting to exploit either or both Azure and Xbox Live, I can assure you there are already ways to load DLLs to do just this in FS2020. I’m not talking about system wide DLLs injection/loader here, I’m talking about a security loophole in the FS2020 implementation they can’t patch, that I didn’t publicly documented yet, and is unrelated to WASM or loading 3rd party add-ons. And even if you’d load a DLL in the FS2020 address space, it wouldn’t give you any better way to exploit Azure and Xbox Live in much meaningful ways anyhow.

Like I said above, I agree, WASM is a good technology for the 1st of their goal: ensuring you only have safe code in the market place. WASM might be a good way to run generic C++ code over a wide variety of devices, no doubt about this, but sandboxing is not a good technology to port legacy add-ons in C++ in particular, because most sophisticated gauges are working outside the box, not inside. In addition the current sandboxing implementation doesn’t allow interfacing with external applications in a way we can ensure both throughput and latency.

This is very easy to solve though. You can ensure both sandboxing protection from rogue code, and ensure low latency with 3rd party code, in adding support of IPC in the SDK for the PC version only. With this, any 3rd party gauge could be split in 2 parts: the sandboxed WASM part in-process, and a separate standalone executable running in its own separated process space. The IPC would be used to make the 2 sides communicating the data they need back and forth.

If you look at this, it is no different in principles that what the JS/HTML layers is forcing the developers to do already: in order to make an add-on displaying something external, you have to build and run a local webserver on your computer listening to requests coming from the simulator and sending back HTTP responses to the JS code running in the “gauge”. Now imagine in a few years, you’ll be running maybe a dozen or so local web servers just to feed your add-ons in FS2020. It is really not lightweight an implementation.

With IPC, you’d open the capability for WASM gauge to do the very same, but in a C++ efficient and close to the metal way (no web servers, no encapsulation of data in JSON response text and HTTP requests, no more RAM allocated to wrap a 2 byte answer into a 1500 byte frame, etc…). With IPC, each developer will build its own protocol to exchange data between the WASM gauge side and the external code side, in the most efficient way for this gauge. But more importantly, with some latency and throughput garanties.

Adding such IPC capability in the WASM SDK is not opening any security hole at all either. And if this is really a concern, they could restrict the IPC API to being available to sandboxed WASM code running on the PC version only (not the Xbox version).

Sandboxing is good to port existing C++ gauges ini theory, but not in practice. If this was so good a way to do so, we’d already have much more aircraft ported over from renown vendors already. The reality is that 3rd party vendors have been able to delivering sophisticated add-ons for their customers enjoyment mostly because they’re implemented outside the box. I’ll try to illustrate this:

From FS2020 point of view:

  • FS2020 is commanding the gauge, sending events when it must init, update and draw.
  • Gauge gets some API to read some simulator data, code can process the data, code can draw the data.

From 3rd party point of view (before FS2020):

  • SDK has a few bindings to sync init, update, draw gauges
  • SDK is offering static constructs to define the gauge elements like needles, background gauge bitmap, which must be set statically during compilation.
  • SDK is offering pre-defined rendering of these elements, gauge can influence some of the parameters.
  • SDK is offering API to read some simulator data.
  • Gauge use all available resources in the computer to process the data the most efficiently possible
  • Gauge connects to internet, read files, use compute shaders on the GPU if needed.

From RXP gauges point of view (and actual implementation):

  • FS has a certain set of entry points and sync points.
  • SDK is offering some static constructs meant to “simplify” building gauges but these are based on dynamic constructs underneath.
  • Gauge is using the SDK in a way to bend the simulator through the SDK to the gauge needs.

Here is some more details about the RXP gauges:

  • FS is instantiating gauges based on the statically set elements during compilation. This is a layer built on top a lower level older SDK which has direct entry points to servicing the different phases of construction, handling and destruction of gauge instances. Knowing how this works allows RXP to delivering gauges using this static compile time constructs but to create gauge at runtime entirely, not statically compiled, and to adapt the gauge depending on the user preferences. This includes the gauge elements, the mouse click spots, the rendering.

  • SDK is limiting rendering to pre-defined handling of elements with 1 bit of transparency and 15 bits colors. Underneath, the rendering is capable of handling 32 bits colors and alpha transparency, but the SDK is not clearly exposing this. RXP gauges are not relying on pre-defined elements, instead, they are rendering any surface in 32 bits with alpha, but always using the underlying simulator gauge rendering code which makes the gauges capable of doing this from FS9 to P3D5 as-is.

  • SDK is offering API to read some simulator data but is lacking any overriding capability to this data (unlike XP11). Because 3rd party GPS gauges need to “replace” the stock GPS which is hard coded in many places inside the FS code, especially directly hard-coded in the autopilot code for example (to the point the FS code is forcefully setting vertical deviation to 0 because the stock GPS doesn’t offer any form of vertical navigation, although the code is capable of supporting such GPS input if it wouldn’t be forcefully set to 0 in the autopilot code…). The RXP gauge is patching the FS code at runtime to augment its capabilities with autopilot flight director override, and simvar override (both XML and C simvars) so that any other 3rd party aircraft gauge reading the SDK var will get its data from the RXP GPS instead.

  • SDK is lacking any introspection API, which is preventing a gauge to knowing which panel.cfg file it is instantiated from. This is not important to know if you’re an aircraft vendors because all the gauges are yours. But this is important to know for customers wanting to merge and mix gauges from different vendors in a generic way. The information is already there in the SDK structures, but it is not exposed publicly. RXP gauge is exploiting this information in order to make generic gauges fitting any other 3rd party aircraft.

I could tell more about all this, but it might be already boring enough :slight_smile:

Suffice to say, I’ve a certain perspective and expertise on the SDK for 3rd party gauge development which is due to the specific needs to implementing gauge/gauge and gauge/simulator integration beyond what an aircraft vendor is dealing with. In successfully delivering solutions to these challenges, I’ve also been able to confront the SDK strengths but also its shortcomings and what it is entirely lacking but essential. This is further confronted to the fact the RXP products are not using any hack whatsoever on X-Plane but couldn’t be built without hacks on any Flight Simulator version, which in itself, is revealing that different and better suited SDK approaches are available to address some of the challenges 3rd party gauge developers are facing.

This is just a glimpse of my 20 years old expertise building retail and professional flight simulation add-ons. Although the above is talking about the past, please don’t see this as a way for me saying FS2020 should revert to antiquated SDK constructs and methods, this is not the point at all.

On the contrary, FS2020 has the unique chance to depart from ancient constructs and old habits, but unfortunately, the SDK is still lacking at the very same fundamental architectural principles, and this is what I’m trying to help with.


To me it felt more like a SDK QnA about scenery and Xbox gaming masquerading as flight simulation. I bought this product for flight simulation and not to take useless pictures of some useless POIs. Let me know when you host a SDK QnA about actual flight simulation and want to talk about advanced stuff such as PMDG, FSLabs, A2A, RXP, Milviz, Simcoders etc and how work with these third parties has been going on, etc. Until then your scenery simulation remains uninstalled and unused on my PC and I won’t be recommending it to anyone who takes aviation and flight simulation even slightly seriously. Also the part where Alyzee claims that the MSFS default flight model has been done in cooperation with real world pilots and that other developers won’t be allowed to override it is extremely concerning and a big red flag.


Thank you very much for your detailed explanation which was quite helpful. I’m not entirely convinced that the fact that previous Flight Simulators didn’t find this a security issue is entirely relevant as they were not nearly as integrated into a large network such as Azure & (soon) the Xbox network on a permanent basis.

I do hope however you will be able to raise a similarly detailed query on the new AnswerHub in the near future and have MS/Asobo come back to you with rather more details as to why they don’t want to enable IPC in the manner you want. Assuming you’re already a member of the third party forum you’ve presumably already asked a similar question and not had much of an answer?

1 Like

Thank you for your kind words, let’s hope indeed… Reality-XP

I’m not a developer, but i am a long time user of highly complex addons, and this is my take on this:

The Good:
I was happy to see how knowledgeable and dedicated Alyzee and Eric are. Even though their team is small, it sounds like they’re expanding it. The SDK will be how this sim is going to make it in the long run because without complex addons the going will be very tough.

The Bad:
The strict sandboxing is a bit too strict. I can understand wanting to create a safe platform, but i don’t think the benefits outweigh the downsides. I think it’s far more likely that someone will insert malicious software in the archive you download than in a dll run inside the sim. And don’t we already have Windows Defender to take care of that? This hasn’t really been a huge problem in the simming community since the addons we use always come from established and trusted developers. And if you’re downloading addons from shady sites, a dll being run outside of a FS sandbox is the least of your problems.
My opinion really is that it will be much, MUCH better for everyone involved if dll support is implemented, or one of the options mentioned by @CptLucky8. If you must, disable this by default and require users who want to do this have to change a setting to allow it, or even to install an extra component. That way it becomes the user’s responsibility and it won’t affect casual users.

The Ugly:
No custom flight model is a big hit. I don’t know what PMDG or A2A (or any other established developer of study level addons) are planning on doing about this, but at this point i wouldn’t be surprised to see them back out. A2A have established their reputation based on the quality of their flight model. If they cannot deliver the same quality, i’m sure they won’t go through with it. And if study level addons are not possible in this sim due to the (sorry to say it) broken flight model, then this sim won’t make it very far.

I was happy to see that the development team is very promising. But i was disappointed to see that some decisions have been set in stone that will preclude study level addons coming to this platform (and don’t tell me about Aerosoft’s CRJs or JustFlight’s Arrow - as good as they are, they are not study level). And if that is the case, this sim will never reach the same potential FSX showed. I can only hope that Asobo sits down and listens to developers like PMDG, A2A, Reality-XP, etc, and gives them the tools they need to bring the realism FS2020 is striving for.


So much knowledge, so much experience, just being IGNORED by Asobo.

If ASOBO can interface 1-0n-1 with Aerosoft, why can’t they do the same with @CptLucky8 , who seems willing to share all his knowledge & experiences with MS & ASOBO , for FREE, and for the benefit of EVERYONE.

In an ideal world, @CptLucky8 would have regular Zoom meetings with the SDK team, and the devs at Asobo, and maybe even make those Zoom session into VOD, so other developers and players, can learn & see what is going ob, and where things are heading.

One things is a Given: MSFS 2020 with input form @CptLucky8 will be a far better product than without that input, and the sooner the better, before too much gets cast in stone, and thereafter, difficult to change.

  • It doesn’t make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do.”
    Steve Jobs

Whats is exactly a custom flight modell? is it the same as the flight modell improvements from a320nx fly by wire mod experimental branch?

As far as i know, the FBW A320 doesn’t use a custom flight model. It is a custom tuned aircraft that runs in the default flight model.

What the flight model does is it takes in the environmental effects, a description of the plane it’s simulating, the control inputs from the pilot, and generates the resultant motion of the 3D model you see on screen. I’m doing a pretty bad job of explaining it, but there you go. It is basically the physics engine of the sim. It’s what you can see when the devs showed the forces acting on the surfaces of the plane.

The problem with the default flight model is that it has to work with all aircraft. From a tiny ultralight to a 747. Not only are their sizes very different, but the type of wing is very different as well. As you can imagine, some approximations have to be made in order for it to work satisfactory. And the result is pretty good in most cases, to be honest. But it is very, very difficult to accurately simulate a particular aircraft. The flight model will have to trade accuracy in favour of flexibility.

Since some third party developers are looking to accurately model the flight characteristics of a particular aircraft, accuracy is the only thing they care about, and they are not interested in flexibility at all. So what they used to do (and are still doing, actually) in FSX and P3D is create their own custom flight model which is perfectly tuned to work with their aircraft. It might even even be fundamentally different to the default model.

In a perfect world there would be no need for such a custom flight model. Asobo would be able to produce a flight model that accurately reproduces any manoeuvre in any plane. But here in the real world that will probably never happened. XPlane couldn’t do it, and its flight model is being actively developed and improved for years and years. This is why it is important for third party developers to be able to use a custom flight model. Otherwise we would still be here, a decade later, with a model that still isn’t quite right, when a third party developer could get it as real as possible in a few months of development.


thx for the explenation! sounds like a big deal…

It really is. Several high profile companies with a long history of flight sim development will pretty much not develop for FS2020 if they cannot get an accurate flight model for their planes. And if that happens, quite a few people will straight up abandon the game, because they are waiting for study level aircraft.

1 Like

is this really possible? then fs2020 will end as flight game and not a real simulator?

I wouldn’t say FS2020 is a game in the sense people use the word on these forums. It most definitely is a simulator. The only thing is that it might not reach the levels of accuracy needed by people practicing real world operations. Some real world pilots have been using P3D to stay current (not in the legal sense, though) during the lockdown. The problem is that if you need to modify your flows or the way you do things in order to cater to the simulator’s particularities, that’s worse than not practicing at all.

I think people might be missing the point. I think MS/Asobo want to improve their flight model so that it works for all planes, not let all plane developers have to create their own flight model.