plane icon Welcome to Microsoft Flight Simulator’s SDK Q&A Platform!

You have questions regarding the SDK? DevMode Tools? SimConnect? You would like to submit an idea for future improvements, seek help or exchange knowledge? You’re in the right place.


Please take a moment to read the platform’s guidelines before you get started!


question

bert.laverman avatar image
bert.laverman asked virtuali edited

If SimConnect is not the Future, what is?

In a recent discussion concerning ways to integrate with the simulator, we were reminded that SimConnect is not future-safe. Also, the SimConnect networking connectivity is not planned for the XBox. However, the SDK documentation, for out-of-process add-on components, only discusses SimConnect as an API.

WebAssembly, which was developed to provide a safe sandbox for embedded and native code in Web pages, has severe restrictions concerning standards-based multi-threading and exception handling, and, if the Web-based implementations are any guide, a managed heap. This again places restrictions on the options for interacting with MSFS, especially when one wants to capitalize on tools and hardware for cockpit building. Let alone live integrations for flight-tracking and mapping, fleet management, or alternative ways to allow for group flights.

Now I'll be the last to claim that SimConnect is the best we can get; it is at best a dinosaur with only minimal nods towards the capabilities of modern languages, but it is what we have, and with some work can be made a lot better. (shameless plug: see CsSimConnect) Can you please indicate what we can do to give our code something that is future-proof, as well as able to use modern tooling and hardware? To wit, to build a modern Windows application only rarely does one start with a Win32 MFC base. CLR and JIT (or pre-compiled), or even JVM or Python, provide more than enough performance for most tasks. Just not for mathematically intense work such as a 3D simulator, but that is not what an add-on developer needs to do, right? That is what you do.

Bert Laverman
Software Architect and Developer

simconnect
10 |10000
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

3 Answers

·
EPellissier avatar image
EPellissier answered bert.laverman commented

Hi everyone,

I think this whole thread started on some wrong assumption - we didn't say that SimConnect was not future-proof but that creating custom flight models through SimConnect wasn't.

So to make things clear:

  • We have no plan to drop SimConnect at the moment.
  • SimConnect is the main interface for standalone WASM modules and out-of-process add-ons indeed.
  • On top of the WASM APIs we mentioned several times, we are also planning to expand SimConnect capabilities.
  • Xbox connectivity is a broader topic that isn't really linked to SimConnect and is discussed internally.

Hope this clarifies a few things but feel free to ask if not.

Best regards,

Eric / Asobo

1 comment
10 |10000
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

bert.laverman avatar image bert.laverman ·
Thank you, I must admit not catching the restriction to flight models. I'll go back to developing using SimConnect. That said, dare I ask about L-vars? Will there be a standard solution to accessing them through SimConnect?
0 Likes 0 ·
virtuali avatar image
virtuali answered virtuali edited

I have no problems with WASM but, it seems it has been made *mainly* to cater the needs of some airplane developers that needed to port lots C++/GDI+ code.

Not there's anything wrong with C++/GDI+: this is coming from the guy who wrote the only default airplane included FSX ( the F/A-18 we made for Microsoft ) which was coded entirely in C++/GDI+, and the official GDI+ example which was included with ESP when it was still owned by Microsoft, was a slightly modified version of the code we sold to Microsoft in 2007, before that, most planes still came with 2D panels and rotating needles/bitmaps, dating back to FS95-era...

We moved away from airplane/gauges in the meantime, and are more focused to stand-alone modules that provides global services to the sim, and there are several things that are a bit unclear about the whole SDK situation:

- Right now, a stand-alone WASM doesn't have much to do OTHER than using Simconnect! It can't call the Windows API, it can't read outside it's own package, it can't link to any 3rd party libraries, it doesn't have a clear interaction with the HTML/JS sub-system, it doesn't have ANY kind of GUI-related function ( why can't we just get an handle to ImGUI, so we could display some stuff using the framework the simulator has already loaded with Dev Mode ? )., it can't do anything with graphic, because those APIs are used only in WASM-based gauge so, it's anybody able to tell me what are we supposed to DO with a Stand-alone WASM module, other than calling Simconnect ?

And what people have been using Stand-alone WASM modules for ? Mostly ONE thing: to act as a server to provide access to out-of-process clients, for the one and only reason to get access to the Gauges API calls, so they could read/write L: variables and all the other variables not accessible from Simconnect directly. There are already an half-dozen of modules all doing this exact thing, so if there was any performance concerns about too much Simconnect (identical) traffic, it has already blown out of proportions and it will only get worse, and the client data area functions are so flexible that you can't be sure some guy hasn't already made a module that is pushing 1K of data over Named Pipes every frame...

Why people do that ? To interface with custom hardware, special joysticks, arduino boards, Streamdecks, moving map apps running on iPads, Yoke/Throttles with lights or even screens, but even apps like Navigraph moving maps, that use their own out of process client. Everything, basically, that MUST be running out-of process to use the real Windows API and interface with USB/hardware, but MUST also get data from the sim. And that's only possible with a Stand-Alone WASM module using Simconnect to connect to an out of process Simconnect client.

