Recompiling a WASM System, doesn't reload unless I reload the plane from main menu

Version: 1.54 SU3

Frequency: Consistently

Severity: Blocker

Context: in flight?

Bug description:
A fully native 2024 WASM module, operating as a System (referenced in the system.cfg as per SDK instructions) will not fully load after compiling when you change the module structure unless you exit to the main menu and fully reload the aircraft.

This happens even if you hit BUILD on the project.

If you change just a line, then it works fine, and you can also reconpile the system via the WASM debug tool → recompile.

However, when you are making a new system, you will be changing classes and structures constanlty, then hitting compile in VS, to then hit compile in MSFS 2024. This would take probably over 500 compiles in a normal night, you guys are asking to exit to main menu 500 times, compile, find the airport again, find the parking spot again, and load again.

This is a no go, in MSFS 2020 when you hit the project compile, it always compiled the WASM module and restarted your plane, this is what I was expecting in MSFS 2024.

Repro steps:
Use a WASM module as system.

Change a class or something that would alter the structure of the module, hit project build in MSFS 2024, note how the WASM module stays with the old version until you go back to main menu, compile in main menu, reload flight.

Please guys, fix this.. developing in MSFS 2024 is complex and difficult enought to hit these crazy obstacules to just adjust your core WASM modules, there must be a better way to work.

Thanks,
Raul

1 Like

No issue with regular WASM gauges. Have you tried in SU2? Maybe this fix broke something in SU3 All WASM is recompiled on project build every time there is a change inside \panel directory

No idea,

Not quiting the SU3, in any case we need this fixed.

The wasm module i did, is not located in panel, is inside common\Wasm like you would for a system, etc.

Really love the concept of systems, they run independently on threads, is the way to move forward.

But this compile issue is a problem.

Best,
Raul

UPDATE

So I think I understand what’s happening, when you hit compile as a project the simulation time is reset, but the module variables are not (counters), so looks like the system_init code is not relaunched for the system module on a full project compile and this makes lots of parts of the code to not get triggered..

R.

Hello @SimbolFSReborn,

A fix has been made, it will be available in SU3 (Maybe not the next SU3 flighting update but the one after).

Regards,
Boris

3 Likes

Hello @SimbolFSReborn ,

Can you confirm this is fixed in SU3 flighting ?

Regards,
Boris

Hi @Boris

Unable until SU3 1.5.10 (Eric told me .10 would allow me again to compile without issues). is out and i am back from fsexpo. As you know 1.5.9 has severe problems and i had to exit back to SU2.

Can you let me know when .5.10 is available so i can rejoin to SU3 and retest?

Best,

Raul

The 1.5.10 is already available in beta.
I should have wrote the version number in my message

Regards,
Boris

1 Like

Very well, i am back next Tuesday and i will test this again.

Best,
Raul

1 Like

@Boris this is a negative, problem still there..

Generating a structural change on the module, doesn’t allow a fast “recompile” in the WASM debug window as expected, however after this happens, while you are in flight hitting a full recompile (full build), doesn’t compile the module fresh either and this problem remains:

As a consequense the module stops working as expected and the only solution is to exit to main menu, do a full recompile, and reload a flight, etc. which is very time consuming.

Note that after performing any structural change to a module, the following code fails entirely returning “zero” for the simvar:

execute_calculator_code("(E:SIMULATION TIME, NUMBERS)", &FloatTime, &IntTime, &strTime);

And nothing will fix this.. only a full exit to menu, compile and reload.

Hope you guys nail this down as it is quite difficult to work like this with WASM System modules.

All the best,
Raul

Thank you for the details and apologies for the failed fix.
A dev is reviewing the issue.

I will let you know when I have some news to share.

Regards,
Boris

2 Likes

Hello @SimbolFSReborn ,

A new fix has been integrated in 1.5.15.0
Can you test it and let me know if it resolves your issue please ?

Regards,
Boris

1 Like

Will test and report, thank you.

R.

2 Likes

Hi @Boris there is an improvement, but this is still very much with bugs:

  • The 1st structural change allows to compile in sim withouth exiting to main menu..

  • However after this occurs, any further changes to the WASM code (no structural change) causes this behavior:

    You cannot compile in sim via the WASM Debug recompile anymore, it keeps saying there is a structural change, when, it is not.. the structural change happened already and I did a full project build. So from this point onwards, I should be able to change code and recompile in sim.

    If you then proceed to compile full in sim (project build), all the code changes are ignored.. basically is not compiling any futher changes anymore at this stage, the code remains running but is the old code from the 1st structural change. Now you stuck again to having to exit to main menu and compile from there or restart MSFS.

I have recorded this in a video, which I will be sending privately to you via DM (so please check it), as it is a project I cannot disclose publicaly.

Best,
Raul

2 Likes