I recently watched a video on Youtube by a fellow simmer named Russ Barlow. I believe Barlow is a retired real-life pilot so his observations are worth consideration. Barlow was big on the Knobster but that involves an investment and plus the new MSFS 2020 doesn’t come fully equipped to work with that type setup. He too has been talking about the need to address the knob adjustment issue. The idea as mentioned in various ways here is to somehow fix the interaction with the knob in the cockpit. Many of the ideas are great but many tend to just treat the symptom working around the current technology so I want to think out-of-the-box and reinvent it (it’s a Wishlist thing). The real fix is to design a new method of controlling the knobs inside the coding of the simulator and permanently fix this, if practical, difficult or not it needs help. Reading this thread most of the problems of dealing with a knob are well documented from the point of interaction from a computer standpoint, not as in real-life. As an example,
Shaking - I’m a licensed pilot. Except on the smoothest of air do you get to reach over and grab a knob without issue, especially in GA aircraft. In the roughest air you’ll fight to get your hand on a knob when getting tossed like a salad. I have flown in mountain terrain with air so rough my plane was pointed nearly 50 degrees from the path of travel and altitude changes +/- a 1000 feet at a whack. That’s bad enough besides trying to put my hand on a knob. That’s real. So, I wouldn’t want to diminish that experience in the sim. No extra windows and no extra investment, we just need a way to simulate grabbing the knob and adjusting it. That brings us to this…
The difference between grabbing a knob physically (real-life) and virtually (in the sim) – I’ve been flying computer sims since the beginning, literally. When you get all your peripherals setup correctly, usually what is left for the mouse to do can be done with minimal frustration, except for those knobs. I believe most would agree using the mouse for cockpit interaction or making view adjustments isn’t overly frustrating, it’s just dealing with knobs. Of course, as coded we are forced to use them as is or learn some feasible work around but it would be far better if we talk about making it do what we need it to do and then making it happen, fixing the issue once and for all until something better comes along. We’ll need the help of the developers to listen to the ideas. So, let me add another “what if”. This is similar to posts above but I’ll take it a bit further. What if you could code the knobs to recognize the mouse like this… It is the right idea to “lock” the cursor to the knob when an action (adjustment) is required. How to go about that is the trick. If I point the cursor at a knob and then start “turning” that knob, then an action (adjustment) is requested on a specific knob. That is the time to “lock” the mouse to that “function” so even if the cursor leaves the spot on the display designated for that knob (from shaking) the action continues until the adjustment stops, recognized after a specific delay. The spot doesn’t follow the mouse, the function is simply “locked” until a set delay is exceeded AFTER the pilot stops making the adjustment. The logic in coding can be designed to work in this manner. So, you need a delay built in. Maybe 2 seconds of inaction before the cursor is released from that adjustment. As long as the pilot is adjusting the knob the action stays “locked” to that “function” even if the cursor leaves the spot that allows the action to be initiated. So, even if there is shaking, I only need to get my cursor on the spot (a knob) once to start the action. That shouldn’t be too difficult.
Adjustment speed – The other issue is, after initiating the adjustment, being able to quickly adjust the knob in a timely manner. Currently I have to spin the wheel on my mouse like a mad man. It doesn’t happen fast enough. In some coding constant, quick adjustments allow the instrument bug to move faster as the adjustment is made but not all do this, it has to be coded that way. But why am I required to spin a mouse wheel at all, why can I not just simply press a button to simulate spinning the knob? For instance, I typically have 2 buttons for each critical instrument adjustment programmed into my USB keypads I use with my simulators. In MSFS 2020 I use the key commands to INC (increase) and DEC (decrease) the instrument “bugs” for Altitude, Airspeed, Vertical Speed, Directional Gyro…you get the idea. When I press these buttons, unlike my mouse wheel the adjustments are extremely quick and accurate. Now notice, INC/DEC is the key here. That equates also to CW or CCW respectively. Or in the case of an instrument “tape” INC/DEC of the setting. After the mouse button is “locked” to change the setting why can I not simply use the left mouse button for CCW or DEC and the right mouse button for CW or INC just like I do my two designated keypad buttons? This would be intuitive to use in this manner. And remember, as long as I’m pressing one of the mice buttons the adjustment is “locked” until inaction is sensed and releases it, again maybe just a second or two. It would even be nice if a delay “range” could be set to our preference. Pressing either the left or right mouse button would be 200% better than trying to spin that mouse wheel like a mad man. And remember, since the action is “locked” it doesn’t matter where the cursor is on the screen, I don’t have to be looking at it, leaving me free to look out the window and fly while my fingers keep a button pressed making the adjustment with merely a glance at the instrument to get it set correctly. This is much more intuitive.
Finally, pressing a knob – Instrument knobs can sometimes be pressed as when synchronizing the heading bug. Assign this to the center mouse button (the wheel button), forget spinning the wheel. This would also be intuitive and help prevent accidentally pressing the knob while trying to rapidly spinning it.
This kind of coding would permanently solve the issue leaving the reality of shaking the cockpit in place. Just more food for thought.
I personally use sim rate to slow down time. because what I can naturally do in real life, it takes just as long using the mouse with slowed down time.
A finger and thumb, takes a few seconds between clicks to update a whole code. In the sim, it’s a bugbear.
so yea, “bullet time” when dealing with the garmin.
This issue will only get worse with VR. Does anyone know how the VR Beta handles “knob twiddling”?
I think it was X-Plane + Knobster which had a small popup menu where you selected the control to be used, then the hardware encoder was used to adjust.
It seems to be like a 2 step approach like this would work well. Click to lock onto a control (with popup if more than one control occupies the same space), then twiddle the mouse wheel, then click again to release the mouse.
I’ve noticed on the Controls setting page there are options for “Cockpit interaction” which sounds like it supports a generic button to control all kinds of cockpit elements, but I can’t get it to do anything.
Do you think the section [DynamicHeadMovement] in the file “FlightSimulator.CFG” is usefull to manipulate and stop the headmovement to solve this issue?
Please provide a “sticky” mouse feature, where the mouse pointer sticks to a control regardless of turbulence or head panning. This would make cockpit interactions much more robust.
If the mouse pointer is hovering over a interactable control, it should stick there regardless or turbulence or head panning. This would require user focus only for the initial selection of a control (similar to real life, once you touch it you sort of hold onto it in turbulence), and it could be used easily while looking around.
Alternatively, the “mouse” cursor could simply be relative to the 3D cockpit, essentially mimicking 2D movement over the surfaces (however this may be more trouble).
Simply forcing the mouse cursor to move based on the position of a currently selected control on screen would make cockpit interactions less burdensome when look around or in heavy “head shake” turbulence. You already seem to know the screen location of the control, so just add an option to move the mouse as it potentially moves.
Zoom is not really the same… it’s currently bound to the same input (rotate knob and zoom), which is another problem on it’s own. But if you pan around (to for example looks outside quickly or at something else), panning back, your mouse will inevitable be in a different place. This request is not about making the button bigger (which zoom fixes), but about being able to “stick” to a control even while panning and there’s motion, until some deliberate mouse movement unsticks it. This even more useful with TrackIR. Vaguely:
On mouse move (e.g. while there’s motion) if it enters a control area, consider it captured
If there’s control translation (turbulence, panning etc.), and it has captured the mouse, translate the mouse cursor with it
While capture, mouse movement is relative to the controle, but as soon as the user moves the mouse enough (e.g. off the control), release (un-capture) it
I’m sure it needs some experimenting, tweaking, but #1 ensures that controls are not captures during a pan, but only on actual mouse events. This could be an option in settings (maybe Accessibility), for those that prefer the zoom or standard interaction.
I know. Sticky mouse would be great. I asked for it a year ago during the tech alfa. Above I was answering to the problem with turning a knob causing zoom.
Maybe check out the ‘Cockpit Interaction’ control mappings, as they effectively provide, perhaps not perfectly yet, what the OP is asking for.
I set my Middle Mouse button to select the primary control and my mouse wheel to increment and decrement the selected control and it appears to work pretty well.
However, if you move your head too much from where it was when you selected the control, it does stop the inc/dec actions working, but that comes back when you move your head back to where it was. Also, using the right mouse button to zoom in on a panel will apparently deselect the primary control.
I’ve yet to try figure out how the secondary and tertiary controls work, but this definitely seems to provide the “sticky keys” we were looking for.
As for how long it’s been available, I can’t say, but I haven’t seen anything in any patch notes, so it might have been there from the start???
