CommBusEvent Client Event ID not registered as Client Event ID

[MSFS 2024] Bug Reports SimConnect
1

Version: SimConnect SDK 1.6.9

Frequency: Consistently

Severity: Low

Marketplace package name: N/A

Context: SimConnect Communication API

Similar MSFS 2020 issue: N/A

Bug description:

The SimConnect_SubscribeToCommBusEvent call lets you specify a CommBus Event name, and map it to a SIMCONNECT_CLIENT_EVENT_ID. This Id is then used in the (incoming) SIMCONNECT_RECV_COMM_BUS::uEventID field to identify to the client which event is incoming. However, the Client Event Id appears to be unregistered as such in SimConnect; I can use that same id in a call to SimConnect_MapClientEventToSimEvent without getting a SIMCONNECT_EXCEPTION_EVENT_ID_DUPLICATE.

I am a bit confused about this, as the type indicates this should clash.

Repro steps:

    std::cout << "\n--- Test A: CommBus subscribe first, then map same ID as client->sim event ---\n";
    SimConnect_SubscribeToCommBusEvent(hSimConnect, ID_COMMBUS_FIRST, "Sandbox.Test.CommBusEvent");
    SimConnect_MapClientEventToSimEvent(hSimConnect, ID_COMMBUS_FIRST, "Exit.Program");
    pumpMessages(2s);

    std::cout << "\n--- Test B: map client->sim event first, then CommBus subscribe same ID ---\n";
    SimConnect_MapClientEventToSimEvent(hSimConnect, ID_EVENT_FIRST, "Exit.Program");
    SimConnect_SubscribeToCommBusEvent(hSimConnect, ID_EVENT_FIRST, "Sandbox.Test.CommBusEvent2");
    pumpMessages(2s);

The pumpMessages function simply handles all incoming messages for the given duration. For both I would expect the exception message, but in neither case I get one.

Attachments:

Private attachments:

2

Hello @BenkeiBuddy

CommBus events are handled separately, so you can reuse IDs you’ve used for other SimConnect events this will not cause any issue.
However, you’re probably right and we’ll likely introduce a dedicated type instead of using SIMCONNECT_CLIENT_EVENT_ID to avoid any confusion.

Regards,
Sylvain

1 Like
3

You could have reused SIMCONNECT_REQUEST_ID instead, since you already have field dwRequestID in the message, but I agree a SIMCONNECT_COMMBUS_EVENT_ID would be more consistent given it is internally neither a RequestId nor an EventId.

Since the obvious intent was to save space in the message and speed matching it, compared to just passing the name, you could copy the dwArraySize, dwEntryNumber, and dwOutOf fields and forego the inheritance of the list template… Nitpicking, I agree.

Anyways, I have two nice demoes for to and from JavaScript communication with this, but Claude had difficulty finding the right sources to base the JS bits on. I admit I have done some very simple Web UI work, but do not consider myself anything more than (at most) a Medior. With the field still having some major different approaches to solve the same challenges, it is sometimes surprising in how it works out. At least TypeScript gave us a better type system than bare JavaScript.

Cheers,
Bert