Severe WASM BUG with SU4 - Unable to perform IO file functions

Version: 1.6.5 (SU4)

Frequency: Consistently

Severity: Blocker - SEVERE

Marketplace package name: Sting S4, TL3000 and FSR500

Context: Streamed or Mounted uppon loading a flight, MSFS 2020 aircraft using WASM

Bug description:

WASM Modules seems to be unable to read files properly from the work folder, prior to SU4 everything was working correctly.

As a result all our persistant variables and controls are now broken, leading to customers contacting us already and posting on MSFS Forums

Repro steps:

Prior to SU4, when you run the engine for example the engine hours, bulbs operations hours, etc. will be recorded every second and saved to disk on regular basis or uppon exiting the flight.

Uppon loading the next flight on the Sting S4, TL3000 or FSR500 EFB you would see the number of minutes / hours each component has been running.

Now with SU4, the data gets wiped, and I have been debugging the WASM module line by line for days, dicovering now the issues seems to be, when the WASM module initialize, and the corresponding files are being read, these come empty!.

I will be sending a snipped of the code used via PM, but basically it seems we have an issue with

ifstream objects and the read functions somehow..

This is a big issue as it is rendering all my products pretty much non functional.

Best,
Raul

1 Like

This sounds like this issue SU4 WASI `fd_read` always returning error 29, even if read is successful

I see.

@EPellissier check the private content how I read files, I bet is the same issue. My problem is even reading, I cannot read data.. is not just writing.

So this is fixed for 1.6.6? If so we wait because patching this for my entire fleet would take a lot of effort and time.

Best,

Raul

We discussed this in PM but so that everybody knows: the same fix will fix Raul’s issue. :wink:

Best regards,

Eric / Asobo

1 Like

@SimbolFSReborn

Can we consider this issue fixed?

Best regards,

Eric / Asobo

Yes 100% thanks for the follow up.

R.

1 Like

I have a similar issue to the one reported here, but in the current MSFS2024 release.
My WASM cannot access files in the Community work folder (as it can in MSFS2020), but it can read files in the persistent storage area, under \AppData\Roaming\Microsoft Flight Simulator 2024\WASM\MSFS2020\WASM-name\work (for Steam install).
Is this a known issue in the current release, and will this be fixed in SU4?

What do you call the “Community work folder”?

This is the expected behavior.

Your description looks like the system is behaving as expected but I might be missing something?

Best regards,

Eric / Asobo

Sorry, I mean the ‘modules’ folder, under the WASM folder that is in the Community folder. Previously, and in MSFS2020, it is possible to read files from this location, but to not write/update them.

Yes, I know you can read/write to file from that location. My question relates to the fact that it no longer seems possible to read files in MSFS2024 (only) from the WASM’s ‘modules’ folder, where the *.wasm module is located.
So the question is why can’t I read files anymore from this location, when this was previously possible and is still possible in MSFS2020.
Or are you saying that it is only possible to read files from the persistent storage area in MSFS2024?

Regards,

John

The MSFS2020 SDK states:

In order to access files from within an add-on, filenames can be prefixed in two ways:

  • " .\": to access the files from within the add-on package. This has a read-only access.

  • " \work": to access a persistent storage that the add-on can use. This is a read/write access.

The second bullet point works in both MSFS2020 and MSFS2024. The first bullet point only works in MSFS2020. I am trying to access files by opening “.\modules” which is not working in MSFS2024 (with WASM compiled with MSFS2020 SDK).

Regards,

John

Sorry, please forget this! The issue was that I had not updated the layout.json file with the new files I have added. It is working once I did that
sorry for the confusion.

Regards,

John

2 Likes

No problem at all, glad you found the issue. :slight_smile:

Best regards,

Eric / Asobo