WASM module not ready (state 5)

Questions & Community Discussions WASM
1

I am getting wasm modules loading dirty and all the console tells me is that
it wasn’t ready in state 5 at the time of loading. What does this mean?

2

Hello @JB3DG You can have a look at the WASM Debug tool to get more
information in general: WASM Debug
(flightsimulator.com)
This error means the WASM module failed to load. You probably have a more
meaningful error that was printed earlier in the console and that you need to
look for. Regards, Sylvain

3

All the WASM Debug tool shows is that the module is dirty. No other
information is presented in the Console.

4

@JB3DG Did you find a solution for this problem? I have the same on one of my projects all of a sudden and no idea, what happens.

Thanks,
Hans

5

Not that I can recall. I think I found some pointer or undefined but declared function that fixed it but it’s always hard to locate

1 Like
6

OK. In my case there’s a console message that Innative couldn’t find a source map. I compared all settings and everything but no joy. I guess, I’ll have to create a new project and copy everything over step by step until I find the reason.

Thanks for the response :slight_smile:

Hans

7

I know it’s no longer a problem for you but I managed to track it down and think it’s a good idea to leave an explanation here.
The culprit was a logging function which used _wfopen(fname, L"a"); but had no check if the result was nullptr (shame on me). The logging function was called during the initialization phase of my panel and crashed it because of an invalid path. However, since the sim was still loading the panel/aircraft, there was no exception message in the console window but a state 5 message instead. The Wasm Debug window showed the status DIRTY.
So, it’s nothing but a simple normal exception that causes state 5.

Hans

3 Likes
8

I miss native C++ debugging tools…

1 Like
9

Hi,

Is it possible for you to provide me with your package so I can take a look at it and find the problem.
It seems that a logging message is missing somewhere too.

Usually, the console shows you the exception code which turned your package dirty. Turning this excepetion on in your debugger should stop the execution at the instruction which produces it.
In your case, you still can turn every exceptions on to try to locate the error.

Best Regards
Maxime / Asobo

10

Well, native Win32 debugging is nicer without any doubt, but I managed to track down the issue with the debugger tools that we got. It’s not perfect, but OK.
The thing that bothers me more is that Intellisense shows all kinds of “invalid” includes or unknown functions that don’t exist when really everything is fine and compiles without any problem.

11

With a few preprocessor directives utilising __INTELLISENSE__ you can get it to calm down, at least in VSCode. Try like this https://github.com/flybywiresim/aircraft/blob/master/fbw-a32nx/src/wasm/fbw_a320/src/main.h

1 Like
12

Thanks a lot. I’ll give it a try :slight_smile:

Hans

13

Hi,

By looking at the package you sent me, it seems that an error message was missing if an error occurred in the SimConnect Dispatch function. The wasm module becomes dirty without telling anyone.

That will be fixed in the next flighting update.
Meanwhile, turning every exceptions on in your debugger (or the right one if you use the error code which can be found in the console) works and allow you to track effectively that kind of issue.

Best Regards
Maxime / Asobo

2 Likes
14

Awesome. Thank you Maxime.

15

I find adding that pre processor definition to the project results in gauge callbacks not found errors

16

It works for me but has no effect on the intellisense errors ( = red underlines) here.

17

I dont think VS intellisense discrepancies with compiler will ever be gotten rid of. WASM is using LLVM/Clang and intellisense is using microsoft C++ compiler as reference. Even sometimes intellisense has discrepancies with microsoft C++ compiler because its not actually using the compiler to generate the errors. I doubt this can be solved.

I wonder if Asobo will consider setting up a proper tool chain in something like CLion instead.

18

Apologies. This maybe works for us in VSCode for the reasons @JoshC stated here (we can use LLVM for intellisense).