Version: 1.4.14.0
Frequency: Consistently
Severity: High
Marketplace package name: N/A
Context: SimConnect API
Similar MSFS 2020 issue: N/A, but same occurs in 2020
Bug description:
The ZOOM_IN (or ZOOM_PLUS) and ZOOM_OUT (or ZOOM_MINUS) sim events cause the camera eyepoint to move up and down, instead of zooming in and out. Huh???
Repro steps:
Hello @SkyWare
Can you please tell us in which camera context you are when sending those events?
You can screenshot the information displayed with the Debug->Aircraft->Camera Blend debug enabled
Regards,
Sylvain
Cockpit camera. I’ve made a recording, and alternated between sending ZOOM_PLUS and ZOOM_MINUS events.
Sending the same events from the external camera has no effect whatsoever.
Hello @SkyWare
That’s very surprising.
Reading the code, these events seem inherited from FSX and were never connected to our camera system.
The expected behavior is that these events simply do not trigger anything, which is the behavior I observe when testing this myself.
How are you sending them using SimConnect?
Do you use SimConnect_MapInputEventToClientEvent by any chance?
The only explanation I could see so far is that, using this function, you map these events using input keys that are already mapped to the move up/down controls in the game control settings.
Also make sure that you don’t have any package or app that could interfere with input behaviors?
Let me know if that’s a valid explanation of if you can share a SimConnect snippet.
Regards,
Sylvain
You know what? You’re right. MSFS behaves differently than FSX/P3D when it comes to detecting keyboard inputs. I was using CTRL+SHIFT+Q and CTRL+SHIFT+E to trigger sending the ZOOM events.
I had checked (and double checked) that both of these did not have any other commands mapped to them.
However, what I just discovered is that anything that is mapped to CTRL+Q or SHIFT+Q will ALSO get triggered when I press CTRL+SHIFT+Q! (and to be clear, I am pressing CTRL, then SHIFT, then Q).
Personally, I find that to be a bug. If I am pressing CTRL+SHIFT+Q, I only expect things that are mapped EXACTLY to that to be triggered. And, this is how FSX/P3D works (and many other games, by the way!!!)
Hi @SkyWare -
this issue with keys mapped to different versions of modifiers has been reported many times (I do recall specifically one from @Umberto67).
I don’t recall it was ever resolved…
Hello @SkyWare and my apologies for the late reply.
Good finding, there is indeed a problem here.
When you use a combination of inputs and the sim cannot find a perfect match in the controls, it will search for sub combinations of those inputs to trigger.
There is a good reason for this, some devices will have inputs active 100% of the time.
For example, some knobs will continuously trigger the corresponding event when set into the ON position.
So unless a perfect match is found, sub combinations are tested.
The issue here is that this process does not take inputs from SimConnect into account, so when you press CTRL+SHIFT+Q, the sim will consider no match was found.
We will fix this.
Regards,
Sylvain
Great, thank you Sylvain!
I’ve NEVER understood why there is a need for knobs or buttons to repeat their event continuously. It floods simconnect events, to say the least, and also causes other problems. Example: The Honeycomb Bravo has a button which by default is assigned to AVIONICS MASTER OFF - this is sent multiple times a second and, even if our aircraft chooses to ignore it, causes ALL radios to be OFF without any ability for us to overcome the problem. Our users therefore start complaining that they have no VORs or ILSs as the sim will happily keep turning them off even though our code DEFINITELY instructs it to turn them back on. It becomes a fight that the sim wins, because we can’t override the event even.
Ideas?
Hello @SkyWare
This should no longer be a problem in SU4 beta.
Please check and tell us if this is good for you.
Regards,
Sylvain
@FlyingRaccoon Confirmed fixed in SU4 beta. Thanks Sylvain!
