Dear Asobo, Since PMDG 737, MD-80 and Fenix A320 are out in the market some
weird behaviour is occurring on user PCs. When they install or update any of
these products, the compilation time of WASM takes very long time (20 minutes
is the average), during the time the user cannot do anything… however what is
happening is after such time, the airplane will behave erratically unless MSFS
is restarted. This seems an odd behaviour, and I am not sure if these
developers have reported it to the asobo team, my aircraft about to be
released is using WASM, however it compiles faster since the modules must be
much smaller, and my beta testers have no issues or have to restart MSFS after
installing the product or after me pushing an update. So it seems the behavior
occurs after very long compilation times, so the question is: 1) Why such long
compilation times? anything that could be done in the future to avoid this?
users are not very happy with this behaviour on many forums, so if we could
find a way to avoid this issue I think it would be good for the overall
experience. 2) Why MSFS needs to be restarted so the modules work? is this the
expected behaviour from your point of view? PMDG and Leonardo (MD-80) are
instructing users to reboot MSFS after a compile in order to ensure all
modules are loaded. It seems to be by design, everything should work despite
of a long compilation time. People are starting to become worry when an
airplane is WASM enabled due to the issues explained above, so I am looking
for ways to improve the process, etc. since I will be using WASM again for
future projects. Thanks in advance, Kind Regards, Raul
Hello @Simbol, Regarding WASM compilation, it’s done
on the user machine to make sure it matches its specs and doesn’t use
unavailable set of instructions. The good side of this is that it’s very
optimized for the user machine. There are no workaround for Community
packages. For Marketplace packages, the compilation is done at ingestion. As
for the module that would need to be restarted to work properly, we are not
aware of this. Could you provide a specific example so we can investigate?
@EPellissier FYI Regards, Sylvain
I think if a wasm file contains several gauges, or the panel.cfg contains
several wasm files, then the gauges may start after first compilation in a
different order than usual. That may catch some developers off-guard if they
expect a certain initialization order. On the compilation time, I wonder if
the compilation of a single WASM file on MSFS side can be made multithreaded?
Currently from what I can observe, most CPU cores during WASM compilation sit
idle.
I think if a wasm file contains several gauges, or the panel.cfg contains
several wasm files, then the gauges may start after first compilation in a
different order than usual. That may catch some developers off-guard if they
expect a certain initialization order.
Was gauge load order even an SDK guarantee to get started with? To my
knowledge it never was and probably will never be a guarantee, for obvious
reasons, but I might have missed a few discussions in this board?!
Hi Sylvain, My project WASM is not as complex as the products I mentioned
above, so I don’t think my sample would be helpful. In any case you can take
my project directly from Market place now if it help? “Sting S4”. Al thought
my users are not seeing this. But a couple reported they had to restart the
flight after loading the S4 because WASM was not started. If this is compiled
during ingestion for MP products, it is odd they had to do such ting. I am
mostly passing feedback of what users are experiencing with the projects above
via community folder, 25 minutes of compilation time seems an awful lot and
slow considering we are in 2022? just a thought. Thanks for coming back to me,
Raul
I haven’t said that the order is guaranteed anywhere.
I must have miss interpreted “than usual” and “certain order” in here: "in a
different order than usual. That may catch some developers off-
guard if they expect a certain initialization order. " In any case, I
didn’t implied anything wrong with what you said either. I’m just raising the
question whether any order is guaranteed, because if not, logically I’d tend
to think that no gauge should expect any other gauge to be loaded prior in
order to work correctly. Failing gracefully in this case is one option,
alerting the user something is amiss and recommending to restart the game
could also be an option then?!
It’s simply a possible scenario of “what could go wrong”. Most of the time,
the gauges initialize in a certain order, IIRC it’s the order in which they
are defined in panel.cfg. Maybe somebody assumed that’s what’s supposed to
happen all the time.
WASM compile times are still surprisingly long. Can we please get an update on
this and the low CPU usage mentioned above. Thank you in advance!
Hello @Toneking Is it slower than it used to be?
We haven’t witnessed any difference on our side and as I explained above,
there is no workaround for the Community package. Regards, Sylvain
Hi Sylvain, Does this mean it is expected by design WASM compilation is taking
a long time because it is done on the user machine? Or can you shed some light
about the OP question? 1) Why such long compilation times? anything that could
be done in the future to avoid this?
But here is the issue: In your post above, you stated " The good side of this
is that it’s very optimized for the user machine". But we are seeing the
opposite. It is very inefficient, very un-optimized, as it is taking about 30
minutes to compile 1 aircraft with high-end hardware. This is what is so hard
to understand. Can you please explain in detail. Thank you very much!
It’s optimized for execution. Compilation takes a long time, but execution is
then faster thanks to optimizations that were made.
Hi everyone, We have identified the cause of the slowdowns you have been
experiencing with the latest SU10 flighting builds during WASM recompilation.
The issue should be fixed with the next flighting update. Apologies for the
inconvenience. Best regards, Eric / Asobo
A few ideas to make it easier on everyone:
- Not showing a 100% complete progress bar when WASM is compiling
- Showing what component is being loaded (like it is in FSX, P3D, X-Plane)
- Showing an animated loading indicator
Not knowing what’s happening leads us to think the sim is hanging and leads to
forum posts, tickets and a terrible experience for everyone.
And while at it, since the game is only displaying a static image with a
progress bar, and because 100% GPU heat/electricity/noise for displaying a
progress bar is not expected (especially if this takes 30min or more), what
about giving a rest to the GPU while the game is ‘processing’ the bytes?
@EPellissier do you mean in future version, what
used to take say 1/2 hour will be much faster? Because if I’m not mistaken, it
looks like compiling about 15MB of wasm file takes 1/2 hours roughly, which is
about 8KB/s processing speed and doesn’t sound right?!