SU5 changes to FsVarParamVariant broke backwards compatibility with SU4 gauges

[MSFS 2024] Bug Reports WASM
1

Version: 1.7.17

**Frequency:**Consistently

Severity: Blocker
Blocker - prevents from working on the project, prevents from releasing the product

Context: WASM gauge compiled with SU4 SDK (or older)

Similar MSFS 2020 issue: none, that’s 2024 API

Bug description:

I’ve encountered an issue where my code sending key events using fsEventsTriggerKeyEvent stopped working in SU5. While I don’t know how this function works internally, here’s my suspicion:

In SU5 SDK the FsVarParamVariant structure has been changed by adding FsVec3d field to the union.

struct FsVarParamVariant
    {
        eFsVarParamType type;
        union {
            unsigned int    intValue;
            const char*        stringValue;
            FsCRC                CRCValue;
            double            doubleValue;
            FsVec3d            vec3dValue;
        };
    };
struct FsVarParamArray {
        unsigned int size = 0;
        FsVarParamVariant* array = nullptr;
    };

This changed the size of the structure and made FsVarParamArray incompatible between different SDK versions, in cases when there is more than one item in the array. Code compiled with older SDK will pack the FsVarParamVariant objects into the array as if each was 12 bytes in size, while the simulator now expects them to be 28 bytes in size. So the receiving function not only can’t read any item other than FsVarParamArray.array[0], but will also over-read the buffer with unpredictable results.

This approach would work if the FsVarParamArray was “a struct containing an array with pointers to the variant” (FsVarParamVariant** array), as stated in the SDK documentation description Core And Helpers

However, the actual code is instead “an array of variants” (FsVarParamVariant* array), which is susceptible to variant struct size changes and not portable between versions.

Repro steps:

This code compiled with SU4 SDK works in MSFS SU4, but not in SU5. The event is not sent to the sim at all, or it’s sent but the second event parameter contains garbled data

auto tmp = FsCreateParamArray("ii", 1013 * 16, 2);
fsEventsTriggerKeyEvent(KEY_KOHLSMAN_SET, tmp);
FsDestroyParamArray(&tmp);

Same with this code that does not use helper functions

    FsVarParamVariant var[2];
    var[0].type = FsVarParamTypeInteger;
    var[0].intValue = 1013 * 16;
    var[1].type = FsVarParamTypeInteger;
    var[1].intValue = 2;

    FsVarParamArray param;
    param.size = 2;
    param.array = var;
    fsEventsTriggerKeyEvent(KEY_KOHLSMAN_SET, param);

Attachments:

2

Thanks for reporting,

This is a severe breaking change indeed that will be investigated & fixed ASAP.

Apologies for this.

Best regards,

Eric / Asobo

2 Likes
3

Hello @some1

A fix is available with SU5 Beta 1.7.24.0 that should address the case of WASM module built with SU4 SDK running in SU5 build.

Another fix will come with the next version of SU5 SDK so that the case of WASM module built with SU5 SDK is also addressed.

Regards,
Sylvain

4

Hi Sylvain, is this fix already out in the current public SDK (1.6.9)?

I’m still experiencing an issue with reading simvars that is related to this problem.

5

Hello @some1

My apologies for not updating the thread when the 1.6.9 SDK was released.
Yes that is the SDK version that addresses the problem.

I no longer witness the problem with the VarsAndEvents WASM aircraft SDK sample that was also demonstrating the problem.

So you recompiled your WASM module with SDK 1.6.9 installed but you still have the exact same issue?
Can you check your wasm file and confirm it contains a GetExtensionVersion symbol?

If so, can you please provide us with a code snippet that demonstrates the issue so we can make sure we are checking the same thing?

Regards,
Sylvain

6

My original issue with eventsTrigger has been fixed, but now with the latest SDK and MSFS I have a similar problem when reading simvars that require two indices.

For example this code always returns ‘1’ regardless of electrical connection state between busses 1 and 2.

    auto name_ = fsVarsGetAircraftVarId("BUS CONNECTION ON");
    auto unit_ = fsVarsGetUnitId("Bool");
    auto param = FsCreateParamArray("ii", 1, 2);
    double result;
    fsVarsAVarGet(name_, unit_, param, &result);

The code starts starts to work when I manually edit MSFS_Core.h and remove FsVec3d vec3dValue from FsVarParamVariant, which suggests the same root cause as discussed in this thread.

GetExtensionVersion is included in the output file.