FSUIPC sent KeyEvents vs. Aircraft XML Control bindings.

[Mario Noriega]

Hello,

MSFS offers a facility that allows us developers to program in overrides for key events. This way we can intercept then, and do something else entirely.

Example: AP_VS_VAR_INC --> (>B:AUTOPILOT_KAP140_1_ALT_Push)

(not actual XML code!)

This causes the AP_VS_VAR_INC keyEvent to press the corresponding VS UP button on the MSFS KAP-140, instead of simply increasing VS target. AS a result the display on the JS gauge  updates properly.

All this works fine when the key event is mapped via MSFS control options

The method however fails when FSUIPC sends the key event instead. This simply results in the key event executing instead.

 

		<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>

I inserted the XML snippet as an example.

 

Any ideas?

[John Dowson]

This is interesting and explains why some key events sent via external apps (i.e. sent using the MSFS SimConnect SDK) sometimes don't work whereas the same (or similar) event assigned in MSFS do.

However, FSUIPC know nothing about this key event mapping - it just sends the key event to MSFS using the MSFS-provided SimConnect SDK. It is therefore an issue with the SDK that events sent using this do not go through the same path as the ones sent internally.

There are two ways to get around this.

1. use the Input Event directly. Direct access to Input Events was recently added to the SDK and Input Events are available for use (via assignments, offsets or lua) in FSUIPC7 since version 7.4.0. You can also list the available Input Events for the current loaded aircraft using the Log -> List Input Events menu option.

Note that not all B:vars (which are the Input Events) may yet be exposed by the Input Events interface. MSFS have indicated that they intend to make all available, but this may not be the case. If the Input Event isn't available, then you will have to use the 2nd method, as it is not possible to control B:vars via calculator code (i.e. using a preset) for some reason...

2. If no Input Event is available/exposed to control the B:var, the only way to control/assign to this externally is by hacking the xml code. The idea here is to introduce an lvar whuch is checked in an update component (on a timer) and used to set the B:var. This is explained in various posts here, and also in the description of some HubHop presets, e.g. TBM930_BLEED_AIR_OFF. Also see https://forum.simflight.com/topic/97903-cockspur-mustang-c510-starter-and-ignition-was-fsuipc7-wasm-submenu-shows-disable-only/?do=findComment&comment=589316

John

[Mario Noriega]

Thanks John,

 

I shall also ask over the MSFS Devsupport forums, the devs there may choose to do something about it. This is in a nutshell a SimConnect issue., as FSUIPC only sent a SimConnect Request. What MSFS does with that is beyond FSUIPC 🙂

 

Regards,

 

Mario N.

[John Dowson]

22 hours ago, Mario Noriega said:

This is in a nutshell a SimConnect issue., as FSUIPC only sent a SimConnect Request. What MSFS does with that is beyond FSUIPC

Yes. and this issue has been known for a long time. There is already a thread on this in the Asobo forums...

[Mario Noriega]

Hello John,

Over at the MSFS Devsupport forums, they suggested that the GroupID/priority setting may be related to this.

A MSFS Dev said that using my code snippet above, and feeding AP_VS_VAR_INC  through the Simconnct SDK example 9modified) yielded the expected result, where my EventID interceptor did its job. Any Thoughts?

I'd suggest that if this is a behaviour that can be changed, it shall possibly be a config option, so not to change the behaviour for all.

 

[John Dowson]

1 hour ago, Mario Noriega said:

Over at the MSFS Devsupport forums, they suggested that the GroupID/priority setting may be related to this.

I am not sure why the group priority would affect this...I will check out the dev support forums (but a link would have been useful).

1 hour ago, Mario Noriega said:

A MSFS Dev said that using my code snippet above, and feeding AP_VS_VAR_INC  through the Simconnct SDK example 9modified) yielded the expected result, where my EventID interceptor did its job. Any Thoughts?

How would I use that snippet to test this here?

1 hour ago, Mario Noriega said:

I'd suggest that if this is a behaviour that can be changed, it shall possibly be a config option, so not to change the behaviour for all.

I really do not know - I will have to look into this further....

John

[Mario Noriega]

		<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;K:ALL_LIGHTS_TOGGLE)</SET_CODE>
		</UseInputEvent>

 

You can add this script into the ModelBehaviors of any aircraft.

For instance, the C-172 AS-1000. The Classic is encrypted.

The file is Cessna172SP_AS1000_interior.xml. You can insert this at the file end, between lines 525 and 526 (in between </Component> and </Behaviors>. (Backup the original first!)

If in doubt, let me know and I'll attach a modified file for you.

The script above will do the blatantly nonsensical thing of toggling all lights when AP_VS_VAR_INC is requested. This removes the need to have KAP-140 to test this. Anything can go into SET_CODE.

 

Quote

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

This is what an user said...

https://devsupport.flightsimulator.com/t/xml-key-event-bindings-do-not-intercept-key-events-via-simconnect/8320

 

Cheers,

 

Mario N.

 

 

[John Dowson]

Does the event work correctly if sent via calculator code/using a preset?
Can you check this by creating a preset - add the following to a file called myevents.txt (create this if it doesn't exist) in your FSUIPC7 installation folder and add the following:
      My_AUTOPILOT_KAP140_1_ALT_Push#1 (>K:AUTOPILOT_KAP140_1_ALT_Push)
or possibly
    My_AP_VS_VAR_INC#1 (>K:AP_VS_VAR_INC)

Then try assigning to that.

I have commented on the MSFS support thread - lets see what they say. I will do some testing with different priorities here...

John

[John Dowson]

34 minutes ago, John Dowson said:

I will do some testing with different priorities here...

I have checked both the event and the preset using your snippet and nothing happens (i.e. lights not toggled) in the VC - but the event is logged by FSUIPC in both cases.

I have also changed the priority of the group with this event and still don't see anything, using both the key event and the preset.

What do you assign to in MSFS to trigger this event? I would like to check that this is working here....

[John Dowson]

Ok, Asobo have now replied again in the DevSupport request that you raised. Sending key events via both  SimConnect (TransmitClientEvent) and the Guages API (execute_calculator_code) will bypass the event interception and call the sim event directly, hence the issue.

A bug will be logged for this - there is not much I can do here I am afraid. I will look at the Input Event mapping sample that they referenced, but I doubt I can implement such a mapping in FSUIPC as this would be dependent on the loaded aircraft.

John

[John Dowson]

13 minutes ago, John Dowson said:

I will look at the Input Event mapping sample that they referenced

This sample maps a key press input event to the client event, which is in turn is mapped to the actual key event. FSUIPC does not and cannot use these type of input events for controller assignments, as it interacts with hardware devices at a lower level via the Windows API, not using these type of input events.

We will have to wait until this issue has been addressed by Asobo.

[Mario Noriega]

Thanks for digging into this.

It is very minor, as I can use InputEvents instead to map my controls.

It will be nicer to get consistent behaviour from FS though.

[John Dowson]

5 minutes ago, Mario Noriega said:

It will be nicer to get consistent behaviour from FS though.

Yes, it would...hopefully this will be fixed in a later SDK update, but no idea how long this will take...

Cheers,

John