SimConnect events are masked with too high a priority

[gizmo71]

Aircraft Version

{
  "built": "2021-04-25T22:16:34+00:00",
  "ref": "master",
  "sha": "8cc7d5fd1cd3b962c03ae3276f47e386b902985c",
  "actor": "davidwalschots",
  "event_name": "manual"
}

Describe the bug In SimConnectInterface.cpp, events which the WASM module listens for are masked at SIMCONNECT_GROUP_PRIORITY_HIGHEST_MASKABLE. This means that an external SimConnect application which wishes to intercept such events can only do so if it is started before Flight Sim; if starting afterwards, such an app ends up with a priority just below the A32NX WASM and never gets to see such events.

In my specific case, I'm trying to catch AUTOPILOT_ON, and then retransmit it, but also send one of the A32NX's custom AP1/AP2 events (depending on which is not selected). Neither activity works if the app is start after FlightSim because the A32NX codes catches and swallows these events.

This is going to affect any external app which wishes to listen for and/or resend events for which A32NX's WASM is also listening. It's particularly irritating with AUTOPILOT_ON because the module swallows it without any action to actually activate an autopilot.

To Reproduce

1. Start MSFS and load a flight with the A32NX.
2. Start an external SimConnect app which listens for AUTOPILOT_ON
3. The external app never receives the event from any input button/key which is mapped to it.

Expected behavior

It should be possible to intercept at least the "standard" FlightSim events and take other actions before retransmitting the event. By convention, an aircraft should use a priority between SIMCONNECT_GROUP_PRIORITY_STANDARD and SIMCONNECT_GROUP_PRIORITY_DEFAULT (usually by simply using the former) so that other SimConnect clients can receive the events first, but the aircraft gets them before the sim itself.

Actual behavior

An external app never receives the event from any input button/key which is mapped to it (see "To Reproduce" above)... unless it is started before MSFS, and therefore 'wins' the race to get the highest priority notification group.

References

Additional context

The app I'm trying to make work includes this module which is designed to receive AUTOPILOT_ON, and issue A32NX.FCU_AP_1_PUSH if AP1 isn't on, or A32NX.FCU_AP_2_PUSH if AP1 is on but AP2 isn't. The net effect should be to turn AP1 on if neither or AP2 is on, AP2 if AP1 is on and not in APPR mode, or AP1+AP2 if exactly one AP is on and APPR is selected.

However, this will be a general problem with any SimConnect module which wishes to listen for events for which A32NX itself is listening via SimConnect. This is perhaps the most insidious problem - the order in which things are started changes their behaviour.

Was this working before/when did the issue start occurring?

_I've only noticed it since trying to implement my APON code, but looking at the A32NX source, it would've been a problem even since the SimConnect module was added.

Is this a problem in the vanilla unmodded game?

No, the default aircraft and game code listen at a much lower priority by design to avoid these sorts of problems.

Discord username (if different from GitHub): Gizmo#3618

[aguther]

This is something that could be looked into.

but most of the events must be captured and masked away from the sim. the default AP must not engage and the same applies for many control input events. as far as i know this is only possible with HIGHEST_MASKABLE.

If someone would interfere those events it potentially breaks our custom systems.

[aguther]

What I don’t see is why it is needed to capture and mask the event AUTOPILOT_ON event. You can send that event at any time as also the other events, nothing is stopping you from that. That way you can control the FCU and autopilot system.

I was able to use either FSUIPC and SPAD.neXt to do so, using Honeycomb Bravo I was able to control the whole FCU using that. So I see really not showstopper to do the same with a different application as well…

Being on standard priority has the big risk ending in default priority if a different client was there before and that would mean the whole fly-by-wire system, autothrust and autopilot would stop working.

So for the moment I disagree to change that.