Version: 1.3.23.0
Frequency: Consistently
Severity: High
Context: Triggering native InputEvents via stand alone SimConnect client
Bug description:
At some point in the beta I became aware that triggering InputEvents via SimConnect stopped working in many cases. Customers tell me that this is especially bad in legacy aircraft that they ported over to FS24.
Calling on their BVar cousins does instead work and yield the expected action.
Repro steps:
Example: IE:AS1000_PFD_1_COM_SWAP in the G1000 V1 is non-functional. One has to resort to
1·(>B:AS1000_PFD_1_COM_Swap_Push)·1·(>B:AS1000_PFD_1_COM_Swap_Release)·
1 Like
Hello @LorbySI
There seems to be an issue with the enumeration and handling of parameters.
How many are you providing when you do a SetInputEvent on AS1000_PFD_1_COM_SWAP?
Regards,
Sylvain
With SimConnect “SetInputEvent” I can only provide one parameter. The SDK documentation says Float or String, but I only use float IEs.
SetInputEvent takes a PVOID and a size, you are expected to pack all parameters listed by EnumerateInputEventParams into a buffer.
For example, if the enumerate params function returns “;char[256];FLOAT64”, you are expected to do the following:
#pragma pack (1)
struct data
{
char value_str[256];
double value_f64;
};
#pragma pack (0)
data my_data;
strcpy_s(my_data.value_str, "a string parameter");
my_data.value_f64 = 12.3;
SimConnect_SetInputEvent(_instance.get_handle(), input.hash, sizeof(my_data), &my_data);
That said, there is a bug in MSFS 2024, where the wrong list of params is returned and they’re not processed correctly.
In the case of AS1000_PFD_1_COM_SWAP, it takes 2 double parameters:
- Push (1) or Release (0)
- Duration in case of a push
But the the enumeration function returns 3, and you have to provide 3 with the 1st param duplicated for it to work.
A fix is being worked on for this.
Regards,
Sylvain
Hello Sylvain,
that seems very complicated. My app processes all potential InputEvents, not only this one. I would have to create the structures dynamically (in C#) for this to work.
Has this been changed compared to MSFS 2020? The process of using IEs and making them available to the end user was very simple. Now it seems next to impossible to accomplish with some IEs, when there is a dynamic logic like this in play.
Best regards
Oliver
No, this is the original design.
A lot of InputEvents are taking 0 or 1 parameter so I assume that’s why your implementation worked most of the time if you always send 1 double.
We need to see how the fix will positively impact your application but that will not be before SU3 unfortunately.
Regards,
Sylvain
Hello @LorbySI
The issue with the InputEvent parameters not being processed correctly when sent through SimConnect_SetInputEvent was fixed in SU3 beta 1.5.1.0.
Regards,
Sylvain
1 Like
Hello Sylvain,
does this also change the number of parameters that are reported by “EnumerateInputEventParams”? Or is that still one more than there should be?
Unfortunately, when implementing this multi-parameter Logic, I didn’t realize that FS20 and FS24 do this differently. As that logic made it into the release, I’m in quite a bit of trouble at the moment… 
Best regards
Oliver
Hello @LorbySI
Yes it should now return the correct amount and type of parameters.
So you are trying to have an implementation in your 2020 package that would also work when the package is mounted in 2024, right?
Regards,
Sylvain
Hello Sylvain,
no, I have an external SimConnect client that is supporting a multitude of sims (using compiler switches to build individual versions). My mistake was that I assumed that FS20 and FS24 would be the same regarding the handling of the InputEvent parameters over SimConnect - and they aren’t. I am currently trying to figure out how to future proof this for all four variants of MSFS (20/24/production/beta). It looks like the FS24 beta is still reporting one more parameter than there should be.
Best regards
Oliver
You are still checking the AS1000_PFD_1_COM_SWAP event?
I just checked it on 1.5.4.0 and SimConnect_EnumerateInputEventParams returns 2 FLOAT64 params, as expected.
Regards,
Sylvain
Hello Sylvain,
I’m scratching my head over a lot of them. Take “AS1000_RANGE_PFD” for example, from the default G1000 in the C172 (FS24). SimConnect says that it needs 3 parameters. No idea what the third one is for, because it also works with just 2 (the x and y coordinates from -1 to 1).
My problem is, that I have to translate this somehow so the end users can configure any IE they want to be operated with their external hardware. And I find that difficult when I myself don’t understand the logic
Never mind, I’ll manage somehow. Don’t waste too much time over this. Thank you that you looked into it!
Best regards
Oliver
Here is another weird example, this time in MSFS 2020 using the FSW Learjet 35A
“GENERIC_LEAR_BATT1” is reported as having 1 paramerter
“GENERIC_LEAR_BATT2” is reported as having 2 paramerters
They both work with just one.
This is most likely not a simulator issue but something the developer made. Nevertheless it is unnerving for the end user (and me )
Best regards
Oliver
The number of parameters returned in FS20 by EnumerateInputEventParams() was always wrong, AFAICT. I brought that up and asked about this whole issue way back when, but was ignored.
At least now there’s an explanation of how multiple params are supposed to be packed (which is kinda bizarre, honestly, just to add to how odd the whole InputEvent system is to use with SimConnect).
Using the equivalent B or F:InputEvent types in RPN and execute_calculator_code() (with FS24) seems much simpler. (Yeah I know.. that’s “deprecated” 
).
@FlyingRaccoon Thanks for this explanation of how it is actually supposed to work. Any chance this could make into the docs? They’re wrong on many levels…
https://docs.flightsimulator.com/msfs2024/flighting/html/6_Programming_APIs/SimConnect/API_Reference/InputEvents/SimConnect_SetInputEvent.htm
Says the value can be “Float/String”. Nothing about a struct or raw memory address.
https://docs.flightsimulator.com/msfs2024/flighting/html/6_Programming_APIs/SimConnect/API_Reference/InputEvents/SimConnect_EnumerateInputEventParams.htm
Example is comically simplified (and wrong)…
Then you would use the SetInputEvent function as follow:
unsigned char byteValues[2048] = "";
// Create your value
value = "<myFloatValueInBytes><myStringValueInBytes>;"
m_simConnectObject.SetInputEvent(<Hash>, value);
Thanks,
-Max
PS. One thing not clear yet… Let’s say the memory for value argument of SetInputEvent() is allocated dynamically. Is it safe to clear the memory right after SetInputEvent() call? Does that make a copy of the memory? Or, and I hope this isn’t the case, does the allocated value memory need to remain available for some time?
I’m not so sure that this is really the simulator’s fault. To me this looks more like an issue that the aircraft developers have to address. A good example is the FSW Learjet. There are some near identical IEs that have different # of parameter. Like GENERIC_LEAR_BAT1 and GENERIC_LEAR_BAT2, where BAT1 has only one parameter while BAT2 has two.
Yes, this is part of what I reviewed with the team and that part of the documentation will be partly rewritten.
You can deallocate it as soon as the SimConnect function returns.
Regards,
Sylvain
1 Like
I agree with @max.paperno on this, this is likely the SimConnect_EnumerateInputEventParams implementation that is at fault in MSFS 2020.
Are you using SDK 1.4.1 and version 1.5.4.0 of the sim?
Because this is not what I’m getting. I receive ;FLOAT64;FLOAT64
This is implementation specific and aircraft dependent.
For Asobo aircraft, as we often use our behavior templates, you can find those and see how the InputEvent is defined.
For example, in the case of the C172 AS1000_RANGE_PFD you can start by checking the corresponding section of the “Behaviors” tool.
This will display the number of parameters and will let you write it for debug purposes, to help understand what they control exactly and what values are expected
If you need to investigate deeper, you can dive into C:\MSFS 2024 SDK\ModelBehaviorDefs\Asobo\GlassCockpit\AS1000.xml to see what templates are used and find your way to the InputEvent definitions.
But for a 3rd party aircraft, especially if they create custom InputEvents, unless they document it themselves, there’s not much you can do I’m afraid.
If available, the Behaviors tool can still help you get some information and test the InputEvent though.
Regards,
Sylvain
Hello @LorbySI
Can we consider this fixed?
Regards,
Sylvain
Hello @FlyingRaccoon,
I haven’t received any more support requests concerning this. I’ve added a bit of logic to AAO, so users can now call IEs with multiple parameters. From my point of view that’s either fixed or can be worked around (resorting to BVars)
Best regards
Oliver
1 Like
