WASM file I/O can't read updated package files anymore

Version: 1.1.10.0

Frequency: Consistently

Severity: Low

Marketplace package name: N/A

Context: An aircraft (all HPG helis) in flight.

Similar MSFS 2020 issue: No

Bug description:
Previously in MFS20 we could read updated package files with wasm. (So using ifstream on a file like \\html_ui\\HPGH145-System\\Settings.json

In MFS24 once that file is modified, it can’t be read again. Since we don’t have a debugger I don’t know the specific error, but changing a single number in my config file (not adding or removing bytes) causes subsequent read operations to fail. In MFS20 we got updated content.

Repro steps:

  1. Install H145
  2. Load the aircraft
  3. Observe everything is OK
  4. modify \\html_ui\\HPGH145-System\\Settings.json
  5. Bind a hotkey to TOGGLE ALTERNATE STATIC which requests reload
  6. Press the hotkey

Expected: Config reloads as it does in MFS20 (seamless)
Actual: All config values go to zero and the aircraft can’t fly anymore, because the file I/O failed.

The only WASM solution now is to use work for files that can be updated at runtime. Or funnel through a JS VFS read, which seems to still work for now.

Apologies for not having a deeper bug report on the API failure, but we have no WASM debug on MFS24 right now.

Attachments:

Private attachments:

1 Like

Is the file your WASM module is reading in the same package as the module itself?
When editing the JSON file, are you changing its size?

I’ll have to check but I think MSFS2020 was not too bothered by the fact that file sizes may differ between the layout file and the actual size, while MSFS2024 needs them to be identical. This seems logical (to me at least) but it may have brought another unforeseen issue - since the layout is read when the package is mounted into the VFS, it is now impossible to make edits that change the actual file size.

I’ll discuss with colleagues from the Engine team to better understand the issue.

Best regards,

Eric / Asobo

Yes, WASM in 2020 couldn’t read files outside of the package.

Any edit at all would cause subsequent failure in my testing, even replacing a character and not changing the file size which was surprising.

Maybe it was never fully legitimate before–I could accept that if so. It certainly makes various things easier and fetch in JS is still getting updated files (from the VFS) as expected. As long as the JS API keeps working we can adapt, meaning it isn’t that critical of an issue. Maybe other devs have higher priority scenarios.