XML Key Event Bindings do not intercept Key Events via SimConnect

Version: SU15 - 1.37.4.0

Frequency: Consistently

Severity: Low

Context: In edition, Community, Official / In in flight

Bug description:
When a Key Event (K:) is generated via the MSFS internal control assignments, it will correctly get intercepted by any key binding code snippet like:

	<UseInputEvent ID="PROCEDURE">
		<INPUT_EVENT_ID_SOURCE>PROCEDURE</INPUT_EVENT_ID_SOURCE>
		<IE_NAME>APVSUP</IE_NAME>
		<SET_ARG_COUNT>1</SET_ARG_COUNT>
		<BINDING_SET_0>L0</BINDING_SET_0>
		<BINDING_SET_0_PARAM_0>2</BINDING_SET_0_PARAM_0>
		<BINDING_SET_0_EVENT_ID>AP_VS_VAR_INC</BINDING_SET_0_EVENT_ID>
		<BINDING_SET_0_EVENT_ID_ONLY>True</BINDING_SET_0_EVENT_ID_ONLY>
		<INC_CODE>1 (&gt;B:#INPUT_EVENT_ID_SOURCE#_#IE_NAME#_Set)</INC_CODE>
		<DEC_CODE>0 (&gt;B:#INPUT_EVENT_ID_SOURCE#_#IE_NAME#_Set)</DEC_CODE>
		<SET_CODE>1 (&gt;B:AUTOPILOT_KAP140_1_UP_Push)</SET_CODE>
	</UseInputEvent>

However, if the same event is sent via SimConnect (FSUIPC), the intercept will not be actioned, and the key event will execute instead.

Repro steps:

  • Utilize an aircraft with KAP-140 and implement the above code snippet in ModelBehaviors.
  • Assign a keyboar/joystick input to AP_VS_VAR_INC via the MSFS controls menu
    – Observe the KAP-140 button being pressed when the control is actioned.
  • Now clear the AP_VS_VAR_INC assignment ion the controls.
  • Use FSUIPC to assign AP_VS_VAR_INC to a joystick button (or alternatively, use a SimConnect utility).
  • Action the key event via SimConnect (or input programmed via Kewyboard)
  • The VS UP button in the KAP-140 will not be pressed
    – Instead, AP_VS_VAR_INC is executed. THe AP VS VAR can be observed to increase at every actioning.

That would depend on the GroupID/priority the event is being sent with I believe. Do you know what priority they send with?

Hello @MariopilotPD808

I am unable to replicate the issue.
I added your code snippet to a C172 classic component and modified the InputEvent SimConnect SDK sample to send the AP_VS_VAR_INC event.
It is intercepted by the Input Event binding as expected and the button is pushed.

Edit: maybe you used SimConnect_TransmitClientEvent instead?

Regards,
Sylvain

THis may be on FSUUPC side at this point. I shall ask what they are doing with SimConnect_SetInputGroupPriority. Apparently this can have an effect on this.

Yes - SimConnect_TransmitClientEvent is being used to send the event - how else do you send an event via SimConnect?

The group priority used for standard events such as these is:
SIMCONNECT_GROUP_PRIORITY_STANDARD - 1
(other events, such as most axis events, use a group priority of SIMCONNECT_GROUP_PRIORITY_HIGHEST_MASKABLE).

Will the priority have an effect on this? What priority needs to be used?
[Later: I have also tried with priority SIMCONNECT_GROUP_PRIORITY_HIGHEST_MASKABLE with the same result]

Note also that executing the calculator code ‘(>K:AP_VS_VAR_INC)’ (or ‘1 (>K:AP_VS_VAR_INC)’) in a WASM also does not trigger the input event

By mapping it to an input event as demonstrated in the InputEvent sample although it’s very limited.
You also have SimConnect_SetInputEvent to trigger model behavior input events.

It makes sense then, SimConnect_TransmitClientEvent, just like trigger_key_event and execute_calculator_code in the Gauge API will bypass JS and Input Event interception and call the sim event directly.
As far as I can tell, only the TRIGGER_KEY_EVENT coherent call is JS allows the user to explicitly set if interceptions should be bypassed or not.

I understand how this is an issue and I’ll log a bug on this.

Regards,
Sylvain

Ah, ok. You can assign directly to Input Events using FSUIPC. I cannot map key events to Input Events, as all such mappings would be aircraft specific.

This is what I believed was the issue…

Ok, thanks, It would be useful to be able to enable/disable intercepts when a key event is sent via SimConnect in the same way that you can with the TRIGGER_KEY_EVENT coherent call in JS.

Thanks for your reply. Regards,
John

Regards,
John

I took a look at the sample you are referring to and realise that you were talking about key/button press input events. I was referring to the new Input Event interface to access B-type variables.
I cannot map client events to such input events in this way for various reasons.
It would be good if events sent via TransmitClientEvent would follow the same path as when sent via an input event mapping, or at least have the option for this.
Thanks again,
John

That sounds right to me so I don’t think that’s the issue :+1:.