• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

MSFS WASM/SimConnect and Asynchronous execution

H

HornetJockey

Messages
16
Country
us-newyork
I regard myself a novice in C++ development, so please excuse my lack of experience. I started developing MSFS WASM/SimConnect module by looking at the included SDK examples. I developed a WASM/SimConnect module which, at a press of a button, reads in and parses a bunch of rather large XML files. The whole operation takes about 14 seconds. During this time, the sim freezes, and then unfreezes when the task is done.

I was under impression that a WASM module is asynchronous: it runs within its own loop and sends/receives events to the server (sim) which doesn't care what the module is doing. Why is it then that the sim freezes? Is there anything I can do about this? I tried threading but WASM is not supporting threading...
 
Last edited:
Unless Asobo has wrapped that module's code execution inside of a dedicated thread, it will not run independantly and thus will indeed interrupt the sim's main process.
 
WarpD said:
Unless Asobo has wrapped that module's code execution inside of a dedicated thread, it will not run independantly and thus will indeed interrupt the sim's main process.
Click to expand...
Thank you for your response! Is wrapping something that happens automatically? During packaging? Can I "ask" for it somehow?
 
You would have to ask Asobo if your module's code is being called within a separate thread that doesn't bring the sim to a standstill while it waits. My guess is no it's not automatic, has nothing to do with packaging and I doubt there's a way to make the sim do this by "request".
 
AFAICS, if you really need to read in so much information your only solution is to do it in much smaller chunks and allow the sim to go off and do something else before coming back for the next chunk.
 
Thanks guys, for chiming in. I am just dumbfounded that Asobo would structure it this way. That defeats the whole purpose of asynchronous architecture, doesn't it? That means all those instruments people are creating can really affect sim performance, and I'm sure that wasn't Asobo's intent...

I have the loading in my code just after the SimConnect initialization, so the loading happens while the sim itself is loading, and it is less noticeable.

I'm going to post this question in MS Dev forum... maybe Asobo responds and explains.
 
The only way you can do any work 'asynchronously' (I put it this way because it isn't really) is to hand off long running stuff to a second WASM SimConnect dll and pick up the result when the second dll tells you that the data is ready. That's not a typo: on loading your WASM module MSFS2020 recompiles it into a dll. I have no idea if _extern calls would work because I haven't tried it, but I have successfully passed data using the SimConnect custom data events. Take a look at sd2gau39 in the Downloads section; most of what is in the SimConnect section is directly transferable to WASM. Alternatively look at the SendEventA/B/C solutions in the MSFS SDK samples.
 
Thanks! So, I got an answer and a few suggestions on the DevSupport forum (link here) from someone who seems knowledgeable (not sure if they are Asobo employees). WASM module is asynchronous but it runs on the main (sim) thread. Among the suggestions is the Communications API approach, which I think is what you are suggesting, WASM to WASM. But what you are suggesting, to hand it off to a second WASM module - wouldn't that pause the sim just the same? I don't care if my main WASM module pauses - but I don't want the sim to pause.

Other suggestions from the forum were to have JS do the loading and send the data to WASM. JS is asynchronous and it appears it runs on the separate thread.
 
It wasn't quite what I had in mind, but if it's the 'official way', in theory it should work.

Before you get utterly frustrated with the SDK, two things I always tell people: 1) it's not at v1.0 so therefore it can't be fully trusted and 2) if it doesn't work after hours of trying, don't assume that your code is faulty. After almost five years the SDK is still incomplete.

Yes, out-of-process SimConnect (the .exe suggestion) works as an asynchronous 'thread' and it's an approach I have used in the past. The downside - of course there had to be a downside - is that Microsoft will NOT under any circumstances allow you to package an .exe for release through the Marketplace and no, you can't release MSFS addons anywhere except through the Marketplace. I haven't done any MSFS development for around a year because I got so frustrated with the poor SDK and the time-to-release of Marketplace packages, but I can't see either of those restrictions having changed in the interim.

P3D may not be as pretty as MSFS by a long way, but it's paradise for a developer compared to MSFS.
 
You must log in or register to reply here.
Back
Top