Sure, lots of this MIGHT be also possible with JS+HTML but, the irony is, that "legacy" Simconnect is at least DOCUMENTED, while the whole JS+HTML framework has exactly...ZERO documentation so, is the only officially documented API that has stood the test of time, is being talked of being phased out, and to be replaced by.... nothing ? A "To Do" empty doc ?

I really wanted to hear something like this:

"Simconnect will eventually go away in the LONG term but, we are designing a brand new API, more modern, more performing, with more access to the complete set of features of the sim, that will do much more than Simconnect ever did, and we ARE keeping Simconnect in "maintenance mode" only, meaning only bug fixes and keep compatibility with updates"

That would sound like a reasonable approach, and developers that are making add-ons sold on the Marketplace, who are contributing to make the sim sustainable on the long term, need to make plans, because some time it might take years to make a complex add-on, when the novelty of the extremely good graphic in MSFS will wear off, users will start asking for more involved stuff, and Xbox beginners will either turn into serious simmers, or they'll just move one and play with something else, there's no middle ground.

4 comments
10 |10000
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

RXP avatar image RXP ·

The sim API is not designed to use the sim as basically a glorified graphics engine or hook in arbitrary native code. Those things are just not in scope, due to sandboxing and security, and the team’s position on that is unlikely to change.

There is a reason third parties can't use their own custom flight models in conjunction with Asobo developing their default flight model for those that want to use it, it is because those third parties leave their knowledge with them and don’t contribute upstream. If instead everyone works together on one flight model that makes everything possible and has everyone with a vested interest in its accuracy, everyone wins.

The alternative is the current FSX and P3D situation: the core components stagnate, folks just hack together proprietary solutions, and development expertise stays completely isolated in pockets that don’t speak with each other. And that doesn’t help the sim community at all.

The way FSX and P3D evolved, from a platform perspective, is not a healthy way forward.

If the community of great third parties instead fold feedback into the MSFS teams, who are open to it and actively building the avenues to supply it, then everyone can benefit from their experience and expertise, instead of the knowledge being held only by a select few. Having fragmented islands of totally custom proprietary implementations of everything is the opposite of what is needed for an awesome experience.

1 Like 1 ·
tml avatar image tml ·
One thing that it would be great if WASM code could do would be to directly affect 3D objects. Animation, texture mapping, etc. Even individual vertices. For example, think how nice it would be if you could implement a drag chute in C++, animating each vertex.
0 Likes 0 ·
charuma0 avatar image charuma0 ·

Maybe I misunderstood, but I can easily build stand alone app with WPF, connect with the sim via simconnect and access all Windows API I like with the same app.

So what are we supposed to do with simconnect? Build things like Flight Recorder or a Pushback tool entirely controlled by voice input (shameless plug II: I am the author of the later). Btw flight recorder is an excellent example, how the app takes over control of the user aircraft and lets it fly exactly the recorded flight path.

I am building selfmade, 3D printed flight controllers, connected as a normal USB peripherals. If something would not possible that way, I would use Arduino based periphery that provides any thinkable input via a custom protocol, build a little WPF app that reads that protocol from a serial port and translates that to the simconnect input I want.

Are you aware of these possibilities or did I understand you completely wrong?

0 Likes 0 ·
virtuali avatar image virtuali charuma0 ·

We were worried because, it appeared at first Asobo devs were hinting not to rely too much on Simconnect, because it might not be considered viable in long term.

This clearly left some puzzled because, Simconnect is reasonably well documented and tested ( although is still missing just A FEW calls from FSX which are crucial for some add-ons, like menus, notifications and event masking ) and, at this time, there's just nothing that could replace it, making WASM stand-on modules basically useless, since there's not much they can do other than calling Simconnnect.

This has been clarified by Eric: they only meant is not suggested to use Simconnect to *override* the flight model, not that Simconnect might go away soon.


1 Like 1 ·
MiGMan_Flight_Sim_Museum avatar image
MiGMan_Flight_Sim_Museum answered 
Why people do that ? To interface with custom hardware, special joysticks, arduino boards, Streamdecks, moving map apps running on iPads, Yoke/Throttles with lights or even screens, but even apps like Navigraph moving maps, that use their own out of process client.

Amen to that. I'm using 5 devices (tablets) at the moment that are using SimConnect, and 6 more using USB. The tablets are using SimDashboard, which was developed primarily to support motor racing, but has a pretty good flight sim component.

But the real heavyweight in that field, Air Manager, which makes professional training simulators but allows the home user to use their instrument panels on tablets and PC, has yet to weigh in to the MSFS field citing concerns with the SDK / SimConnect not being stable yet.

This image (running P3D with Air Manager) gives an idea of how good their instruments look and I'm hanging out to be able to use them in MSFS, having built a cockpit around the MB-339 and accumulated over 2,000 hours in it!

1646296452955.jpeg

More here (from Oct 2020)


1646296452955.jpeg (198.7 KiB)
10 |10000
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 5 attachments (including images) can be used with a maximum of 19.1 MiB each and 23.8 MiB total.