Hi,

Noesis only responds to the input provided by the integration layer, it doesn't interact with the operating system, so all the key downs and ups should be provided by the MonoGame wrapper.
Could it be a problem that appears when you deactivate the window and come back? Or does it happen without changing the foreground window?
Is there a way to easily reproduce it in your game that I can try?

Alas, there is no easy way to reproduce it. I'm looking to find a way and yes, probably you're right as this might be affected by the integration layer. Though I've checked it several times. I will add extra logging to find out whether the modified key was actually sent as released to NoesisGUI or not, then I will know for sure whether it's wrapper or NoesisGUI issue.

I believe it's related to the usage of Alt+Tab.

Turns out the issue 0001503 ("Click on the currently selected listbox item will deselect it") is related to it. My Ctrl key for NoesisGUI was assumed to be held so every time I clicked on an entry in a list box it was deselected as NoesisGUI processed it as Ctrl+Click.

Regards!

Hi guys,

the issue is bothering us and our players a lot.
It's Ctrl key getting stuck sometimes. So pressing A key will perform Ctrl+A (select all). Pressing any other key after that will replace the selected text which is really frustrating.

It's absolutely random. But happens very often to some players who are using the chat a lot. Pressing the Ctrl key several times usually resolves it.

I've added logging to verify that the Ctrl key is definitely released when that issue happens—and it looks like the "key up" was sent to NoesisGUI properly by our wrapper.
So I believe there is something wrong inside NoesisGUI...
Do you have similar issues reported by other developers? Or other developers barely using in-game chat so this issue just has very little chance to occur there?

Regards!

Reviewing our code I can only identify two scenarios where control key could be kept as pressed.

• If the View receives a KeyDown for the LeftCtrl key, and a KeyUp for the RightCtrl key. As they are different phisycal keys, but both report Ctrl modifier as down, it could lead to the situation explained.
• If KeyDown was sent to the View for LeftCtrl (or RightCtrl), then Alt+Tab or click in other application without calling Deactivate on the View, and come back to the game after releasing the Ctrl key.

Is it possible that any of that is happening in your situation?
Is this something I can try to reproduce with the latest game build you sent? Just typing in the chat box and pressing Ctrl sometimes?

If you need it I can generate a debug library with some logs to determine when our internal key state gets out of sync.

Hi Sergio,
thank you for the message. I was mostly interested if you have any other developers complaining about this issue. It seems we're alone with it! :-) Didn't want to waste your time, sorry!

I've prepared a special client build with extra logging and made it public in Steam (patch-testing branch). Selected players started using it. I've instructed them to press Alt+F4 as soon as they notice the Ctrl key getting stuck in any textbox (usually, chat, but also the game console). The log will contain info about the KeyDown/KeyUp events sent to NoesisGUI as well as the cases when the input is ignored (there are several cases related to IME processing; I've also noticed there was a workaround for old bug #1270 that is long-ago fixed so the workaround is no longer necessary!). I will let you know when I get more data from players. I hope it's an issue in my wrapper code after all!

Anyway:
1) It's unlikely that players are using the Right Ctrl at all. I never use it and the issue still happened to me.
2) If the game window is not focused, the game recognizes this as "empty input" so if there was a key held before Alt-Tab, it's released immediately. This is a simple and effective solution. When the game window focused again the game reads the current input state and provides it to NoesisGUI key down events (if there are any keys pressed).
To get current input state we're using this PInvoke call (through MonoGame Keyboard API):
[DllImport("user32.dll")]
private static extern bool GetKeyboardState(byte[] lpKeyState);

Regards!

Sorry to say we don't have any other report about this issue, but it could still be a bug in our side. Let's see if we can get more information and find the source of the problem.

I downloaded CryoFall demo from steam and switched to the patch-testing branch, but it seems no Data or Log folder is created. Maybe this only works for the full version of the game?

The Steam version is using Documents/AtomicTorchStudio or %LocalAppDats%/AtomicTorchStudio folder for thr dynamic data.

I don't get this issue reports for a day. It might have been that old workaround that caused wrapper to not send KeyUp sometimes.

Hi Sergio,
today we're pushing the new game build with an updated wrapper code (that doesn't contain the workaround for #1270 that stayed for too long and likely caused this key stuck issue before).
If the issue is not reproducible by anyone after that we can consider it fixed.

Regards!

The issue is definitely fixed.
It was a wrapper code issue after all.
It was really important to carefully record all the key down events to ensure the key up events will be submitted to NoesisGUI for these keys no matter what :)

Regards!

Thanks for the update, we're closing this then.