GSX 3.6.8 editor shift key sticking or not recognized

[w6kd]

When doing parking spot customizations in GSX 3.6.8, GSX is sometimes not recognizing the shift key, and sometimes it's sticking.  IOW, the edited object position movements should be coarse with the shift key down, and fine when it's not, but now the resolution you get is intermittent and does not correspond to the shift key position.  I've restarted couatl, rebooted...still broken and repeatable.

This is in MSFS 2020.

[Aussie123]

Strange?

Mine is working as a Toggle, as per the Release Notes: Press once for fast, press once for slow.

Version 3.6.8 – August 11th, 2025

GSX Pro Change: The Shift key in all editors (Parking, QuickEdit and Airplane) now behaves like a toggle, to prevent problems caused by a Simconnect bug in MSFS calling back twice when subscribing to both Shifted and Unshifted key events. Now, pressing the Shift key will alternate between FAST and SLOW cursor Move/Rotate/Raise, so it’s no longer required to keep it pressed to move FAST.
GSX Pro Change: The editor keys to Raise/Lower objects (VGDS or Pax Waypoints) have been changed to PgUP and PgDN, replacing the previous Q/Z keys, to prevent conflicts with the default keys used by the MSFS Showcase camera.
GSX Pro Change: Manual updated to explain the changes to the editor keys behavior.

Aussie

[davidcherrie]

Can this be changed back or given the option for it to remain like a shift key rather than caps lock? This has significantly slowed down UX by constantly being on wrong speed for adjustments.

[virtuali]

The key change is correct and cannot change back as it was, because of a weird bug in MSFS Simconnect we just found out, after users reported GSX froze when editing a custom pushback route.

When you subscribe for a certain key event, there's no way to differentiate between a Shifted and a non-Shifted version so, for example, if you subscribe to Shift-Up and just Up, if you press "just" Shift-Up, your code will be called TWICE with two Simconnect calls happening at the same time, so not only you don't know which event happened (both happened, from MSFS point of view), but the simultaneous call would cause threading issues, because pointers would had to be removed/deleted so quickly that their own Simconnect calls would mix up.

So, the only possible fix was to change the Shift behavior to be a Toggle, solving all reported issues of GSX locking-

[davidcherrie]

It was working fine before though... Why not add the option that users can toggle it back on and give a warning that it may have some SimConnect issues when editing a custom pushback route?

[virtuali]

It was working fine before though... Why not add the option that users can toggle it back on and give a warning that it may have some SimConnect issues when editing a custom pushback route?

It might have worked with a previous version of the sim, now it won't work for the reason I explained, and it wasn't just a "Simconnect issue": the error would made using the QuickEdit function (arguably one of the most useful in GSX ) impossible with the Shift key, causing the program to freeze. It was reported by several users, and it had to be fixed.

[davidcherrie]

Then why not instead have two buttons to select the speed, faster or slow? The shift button is not a toggle button in any UX environment.

[virtuali]

Then why not instead have two buttons to select the speed, faster or slow?

Because for the same reason as above (not possible to "steal" keys momentarily), we try to use the least amount of keys possible, to minimize conflict with the sim own functions and other add-ons.

The shift button is not a toggle button in any UX environment.

Except in the best selling game of all times, Minecraft, where Shift act as a toggle for Fast/Slow walking speeds. Of course, since Minecraft is a stand-alone game in full control of how the key inputs work (instead of an add-on like GSX which is limited by what MSFS allows to do), you can go in the settings, and configure it as a Toggle (default, like GSX is now) or Hold (like GSX used to be).

[davidcherrie]

Actually Minecraft default is a hold. It's in the accessibility settings to change it to be a toggle like almost every game so accessibility users who aren't able to hold down keys to run, crouch etc don't have to hold the buttons.

Anyway, so you are saying that it is impossible to return it to the old settings of hold because of SU3? Or because some users experienced crashes?